Многоуровневая SOA

В заметке рассмотрена многоуровневая сервисно-ориентированная архитектура и ее отображение на технологическую платформу Oracle SOA Suite.

В типичной сервисно-ориентированной архитектуре на предприятии можно выделить пять основных слоев:

1. Пользовательский интерфейс (User Interface).
   
   
2. Бизнес-процессы (Business Processes).
   
   
3. Бизнес-сервисы (Business Services).
   
   
4. Виртуальные сервисы (Virtual Services).
   
   
5. Сервисы приложений (Application Services).

Иногда разумно добавить еще один слой - второй слой виртуальных сервисов между уровнем бизнес-процессов и пользовательским интерфейсом. Его цель: интеграция сервисов нашей организации и сервисов сторонних организаций или отделов. Получается следующая картина:

1. Пользовательский интерфейс (User Interface).
   
   
2. [Виртуальные сервисы].
   
   
3. Бизнес-процессы (Business Processes).
   
   
4. Бизнес-сервисы (Business Services).
   
   
5. Виртуальные сервисы (Virtual Services).
   
   
6. Сервисы приложений (Application Services).

Рассмотрим данные слои подробнее, снизу-вверх.


Сервисы приложений. Разработаны для удовлетворения специфических требований. Могут быть композитными и охватывать бизнес-область или функциональную логику. Обычно недоступны конечным пользователям напрямую. Зачастую реализуются с помощью т.н. пакетных (SAP, Siebel, PeopleSoft, OEBS) или кастомных (разработанных на Java, C#, PL/SQL или с помощью других технологий) приложений.

Виртуальные сервисы. Необходимы для снижения связности между потребителями сервисов и их провайдерами, что ведет к снижению затрат на поддержку, т.к. облегчает процесс внесения изменений.

Это производится за счет двух действий:

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

Бизнес-сервисы. Реализуют бизнес-логику, доступную через разработанный контракт сервиса. Заменяют формат сервиса на общий, канонический формат. Сервисы подразделяются на категории по типу реализуемой функциональности либо по типу возможных клиентов.

Функциональные типы:

• Сервисы сущностей (Entity Services, Data Services). Эмулируют бизнес-объекты компании).
  
  
• Функциональные сервисы. Используются для реализации "голой" бизнес-логики, например, бизнес-правил, алгоритмов вычисления цен и т.д. Обычно не используют сервисы сущностей (за редким исключением), вместо этого создаются основанные на задачах сервисы, включающие в себя функциональную логику.
  
  
• Сервисы, основанные на задачах. Специфичные множества связанных активностей, часто исполняющихся в контексте бизнес-процесса. Обычно строятся через один или несколько сервисов-сущностей, и могут использовать другие, основанные на задачах, и функциональные сервисы.

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

Варианты:

• другой бизнес-сервис;
  
  
• бизнес-процесс;
  
  
• внешний потребитель (UI слой, партнер и т.д.).

Иные требования к сервисам:

• безопасность;
  
  
• управляемость;
  
  
• поддержка;
  
  
• управление изменениями;
  
  
• валидация.

Бизнес-процессы. С точки зрения потребителя - это лишь специфичный бизнес-сервис. Бизнес-процесс ориентирован на изменения, это - некая вещь, соединяющая системы по принципу точка-точка для достижения определенных целей. Еще важно: обычно сервисы не сохраняют и не зависят от состояния (stateless), бизнес-процессы же сохраняют и зависят от состояния (statefull), они должны хранить состояние днями, неделями, иногда месяцами и годами.

Пользовательский интерфейс. В терминах MVC выглядит следующим образом:

• Модель - бизнес-процесс или бизнес-сервис;
  
  
• Вид и контроллер - фреймворк, предназначенный для построения графического пользовательского интерфейса, например Eclipse RCP или Oracle ADF.
  

Отображение архитектуры на технологическую платформу Oracle SOA Suite

Упрощенно сервис-ориентированную архитектуру предприятия, реализованную на платформе Oracle, можно представить состоящей из трех основных компонентов:

• Интегрируемые приложения.
  
  
• Композитные приложения, реализованные с помощью SCA-контейнера Oracle SOA Suite.
  
  
• Oracle Service Bus (OSB).

Отображение архитектуры на технологическую платформу SCA-контейнера:

• Уровень сервисов приложений: Oracle Application Adapters.
  
  
• Уровень виртуальных сервисов: Mediator.
  
  
• Уровень бизнес-сервисов: BPEL, Human-Workflow, Business Rules, ADF Business Components (ADF BC).
  
  
• Уровень бизнес-процессов: BPEL, Business Rules.

Подходы к реализации многоуровневой сервис-ориентированной архитектуры с помощью SCA-контейнера:

• Все уровни в одном композите.
  
  
• Каждый сервис в своем композите.
  
  
• Промежуточный вариант.

Алгоритм принятия решения о размещении сервиса в композите следующий. Прежде всего нужно выделить ключевые бизнес-процессы и сервисы, определить их контракты. Это будет стартовой точкой для определения степени детализации (granularity). Каждый бизнес-процесс и сервис будет определен как единый композит. Как только начинаем строить композит - определяем другие сервисы, которые ему требуются. Для каждого такого дополнительного сервиса определяем нужно ли вынести его в отдельный композит или оставить в существующем. Ключевые критерии для выбора: необходимость обеспечения повторного использования, жизненный цикл и операционное управление композитом. Производительность здесь менее важна, т.к. все композиты исполняются в рамках одной среды и вызовы между ними будут оптимизированы.

Паттерны проектирования композитов

Существуют следующие зарекомендовавшие себя приемы проектирования композитов:

1. Разработка "от контракта" (сверху-вниз) - сначала определяем контракт, затем используем его как стартовую точку для разработки композита.
   
   
2. Mediator как точка входа в композит. Данный прием обладает следующими преимуществами:
   - настройка безопасности и управление политиками;
   - валидация XML-синтаксиса каждого запроса;
   - дополнительная валидация с использованием Schematron;
   - абстрагирование от структуры композита - можно менять реализацию, не меняя интерфейса.
   
   Однако в данном случае сложнее управлять транзакциями.
   
   
3. Mediator как прокси ко внешним сервисам (медиатор на выходе композита).
   Данное решение удобно, если внешние сервисы не используют каноническую модель, используемую внутри композита.
   

Несколько слов про реализацию слоя виртуальных сервисов

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

Материал написан на основе главы 10 книги SOA Suite 11g R1 Developer's Guide. Рисунок взят так же из данной книги.

Понравилось сообщение - подпишитесь на блог и Twitter