Интеграционная шина данных. Роль ESB в структуре SOA. Синхронный вызов через посредника

Функции Enterprise Service Bus

Современная интеграция информационных систем представляет собой реализацию сервис-ориентированной архитектуры (Service-Oriented Architectures, SOA) с использованием технологий Web-cервисов; существует много превосходных описаний преимуществ и методов такой реализации (см. раздел ). В последнее время ключевым компонентом инфраструктуры SOA считается корпоративная сервисная шина Enterprise Service Bus (ESB) (см. раздел ). Однако важно точно знать, что такое ESB - продукт, технология, стандарт или что-либо еще. В частности, можно ли построить ESB сегодня, и если да, то как именно?

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

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

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

Поскольку развиваются ситуации, в которых используется решение ESB, соответствующим образом развиваются и необходимые для ESB функции. Аналогично будут развиваться функции и средства явно использующих ESB продуктов. Поэтому в заключительной статье данной серии мы рассмотрим схему внедрения SOA и ESB, чтобы дать рекомендации на первом этапе использования функций и технологий ESB и продемонстрировать возможности постепенного внедрения.

Роль ESB в структуре SOA

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

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

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

Рисунок 2. Централизованное управление распределенной инфраструктурой ESB

Кроме того, следует обозначить позицию ESB по отношению к другим компонентам инфраструктуры SOA, в частности, компонентам службы каталогов Service Directory, Business Service Choreography и Business-to-Business (B2B) Gateway. Поскольку перечисленные выше принципы SOA не требуют обязательного наличия этих компонентов, давайте считать их необязательными компонентами. На показана инфраструктура SOA, демонстрирующая отношения этих компонентов к ESB.

Рисунок 3: Роль ESB в структуре SOA

Для осуществления маршрутизации запросов сервиса ESB необходим особый каталог маршрутизации сервиса . Однако в SOA может также присутствовать отдельный каталог бизнес-сервиса , который, в самой простой форме, может представлять собой временный (используемый при разработке проекта) каталог, который используется для обеспечения многократного использования сервисов разработчиками организации. В представлении о Web-cервисах роль каталога бизнес-сервиса и каталога маршрутизации сервиса отводится каталогу UDDI, тем самым обеспечивается динамическое обнаружение и вызов сервисов. Такой каталог может рассматриваться как часть ESB, однако до тех пор, пока такие решения не получат достаточного распространения, лучше, чтобы каталог бизнес-сервиса существовал отдельно от ESB.

Функцией компонента Business Service Choreographer является компоновка бизнес-процессов из нескольких бизнес-сервисов ; поэтому этот компонент вызывает сервисы через ESB, а затем предлагает бизнес-процессы клиентам как другие сервисы, также через ESB. Однако роль компонента Business Service Choreographer, технологии организации производственного процесса, в координации работы бизнес-процессов и сервисов идентифицирует этот компонент как невходящий в ESB, технологию инфраструктуры.

И наконец, функцией компонента B2B Gateway является обеспечение доступности сервисов каждой из двух или более организаций всем остальным организациям управляемым и безопасным способом. Полезно рассматривать такие компоненты как подключенные к ESB, но не входящие в ее состав. Хотя существуют шлюзовые технологии, предоставляющие функции, необходимые для реализации как компонентов B2B Gateway, так и ESB, само назначение компонента B2B Gateway отделяет его от ESB. Действительно, для выполнения своих функций этому компоненту могут потребоваться дополнительные средства, например, инструменты управления партнерскими взаимоотношениями, которые не являются частью ESB и не обязательно поддерживаются технологиями ESB.

Модель производительности ESB

Обобщает и классифицирует некоторые функции ESB, описанные в имеющейся литературе (см. раздел ). Одни из этих функций являются простыми, другие, например, функции автономности и интеллектуальные функции, представляют собой значительный шаг к операционной среде по требованию (On Demand). Важно понимать, что для большинства существующих сценариев использования ESB необходимыми являются только некоторых из этих функций из некоторых категорий. О минимальном наборе функций, необходимых для реализации ESB, мы поговорим в разделе Минимальный набор функций ESB для SOA .

Таблица 1. Функции ESB, описанные в специальной литературе

