Ответ 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