Можно ли спроектировать SOA с помощью REST?

В последнее время я много читал о SOA, но большая часть контента связана с SOAP и имеет много "бюрократических" вещей, которые принадлежат системам С#/Java. Честно говоря, я считаю, что такая бюрократия, особенно SOAP, является болью в заднице. Итак, мне любопытно, может ли SOA быть спроектирована с REST?

Прямо сейчас в приложениях Ruby я делаю все мои контроллеры RESTful. Мой веб-интерфейс (формы и т.д.) Делает запросы GET/POST/PUT/DELETE в ядро, которое является веб-сервисом REST. Все остальные системы, использующие ядро, запрашивают RESTful. Является ли это SOA?

ОТВЕТЫ

Ответ 1

На высоком уровне ответ Да, однако не полностью.

SOA требует думать о системе в терминах

  • Услуги (четко определенные бизнес-функции)
  • Компоненты (отдельные фрагменты кода и/или структуры данных)
  • Процессы (Сервисные оркестровки. Обычно используются BPEL)

Возможность создавать новые сервисы более высокого уровня или бизнес-процессы является основной особенностью хорошего SOA. XML, веб-службы, основанные на SOAP, и соответствующие стандарты хорошо подходят для реализации SOA.

Также у SOA есть несколько принятых принципов - http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles

  • Стандартизованный контракт на обслуживание - Сервисы придерживаются соглашения об обмене данными, которое определяется совместно одним или несколькими документами описания услуг.
  • Служба Loose Coupling - Сервисы поддерживают отношения, которые минимизируют зависимости и требуют только того, чтобы они поддерживали понимание друг друга.
  • Абстракция сервиса. Помимо описаний в контракте на обслуживание, службы скрывают логику из внешнего мира.
  • Повторное использование сервиса. Логика разделена на службы с целью поощрения повторного использования.
  • Автономия службы. Службы контролируют логику, которую они инкапсулируют.
  • Гранулярность сервисов. Рассмотрение дизайна для обеспечения оптимального объема и правильного детализации бизнес-функциональности в сервисной операции.
  • Служба безгражданства - Сервисы минимизируют потребление ресурсов, откладывая управление информацией о состоянии в случае необходимости
  • Обнаружение служб - Сервисы дополняются коммуникативными метаданными, с помощью которых они могут быть эффективно обнаружены и интерпретированы.
  • Сервисная способность - услуги - эффективные участники композиции, независимо от размера и сложности композиции.

Ожидается, что архитектура на основе SOA будет иметь Service Definition. Поскольку веб-службам RESTful не хватает окончательного определения службы (аналогично wsdl), для системы, основанной на REST, сложно выполнить большинство вышеуказанных принципов.

Чтобы достичь этого, используя REST, вам нужно иметь RESTful Web Services + Orchestration (возможно, используя некоторый легкий ESB, такой как MuleESB или Camel)

Также смотрите этот ресурс - От SOA до REST

Добавление этой части в качестве пояснения для следующего комментария -

Для составления процессов требуется оркестровка. Это то, что обеспечивает основное преимущество SOA.

Скажите, что у вас есть приложение для обработки заказов с такими операциями, как  -

  • addItem
  • addTax
  • calculateTotal
  • PlaceOrder

Сначала вы создали процесс (используя BPEL), который последовательно использует эти операции. У вас есть клиенты, которые используют эту составную услугу. Через несколько месяцев появляется новый клиент, у которого есть освобождение от налогов, вместо того, чтобы писать новую услугу, вы можете просто создать новый процесс, пропустив операцию addTax. Таким образом, вы могли бы быстрее реализовать бизнес-функции, просто повторно используя существующий сервис. На практике существует несколько таких услуг.

Таким образом, технология BPEL или аналогичная (ESB или маршрутизация) необходима для SOA. Без использования бизнеса SOA на самом деле не является SOA.

Перекресток, опубликованный в моем личном блоге - http://blog.padmarag.com

Также проверьте этот новый ресурс, с которым я столкнулся - SOA на основе REST

Ответ 2

Служба в терминах SOA - это компонент, который решает определенную деловую проблему. SOAP/WCF больше связаны с интерфейсом/частью доставки SOA. Также может использоваться подход REST. Сервисный контракт, политика, управление версиями и другие "стандартные" функции SOA также могут быть реализованы с помощью службы RESTful.

Основная проблема RESTful заключается в том, что она нацелена на CRUD, поэтому это был бы не лучший выбор для реализации сложной логики. Но если ваша бизнес-логика полностью CRUD (или сходится к CRUD), тогда все должно быть в порядке.

Btw, похоже, что Microsoft добавила операции в службы передачи данных WCF специально для эмуляции SOAP с помощью REST.

Ответ 3

Самая важная вещь в SOA - это мягкие факторы, например, заставить других людей использовать ваши услуги, а наоборот, с этой связью wsdl, из которой вы можете создать простой в использовании прокси, является почти эссенциальным. Услуги должны быть сложными.. но вам НЕ нужна Orchestration, BPEL или модный автобус, чтобы сделать это, и я бы не рекомендовал их, когда вы начинаете с SOA. (фактически, используя эти, я думаю, что вы можете добиться лучших результатов без них, но вам нужны события)

Обратите внимание, что такие продукты, как WCF, позволяют создавать службу, которая предоставляет wsdl, но помимо SOAP вы также можете использовать REST/Json или даже лучшие двоичные конечные точки TCP. Это идеально, поскольку вы используете SOAP для простоты и переключаетесь на двоичные (который удаляет REST из воды), когда вам нужно.

Насколько SOAP идет через 8 лет создания высокопроизводительных SOA-систем с WCF, я никогда не замечал, что SOAP был даже там.. Это потому, что я в основном работаю на С#, и у нас хороший SOAP-стек. Большинство других языков нет.