Тестирование ESB-пакетов.

Лори Мак-Витти
Старший технический редактор журнала Network Computing.
С ней можно связаться по e-mail: lmacvittie@nwc.com

Интерес к системам, называемым корпоративными сервисными шинами (enterprise service bus, ESB), сейчас на подъеме, поэтому мы (совместно с Network Computing) решили разобраться, что происходит в этой области. С таковой целью сотрудники центра тестирования бизнес-приложений установили и протестировали ESB-пакеты восьми поставщиков.

Нетребовательность как идеал

Прочная инфраструктура для архитектуры SOA (service-oriented architecture) предполагает и обеспечение, и оркестровку сервисов: это обязательное условие корректной поддержки бизнес-приложений, предназначенных для предоставления услуг. Системы ESB относятся к уровню оркестровки сервисов: они выстраивают элементарные сервисы (образующие уровень сервисов) в бизнес-сервисы, используемые на уровне бизнес-процессов. Тому, кто занимается обеспечением элементарных сервисов, необходимы техническая подготовка и умение программировать, но с ESB реализация преимуществ SOA должна быть доступна даже пользователю-непрограммисту без специальных технических навыков. Применение принципов SOA означает, что при оркестровке применяются открытые стандарты и описания на основе метаданных. Жестко закодированные и тесно связанные с конкретной средой решения уничтожают ту гибкость, которую обещает SOA, и, следовательно, противоречат ее принципам.

Для работы с хорошей реализацией ESB не нужно владеть специфическими технологиями, такими как JMS (Java Message Service) или другая система передачи сообщений, — достаточно знать только языки и технологии SOA, такие как WSDL, XPath, SOAP, WS-Security. Хорошо бы, конечно, получить стандартный язык моделирования, но это условие не является обязательным, если продукт не требует программирования и обеспечивает основные функции ESB, т. е. маршрутизацию, преобразование, интеграцию сервисов, работающих по разным протоколам, и предоставление оркестрованных сервисов в Web (по протоколу HTTP или JMS).

Детали связей

Чтобы оркестровать сообщения, не обязательно понимать, как работает шина передачи сообщений. Большинство протестированных продуктов порадовали нас хорошим уровнем абстрагирования, однако предложение Sonic Software разочаровало решением выдать администратору сервисов большую дозу конфигурационных режимов и терминов из области работы с сообщениями. Мы должны были не только иметь представление о конечной точке JMS, нам пришлось еще разбираться в подробностях реализации качества обслуживания (quality of service, QoS) в этих конечных точках, чтобы оркестровка не получилась неправильно сконфигурированной.

Хотя все продукты требовали некоторой магистрали передачи сообщений, а по умолчанию — очереди сообщений или определенной реализации JMS (второе характерно для продуктов таких компаний, как TIBCO и IBM, вкладывающих значительные средства в обработку сообщений), ни один не навязывал нам механических деталей в такой деспотичной манере, как Sonic. Для работы с тремя продуктами (от Software AG, Sonic и TIBCO) необходимо было знать больше, чем, на наш взгляд, нужно, об устройстве формата WSDL (Web Services Definition Language), используемого для предоставления оркестрованных сервисов через Web. При работе с пакетом TIBCO нам не пришлось перенастраивать значения по умолчанию для типа порта, составных частей сообщения и параметров построения связей, но все же он дает доступ ко всем этим мелочам, так что у пользователя, не имеющего надлежащей подготовки, может возникнуть соблазн их модифицировать. Видимо, автоматическое выкладывание, реализованное в программах Oracle, BEA и CapeClear, — более удачное решение, чем то, которое предлагают Fiorano, Software AG и Sonic, где перед тем, как предъявить сервис окружающему миру, для него необходимо построить WSDL-код. Само собой разумеется, нас нисколько не обрадовало то, что в продукте Fiorano при создании WSDL нужно использовать данные, специфичные для предметной области, — заголовки JMS.

Принудительное кодирование

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

Оркестровка сервисов без кодирования означает, что для их перемещения из одного окружения в другое нужны только метаданные. Было бы еще лучше, если бы метаданные обеспечивали взаимодействие между реализациями шины, однако для этого необходим стандартный общепринятый язык метаданных, а он вряд ли появится в обозримом будущем. BPEL (Business Process Execution Language) — главный кандидат на роль языка взаимодействия для описания оркестровок — не является стандартным, а версия 2.0, которая, как ожидается, будет утверждена в качестве стандарта, в корне отличается от ныне действующей 1.1.

