Знакомимся: Компонентная архитектура сервисов - Service Component Architecture (SCA)

Компонентная архитектура сервисов (SCA) - это множество спецификаций, описывающих модель построения приложений и систем с использованием сервис-ориентированной архитектуры (SOA). SCA расширяет и дополняет предыдущие методы реализации сервисов и основывается на открытых стандартах, таких как веб-сервисы.

По-сути, SCA обеспечивает программную модель для реализации SOA.

Спецификация состоит из двух основных частей, описывающих методы

1. Реализации компонентов, предоставляющих одни и использующих другие сервисы.
   
   
2. Объединения множества компонентов для построения бизнес-приложений путем связывания сервисов и сервисных ссылок (service references).
   
   

Разработчиком спецификации является консорциум Open SOA Collaboration (www.osoa.org). Текущая версия спецификации - 1.0 от 21 марта 2007 г. Некоторые части спецификации приняты позднее, например SCA Assembly Extensions for Event Processing and Pub/Sub V1.00 - 30 апреля 2009 г. Существует черновик версии 1.1, выпущенный 31 мая 2011. Несмотря на то, что это - черновик, он уже поддерживается Oracle.

SCA подчеркивает независимость способа реализации и объединения сервисов от возможностей инфраструктуры и используемых методов доступа. Компоненты SCA обслуживают бизнес-уровень и используют минимум API промежуточного слоя.

Библиотеки, необходимые для сборки и развертывания OSB и SOA Suite проектов

Одной из популярных сегодня техник создания программного обеспечения является непрерывная интеграция. При внедрении данного процесса при разработке сервисной шины предприятия, основанной на Oracle Service Bus (OSB) или Oracle SOA Suite, требуется решить две задачи:

• обеспечить сборку проектов OSB и SCA-композитов SOA Suite;
  
  
• обеспечить развертывание собранных компонентов на сервере приложений Oracle WebLogic.

В сети представлено много материалов, описывающих автоматизацию этих задач. Рекомендую статью Станислава Девятова Непрерывная интеграция для Oracle SOA Suite 11g. В данной же заметке хочется рассмотреть вопрос минимизации количества необходимых библиотек.

Несколько слов в защиту шаблона "Анемичная модель предметной области" (Anemic Domain Model)

Мартином Фаулером в его классическом труде "Шаблоны корпоративных приложений" (Patterns of enterprise application architecture) выделено несколько подходов к организации бизнес-логики.

1. Транзакционный сценарий - бизнес-логика разбивается на процедуры, каждая из которых соответствует конкретному запросу, поступающему от слоя представления.
   
   
2. Табличный модуль - бизнес-логика как и в предыдущем варианте описывается в процедурном стиле, однако манипуляции с каждой таблицей выносятся в отдельный класс, что делает код более структурированным.
   
   
3. Модель предметной области - самый сложный для реализации подход, однако имеющий ряд преимуществ при описании сложной логики. Суть заключается в том, что выделяются объекты, соответствующие объектам предметной области. Описываются отношения между данными объектами, соответствующие отношениям между объектами реального мира. При этом решение технологических вопросов, таких как хранение, безопасность, управление транзакциями как правило выносится за пределы слоя бизнес-логики.
   
   Выделяют два варианта данного подхода:
   
   
   • Насыщенная модель предметной области - данные и поведение инкапсулируются внутри объектов предметной области.
     
     
   • Анемичная модель предметной области - в объектах предметной области инкапсулируются только данные, поведение же выносится в слой сервисов, расположенный поверх слоя предметной области.
   
   

Если выбор между тем какой шаблон - транзакционный сценарий, табличный модуль или доменную модель - использовать как правило не вызывает проблем, т.к. критерии их применимости четко описаны в первоисточнике, то ответ на вопрос использовать или нет анемичную модель предметной области не так очевиден. С одной стороны теоретики объектно-ориентированного подхода считают данный шаблон "антипаттерном", с другой стороны он завоевал определенную популярность в практике разработки корпоративных приложений, что свидетельствует о наличии некоторых преимуществ. Давайте постараемся разобраться в данном вопросе.