СБОРНИК НАУЧНЫХ ТРУДОВ НГТУ. – 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.