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

Question

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

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

Answer 1

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

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

• Services (четко определенные бизнес-функции)
• компоненты (дискретные куски кода и/или структур данных)
• процессов (Service оркестровки. Как правило, с использованием BPEL)

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

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

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

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

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

Также см этот ресурс - From SOA to REST

---

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

Для составления процессов требуется оркестровка. Именно это обеспечивает основную выгоду SOA.

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

• AddItem
• addTax
• calculateTotal
• PlaceOrder

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

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

Cross размещен на моем персональном блоге - http://blog.padmarag.com

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

Answer 2

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

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

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

Answer 3

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

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

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