Комментарий: Использование модели адаптеров сервисов для создания более гибкой и простой в эксплуатации ESB

Интеграция нескольких систем по принципу точка-точка может оказаться очень трудоемкой и дорогостоящей в эксплуатации. Один из общих подходов к решению этой проблемы заключается во внедрении сервисной шины предприятия (Enterprise Service Bus - ESB), которая заменяет соединения точка-точка единым центром интеграции систем и делает это сервис-ориентированным способом. Однако в случае неправильной реализации этого подхода проблемы, связанные с необходимостью технического обслуживания остаются. Здесь описана модель, которая поможет поддерживать интегрированную систему на современном уровне, позволяя модернизировать или заменять устаревшие компоненты без чрезмерных дополнительных усилий. Из журнала IBM WebSphere Developer Technical Journal.

Пол Илечко, старший архитектор решений, IBM

Пол Илечко работает старшим архитектором решений подразделения услуг программного обеспечения для WebSphere IBM. Имеет более чем 25-летний опыт работы в ИТ-индустрии, в том числе в области мейнфреймов и распределенных технологий. Занимается WebSphere и J2EE почти с самого момента их создания. Его основная задача – помогать клиентам IBM успешно работать с этими продуктами. Получил степень бакалавра математики в Лондонском университете.



27.06.2012

Планирование на будущее

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

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

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

В идеале, когда в архитектуру вводится ESB, все приложения, которые обеспечивают необходимые функции, должны предоставлять их в виде Web-сервисов. Эти Web-сервисы будут предоставлять артефакты WSDL и XSD в соответствии с корпоративными стандартами и могут устанавливаться как proxy-сервисы ESB. Клиенты используют реестр сервисов для поиска соответствующей конечной точки обслуживания в сети и обращаются непосредственно к ней. Реализация ESB использует соответствующие правила маршрутизации, чтобы найти ту версию сервиса, которая поддерживает клиента. Однако во многих случаях такой изящный, чистый подход к интеграции оказывается невозможным. В числе проблем могут быть:

  • поддержка приложением только какого-нибудь другого протокола, такого как очереди сообщений, и отсутствие времени или средств на его переработку для поддержки Web-сервисов;
  • приложение в виде системы пакетной обработки, которая может только обмениваться файлами и не поддерживает взаимодействие на основе сообщений или транзакций;
  • готовое приложение с фиксированными форматами данных, которые нельзя модифицировать для взаимодействия с нужными приложениями. Типичным примером может служить клиентская часть eCommerce системы IBM® WebSphere® Commerce, которую нужно интегрировать с системой SAP, поддерживающей связь только через iDoc или BAPI.

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


Сервисная архитектура

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

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

Лучшим решением этой проблемы служит определение "чистого" канонического сервиса, который представляет собой идеализированный вариант того, как выглядел бы сервис, если бы все внешние приложения можно было бы модифицировать для поддержки Web-сервисов. Это отражено на рисунке 1.

Рисунок 1. Описание рисунка 1
Рисунок 1.

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

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

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

Чтобы обеспечить более гибкую среду выполнения, для поддержки динамического поиска конечной точки может использоваться реестр сервисов, такой как IBM WebSphere Registry and Repository. Это поможет управлять качеством обслуживания и требованиями SLA. WebSphere Registry and Repository может использоваться как средство разработки для обеспечения управления сервисами и жизненным циклом.

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=823167
ArticleTitle=Комментарий: Использование модели адаптеров сервисов для создания более гибкой и простой в эксплуатации ESB
publish-date=06272012