интеграционное решение на основе сервис

СБОРНИК НАУЧНЫХ ТРУДОВ НГТУ. – 2009. – № 2(56). – 103–108
УДК 532.783
ИНТЕГРАЦИОННОЕ РЕШЕНИЕ НА ОСНОВЕ СЕРВИС ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ
Д.В. ПРЫТКОВ
Рассмотрены возможности сервис-ориентированной архитектуры. Приведена общая
схема интеграционного решения на основе продукта Oracle SOA Suite. Описаны ключевые интеграционные компоненты и их связь с соответствующими программными продуктами. Приведены рекомендации, помогающие сделать выбор между ESB и BPEL
для реализации определенных сервисов.
ВВЕДЕНИЕ
Внесение изменений в информационные системы (ИС) всегда сопряжено
с затратами. Делая выбор в пользу того или иного программного обеспечения
(ПО), потребители учитывали и наличие в нем функционала, позволяющего
наилучшим образом решать повседневные задачи. В условиях современного
бизнеса столь ограниченный подход неприемлем. Совершенно очевидно, что
потребность в адаптации ИС к изменяющимся потребностям бизнеса будет
постоянно возрастать. Использование сервис-ориентированной архитектуры
(Service-Oriented Architecture, SOA) позволяет адекватно реагировать на меняющиеся требования. В программном коде каждого приложения очень трудно отразить бизнес-правила, относящиеся ко всей ИС. Зачастую используемые
компаниями технологии, лежащие в основе различных поколений ИТрешений, несовместимы, а описания бизнес-объектов и атрибутов в различных ИС не соответствуют друг другу. Это объясняет популярность концепции
SOA, обещающей обеспечить применение широкого набора эксплуатируемых
на предприятии приложений и построить на их основе сквозные бизнеспроцессы.
1. ОБЩАЯ СХЕМА ИНТЕГРАЦИИ
Схема интеграции опирается на заложенные в SOA принципы, согласно
которым подход к разработке программного обеспечения основан на использовании сервисов со стандартизированными интерфейсами. Компоненты сис-

Магистрант кафедры вычислительной техники
Д.В. Прытков
104
темы могут быть распределены по разным приложениям и предлагаются как
независимые, слабо связанные и заменяемые сервисы.
Интерфейс компонентов SOA-программы предоставляет инкапсуляцию
деталей реализации конкретного компонента (ОС, платформа, язык программирования, вендор и т. п.) от остальных компонентов. Таким образом,
SOA предоставляет способ комбинирования и многократного использования
компонентов для построения сложных распределённых программных комплексов.
В качестве инструмента реализации выбран продукт SOA Suite компании
Oracle. Связь интеграционных компонент и программных продуктов SOA
Suite показана на рис. 1.
Рис. 1. Связь интеграционных компонентов
и программных продуктов SOA Suite
2. КАНОНИЧЕСКАЯ МОДЕЛЬ ДАННЫХ
Каноническая модель данных (Enterprise Business Objects, EBO) представляет собой модель, состоящую из стандартных определений объектов и бизнес-компонентов многократного использования. EBO, обладающая наивысшим уровнем обобщения логической модели данных, предназначена для использования разработчиками, бизнес-пользователями и специалистами по
Интеграционное решение.…
105
интеграции. В случае интеграции каноническая модель используется как общая, тем самым отпадает необходимость маппирования систем по принципу
«one-to-one» и создания разрозненных схем данных между каждой парой приложений.
Каноническая модель данных обладает следующими характеристиками:
 содержит компоненты удовлетворяющие требованиям бизнес-объектов
моделей данных целевых приложений;
 не содержит данные, а описывает их структуру;
 реализуется в виде XML-схем в формате XSD.
При проектировании EBO необходимо максимально включать объекты
многократного использования, принимая во внимание типы, унаследованные
от различных стандартных общих объектов.
3. ABC-СЕРВИСЫ
ABC-сервисы (Application Business Connector, ABC) играют роль шлюзов
между бизнес-функциями приложений и бизнес-сервисами. Таким образом,
задача ABC-сервисов – преобразовывать данные из канонических форматов в
родные для приложений, с которыми они взаимодействуют, и наоборот. ABC–
сервисы могут быть двух типов: Request-side; Provide-side. Request-side ABC
принимает запросы от приложения и возвращает ответ в виде сообщения в
специфичном для данного приложения формате (Application Business Message,
ABM). Provide-side ABC принимает запрос от бизнес-сервиса и возвращает
ответ, используя сообщения в утверждённом общем формате (Enterprise
Business Message, EBM). При обращении Request-side ABC выполняет следующие этапы работы:
 обогащает данными ABM, полученное от приложения инициатора;
 трансформирует ABM в формат EBM;
 вызывает одно или несколько внешних расширений для дополнительных трансформаций;
 вызывает бизнес-сервис, результатом работы которого является ответ в
