Все новости от 10 октября 2003 г.

Проблемные направления: для разработчика

Трансформация данных. При традиционном интеграционном подходе эту функцию обеспечивает брокер сообщений. Переход на Web-сервисную архитектуру не снимает задачу преобразования данных с повестки дня.

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

Рис. 3. Будущий стек технологий Web-сервисной интеграции

Средства для графического построения схем преобразования данных предоставляются большинством современных платформ интеграции, поддерживающих технологию WS, -- Microsoft BizTalk Server, SunONE Integration Server, BEA Integration Platform, IBM MQ Message Broker, Oracle9i AQ и т. п.

Правила конвертации сохраняются пока в разных форматах (например, в виде Java-кода в IBM InterChange Server), но в будущем неминуем сдвиг к обмену исключительно XML-форматированными документами, с преобразованием при помощи таблиц стилей XSLT (eXtensible Stylesheet Language Transformations), механизмов запросов к базам данных XQuery и путей XPath.

Серверы SunONE Intergation Server и Microsoft BizTalk уже сегодня используют XML для внутреннего представления сообщений и XSLT для их конвертации.

Адаптеры. На сегодня большинство крупных производителей бизнес-ПО объявили о переходе к WS-архитектуре. В качестве примеров можно привести Baan, новая ERP-платформа Gemini которой будет иметь Web-сервисный API, и SAP AG, заявившую о переходе к архитектуре xApps на базе WS.

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

Асинхронность. Современная архитектура WS не предполагает подобной возможности: Web-сервисы можно вызывать только синхронно. Что касается средств асинхронного взаимодействия, то наборы XML-стандартов RosettaNet и ebXML включают и спецификации на гарантированный обмен сообщениями, однако SOAP, лежащий в основе WS, не предусматривает ни гарантированной доставки, ни многоузловой маршрутизации.

Недавно компании webMethods, Microsoft, IBM, Intel и другие предложили создать рабочую группу в W3C, которая займется решением этих проблем SOAP.

В рамках организации OASIS уже действует комитет Web Services Reliable Messaging, призванный создать "общую и открытую модель" для гарантированной доставки сообщений Web-сервисам.

Пока же решения можно создавать только при помощи интеграционных шин. Например, российский продукт "Юпитер" компании ИВК предлагает прокси-компонент, позволяющий территориально удаленным приложениям вести сессии по протоколу HTTP (который SOAP использует в качестве транспорта) с гарантированной доставкой пакетов.

Важно только правильно оформить вызов к Web-методу. Но для удобства работы с асинхронным обменом сообщениями требуется поддержка на уровне языка программирования и платформы исполнения, а эта поддержка не всегда имеется. Так, Java API for XML Messaging (JAXM) пока обеспечивает вызов Web-сервиса только синхронным способом.

Транзакционность. Web-сервисы не предусматривают возможности "отката" внесенных изменений, они по природе своей атомарны: сервис отработал, и состояние объекта, с которым он связан, изменилось.

Нет также никаких стандартов, определяющих, как можно распространить контекст большой транзакции внутрь Web-сервиса.

Сейчас в мире делается ряд попыток создать необходимую базу спецификаций для координации транзакций. Первая такая попытка была предпринята в 2000 г., когда Oracle, IBM, Hewlett-Packard, Sun Microsystems и др. образовали организацию XAML. Она должна была разработать спецификацию одноименного языка (Transaction Authority Mark-up Language) для описания правил координации и исполнения транзакций, построенных на базе XML-ориентированных Web-сервисов.

Однако Microsoft не поддержала этого начинания и оно закончилось ничем: несколько лет о проекте нет новостей, а теперь даже сайт xaml.org перестал функционировать, а аббревиатура XAML используется Microsoft для обозначения совсем другой технологии.

Примерно тогда же BEA предложила аналогичный протокол Business Transaction Protocol (BTP), который подала на утверждение в OASIS. Предполагалось сделать акцент на его совместимость с ebXML и RosettaNet. Им теперь занимается одноименный комитет этой организации, одобривший версию 1.0 в мае 2002 г. в статусе "спецификации комитета".

Нынешним летом был предложен еще ряд решений. Группа компаний, возглавляемая Sun Microsystems и Oracle, анонсировала проект Web Services Composite Application Framework (WS-CAF; ) и сразу же передала его на попечительство соответствующего технического комитета в OASIS.

Выдвинуто три спецификации, описывающие механизм координации транзакций в многошаговых бизнес-процессах: Web Service Context (WS-CTX), Web Service Coordination Framework (WS-CF) и Web Service Transaction Management (WS-TXM).

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

Однако этот проект пока не поддерживают IBM и Microsoft, причем последняя уже отказалась в нем участвовать. Год назад Microsoft предложила свое решение проблемы WS-транзакций -- WS-Transaction (WS-Tx). Она же предлагает в своей платформе .Net протокол многоузловой маршрутизации WS-Routing.

Динамическое согласование параметров запроса. Эта задача, возникающая при проектировании систем электронного бизнеса, также пока не решена с помощью стандартов WS.

Попытки создать необходимую базу стандартов делаются в рамках консорциума ebXML, в котором для этого разрабатывается спецификация Collaboration-Protocol Profile and Agreement (CPP/CPA, текущая версия 2.0).

Workflow и управление бизнес-процессами. Современный уровень развития WS не обеспечивает стандартных механизмов описания на XML бизнес-процессов, состоящих из обращений к Web-сервисам и организации составных сервисов.

Пока на рынке есть лишь ряд технологий, эту задачу решающих. Например, XLANG, используемая в Microsoft BizTalk Server, ebXML Business Process Schema Specification (BPSS) и Web Services Business Process Execution Language (BPEL4WS), поддержка которой должна появиться в BizTalk Server2004.

Корпорация IBM, со своей стороны, предложила спецификацию Web Services Flow Language (WSFL), которая позволяет описать сервис, состоящий из более мелких сервисов.

Для описания бизнес-процессов иногда применяют и спецификацию RosettaNet PIP, хотя она не заточена под модель WS, да к тому же является "бумажной" (т. е. не машинно-обрабатываемой).

Сейчас BPEL4WS проходит утверждение в организации OASIS и в будущем, вероятно, станет основным стандартом на подобные вещи.