Из сравнительно абстрактного на первый взгляд мира SOA предприятия довольно быстро смогут извлечь практические преимущества.
При повышении гибкости инфраструктуры предприятия одна из самых сложных задач ИТ заключается в том, чтобы заставить нормально работать гетерогенный ландшафт приложений. Уже несколько лет рынок предлагает разнообразное промежуточное программное обеспечение, объединяемое общим названием «интеграция корпоративных приложений» (Enterprise Application Integration, EAI): при помощи адаптеров и так называемых брокеров интеграции оно позволяет осуществлять обмен данными между разными приложениями. Однако в условиях сложных сред этот подход быстро упирается в пределы своих возможностей. Причина в том, что EAI выполняет задачу интеграции лишь избирательно, когда соединения организуются через нестандартные интерфейсы, в результате возникают скрытые зависимости, а изменения оказываются весьма дорогостоящими. Развитие служб Web сделало возможным новый тип интеграции, реализация которого должна позволить преодолеть ограничения нестандартных решений EAI и ее двухточечной или звездообразной архитектуры (в виде концентратора и лучей) благодаря центральной магистрали обмена сообщениями.
ЕДИНЫЙ ПОДХОД
Концепция ориентированной на услуги архитектуры (Service-Oriented Architecture, SOA) подразумевает единый подход к ландшафту ИТ и производственным процессам. Вместо того чтобы, как раньше, функции выполнялись отдельными приложениями, деловые функции и процессы должны предоставляться в виде услуг. Эти независимые от приложений и платформ компоненты содержат всю логику приложений, нейтральны с технической точки зрения, комбинируются друг с другом в стандартизированной форме и доступны для повторного использования. Вместо прежних монолитных приложений возникают композитные, чьи компоненты или услуги являются слабо (и динамически) связанными.
К примеру, приложение, которому нужна информация о клиенте, может обратиться к службе под названием «поиск клиента». При этом неважно, где расположена услуга в сети, на каком аппаратном обеспечении она выполняется и какой язык программирования предпочли разработчики.
Определение услуг понимается довольно широко: иногда они включают монолитные приложения, берут на себя обязанности адаптера, выполняют отдельные операции, к примеру функции вычисления цен, или целые процессы, вызывают внешнюю службу Web либо представляют полный бизнес-блок, которому нужен доступ ко всей информации предприятия.
Услуга составляется из нескольких частей: интерфейс, помимо прочего, определяет, как она вызывается и где находится. Как и ранее, собственно реализация услуги осуществляется посредством кода, выполняемого при ее вызове. В отличие от интерфейса, который определяется в нейтральном формате, реализация услуги зависит от платформы, а ее дальнейшее поведение определяется информацией, полученной от интерфейса.
Наиболее очевидной технологией для использования в SOA являются службы Web, прежде всего базовые спецификации языка описания служб Web (Web Services Description Language, WSDL) и протокола простого доступа к объектам (Simple Object Access Protocol, SOAP). WSDL, язык на базе XML, служит в качестве описания сервисного интерфейса, а SOAP рассматривается в качестве предпочтительного коммуникационного протокола.
Связь между службами и их взаимодействие с имеющимися системами берет на себя уровень интеграции с коммуникационной инфраструктурой. В роли центрального компонента SOA выступает так называемая шина служб предприятия (Enterprise Service Bus, ESB). Эта новая категория промежуточного программного обеспечения не имеет однозначного определения, однако она должна решать несколько базовых задач, среди которых — обмен сообщениями, преобразование данных, а также маршрутизация сообщений в зависимости от их содержания (см. Рисунок 1).
|
| Рисунок 1. В качестве центрального связующего звена коммуникационного обмена служит шина служб предприятия. |
ESB рассматривается в качестве связующего звена между генерацией сообщений нестандартным промежуточным программным обеспечением, ориентированным на сообщения (Message Oriented Middleware, MOM), и SOAP. Она обеспечивает построение федеративной сети, образующей систему слабо связанных между собой интеграционных услуг и, возможно, концентраторов сообщений, между которыми существуют свободно определяемые переходники. В случае необходимости приложения подключаются к шине, принимают соединения с любым другим приложением в шине и обмениваются данными.
СИНХРОННАЯ КОММУНИКАЦИЯ
Хотя WDSL и SOAP можно связать с различными транспортными механизмами, эти службы Web лучше всего подходят для синхронной коммуникации по HTTP. Синхронный обмен сообщениями означает, что клиент (запрашивающая сторона) отправляет запрос серверу (генерирующая сторона) и ждет ответа. Так происходит, в частности, когда пользователь должен ввести какие-то данные. Следующее действие производится после получения ответа на запрос: обычный способ отработки этапов в нераспределенных приложениях. Однако в средах, где параллельно работает множество приложений и служб, синхронная модель обладает рядом недостатков, и главный из них — отправитель и получатель должны быть одновременно доступны, чтобы обмен данными состоялся. Если эта операция по какой-то причине не может быть завершена, то и все остальные задействованные процессы не будут выполнены. Вывод очевиден: любому приложению, использующему синхронную коммуникацию, необходимы собственная система обработки ошибок и логика восстановления.
Асинхронная передача сообщений с промежуточным хранением не требует одновременной доступности отправителя и получателя. Поэтому такой тип коммуникации является по необходимости основным в архитектуре со слабо связанными интерфейсами и распределенной обработкой процессов. Он позволяет добиться того, чтобы любое взаимодействие между двумя процессами представляло собой самостоятельный рабочий блок с собственными контекстом и данными. При этом задействованные приложения не должны знать деталей и параметров друг друга. Для асинхронной коммуникации требуется MOM или служба обмена сообщениями Java (Java Messaging Service, JMS). Новые версии SOAP 1.2 и WDSL 2.0 стандартов служб Web поддерживают и асинхронные взаимодействия. Однако услуги Web пока не способны заменить все функции МОМ.
Ориентированное на сообщения промежуточное программное обеспечение должно предоставлять разные — синхронные и асинхронные — возможности и механизмы для передачи сообщений, к примеру для публикации и подписки или промежуточного сохранения и последующей передачи. При отправке сообщения отдельные этапы делового процесса полагаются на то, что ESB обеспечит надежную доставку данных получателю. Промежуточное программное обеспечение позаботится и об ответном сообщении. Детали передачи реализуют такие механизмы, как публикация и подписка (отправитель публикует сообщение, которое получают несколько адресатов) или промежуточное сохранение с последующей передачей (в доставке сообщения участвуют несколько адресатов). Отсюда вытекают и правила обеспечения качества услуг при передаче сообщений. Надежная передача сообщения гарантируется спецификацией услуг Web под названием WS-ReliableMessaging, где описываются соответствующие расширения для SOAP.
ESB должна быть достаточно гибкой, чтобы поддерживать разные типы соединений и протоколы (HTTP, TCP/IP, SOAP), в частности взаимодействие службы Web и приложения МОМ. В рамках корпоративной магистрали обмена сообщениями программное обеспечение должно поддерживать как стандарты служб Web (WS-Reliability или WS-ReliableMessaging) и компоненты J2EE, к примеру службу обмена сообщениями Java (Java Messaging Service, JMS), так и ориентированное на обмен сообщениями нестандартное промежуточное программное обеспечение и архитектуру коннекторов J2EE (J2EE Connector Architecture, JCA) для соединения с адаптерами приложений без интерфейсов служб Web. Из сообщества Java выделилась деловая интеграция Java (Java Business Interation, JBI), где описывается, каким образом интеграционные компоненты разных ESB сопрягаются друг с другом.
Трансформация данных и службы XML также относятся к базовому комплекту функций ESB, поскольку разные подключенные к шине компоненты требуют разных форматов данных. Одно из преимуществ промежуточного программного обеспечения заключается именно в том, что услуги взаимодействуют между собой, не будучи осведомленными о деталях реализации друг друга. Для обмена сообщениями можно использовать службы XML, которые при помощи таблицы стилей XSLT преобразуют входящее сообщение XML из одного варианта языка разметки в другой.
Наконец, ESB характеризуется возможностью интеллектуальной маршрутизации. Для определения деловых услуг, составленных из разных компонентов на шине, последняя должна определять процесс перехода от одной услуги к другой и в случае необходимости динамически изменять путь. Например, какая-либо фаза процесса, скажем «проверка» (когда документ идентифицируется как искомый), на основе содержащихся там правил будет направлять данные в зависимости от контента.
РЕПОЗИТОРИЙ И РЕЕСТР
Концепция ориентированной на услуги архитектуры подразумевает также наличие хранилища, или реестра, в качестве центрального каталога для всех доступных услуг. Уже несколько лет существует стандарт для служб Web — универсальное описание, обнаружение и интеграция (Universal Description, Discovery and Integration), однако, как выяснили аналитики из компании Berlecon Research, лишь немногие предприятия используют эту службу каталогов. Большинство предпочитает самостоятельно разработанные хранилища.
Основная функция центральных каталогов состоит в публикации имеющихся услуг. Наряду с описанием интерфейсов сюда вносятся дополнительные данные о версиях или соглашениях об уровне сервиса (Service Level Agreements, SLA). Пользователи получают возможность поиска услуг, чтобы, к примеру, установить, какие базовые услуги уже имеются, когда необходимо внедрить новые функции.
Многие продукты ESB держат приложения в так называемых контейнерах. Это либо легкие контейнеры Plain Old Java Object (POJO), либо контейнеры J2EE, где находится сервер приложений или также только служба поиска.
МЕТОДЫ ОРКЕСТРОВКИ
Почти любая платформа SOA, помимо «базовой комплектации», предоставляет дополнительные методы для так называемой оркестровки услуг. Речь идет о том, чтобы объединить фазы процессов в один деловой процесс (см. Рисунок 2). Обычно такая задача решается при помощи инструмента для управления деловыми процессами, однако это может сделать и услуга. Базой для нее служит модель протекания делового процесса, которая составляется при помощи спецификации языка выполнения делового процесса (Business Process Execution Language, BPEL). Для процесса, который в зависимости от взаимодействия с пользователем — например при подтверждении заказа на доставку — продолжается дальше, очень важен механизм, посредством которого его ход будет автоматически прерываться до определенного действия, а потом запускаться снова. Служба оркестровки и предлагает такой механизм. В таком случае ориентированная на услуги архитектура приближается к идеалу динамично составляемых приложений.
|
| Рисунок 2. При оркестровке услуг отдельные фазы сливаются в единый деловой процесс. |
Высококонкурентный рынок продуктов SOA довольно сложно разделить на категории. Так, компания Burton Group выделяет несколько типов архитектуры, на базе которой продукты ESB обеспечивают совместную работу протоколов. С одной стороны, есть целый ряд производителей, программное обеспечение которых строится вокруг уже имеющихся МОМ. К таковым относятся традиционные поставщики EAI — Tibco, IBM, BEA или Sonic. Они предлагают собственную магистраль для обмена сообщениями, поддерживающую интерфейсы SOAP. Сообщения SOAP передаются по протоколам HTTP или МОМ, и каждая среда с поддержкой SOAP получает доступ к приложениям с интерфейсом службы Web. Подобный тип ESB реализуется в SOA на нескольких узлах. Как и в случае с брокерами интеграции, имеется один или несколько центральных узлов для координации или эти узлы образуют федеративную сеть.
Другой тип архитектуры базируется на коммутации протоколов при помощи механизма обработки сообщений и набора подключаемых драйверов протокола. На основе информации о привязке в файле WSDL сообщения он выбирает нужный драйвер. На данный момент стандартизирована только привязка HTTP для SOAP, но коммутатор протоколов содержит и все другие протоколы. Наиболее известные производители архитектур такого типа — Microsoft и Iona.
И наконец, Burton Group упоминает архитектуру шлюзов, когда совместная работа протоколов обеспечивается благодаря переводчику и посреднику между SOAP и специальными протоколами МОМ. Имеющиеся очереди МОМ инкапсулируются и публикуются в качестве службы Web. Такие коммутаторы выпускают Blue Titan и Systinet.
ГИБКИЕ ДЕЛОВЫЕ ПРОЦЕССЫ КАК ЦЕЛЬ
В том, что касается потенциальной пользы от введения SOA, царит согласие: архитектура должна привести к гибким деловым процессам, которые проще адаптируются к новым требованиям, а издержки на обслуживание расширяющихся ландшафтов ИТ станут ниже. Но аналитики из Burton Group предупреждают: ни один продукт ESB не является универсальным решением для всех требований предприятия к интеграции — по иронии судьбы, внедрение ESB может понадобиться для взаимной интеграции уже имеющихся шин.
Сюзанна Франке — независимая журналистка.
? AWi Verlag
Глоссарий
Архитектура коннекторов J2EE (J2EE Connector Architecture, JCA) определяет архитектуру и интерфейс программирования для создания адаптеров, посредством которых осуществляется интеграция приложений в платформу J2EE.
Брокер интеграции — промежуточное программное обеспечение, в звездообразной архитектуре отвечающее за централизованную маршрутизацию.
Деловая интеграция Java (Java Business Interation, JBI) специфицирует, как компоненты интеграции, к примеру услуги ESB, работают совместно вне зависимости от производителя.
Композитное приложение — приложение, ориентированное на деловые процессы, которое при необходимости составляется из деловых и прикладных услуг по принципу конструктора.
Ориентированное на сообщения промежуточное программное обеспечение (Message Oriented Middleware, МОМ) служит для асинхронной коммуникации посредством передачи сообщений.
Протокол на базе SOAP WS-Reliable-Messaging гарантирует доставку сообщения с определенными параметрами качества.
Служба обмена сообщениями Java (Java Messaging Service, JMS) представляет собой интерфейс программирования (API) для обмена сообщениями Java и является частью спецификации J2EE.
Управление деловыми процессами (Bu-siness Process Management, BPM) означает как метод, так и набор инструментов, посредством которых определяются и выполняются отдельные фазы деловых процессов.
Язык описания служб Web (Web Services Description Language, WSDL) представляет собой метаязык на базе XML, позволяющий описывать функциональность службы Web: интерфейсы, протокол доступа, а также параметры и возвращаемые значения этих операций.
Язык разметки выполнения деловых процессов для служб Web (Web Service Business Process Execution Markup Language, WS-BPEL) — ориентированный на процессы язык на базе WSDL, где определяется ряд базовых заданий для создания очередности выполнения сервисов Web.