Связь	Взаимодействие сервисов
Маршрутизация; Адресация; Технологии, протоколы и стандарты связи (например, IBM® WebSphere® MQ, HTTP и HTTPS) Публикация/подписка; Ответ/запрос; Запустил-и-забыл, события; Синхронный и асинхронный обмен сообщениями.	Определение интерфейса сервиса (например, язык WSDL (Web Services Description Language, язык описания Web-сервисов); Поддержка возможности замены реализации сервиса; Модель организации сервиса обмена сообщениями, необходимая для связи и интеграции (например, SOAP или модель связующего ПО корпоративной интеграции приложений (EAI, enterprise application integration); Каталог сервиса и обнаружение сервиса.
Интеграция	Качество сервиса
База данных; Агрегация сервиса; Адаптеры для имеющихся систем и приложений; Обеспечение подключения к связующему ПО EAI; Отображение сервиса; Преобразование протоколов; Среда сервера приложений (например, J2EE и.NET); Интерфейс языка прикладного программирования для вызова сервиса (например, Java и C/C++/C#).	Транзакции (Неделимые транзакции, Компенсация, WS-транзакция); Различные парадигмы гарантированной доставки (например, WS-ReliableMessaging или поддержка связующего ПО EAI).
Безопасность	Уровень сервиса
Аутентификация; Авторизация; Невозможность отказа от авторства; Конфиденциальность; Стандарты обеспечения безопасности (например, Kerberos и WS-Security).	Производительность; Пропускная способность; Доступность; Прочие непрерывные меры, которые могут стать основой контрактов или соглашений.
Обработка сообщений	Управление и автономность
Закодированная логика; Логика, основанная на контенте; Преобразование сообщений и данных; Проверка корректности; Посреднические; Тождественное отображение объектов; Обогащение данных.	Инициализация и регистрация сервиса; Ведение журналов, измерения, мониторинг; Обнаружение; Интеграция с инструментами управления и администрирования системы; Самонаблюдение и самоуправление.
Моделирование	Интеллектуальные функции инфраструктуры
Моделирование объектов; Общие модели бизнес-объектов; Библиотеки форматов данных; Открытые или закрытые модели для интеграции B2B; Инструменты разработки и развертывания.	Бизнес-правила; Управляемое политиками поведение, особенно для функций уровня сервиса, обеспечения безопасности и качества сервиса (например, WS-Policy); Распознавание шаблона.

Многие из этих функций могут быть реализованы при помощи соответствующих технологий или с использованием открытых стандартов. Но технологии, претендующие на использование в реализации ESB, могут в значительной степени различаться по характеристикам производительности, масштабируемости и доступности, а также по тому, какие функции ESB и открытые стандарты они поддерживают. По этим причинам и вследствие того, что некоторые из значимых стандартов были разработаны недавно или все еще находятся в стадии разработки, многие критически важные решения по реализации ESB в настоящее время сопряжены с поиском компромиссов между поддержкой зрелых, сложившихся технологий и менее зрелых открытых стандартов.

В данной серии статей я не буду подробно рассказывать о каждой из этих категорий функций. Скорее мы сосредоточимся на тех из них, которые имеют значение для принятия решений по поводу выбора подхода к внедрению или реализации ESB. В частности, в следующем разделе мы остановимся на том, какой минимальный набор функций необходим для поддержки SOA реализацией ESB.

Минимальный набор функций ESB для SOA

Если для большинства SOA-сценариев имеет значение только подмножество перечисленных ранее функций, мы можем поставить следующий вопрос: какие функции входят в минимальный набор функций, необходимых для того, чтобы реализовать ESB? Чтобы ответить на этот вопрос, мы рассмотрим самые распространенные элементы определения ESB, по поводу которых не существует особых разногласий:

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

В приводится минимальный набор функций ESB, выбранных с учетом этих принципов.

Таблица 2. Минимальный набор функций ESB

Связь	Интеграция
Маршрутизация и адресация сервисов для обеспечения прозрачности размещения; Функция администрирования для управления адресацией и именованием сервисов; По меньшей мере одна из форм парадигмы обмена сообщениями (например, запрос/ответ, публикация/подписка и т. п.); Поддержка по меньшей мере одного транспортного протокола, который является или может стать общедоступным.	Поддержка нескольких средств интеграции с поставщиками сервиса, например, коннекторов Java 2, Web-сервисов, асинхронного обмена сообщениями, адаптеров и т. п.
Взаимодействие сервисов
Открытая и независимая от реализации модель обмена сообщениями и организации интерфейсов, которая должна изолировать код приложения от специфических условий маршрутизации сервисов и транспортных протоколов, а также обеспечение возможности замены реализации сервиса

Обратите внимание на то, что минимальный набор функций не требует использования каких-либо определенных технологий , например, связующего ПО EAI, Web-сервисов, J2EE или XML. Вполне вероятно, что такие технологии будут использоваться, поскольку они отвечают требованиям, но это не является обязательным. И наоборот, минимальный набор функций почти, если не полностью, обеспечивается простым использованием SOAP/HTTP и WSDL.

• Адресация URL и существующая инфраструктура HTTP и DNS предоставляют инфраструктуру "шины", обеспечивающей маршрутизацию сервисов и прозрачность размещения;
• SOAP/HTTP поддерживает парадигму обмена сообщений запрос-ответ ;
• Транспортный протокол HTTP является широко доступным;
• SOAP и WSDL представляют собой открытую, независимую от реализации модель организации интерфейса и обмена сообщениями сервисов.

Тем не менее, использование SOAP/HTTP и WSDL в простейшей форме в действительности обеспечивает только интеграцию от точки до точки и не предоставляет следующих ключевых функций, необходимых для ESB:

• Отсутствует функция администрирования для управления адресацией и наименованием сервисов Имена сервисов контролируются в индивидуальном порядке каждым адаптером, поэтому управление маршрутизацией сервиса распределяется между адресами, вызываемыми клиентами сервиса, инфраструктурой HTTP и именами сервисов, присваиваемых адаптерам;
• Хотя этот подход зависит от деталей реализации, он не способствует обеспечению замены реализации сервиса; код запросчика сервиса (возможно, сгенерированный инструментами разработки), часто будет напрямую привязан к специфической реализации поставщика сервисов через специфические протоколы по специфическим адресам. Замена реализации сервиса другой реализацией потребует изменений в коде приложения и его повторного развертывания.

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

• Функции обеспечения качества сервиса и уровня сервиса;
• Концепции SOA более высокого уровня - service choreography, каталог, преобразование и т. д.;
• Требования операционной среды по требованию (On Demand), такие как функции автономности и управления, а также интеллектуальные функции инфраструктуры;
• По-настоящему неоднородные операции в нескольких сетях, с несколькими протоколами и несколькими доменами с разными моделями владения.

Проблемы безопасности, связанные с ESB

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

1. Будет ли приемлемым уровень безопасности инфраструктуры связи при использовании взаимной аутентификации по протоколу безопасных соединений Secure Socket Layer EAI между серверами связующего ПО EAI или при использовании протокола HTTPS?
2. Будет ли достаточно индивидуальной, от точки к точке, системы безопасности между системами-участниками, или необходима сквозная модель обеспечения безопасности? Например, есть ли необходимость в распространении идентификационной информации клиента через промежуточные системы, например, брокеры, конечным поставщикам или реализациям сервиса?
3. Будет ли приемлемой безопасность на прикладном уровне, например, может ли клиентский код выполнить базовую аутентификацию HTTP по идентификатору пользователя и паролю, или сможет ли он передать эту информацию сервису как данные приложения?
4. Требуется ли соответствие механизма безопасности стандартам обеспечения безопасности, например, Kerberos или WS-Security?

Хотя возможны все перечисленные подходы к обеспечению безопасности, рекомендуется использование соответствующих стандартам (например, WS-Security) функций обеспечения безопасности при поддержке инфраструктуры и связующего ПО. Однако эти стандарты появились сравнительно недавно, и поддержка их программными продуктами пока находится в фазе развития, особенно в случаях, связанных с обеспечением функциональной совместимости. Таким образом, одним из приоритетов архитектуры ESB должно стать утверждение требований к обеспечению безопасности на ранних фазах разработки, чтобы их можно было учесть при выборе технологии реализации.

Заключение

В данной статье рассказывалось о самых общих принципах SOA и их связи с технологией Web-сервисов. Исходя из этих принципов автор утверждает, что компонент инфраструктуры, предоставляющий функцию маршрутизации, должен обеспечить взаимодействие сервисов между собой, а также поддержку замены одной реализации сервиса другой реализацией. Эти функции, в числе многих других, реализуются посредством ESB.

ESB предоставляет распределенную инфраструктуру и функции централизованного управления, для чего необходим каталог маршрутизации сервиса и кроме того, возможно, каталог бизнес-сервиса. Компонент Business Service Choreographer вызывает сервисы из ESB, а затем представляет процессы как новые сервисы через ESB.

Среди множества функций, предоставляемых ESB, имеются функции:

• Связи;
• Взаимодействий сервисов;
• Интеграции;
• Обеспечения качества сервиса;
• Безопасности;
• Обеспечения уровня сервиса;
• Обработки сообщений;
• Управления и автономии сервиса;
• Моделирования;
• Интеллектуальные функции инфраструктуры.

В следующей статье серии мы рассмотрим распространенные сценарии, подходящие шаблоны решений для сценариев и поговорим о самых распространенных проблемах, связанных с этими сценариями.

Благодарности

Эта статья вряд ли вышла в свет, если бы автор не обсуждал свои идеи со следующими людьми: Бет Хатчисон (Beth Hutchison), Рейчел Рейниц (Rachel Reinitz), Олаф Циммерман (Olaf Zimmerman), Хелен Уайли (Helen Wylie), Кайл Браун (Kyle Brown), Марк Колан (Mark Colan), Джонатан Адамс (Jonathan Adams), Пол Фремантл (Paul Fremantle), Кейт Джонс (Keith Jones), Пол Вершурен (Paul Verschueren), Дэниэл Стэрмен (Daniel Sturman), Скотт Косби (Scott Cosby), Дейв Кларк (Dave Clarke), Бен Манн (Ben Mann), Луиза Гиллис (Louisa Gillies), Эрик Хернесс (Eric Herness), Билл Хасселл (Bill Hassell), Гуру Васудева (Guru Vasudeva), Карим Юсуф (Kareem Yusuf), Кен Уилсон (Ken Wilson), Марк Эндреи (Mark Endrei), Норберт Биберштейн (Norbert Bieberstein), Крис Нотт (Chris Nott), Алан Хопкинс (Alan Hopkins) и Ярослав Данчич (Yaroslav Dunchych).

В Москве с 1958 года существовала 3-я улица Строителей, но в 1963 году её переименовали - теперь это улица Марии Ульяновой, а дом 25 по этой улице - хрущёвская пятиэтажка. В Ленинграде (Санкт-Петербурге) 3-ей улицы Строителей не существовало никогда…

Я снова про интеграцию приложений. Читал сегодня отечественный стандарт межведомственного документооборота ГОСТ Р 53898-2010 И стандарт вроде бы «правильный» на XML-е писанный и поля там всякие полезные на 53-х страницах приведены и все дела. Помнится, в конце прошлого века я всячески ратовал за появление стандартов электронных сообщений на страницах журнала Компьютера в заметке Фактор Internet в развитии систем «клиент-банк» В конце прошлого века все выглядело оптимистичней, чем в начале нынешнего. Дот-комы еще не рухнули, небо было выше, трава зеленее, социальные сайты вызывали доверие, а Филдинг еще не защитил диссертацию с названием Representational State Transfer. Что же случилось за десять с небольшим лет и почему идея стандартизации формата электронного документа больше меня не прикалывает? Да ничего важного, просто парадигма интеграции приложений изменилась.

Как это было раньше? Один банк отправлял другому электронное сообщение (Уж извините, я тогда в Инкомбанке работал, потому про банки буду рассказывать). Второй банк сообщение получал и отправлял на него квитанцию. Все это десять раз шифровалось, заверялось цифровой подписью, в квитанцию включалась хеш-функция исходного сообщения … номера входящих и исходящих, отметки времени (тоже, кстати, криптографические) и т.д. и т.п. Наиболее обсуждаемый вопрос тех лет, а нужно ли на квитанцию формировать квитанцию о получении квитанции и что делать, когда квитанция не доставлена. В общем, страшно вспомнить до какого уровня сложности можно довести процесс синхронизации состояний множественных виртуальных образов одного реального документа. С бумагой было проще. По крайней мере, до изобретения ксерокса.

Возвращаемся в современность. Если очереди сообщений существовали для того, чтоб безопасно и гарантированно сообщения доставлять, то сервисная шина появилась для того, чтоб обмен сообщениями исключить. И не надо мне рассказывать, что эта самая шина как раз и осуществляет обмен сообщениями. Я это знаю, мы и сами так делаем, только это не очень правильно. Изначальная идея сервисной шины, тем более Enterprise Service Bus (ESB) состоит не в том, чтоб передавать сообщения, а в том, чтоб любое приложение не заботилось о необходимости создания своего локального экземпляра объекта. Смысл сервиса в том, чтоб всегда можно было такой объект получить. Нужен вам документ – вбили URL и методом HTTP GET документ получили и почитали. Захотели документ изменить – по тому же самому URL, методом HTTP PUT документ изменили. POST-ом добавили, DELETE-ом удалили, ну что может быть проще? Присвойте вы документу URL. Воспользуйтесь протоколом в стиле WebDAV чтобы взять документ, поработать и в новом статусе вернуть на его место, то самое, определенное в качестве мастер-копии, т.е. на тот же URL с которого взяли

Иначе – апокалипсис. Квитанции и уведомления об изменении статуса – это еще полбеды. Необходимость одинаково толковать поля документов, а для этого синхронизировать справочники – вот это беда. Третья улица строителей в Москве и 3-я улица строителей в Питере, как это известно из главного новогоднего фильма, далеко не одно и то же. Пожалуй, единственный справочник одинаково трактуемый в разных ведомствах это григорианский календарь. И то, я до конца не уверен. Или другой пример — моё имя в загранпаспорте не совпадает с моим же именем на британской визе, вклеенной в тот же загранпаспорт. В паспорте написано MAXIM, а в визе — MAKSIM. Я из-за этого границу пересекать боюсь 🙂 Прибавим к этому различие наборов состояний документа в разных системах, разные графы переходов, составные документы, включающие в себя набор других документов, электронные конверты и пр. Мы получаем задачу невероятной комбинаторной сложности. А если документ не в одно ведомство пойдет, а сразу в несколько? В одном его исполнят, в другом отвергнут, в третьем – потеряют. Потому процессные человечки очень скоро добавят к этому документу маршрут, лаконично выраженный в нотации BPMN на десятке страниц. Исключения, возвраты, отмены, неверные результаты проверки ЭЦП, недоставленные квитанции, просроченные ключи… Матрица отдыхает (зато программисты продолжают работать)

Интеграция приложений - вопрос, который рано или поздно встает перед ИТ-подразделением любой организации, в которой этих приложений больше одного. Вот далеко не полный перечень задач, укладывающихся в понятие «интеграция»:

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

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

Интеграция по типу «точка­точка»

Задача интеграции «точка­точка» относительно проста. Нужно понять, каким образом каждая из двух взаимодействующих систем готова передавать и получать данные, создать соответствующие технические решения для обращения к этим интерфейсам, а также реализовать механизм преобразования данных из формата системы­источника в формат системы­приемника. В лучшем случае информационные системы предоставляют для интеграции специальный программный интерфейс (API), а в худшем - чтение и запись информации приходится производить непосредственно в базу данных приложения. В результате возникает локальное интеграционное решение - некий обособленный программный модуль собственной разработки со всеми вытекающими требованиями к его обслуживанию и поддержанию актуальности.

Интеграция «точка-точка»

Это не составляет большую проблему до тех пор, пока интеграций «точка­точка» мало - одна-две. Однако практика показывает, что количество интеграций «точка­точка» имеет склонность возрастать, а качество управления этими интеграциями - наоборот, стремительно падать. Причин тому много: возрастает число модулей интеграции, из организации уходят разработчики, делавшие тот или иной модуль, изменяются форматы данных в интегрируемых системах и т.д. Печальным итогом эволюционного развития интеграций «точка­точка» является сложнейший «фарш» интеграционных взаимодействий между приложениями предприятия, отношение к которому сотрудников ИТ-подразделения проще всего выразить в нескольких словах: «Пока работает - лучше не трогать». Однако такая ситуация не устраивает ни само ИТ-подразделение, ни бизнес-заказчиков.

Интеграционный «фарш»

Единая сервисная шина

Пережив несколько поколений различных подходов к интеграции приложений, мировая индустрия программного обеспечения пришла к концепции единой сервисной шины предприятия (Enterprise Service Bus, ESB). С точки зрения архитектуры, ESB - это программное решение, обеспечивающее взаимодействие всех интегрируемых приложений через единую точку, единообразно, предоставляя разработчикам и администраторам унифицированные и централизованные средства разработки, тестирования и контроля протекания всех интеграционных сценариев.

Основными компонентами, составляющими современную сервисную шину, являются:

• брокер сообщений - это высокопроизводительная магистраль для обмена сообщениями в унифицированном формате между приложениями в режиме реального времени;
• адаптеры - технологические адаптеры и адаптеры к бизнес-системам обеспечивают взаимодействие с приложениями в том формате, который для них приемлем, представляя информацию из этих сообщений в унифицированном формате, воспринимаемом брокером - чем больше различных адаптеров предоставляет та или иная интеграционная платформа, тем больше шансов, что для ее внедрения в вашей организации не потребуется дополнительных работ по созданию адаптеров, специфичных для ваших систем;
• среда разработки интеграционных сценариев - чем проще и быстрее происходит разработка сценариев интеграции, тем меньше вложения средств в эту разработку, а следовательно, быстрее возврат от вложенных средств. Современная интеграционная шина предоставляет в распоряжение разработчика визуальные средства конструирования интеграционных сценариев, позволяющих в большинстве случаев обходиться без низко­уровневого кодирования;
• SOA-средства - следование принципам сервис-ориентированной архитектуры является безусловным стандартом для всех интеграционных решений типа «единая сервисная шина» (что понятно по его названию). Информационные системы рассматриваются здесь как поставщики и потребители сервисов, все опубликованные в шине сервисы помещаются в единый реестр с возможностью повторного использования и управления политиками, связанными с сервисами;
• различные инструменты контроля и управления (аудиты, протоколирование, централизованный мониторинг, контроль соблюдения соглашения об уровне услуг и т.д.).

Преимуществами использования единой сервисной шины можно назвать:

• масштабирование - возможность строить решения любого размера и нагруженности;
• гибкость - возможность реализовывать и изменять интеграционные сценарии без существенного вовлечения разработчиков;
• безопасность - встроенные средства аутен­тификации и авторизации обеспечивают контроль доступа к сервисам на уровне самой шины, избавляя разработчиков интеграционных сценариев от задач по реализации этих механизмов;
• использование открытых стандартов - позволяет уменьшить вовлеченность дорогостоящих специалистов по проприетарным технологиям;
• централизация средств контроля и администрирования - позволяет избежать «размытия» точки ответственности за интеграционные сценарии, обеспечить оперативное наблюдение и раннее оповещение в случае сбоев.

Еще одним важным требованием к функционалу ESB-среды является возможность реализации интеграции с внешними организациями - бизнес-партнерами, поставщиками, корпоративными клиентами, удаленными филиалами. Особенностями такой интеграции является непредсказуемое качество каналов, отсутствие гарантий доставки информации и слабая готовность к интеграции как таковой - как правило, организация-партнер предоставляет очень ограниченный спектр форматов обмена данными. На этот случай в составе интеграционной шины должно присутствовать средство построения B2B-взаимодействия, позволяющее осуществлять информационный обмен по открытым, в том числе отраслевым, стандартам, обеспечивать гарантированную доставку, обладать средствами настройки информационного обмена в разрезе конкретного бизнес-партнера и, конечно же, работать в полном соответствии с принципами самой интеграционной платформы, изолируя разработчика интеграционных сценариев от технических деталей взаимодействия с партнером.

Enterprise Service Bus

Управление бизнес-процессами

Существенная доля интеграционных сценариев подразумевает, что в информационный обмен вовлекаются не только приложения, выступающие в роли источников или приемников информации, но и люди - сотрудники организации, выполняющие различные задания или принимающие решения. В этом случае мы можем говорить о выходе за рамки «чистой» интеграции и появлении в фокусе нашего внимания новой сущности - бизнес-процессов, а в требованиях к интеграционной платформе - новой функциональности по управлению бизнес-процессами (Business Process Management, BPM). При наличии BPM-требований интеграционная платформа должна предоставить в распоряжение разработчика:

• средство визуального проектирования бизнес-процессов - оптимально, чтобы этими средствами могли воспользоваться люди, далекие от ИТ, - например бизнес-аналитики или методологи. Кроме того, чрезвычайно полезным является возможность переноса моделей бизнес-процессов из специализированных средств моделирования в среду разработки. Это же средство должно давать возможность проектировать формы заданий для участников процессов, причем максимально ограждая разработчиков от программирования;
• среду исполнения бизнес-процессов - специальный движок, обеспечивающий обработку бизнес-правил, передачу заданий между пользователями и информационными системами в соответствии с разработанными моделями бизнес-процессов, а также обработку исключительных ситуаций (например, превышения исполнителем времени, отведенного для выполнения задания);
• портал участников бизнес-процессов - специализированный портал, позволяющий пользователям запускать процессы, участвовать в них, контролировать ход запущенных процессов и осуществлять административные воздействия в соответствии с установленными для них правами;
• средства мониторинга и контроллинга. Возможность оперативного и ретроспективного анализа протекания бизнес-процессов - важная часть любой платформы BPM.

На данный момент многие производители ПО склонны объединять BPM-среду и интеграционную шину в единую платформу промежуточного ПО, убирая существовавшее несколько лет строгое разделение между BPM-системами и средствами для интеграции приложений. Такой подход очень прогрессивен. Некоторые вендоры идут еще дальше и присоединяют к платформе профессиональные средства для моделирования бизнес-процессов. Пионером в этом является компания Software AG, предлагающая решение, объединяющее в себе известное средство моделирования ARIS Platform и интеграционную/BPM среду webMethods.

Комплексное использование интеграционной платформы

Предложения на рынке

На текущий момент можно выделить три группы предложений ПО для построения ESB. Эти группы разнятся как по цене, так и по предлагаемой функциональности.

Первая группа - предложения от фирм, чьи продукты лидируют в исследованиях аналитических агентств по всем обозначенным в статье категориям (ESB, SOA Governance, BPM, B2B). В эту группу входят:

• IBM с линейкой продуктов WebSphere;
• Software AG c интеграционной платформой webMethods;
• Oracle с целой серией предложений;
• Tibco с линейкой Business Integration.

В принципе, тем, кто не любит компромиссы, можно выбирать любого из этих производителей - все перечисленные компании предлагают полноценные линейки продуктов (правда, в случае с Oracle не всегда понятно, о каком именно продукте идет речь, поскольку после покупки ряда компаний Oracle предлагает сразу несколько продуктов, не всегда в достаточной степени интегрированных между собой). Немного особняком стоит Tibco, так как размер этой компании гораздо меньше размера остальных участников данной четверки, что может вызвать некоторые сомнения в ее стабильности. Software AG - пока не очень известный на российском рынке производитель, но у платформы webMethods, которая является сегодня ключевым предложением этой компании, большой потенциал. IBM и ее продукты знают и используют уже очень многие предприятия, но у некоторых из них возникают претензии по стоимости самого внедрения и обслуживания системы.

Вторая группа предложений - это компании, сконцентрированные в основном на «чис­том» ESB-функционале и достигшие здесь успеха. В эту группу попадают: Sun (Glassfish), Progress (Sonic) и Fujitsu.

Предложения от этих компаний хороши, если вы не собираетесь расширять сферу применения своей платформы в сторону BPM и/или B2B. В противном случае вы рискуете оказаться наедине с недостаточно проработанной функциональностью и существенно увеличить свои расходы на ее доработку до соответствия своим потребностям.

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

Заключение

В заключение хотелось бы дать читателям несколько простых советов по выбору интег­рационной шины:

• задумывайтесь о построении интеграционного решения, не дожидаясь, когда проблемы взаимодействия приложений прижмут вас к стенке. Чем больше завал, тем сложнее его разгребать;
• тщательно подойдите к выбору платформы. Ищите вендора, который удовлетворяет вас по всем позициям, благо сейчас есть из чего выбрать. Вас должны интересовать и технологические параметры платформы, и методологические аспекты внедрения;
• думайте о перспективе. Функциональные требования, которые осознаются вами сейчас, могут существенно измениться через год, и если платформа не будет их удовлетворять, то вам придется «переезжать» на другую. А один переезд, как известно, равен двум пожарам.

При интеграции корпоративных систем возникает задача управления справочными данными. Для решения этой задачи часто используется Master Data Managment(MDM). MDM - это хранилище, которое содержит “эталонные” справочные данные, так называемые “золотые записи”. Справочники в MDM содержат очищенные полные и непротиворечивые данные.

Часто MDM используется как платформа для централизованного ведения справочников. Ввод и валидация справочных данных производится в MDM, а оттуда они реплицируются в IT-системы. Такой подход имеет несколько проблем

• Создать эталонную модель данных, которая подойдет всем системам не так-то просто.
• Справочные данные становятся оторванными от приложений.
• Репликация данных из MDM часто требует серьезной доработки систем. Для систем “из коробки” такая доработка может быть очень дорогой.

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

Трансформация на интеграционной шине.

Мы используем второй подход. Все взаимодействия бизнес-систем происходят через интеграционную шину. Шина (в нашем случае Oracle Service Bus) трансформирует сообщение, которое посылает система Поставщик, в сообщение, понятное системе Потребителю. Такая трансформация включает мапирование значений справочников.

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

(source_system, source_value, valid_from, valid_to, target_system, target_value)

Данные в справочниках меняются очень редко, а используются очень часто. Чтобы не обращаться каждый раз к базе данных, справочники кэшируются на шине, причем в формате, который шина может сразу использовать.

Для кэширования мы используем . Это очень и очень платный продукт. Однако, в данном случае все его мега-функции не используются, поэтому его вполне можно заменить на бесплатное решение (например, hazelcast). Подробнее про coherence можно прочитать . Также лицензия на coherence входит в различные Oracle Suite.

Использования кэша имеет очевидные преимущества:

• данные хранятся в памяти
• данные хранятся в сериализованном виде
• данные могут быть проиндексированы
• синхронизация с базой данных может быть проведена асинхронно

Кэш является распределенным и синхронизация между узлами производится самим Coherence. При добавлении или удалении сервера кластер производит ребалансировку данных между узлами.

Для справочных данных используется схема Distributed Cache Map. Во время старта Oracle Service Bus создается кэш внутри JVM, который держит данные в памяти. На каждом физическом сервере имеется coherence сервер, который хранит справочники (в памяти и на диске) и синхронизируется с базой данных.

При трансформации osb workflow обращается к coherence через Java callout. Можно также обращаться через вызов Enterprise Java Bean.

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

Поддержка различных стандартов и сценариев интеграции с помощью интеграционной шины данных

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

В DATAREON ESB существуют следующие типы коннекторов:

• Коннектор SOAP-сервисов, включая web-сервисы «1С:Предприятие 8»
• Коннектор REST-сервисов, включая web-сервисы «1С:Предприятие 8»
• Коннектор MS SQL
• Коннектор IBM DB2
• Коннектор Oracle
• Коннектор PostgreSQL
• Коннектор SharePoint
• Коннектор OData 1C
• Коннектор TCP
• Коннектор Siemens Team Center
• Коннектор SAP и другие.

Все коннекторы имеют возможности параметрической настройки подключения к системе-источнику и взаимодействию с ней.

Список доступных коннекторов постоянно расширяется, полный перечень необходимо уточнять в компании DATAREON .

В составе DATAREON ESB присутствует механизм, позволяющий самостоятельно разрабатывать различные коннекторы на языке Java или языках платформы.Net. Таким образом может быть реализован любой пользовательский сценарий подключения к системам-источникам.