формате EBM;
 трансформирует из EBM в формат ABM;
 вызывает одно или несколько внешних расширений для дополнительных трансформаций;
 производит проверку данных ABM на соответствие формату заинтересованного приложения;
 возвращает ответ приложению, отправившему запрос.
При обращении Provide-side ABC выполняет следующие этапы работы:
106
Д.В. Прытков
 трансформирует EBM в формат ABM запрашиваемого приложения;
 вызывает одно или несколько внешних расширений для дополнительных трансформаций;
 производит проверку данных ABM на соответствие формату вызываемого приложения;
 вызывает одну или несколько бизнес-функций соответствующего приложения;
 трансформирует полученный ответа из формата ABM в формат EBM;
 вызывает одно или несколько внешних расширений для дополнительных трансформаций;
 возвращает ответ бизнес-сервису, отправившему запрос.
В случае если приложение позволяет использовать свои бизнес-функции
посредством веб-сервисов, для создания ABC сервисов рационально применение ESB, так как основные усилия будут сконцентрированы вокруг трансформации ABM в формат EBM, и наоборот.
В случае если представленных веб-серсивов приложения недостаточно
и/или необходимо провести модификацию системы, когда функциональность
ABC-сервисов выходит за рамки трансформации форматов сообщений (например, при агрегации данных или принятии решения человеком), создание
ABC-сервисов рационально осуществлять при помощи BPEL.
4. EBS–СЕРВИСЫ
Бизнес-сервисы (Enterprise Business Service, EBS) играют роль маршрутизаторов EBM. Источником EBM являются Request-side ABC, получателями –
Provide-side ABC. Ключевой момент в использовании бизнес-сервисов заключается в том, чтобы приложения поставщика и потребителя информации
взаимодействовали через посредника. Таким образом, ни одна из сторон не
влияет на другую, что особенно важно, если приложения были реализованы
для разных платформ, с использованием различных протоколов, форматов
данных и т. п. ABC-сервисы преобразуют сообщения из специфических форматов в канонический (и наоборот), в то время как бизнес-сервисы имеют дело с сообщениями только в каноническом формате. Такой подход позволяет
создавать гибкую, масштабируемую архитектуру, позволяющую с минимальными затратами добавлять новых поставщиков и потребителей и заменять
уже имеющихся. Для этого потребуется создать соответствующие ABC сервисы (рис. 2).
В общем случае EBS-сервис выполняет следующие этапы работы:
 получает сообщение вызова от Request-side ABC-сервиса;
Интеграционное решение.…
107
 определяет соответствующих Provide-side ABC-сервисов;
 вызывает требуемые сервисы;
 получает ответ и возвращает его Request-side ABC-сервису.
Рис. 2. Схема взаимодействия приложений и сервисов
ЗАКЛЮЧЕНИЕ
Фундаментальное отличие сервис-ориентированной архитектуры от ранее
созданных гибких сред такого рода заключается в ее нечувствительности к
типам технологий, на которых базируются конкретные приложения. Важнейшим фактором, определяющим переход на сервис-ориентированную архитектуру, по мнению ИТ-менеджеров, является высокая способность реагировать
на изменения бизнеса. Следующее преимущество – простота интеграции приложений и долгосрочная отдача от ИТ-инвестиций за счет многократного использования аппаратных и программных средств.
По мере накопления опыта в управлении сервис-ориентированной архитектурой и совершенствовании инфраструктуры ПО интересы заказчика
будут медленно смещаться от вопросов внедрения архитектуры к управлению ею. Появятся пакеты приложений с реализованными и готовыми к применению интерфейсами SOA-сообщений, станут широко доступными прошедшие практическую апробацию модели типовых процессов для каждой
108
Д.В. Прытков
отрасли. Это будет способствовать снижению уровня риска и откроет широкие возможности для проектирования по-настоящему инновационных процессов.
[1] Anand V., Berry D. Oracle® Application Integration Architecture Foundation 2.0: Concepts and Technologies Guide. – Redwood Shores: Oracle Press, 2007.
[2] Биберштейн Н., Боуз С. Компас в мире сервис-ориентированной архитектуры (SAO). – М.: КУДИЦ-ОБРАЗ, 2007.
[3] Шаппелл Д. ESB – Cервисная Шина Предприятия. – СПб.: БХВПетербург, 2008.
[4] Anand V., Berry D. Oracle® SOA Suite. Best Practices Guide. – Redwood
Shores: Oracle Press, 2007.