На роль своего основного языка оркестровки BPEL 1.1 выбрали только Oracle и Cape Clear, его вторичную поддержку предлагают Fiorano и TIBCO. Компании IBM и BEA рассматривают BPEL как язык уровня бизнес-процессов, и понятно, почему: в BPEL 2.0 должно появиться управление ручными операциями, отсутствующее в версии 1.1 и обязательное для BPM-систем. Но как бы то ни было, без BPEL или другого принятого стандарта мы остаемся один на один со множеством вариантов описания метаданных для оркестровки сервисов, которые нельзя легко перенести из одной системы в другую. В результате поставщик замыкается в пределах собственных продуктов.

Но даже без стандартного языка метаданных большинство протестированных продуктов все же фактически предлагают среду оркестровки сервисов, позволяющую обойтись без кодирования. В AquaLogic Service Bus компании BEA эта среда не только бескодовая, но и независимая от клиента: для оркестровки сервисов, составленных как из внутренних, так и из внешних элементарных услуг, необходим только Web-браузер.

Не все продукты не требуют кодирования и не все базируются исключительно на метаданных. К примеру, в ESB 6.5 компании Cape Clear используется кодогенерирующая среда на основе Eclipse, в которой код компилируется и вместе со связанными с ним библиотеками (файлы JAR) устанавливается на ESB-сервере. В SOA Suite компании Sonic простая маршрутизация по контенту в рамках оркестровки должна программироваться на JavaScript, а в IBM Message Broker 6.0 для включения в оркестровку RDBMS и электронной почты необходимо использовать язык ESQL (Extended SQL).

И хотя во всех продуктах есть средства для получения из оркестровки Web-сервиса, доступного по протоколу SOAP, только у BEA, Cape Clear и Oracle они работают совершенно гладко и полностью автоматически. В остальных пакетах вы вручную добавляете эту возможность к оркестровке, которая, в свою очередь, регистрирует сервис как доступный для внешнего потребления. Процедура, посредством которой оркестровка превращается в Web-сервис, зависит от продукта, но во всех случаях в ней участвует генерация WSDL-кода, а определить требования WS-Security можно только в одной системе — Enterprise Service Integrator компании Software AG.

Опыт трансформации

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

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

В реальности же и IBM WebSphere Message Broker, и Sonic SOA Suite, и ESI компании Software AG требуют, в зависимости от ситуации, ручного написания выражений XSLT, XPath или и тех и других. (Вы можете не считать эту работу кодированием, но все равно вас вряд ли обрадует перспектива ею заниматься.) В остальных тестировавшихся продуктах имеются визуальные средства, обеспечивающие построение выражений XPath, а в большинстве случаев ещё и генерацию XSLT-кода для отображения данных между шагами оркестровки. Как правило, отображение задается путем перетаскивания: пользователь захватывает поле исходного документа и переносит его в нужное поле выходного, а система при этом генерирует выражения XPath и XSL для выбора исходных данных и копирования их в указанном поле.

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

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

Из всех рассмотренных нами решений по отображению Mapper компании Fiorano — возможно, самое элегантное и наиболее близкое к нашему идеалу. Это полностью визуальный механизм для определения выражений XPath и включения функций XSL для преобразования данных на каждом шаге. Oracle и Cape Clear также предлагают визуальные методы, но они уступают тому, что мы находим у Fiorano, по доскональности и простоте использования. А вот продукт BEA нас озадачил. При том, что в целом реализованное в нем решение максимально абстрагировано от мелких деталей, для работы с механизмами отображения необходимо хорошо разбираться в XQuery/XPath, — а мы не считаем, что этого можно требовать от оркестровщика сервисов.

Хрупкость и неуклюжесть

Для оркестровки сервисы должны регистрироваться. Для обеспечения этой процедуры в продуктах используется ряд механизмов, включая как встроенные реестры UDDI (в продуктах BEA, Cape Clear, Fiorano, Oracle и Software AG), так и фирменные решения (у IBM, Sonic Software и TIBCO). Ряд поставщиков (в том числе BEA, Fiorano и Oracle), что не удивительно, перепродают популярный реестр Systinet Business Service Registry. В решении IBM реестр на стадии проектирования почти не используется — он нужен только для того, чтобы разрешить импорт внешних Web-сервисов. Фактически это был единственный способ, с помощью которого нам удалось при использовании продукта IBM интегрировать в оркестровку внешний Web-сервис.

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

Четыре победителя

После нескольких месяцев тестирования мы выделили в качестве лучших четыре ESB-продукта: BEA, Fiorano, Oracle и TIBCO. Хотя у Fiorano выкладывание оркестрованных сервисов в Web реализовано не без странностей, в целом пакет этой компании производит очень хорошее впечатление. Продукты Oracle и BEA ближе всего подошли к тому, что мы хотели бы видеть в ESB, а TIBCO недостает лишь нескольких мелочей, чтобы достигнуть в оркестровке сервисов того же уровня легкости, что и у двух гигантов рынка ПО.