Единица работы

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

В примере, связанном с продажей или покупкой акций, онлайновая торговая компания вступает во взаимодействие с различными Web-сервисами, которые предоставляют сторонние организации (например, Web-сервис кредитных карт). Если возникает исключительная ситуация или Web-сервис не может выполнить транзакцию ни с каким из сторонних провайдеров, то он должен вернуться к предыдущему состоянию. Это достигается с помощью использования элементов транзакции и компенсации (<compensation>). В листинге 4 показан пример соответствующего кода.

Как WSC может помочь

WSC помогает справиться со всеми вышеназванными сложностями, возникающими при интеграции процессов, путем использования WSDL как базовой основы и расширяя его функциональные возможности (рис. 3). В следующих разделах объясняется, как WSCI справляется с этими недостатками.

Рис. 3. Торговля акциями с помощью WSC

Контекст

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

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

В листинге 1, приведенном ниже, определение локального процесса имеет различные контексты для продажи и покупки акций. Если в процессе покупки акций случается ошибка, то она не выходит за рамки этого процесса. А, например, если контексты не определены, то ошибка в процессе продажи может прервать доступ пользователя к Web-сервису вместо того, чтобы перенаправить это состояние в состояние продажи (placeSellOrder). Ниже приведен фрагмент определения WSCI:

Пример элемента контекста

Пример элемента последовательности

Пример элемента взаимодействия

<correlation name = "buysellCorrelation"

property = "tns:placeOrderId" />

Пример элемента транзакции

<action name = "reverseBuyOrder"= "tns:trader"=

"tns:reverseBuyOrder"/>

</compensation>

</transaction>

Транзакция может быть вызвана в элементе компенсации в том случае, когда возникает исключительная ситуация:

<onTimeout property = "tns:confirmationTime"= "duration"=

"tns:PlaceBuyOrder@end">

</onTimeout>

Пример исключения и элемента превышения лимита ожидания

<onTimeout property = "tns:expiryTime"

type = "duration"

reference="tns:ReserveSeats@end">

</onTimeout>

</exception>

Об авторе

Джером Джозефрай (Jerome Josephraj) живет в Эссексе (графство Англии). Его статья "Struts и Web-сервисы" (Struts and Web Services) была опубликована на сайте IBM. Он также является официальным рецензентом "Справочного руководства по Jakarta Struts" (Jakarta Struts Cookbook) и готовящейся книги "Web-сервисы, сейчас" (Web Service, Now). С ним можно связаться по адресу: .

Обработка исключений

В интеграции бизнес-процессов обработка исключений и выбор соответствующего пути важны так же, как и обработка стандартных вариантов. Для этого WSCI использует элементы исключений (<exception>). WSCI позволяет декларировать исключительное поведение, которое демонстрирует Web-сервис в определенный момент хореографии. Декларация исключительного поведения является частью определения контекста и связанных с ним исключений и содержит набор действий, выполняемых Web-сервисом в ответ на эти исключения. Исключения - это модельный признак WSCI, созданный для моделирования исключительного поведения Web-сервиса в определенный момент обмена сообщениями. При этом они не обязаны представлять какой-либо технический сбой.

WSCI может сгенерировать исключение на основе сообщения о сбое из WSDL, содержания сообщения или какого-либо события (например, превышения лимита ожидания). Появление такого исключения вызывает отмену текущего контекста после выполнения действий, связанных с этим исключением. Таким образом, WSCI поддерживает концепцию "восстанавливаемых исключений" (recoverable exceptions), которые не вызывают отмены всей хореографии (что похоже на концепцию throw/catch в JavaTM). Но появление сбоя, для которого не определено никакого исключительного поведения, вызывает отмену контекста и появления сбоя в родительском контексте. Более абстрактно, исключение, связанное с обработкой поведения, определенного в родительском контексте, может работать как поведение по умолчанию для всех своих потомков, и наоборот: исключение, связанное с обработкой поведения, определенного в дочернем контексте, может замещать исключение, связанное с обработкой поведения, определенного в своем родителе.

Как показано в листинге 5, если подтверждение заказа занимает более минуты, приложение выдает сообщение о превышении лимита ожидания. В WSC это осуществляется с помощью операции о превышении этого лимита. Элемент превышения лимита ожидания (<onTimeout>) фактически является событийным элементом, который используется внутри элемента исключения. Через минуту возникает событие превышения лимита ожидания, и система использует элемент компенсации для возвращения к прежнему состоянию размещения заказа на покупку (placeBuyOrder).

Онлайновая компания, использующая Web-сервисы

Необходимость и роль WSC лучше всего можно увидеть на простом примере торговли акциями. Для краткости автор предлагает рассмотреть основные действия, из которых состоит этот процесс. Все шаги покупки и продажи акций не будут рассматриваться, т.к. это выходит за рамки статьи. Вместо этого предлагается простой пример приложения для торговли акциями. На рис. 1 показаны все шаги бизнес-процесса, необходимого для того, чтобы продавать и покупать акции, используя онлайновое Web-приложение.

Рис. 1. Бизнес-процесс торговли акциями

Определение последовательности процессов

Для того чтобы элементарные бизнес-процессы вызывались в определенной последовательности и были сгруппированы в рамках более глобального бизнес-процесса, WSC использует последовательность элементов интерфейса. Как видно из названия, это действие обеспечивает вызов системой процессов в определенной последовательности. Когда пользователь сервиса хочет купить акции, элемент интерфейса вызывает операцию перевода денег раньше, чем собственно процесс покупки. Это достигается определением всех операций, вызываемых последовательно, в рамках элемента последовательности (<sequence>), как это показано в листинге 2.

Практическая хореография Web-сервисов

Джером Джозефрай (Jerome Josephraj)
Перевод:

Оригинал: Web services choreography in practice

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

Пример использования

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

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

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

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

Для того чтобы увеличить число бизнес-каналов и иметь возможность сотрудничать с другими системами, онлайновая торговая компания может представить приложение Купить/Продать (Buy/Sell) как Web-сервис. В случае простого Web-сервиса шаги, перечисленные выше, могут быть преобразованы ("мэппированы") в операции в WSDL-файле. Используя программное обеспечение для Web-сервисов, например, редактор Microsoft VBA или внешнее приложение, вызывающее Web-сервис, пользователь может вызывать эти операции, описанные на WSDL, для того, чтобы разместить заказ на продажу или покупку. Пример того, как выполнить эту задачу с помощью VBA, можно найти по следующей ссылке: http://www.microsoft.com/office/previous/xp/webservices/toolkit.asp. На рис. 1 показаны операции, описанные на WSDL, и мэппирование между бизнес-процессами.

Проблемы WSDL

Хорошо разработанный Web-сервис для покупки и продажи акций работает нормально, если все процессы являются атомарными или, другими словами, у них нет общих состояний. Но в этом случае выполнение ряда ключевых требований к интеграции бизнес-процессов обеспечивает только посредством WSDL (рис. 2). Ниже перечислены эти основные требования:

Рис. 2. Торговля акциями с помощью WSDL

Последовательность процессов

Клиент сервиса, использующий Web-сервис купить/продать, может вызывать операции в любой последовательности. Например, клиент может обратиться к операции перевода денег до вызова операций размещения заказов на продажу или покупку (placeBuyOrder или placeSellOrder). WSDL не препятствует вызову операций в любом порядке. Приложение Web-сервиса, использующее WSDL, должно удовлетворять этому путем определенной логики, описанной выше.

Взаимосвязь сообщений

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

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

Единица работы

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

В этом примере операции размещения заказа на покупку (placeBuyOrder) и его подтверждения (confirmBuyOrder), а также процесс снятия денег (debit money) должны осуществляться как одна единица работы. Web-сервис должен успешно выполнить все три операции; в противном случае пользователю придется восстанавливать операции до состояния, соответствующего началу их выполнения. Эти операции не могут быть использованы для распределенных транзакций, выраженных с помощью WSDL. В WSDL рамки транзакции ограничены отдельными операциями и не могут охватывать более одной операции.

Обработка исключений

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

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

Контекст

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

Прочие особенности WSCI

В таблице 1 перечислен ряд других полезных возможностей WSCI. Полный список доступен в документации по WSCI.

Таблица 1. Элементы WSCI

Название элемента	Краткое описание	Пример
Выбор (selector)	Элемент выбирает значение свойства из сообщения. Он полезен для преобразования сложного сообщения в набор свойств.	Элемент выбора может быть использован для получения общего числа акций из сообщения обо всех акциях (getAllStocksResponse): <selector property = "tns:stockCount" element = "tns: ArrayOfStockList xpath = "count (./StockList)" />
Вызов (call)	Элемент вызывает произвольную операцию (например, вызов стороннего Web-сервиса) в процессе выполнения действия. Это атомарный элемент, и действие не может быть выполнено, если не выполняется вызываемый процесс.	Если приложение должно записать все транзакции для операций аудита и согласования, то для этого может быть вызван произвольный процесс: <process name = "DebitMoney" instantiation = "other"> <action name = "debitMoney" role = "tns:trader" operation = "tns:debitMoney"> </action> <call process = "auditTransactions"/> </action> </process>
Все действия (all activity)	Этот элемент похож на элемент последовательности. Все операции, определенные в элементе последовательности, выполняются, но операции, определенные в этом элементе, могут быть выполнены непоследовательно.	В этом примере заказ на покупку и снятие денег могут быть выполнены в любом порядке: <all> <operation name="confirmBuyOrder"> <input message="buySellOrderResponse"/> <output message="buySellOrderResponse"/> </operation> <operation name="debitMoney"> <input message="creditCardDetails"/> <output message="debitMoneyResponse"/> </operation> </all>
Для каждого (foreach)	Элемент выполняет действия в условном цикле. Он похож на элемент цикла в языке Java.	Элемент выполняет операцию размещения заказа на продажу (PlaceSellOrder) для каждого набора акций в общем списке (arrayOfStocks): <foreach select="ns1:arrayOfStockList/leg[position()>1]"> <process name = "PlaceSellOrder" instantiation = "other"> <action name = "PlaceSellOrder"= "tns:trader"= "tns:placeSellOrder"> </action> </process> </foreach>
Переход (switch)	Элемент осуществляет условный выбор действия из списка действий. Порядок условий очень важен; первым выполняется условие, значение которого истинно. Элемент похож на условный элемент языка Java (case statement).	Элемент выполняет соответствующее действие, когда значение условия истинно. Если условие не выполняется, элемент осуществляет операцию отказа. <switch> <case> <condition>tns:reverseBuyOrder</condition> <action name = "reverseBuyOrder" role = "tns:trader" operation = "tns:reverseBuyOrder"/> </case> <default> <action name = "confirmBuyOrder" role = "tns:trader" operation = "tns:confirmBuyOrder"/> </default> </switch>
До того, как (until)	Элемент выполняет все действия на основе значения оператора Boolean. Он выполняет эти действия как минимум один раз. Элемент похож на элемент языка Java "делай пока" (do while).	<until> <condition>tns:creditCardProcessed</condition> <process name = "DebitMoney" instantiation = "other"> <action name = "debitMoney" role = "tns:trader" operation = "tns:debitMoney"> </action> </process> </until>
Пока (while)	Элемент выполняет все действия на основе значения оператора Boolean. При этом они могут быть выполнены как один или более раз, так и ни одного. Элемент похож на элемент языка Java "пока" (while).	<while> <condition>tns:creditCardProcessed</condition> <process name = "DebitMoney" instantiation = "other"> <action name = "debitMoney" role = "tns:trader" operation = "tns:debitMoney"> </action> </process> </while>
Задержка (delay)	Элемент выполняет действие с определенным периодом задержки. Если в процессе выполнения этого действия возникает исключительная ситуация, то оно может быть завершено раньше указанного времени.	<exception> <delay property = "tns:delayTime" type = "duration" reference="tns:delayBuyingStock"> </delay> </exception>
Вызов (call)	Элемент инициирует процесс и ждет окончания его выполнения. Он полезен для вызова внутренних процессов.	<call process = "tns:audit" />
Генерирование (spawn)	Элемент инициирует процесс, но не ждет его окончания.	<Spawn process = "tns:logBuyTransaction" />
Объединение (join)	Элемент ждет окончания выполнения генерированного процесса. Если нет никаких экземпляров или все они уже выполнены, действие завершается.	<join process = "tns:logBuyTransaction" />

Ресурсы

Спецификация интерфейса хореографии Web-сервисов (Web Service Choreography Interface).

Сайт журнала Web Services Journal.

Обзор инструментов Office XP для работы с Web-сервисами: как использовать Web-сервисы в редакторе Microsoft VBA (Office XP Web Services Toolkit Tour).

"Книжный магазин разработчика" (Developer Bookstore): книги по технической тематике, в том числе по Web-сервисам (Web services titles).

Блоги разработчиков (developerWorks blogs).

Статьи и пособия по созданию приложений для Web-сервисов (SOA and Web services).

По мере того, как все

По мере того, как все больше компаний обращаются к модной сегодня технологии Web-сервисов, исследователи прогнозируют, что Web-сервисы смогут обеспечивать больше, чем просто одностороннее взаимодействие. Общая тенденция состоит в увеличении значимости композитных приложений, и корпорации все больше используют Web-сервисы как часть более сложных взаимодействий процессов. Так называемая хореография Web-сервисов (Web Service Choreography - WSC) предназначена именно для этой цели.
Интерфейс хореографии Web-сервисов (Web Service Choreography Interface - WSCI) - это описательный язык интерфейсов на основе XML, который работает "в связке" с языком описания Web-сервисов (Web Services Description Language - WSDL). Его цель - позволить корпорациям использовать возможности Web-сервисов для создания бизнес-процессов, отражающих постоянно меняющиеся требования современного бизнеса. Корпорации могут представлять свои прикладные программы и ресурсы в виде Web-сервисов для того, чтобы другие компании могли оперативно находить и использовать их в своих бизнес-процессах. Создание бизнес-процесса требует не только ясного определения моделей взаимодействия для всех его компонентов, но и нахождения способов выражения стандартных взаимодействий бизнес по схеме "бизнес-бизнес".
Далее в предлагаемой статье рассматривается, как обычная онлайновая компания, торгующая акциями, использует Web-сервисы и язык WSDL для оказания услуг, демонстрируются недостатки этого подхода и то, как они могут быть преодолены с помощью WSC. Цель настоящей статьи - объяснить, что такое WSC, дать информацию о возможностях этой технологии и рассказать о некоторых ее особенностях.

До сегодняшнего дня не существовало

До сегодняшнего дня не существовало стандартного способа описать поток сообщений, который проходит через Web-сервис, участвующий в хореографическом взаимодействии с другими сервисами. BEA Systems, Intalio, SAP AG и Sun Microsystems создали WSCI для решения этой проблемы. В статье на простом примере были описаны некоторые основные функции WSCI. Но это только небольшая часть информации. Для того чтобы лучше понять WSCI, нужно ознакомиться с его спецификацией и попробовать написать простое приложение.

Взаимосвязь сообщений

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

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

Для этого определяется элемент взаимодействия (<correlation>) и свойство (property) со своим ID. Как показано в листинге 3, в данном случае им может быть код акций.

ESB и XML

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

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

Вместе с тем стремительный рост объемов данных, подлежащих передаче, создает серьезные сложности для функционирования корпоративной информационной структуры. Так, первые интеграционные проекты, в которых использовались возможности XML, явились "живым" доказательством перспективности этого языка, однако сейчас наблюдается определенные проблемы при увеличения количества, размера и сложности XML-документов. Ниже перечислены основные причины существующих сложностей (недостаточной масштабируемости): Синтаксический разбор всего документа: как правило, требуется разбирать документы целиком, даже если для маршрутизации и фильтрования необходимо извлечь только его фрагмент. Если документы становятся большими, время ожидания увеличивается. Повторное сканирование. Документы часто разбираются повторно - на каждом этапе бизнес-процесса, другими словами, одни и те же документы могут сканироваться несколько раз. Поскольку такая практика чрезвычайно ресурсозатратна, ухудшается производительность и пропускная способность. Однонитевое исполнение. В этом случае следующий шаг обработки не может быть начат пока не завершен текущий; в результате, увеличивается время ожидания, поскольку весь процесс зависит от самого медленного шага.

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

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

Корпоративная сервисная шина - "бюджетный" подход к решению задач интеграции

Подготовлено: по материалам зарубежных сайтов
Перевод:

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

Что же такое корпоративная сервисная шина и как она соотносится с рассмотренной в предыдущих номерах Журнала Клуба знатоков DWH, OLAP и XML интеграцией корпоративных приложений (EAI)? По сложившейся традиции сначала предоставим слово экспертам в данной области.

Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня (middleware), который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция). Многие корпоративные сервисные шины также поддерживают другие стили обмена информацией, включая гарантированную доставку и "публикацию и подписку" (publish and subscribe). Сервисы, предоставляемые этими шинами, обладают "добавленной стоимостью", которой не располагают межплатформенное обеспечение, предназначенное для упрощенного обмена сообщениями, - они обеспечивают проверку сообщений, трансформацию, маршрутизацию на основе содержания, безопасность, обнаружение сервисов для сервис-ориентированной архитектуры, балансирование нагрузки и регистрацию. Некоторые сервисы встроены в основание шины, другие - исполняются в модулях расширения (plug-in). Кроме того, шины поддерживают язык XML и другие форматы сообщений.

Чем же так привлекательна корпоративная сервисная шина? Прежде всего, своей относительной дешевизной. Продукты ESB, как правило позиционируются как доступные по цене, или, как говорят, "бюджетные", решения.

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

Говоря о достоинствах корпоративной сервисной шины, стоит привести слова вице-президента и члена исследовательского отдела компании Gartner Ройя Шульте (Roy Schulte): "Обычное программное обеспечение промежуточного уровня уже не может поддерживать новые приложения, которые используют сервис-ориентированную (Service Oriented Architecture, сокр. SOA) и управляемую событиями архитектуры (Event Driven Architecture, сокр. EDA), Web-сервисы и управление бизнес-процессами. Это и является основной причиной, почему архитекторы и менеджеры информационных систем должны усилить свои корпоративные информационные инфраструктуры с помощью ESB".

Ведущий аналитик Gartner выделяет группы поставщиков ESB. К первой группе он относит продукты ESB, которые позиционируются как "бюджетные" интеграционные решения, оптимально подходящие для поддержки композитных приложений и SOA. Вторая группа - это продукты, предназначенные для рынка Web-сервисов, наконец последние - это программные средства, обеспечивающие поддержку EDA. По оценке Ройя Шульте, на протяжении следующих лет произойдет уплотнение рынка ESB, что объясняется усиливающимся спросом на Web-сервисы и многопротокольные и управляемые событиями решения.

Интересно, что в ряде компаний ESB трактуют не как категорию продуктов, а как архитектуру.

Например, в IBM корпоративную сервисную шину считают "архитектурной моделью" (architectural pattern).

Таким образом, можно констатировать, что до сих отсутствует четкое определение, что такое же ESB. Фактически, дискуссия разворачивается вокруг двух вопросов: Является ли ESB архитектурой (причем такой, которую не нужно даже стандартизировать), "односторонним подходом" или же самостоятельным продуктом. Несмотря на то, что для ряда поставщиков, не располагающих на текущий момент готовыми решениями, выгодно говорить о корпоративной сервисной шине как об архитектуре, нынешняя ситуация такова, что потребителям необходимо, чтобы предлагаемые продукты располагали функциональностью ESB. Поэтому следует ожидать в следующие два года рост числа поставщиков, предлагающих возможности ESB. Каковы место и перспективы продуктов ESB, а именно, является ли корпоративная сервисная шина более совершенной системой организации очередей сообщений, обеспечивающей простое преобразование XML, а также маршрутизацию и обмен сообщениями, или же использование адаптеров приложений, автоматизации и моделирования бизнес-процессов позволит ESB успешно заменить EAI.

На данный момент на обозначенные вопросы нет окончательных ответов.

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

Заметим, что слово "сервисная" в термине "корпоративная сервисная шина" является центральным. Так, аналитики Forrester Research рассматривают ESB как "слой промежуточного программного обеспечения, с помощью которого можно получить доступ к набору основных (многократно используемым) бизнес-сервисам". SOA позволяет представить большую часть функциональности как "сервис" в корпоративной сервисной шине, которая переправляет, преобразовывает и проверяет входные и выходные данные в формате XML, получаемые из этих сервисов.

Публикации

Бесс Голд-Бернштейн (Beth Gold-Bernstein) "Нужна ли вам корпоративная сервисная шина" (). Найджел Томас (Nigel Thomas) и Уоррен Бакли (Warren Buckley) "Появление корпоративной сервисной шины" (). Материалы, опубликованные на сайте Консорциума по интеграции ().

и оценкам аналитиков ведущих исследовательских

Судя по публикациям в зарубежных Интернет-изданиях и оценкам аналитиков ведущих исследовательских компаний, корпоративная сервисная шина уже больше не является просто новой технологией с большим потенциалом. Действительно, по прогнозу Gartner, в 2005 году большинство крупных компаний будут использовать ESB. В IDC же полагают, что корпоративная сервисная шина должна "революционизировать" информационные технологии и сделать возможным гибкую и масштабируемую распределенную обработку данных.
Действительно, поддержка открытых стандартов (и особенно XML) позволяет получить недорогое, но эффективное решение и гарантирует быструю окупаемость инвестиций, т.е высокий показатель ROI. Как отмечает вице-президент Консорциума по интеграции Стив Крэггс (Steve Craggs), "ESB является базисом для интеграции, обеспечивает гибкую и настраиваемую среду, которая позволяет плодотворно, успешно и планомерно реализовывать интеграционные проекты".
И все же неопределенность с многозначностью термина "корпоративная сервисная шина" пока сохраняется. Сегодня ESB означает любую технологию, необходимую для реализации SOA. Именно такой точки зрения придерживаются в компании ZapThink, специализирующейся на вопросах развития и применения сервис-ориентированная архитектуры. В этой связи аналитики ZapThink предупреждают, что если в 2005 году не будет выработано реального и конкретного определения корпоративной сервисной шины, термин ESB "навсегда уйдет из лексикона SOA". Что касается же самой SOA, то о ней речь пойдет в .

Быстродействие

Для тестирования быстродействия вызова веб-сервиса был включен код, отвечающий за вычисление времени, потраченного на создание proxy-сборки, на подключение к серверу и время выполнения; кроме того, для того чтобы получить более корректные результаты в ходе тестирования при повторных вызовах, был добавлен цикл while(). Этот подход позволяет исключить погрешность, обусловленную первоначальной загрузкой и инициализацией библиотек. Такой же код был включен в собранный ранее клиент C#.

Для клиента, реализованного с использованием C#, время, потраченное на вызовы, составило чуть более 2010 мс. В то время как для клиента на Java — около 2460 мс. Я не нашел логичного объяснения столь большому времени отклика, на некоторых машинах это время было меньшим на порядок и составляло около 250 мс. Но на большинстве машин, где проводилось тестирование, порядок цифр, тем не менее, оставался прежним — 2000 мс. Java-клиент, запущенный под управлением RH9 Linux, показал намного лучший результат. Время отклика в этом случае составило примерно 300 мс.

Данные приведены для Athlon 2000+ c 400 Мб RAM. Внизу представлен рисунок, демонстрирующий работу Java-клиента на Linux-системе.

Рис. 9. Результаты работы Java-клиента, запущенного под управлением RH9 Linux

Даже 0,25 с может быть многовато для некоторых критичных приложений реального времени. 2460 мс — эта величина может оказаться неприемлемой даже для очень нетребовательных приложений. На КП-диске также приведен пример простого XML-RPC-сервера и клиента с той же функциональностью, что и в первом примере. В отличие от первого примера, эта связка показала примерно одинаковые результаты — независимо от места тестирования. Время отклика в этом случае составило около 110 мс для Windows 2000, что более чем вдвое превышает показатели даже для наиболее оптимального для SOAP-сервиса случая.

Достоинства

Первое достоинство такого рода служб (которое, собственно, и является определяющим) — это простота создания. Что можно объяснить, прежде всего, существованием всякого рода кодогенераторов и визардов.

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

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

Несколько спасало положение то, что в местах, где информация должна передаваться достаточно оперативно, разработчики использовали Java Applets (в этом случае в качестве протокола можно также использовать веб-сервисы). Но в последнее время, в результате выяснения отношений с Sun, Microsoft удалила Java-машину из последних версий своих браузеров, что привело к некоторым неудобствам на стороне пользователя, который теперь вынужден загружать Java-машину отдельно. То же самое касается Flash- и SVG-технологий.

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

Недостатки

Хотелось бы сразу отметить, где можно использовать подобные приложения и где их использование не желательно.

Прежде всего, если вы создаете приложение реального времени, то вам, вероятно, придется отказаться от применения этой технологии в пользу сокетов, DCOM, Remouting, RMI или других протоколов-оберток для создания распределенных приложений. Это объясняется достаточно большим временем отклика и некоторой избыточностью пересылаемой информации, что при больших нагрузках может привести к перегруженности сетевого трафика. Если же у вас нет критических требований к времени отклика (а таких приложений в реальном мире где то 90%), то смело можете брать эту технологию на вооружение.

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

Определение

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

Протоколы уровня представления — это XML-RPC и SOAP. Они определяют, каким образом в строке представлены структуры данных.

Идея представить структуры данных в виде строки возникла задолго до появления протоколов представления XML-RPC и SOAP. И именно существование великого множества доморощенных протоколов послужило толчком для создания этих стандартов. Оба протокола построены на основе XML.

Протоколы уровня представления

Протоколами уровня представления информации (wire protocols) сейчас являются два стандарта — SOAP и XML-RPC.

SOAP является основным стандартом, принятым многими фирмами разработчиками. В том числе и Microsoft. Собственно SOAP родился в результате сотрудничества между тремя фирмами UserLand, DevelopMentor и, конечно же, Microsoft. Позже протокол был переработан и дополнен W3C.

Протокол XML-RPC менее известен, однако используется не менее широко. Его реализации тоже существуют для большинства сред и языков. Основное достоинство этого протокола — меньшая избыточность и, как следствие, легковесность. Естественно, за все надо платить — и в результате XML-RPC не сможет похвастаться той гибкостью, какую предоставляет SOAP. Но при этом, у него есть серьезное одно достоинство: этот протокол более безопасен. В отличие от SOAP, не предусмотрена возможность просмотра экспонируемых методов посредством discovery- и description-сервисов.

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

Фактически, прототипом для XML-RPC явился один из черновиков протокола SOAP. Поэтому, если посмотреть на фрагменты строк, взятых из двух протоколов, становится ясно, что у них достаточно много общего. В текущем состоянии SOAP поддерживает XML-схемы, перечисления, странные гибриды структур и массивов, а также определяемые пользователем типы — в то время как у XML-RPC более скромный набор. В то же время, некоторые аспекты SOAP не документированы и поэтому оставлены на усмотрение разработчика. Поэтому фактически окончательным стандартом SOAP можно считать его реализацию предоставленную Microsoft.

Вот как выглядит строка-запрос в XML-RPC-протоколе:

Этот фрагмент дает возможность оценить, насколько проще и нагляднее выглядит XML-RPC по сравнению с SOAP. Именно этим обусловлено меньшее время отклика в реализациях протокола XML-RPC.

Справедливости ради стоит отметить, что Microsoft в качестве альтернативы предлагает использовать классические HTTP-GET и HTTP-POST методы передачи параметров, результат при этом возвращается в виде очень простой XML-строки. Время отклика в этом случае будет еще меньшим, чем у XML-RPC. Но эти альтернативные методы не могут работать со сложными типами данных, так что рассматривать их в качестве кандидатов для использования в реальных приложениях не имеет смысла.

Веб-сервисы в гетерогенных средах

Олег Ремизов,

Данная статья посвящена рассмотрению некоторых практических аспектов технологии web-services на платформах DOT.NET и Java. Такой метод обмена информацией, хотя не является наиболее оптимальным, тем не менее, имеет много преимуществ по сравнению с другими современными технологиями создания распределенных приложений.

Благодаря поддержке таких гигантов рынка как Microsoft, IBM, Sun эта технология быстро набирает вес и становится стандартом де-факто для создания распределенных приложений. Использование данной технологии в последнее время является наиболее актуальным конкурентным преимуществом при продвижении на рынок нового поколения распределенных приложений.

Возможности интеграции со средами разработки

В качестве демонстрации того, насколько просто создать такое приложение с использованием современных средств разработки, приведем пример, в котором создадим веб-сервис в среде DOT.NET и Java-клиент, вызывающий этот веб-сервис (для демонстрации гетерогенных возможностей технологии).

На практике подобная задача встречается довольно часто. Так что рассмотрим ситуацию из реальной жизни. Система учета супермаркета использовала в качестве базы данных MSSQL-сервер. Таким образом, серверная сторона была привязана к Win2k. Дабы сэкономить на лицензиях Win2k, для торговых терминалов решено было создать рабочее место оператора с использованием UNIX-машин. Для реализации проекта был создан свой протокол с использованием Berkley Sockets. Его создание и отладка отняла значительную часть то общего времени реализации проекта, которое в результате составило примерно полгода! Если бы разработчики использовали веб-сервисы, время разработки значительно сократилось бы.

Приступим непосредственно к созданию нашего примера. В начале создадим проект сервиса. Для этой цели я использовал VS7.1. Запускаем его и создаем новый проект C# на основе шаблона Web Service. При этом в IIS будет создан виртуальный каталог (на диске в соответствие ему ставится реальный каталог), в котором будут размещены файлы проекта.

Рис. 1. Создаем Web Service в среде разработки Visual Studio 7.1

Интерес для нас представляют три файла: *.asmx — файл в формате XML, точнее WSDL (это язык, созданный на базе XML; можно также встретить определение, что WSDL — это XML-схема, оно тоже верно) специально для описания методов, экспонированных сервисом. IIS на лету преобразует WSDL в HTML-представление для отображения в браузере пользователя. Этот файл представляет информацию для description service. Для каждого сервиса (службы) существует свой файл описания; *.disco — файл в формате XML, предназначенный для просмотра (listing) всех существующих веб-служб по указанному адресу: discovery service. Посредством этих двух файлов и IIS пользователь, вооруженный браузером, может найти исчерпывающую информацию об инсталлированных веб-сервисах; *.asmx.cs — файл, ответственный за реализацию методов сервиса.

Переименуйте файл сервиса и класс службы, для того чтобы они несли определенную смысловую нагрузку. Для тестового приложения я выбрал имя файла AccountState.asmx, а для класса службы — AccountState, поскольку наше тестовое приложение будет отображать состояние некоего счета в банке.

Существует распространенное заблуждение, что веб-сервис представляет сущность без состояния. Это не совсем так, мы вполне можем хранить промежуточные данные в статических переменных класса или в переменных приложения. Эти данные будут оставаться живыми вплоть до перегрузки веб-сервера. Верно то, что при каждом новом запросе создается новый экземпляр класса веб-службы. После закрытия клиентом соединения с сервером экземпляр класса будет разрушен — при этом все нестатические члены класса должны быть сохранены в базу данных или посредством serializing. Точно так же они должны быть загружены при новом запросе. Если мы хотим оптимизировать работу сервера, избежав многочисленных обращений к диску или базе данных, оптимальным решением будет сохранение результатов в статической коллекции объектов и сохранение той в хранилище данных через некоторые промежутки времени. Из кода, сгенерированного wizard, несложно догадаться, что место для инициализации — это конструктор класса. Когда нам надо освободить ресурсы, то делать мы следует в методе Dispose().

Код методов нашего веб-сервиса выглядит так:

[WebMethod]
public string GetBankName()
{
   return "Baby Bank";
}
[WebMethod]
public void Deposit(int ammount)
{
   state += ammount;
}
[WebMethod]
public int GetState()
{
   return state;
}

[WebMethod]
public int Withdraw(int ammount)
{
   state -= ammount;
   if (state < 0)
   {
     state = 0;
     return state;
   }
   else
   {
     return ammount;
   }

}

Не забудьте определить переменную state как static (полный код этого примера вы сможете найти на КП-диске).

При вызове сервиса в Internet Explorer мы сможем прочитать пару "запрос-ответ" в формате SOAP. Для примера приведем текст запроса и ответа для функции int GetState() будет выглядеть следующим образом:

Если сравнить формат SOAP с ранее приведенным фрагментом в формате XML-RPC, сразу видно, что при наличии большого количества сложных объектов размер строки XML-RPC будет гораздо меньшим.

Возможность тестировать методы прямо из Internet Explorer делает разработку сервисов еще более простым занятием. Внизу приведены рисунки, отображающие некоторые экраны в процессе тестирования.

Рис. 2. Мы можем просмотреть все методы web службы прямо в Internet Explorer

Рис. 3. Есть возможность вызвать любой метод web службы

Рис. 4. Результат вызова службы в Internet Explorer представлен виде XML

Протестировав наш сервис в Internet Explorer, напишем небольшой консольный клиент, проверяющий его работу.

Код простейшего клиента будет выглядеть так:

[STAThread]
static voidMain(string[] args)
{
try
{
    AccountClient.AccountState.AccountState ac
      = new AccountClient.AccountState.AccountState();
    Console.WriteLine("Try to invoke service from URL : " + ac.Url);
    Console.WriteLine("Bank name : " + ac.GetBankName());
    Console.WriteLine("Accaunt initial state : " + ac.GetState());
    ac.Deposit(10);
    ac.Withdraw(5);
    Console.WriteLine("After Operations accaunt state : " +     ac.GetState());
    ac.Dispose();
    Console.WriteLine("Press key 'Enter' to complete program execution");
    Console.ReadLine();
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);

}
}

При этом необходимо создать в проекте веб-ссылку, для того чтобы Visual Studio мог сгенерировать промежуточную proxy-сборку. Таким образом, среда разработки берет всю черновую работу на себя, нам остается только создать экземпляр класса и вызвать его методы.

Чтобы создать веб-ссылку, щелкните по контекстному меню на дереве проекта нашего клиента и выберите пункт add web reference. Появится интуитивный дружественный wizard. На рисунке показано его финальное диалоговое окно, где название ссылки изменено с localhost на AccountState.

Рис. 5. Окно визарда, создающего proxy-сборку

Если заглянуть внутрь папки проекта [имя проекта]\Web References, мы обнаружим исходный код нашего proxy-класса. Благодаря применению атрибутов он достаточно компактен. Стартуйте клиент на выполнение и убедитесь, что все работает.

Рис. 6. Клиент DOT.NET, опрашивающий веб-службу

Если вы запустите его несколько раз, то обнаружите, что данные, хранящиеся в статической переменной state, не будут уничтожены. Но если пересобрать проект, что приведет к перезагрузке приложения в IIS, эти данные все же исчезнут. Поэтому вам в любом случае необходимо позаботиться об их сохранении. Глобальные данные можно сохранять при помощи класса Application.

Первая часть проекта завершена, создадим теперь аналогичный консольный проект Java при помощи среды разработки JBuilder X. Создайте проект, после чего добавьте объект Web Services Designer из меню New. На следующей вкладке визарда установите параметры, как это показано на рисунке 7.

Рис. 7. Настраиваем объект Web Services Designer в среде разработки JBuilder X

После этого в дереве проекта выберите Web Services Designer > Import WSDL > From URL. Из контекстного меню выберите пункт Add. Будет добавлен новый сервис. Вставьте URL нашего сервиса с постфиксом ?WSDL. Все остальное визард сделает сам — по удобству и интуитивности он ничем не уступает своему аналогу из Visual Studio.

На рисунке ниже показано окно визарда с URL.

Рис. 8. Окно Web Services Designer с импортированным объектом веб-сервиса в среде разработки JBuilder X

Все установки на вкладках оставьте по умолчанию (я изменил только имя пакета для proxy-классов и имя самого сервиса). Соберите проект, в пакете со введенным вами именем возникнут сгенерированные классы. Добавьте новый класс с методом main() и вставьте туда следующий код:

try
{
   // here we will invoke our soup method :
   long time1 = System.currentTimeMillis();
   AccountStateSoapStub proxy = (org.tempuri.AccountStateSoapStub)
       new org.tempuri.AccountStateLocator().getAccountStateSoap(new URL(" /Account/AccountState.asmx"));
   if (proxy != null)
   {
     proxy.setTimeout(60000);
     // operations:

     proxy.getBankName();
     System.out.println("Bank name : " + proxy.getBankName());
     System.out.println("Accaunt initial state : " + proxy.getState());
     proxy.deposit(10);
     proxy.withdraw(5);
     System.out.println("After Operations accaunt state : " + proxy.getState());
     System.out.println("Name : " + proxy.getName());
     proxy.setName("Oleg");
     System.out.println("Name : " + proxy.getName());
     long time2 = System.currentTimeMillis();
     long delta = time2 - time1;
     System.out.println("Request take : " + Long.toString(delta) + " millisecond");
     System.out.println("Press key 'Enter' to complete program execution");
     System.in.read();
   }
}
catch (Exception ex)
{
   ex.printStackTrace();
}

Следует отметить, что JBuilder использует Apache Axis — самый известный пакет для работы с SOAP. Существуют другие реализации этого протокола — как платные, так и free. Не исключено, они более оптимальны — но если вы остановитесь на одной из них, то почти наверняка потеряете интеграцию с вашей средой разработки. А это означает снижение производительности вашего труда.

В ходе тестирования были обнаружены

В ходе тестирования были обнаружены странные флуктуации производительности веб-сервисов, использующих SOAP. Если быстродействие приложения, использующего веб-сервисы, вас не устраивает, то возможным вариантом его оптимизации может стать отказ от протокола SOAP в пользу более легковесного XML-RPC.
На разных задачах DOT.NET-машина перегоняет JVM в полтора-два раза. Именно такого результата следовало ожидать в этом случае. В этом тесте не было замечено значительной разницы в производительности на стороне клиента.
Если принять во внимание тот факт, что объемы передаваемых данных в наших примерах просто смехотворны, а эксперимент проводился на одной машине (без реального сетевого взаимодействия), следует еще раз задуматься о целесообразности использования веб-сервисов вообще для приложений с повышенными требованиями к быстродействию (особенно в гетерогенных средах). Для сравнения: та же последовательность вызовов посредством RMI занимает всего 20…30 мс. К счастью, большинство реальных приложений таковыми не являются.

BPEL (Business Process Execution Language – язык выполнения бизнес-процессов) – это язык сервисов.

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

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

Язык выполнения бизнес-процессов (Business Process Execution Language – BPEL) предлагает общеупотребительный язык для бизнес-приложений и сервисов. BPEL является новым стандартом для интеграции гетерогенных приложений и сервисов в транзакционные бизнес-процессы.

"BPEL – это язык потоков технологических процессов и данных (workflow and process flow language). Поэтому если имеется несколько стадий, которые нужно объединить в единое целое для формирования бизнес-процесса, то BPEL – это тот язык, который вы будете использовать для описания, как и в какой последовательности должны происходить события, – объясняет Дейв Шаффер (Dave Shaffer), бизнес-консультант и эксперт по BPEL корпорации Oracle. – Есть одно неправильное представление, которое необходимо рассеять: для того, чтобы BPEL был полезен, вовсе обязательно всюду иметь Web-сервисы. BPEL позволяет связываться со многими различными видами выполняющихся на сервере систем через родные для них (native) протоколы".

До BPEL

"До появления BPEL существовали различные технологии интеграции прикладных систем уровня предприятия (Enterprise Application Integration – EAI) и составляющих чью-то собственность (proprietary -проприетарный) технологий управления бизнес-процессами (Business Process Management – BPM), – объясняет Шаффер. – Люди имели возможность строить связанные приложения, но они были дорогими, сложными и проприетарными".

В декабре 2000 года корпорация Microsoft опубликовала XLANG – язык бизнес-процессов на базе XML, используемый в Microsoft BizTalk Server для управления приложениями и Web-сервисами XML. Три месяца спустя корпорация IBM опубликовала язык потоков данных Web-сервисов (Web Services Flow Language – WSFL), язык XML для описания Web-сервисов как части определения бизнес-процесса. IBM разработала WSFL как часть инфраструктуры технологии Web-сервисов, опираясь на спецификации таких существующих стандартов как SOAP, UDDI, WSDL и XMLP.

В августе 2002 года IBM, Microsoft и BEA выпустили первый общедоступный проект спецификации языка выполнения бизнес-процессов для Web-сервисов (Business Process Execution Language for Web Services -- BPEL4WS), в которой они скомбинировали идеи спецификаций XLANG и WSFL. В апреле 2003 года OASIS (Organization for the Advancement of Structured Information Standards – организация по усовершенствованию стандартов структурированной информации) пригласила всех желающих принять участие в работе технического комитета BPEL. В мае 2003 года о своей поддержке BPEL объявили Sun и Oracle.

Характеристики BPEL

BPEL определяет поведение бизнес-процессов, базирующихся на Web-сервисах. BPEL реализует функциональность экспорта и импорта, используя исключительно интерфейсы Web-сервисов. BPEL вписывается в архитектуру основных Web-сервисов, построенную поверх UDDI, WSDL, XML и XML Schema.

"BPEL – это упрощенный стандартный язык, который облегчает гармоническое сочетание различных Web-сервисов, – говорит Шаффер. – Он образует слой поверх Web-сервисов и XML, а также стандартных блоков различных компонентов. Большинство людей уже работает в среде SOAP, WSDL, XML и XML Schema, и большинство компаний уже двигается в направлении интеграции на основе XML. Так что BPEL – это правильный путь для разработчиков".

Императив интеграции (Integration Imperative)

(Rich Schwerin), старший редактор издательства Oracle Publishing.

Источник: журнал Oracle Magazine, no.6, 2004, раздел "ТЕХНОЛОГИЯ", рубрика "Промышленный стандарт", http://www.oracle.com/technology/oramag/oracle/04-nov/o64industry.html

Перевод: Oracle Magazine RE

Oracle BPEL Process Manager

Oracle BPEL Process Manager является масштабируемым сервером оркестровки на основе BPEL с поддержкой моделирования, объединения, развертывания и управления процессами BPEL; он предлагается и как автономный продукт, и как опция сервера приложений Oracle 10g Enterprise Edition. Помимо BPEL сервер приложений Oracle 10g поддерживает SOAP, WSDL, WS-Coordination, WS-Transaction и XML, каждый из которых позволяет приложениям гибко находить друг друга и прозрачно взаимодействовать в рамках независимой от платформы модели.

"Основная бизнес-проблема с BPEL – это интеграция, – объясняет Роб Ченг, директор, управляющий выпуском продукта Сервер Приложений Oracle 10g. – Цель BPEL состоит в том, чтобы найти более простые, более гибкие и более легкие способы разрешения проблем интеграции – не только для подключения унаследованных приложений, но также и для того, чтобы в будущем строить приложения с более высоким уровнем модульности".

"BPEL определяет совместную оркестровку и хореографию (orchestrated and choreographed) сервисов и способен компоновать сущности воедино в потоки процессов и потоки приложений в рамках гетерогенной архитектуры – независимо от используемого оборудования, языка программирования или операционной системы – то есть, именно там, где сервер BPEL от Oracle превосходит другие системы, – говорит Ченг. – У нас есть единственный промышленный механизм BPEL, который обрабатывает BPEL естественным образом, так что он богаче, быстрее, работе с ним проще научиться и он более расширяем, чем проприетарные альтернативы".

От сервисов к процессам

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

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

Поддержка обслуживания BPEL

Технический комитет OASIS по проблеме языка Web Services Business Process Execution Language (WSBPEL), работает над развитием BPEL. В него входят фирмы BEA Systems, Commerce One, EDS, IBM, Microsoft, NEC, Novell, Oracle, SAP, Siebel Systems, Sybase, Tibco и Vignette.

Текущая спецификация BPEL, рассмотрением которой в настоящее время занимается OASIS, имеет номер версии 1.1. Планируется, что ее рассмотрение будет завершено к концу 2004 года. Тем временем, продукты BPEL для серверов типа Oracle BPEL Process Manager поставляются уже сегодня.

После BPEL

Есть некоторые вещи, которые BPEL разрешить не может, в том числе, сложные преобразования, конвертирование данных, соглашения с торговыми партнерами, ручные (выполняемые человеком) процессы и привязка к определенным выполняющимся на сервере системам, объясняет Шаффер и добавляет, что BPEL и не пытается “дать всем сестрам по серьгам”.

"BPEL не включает в себя сложные преобразования, но поддерживающие BPEL продукты поддерживают и некоторые XQueries, так что вы можете связать все вместе, как сервис, – объясняет Шаффер. – В BPEL имеются некоторые простые преобразования, но без помощи XQuery или XSLT для сложных преобразований вы должны были бы выполнить их отдельно, а затем интегрировать их".

Шаффер добавляет, что в BPEL отсутствует концепция ручного процесса, но он имеет ключевую поддержку асинхронных сервисов и ручных задач; а ручные задачи легко поддерживаются как сервисы.

Три ключа к BPEL

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

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

Flow coordination. (Координация потоков) Координация потоков включает параллельный поток выполнения, образцы соединений и динамические потоки. В реальных приложениях бизнес-потоки могли бы включать образцы сложных взаимодействий, и с синхронными, и с асинхронными сервисами. Координация потока включает интерфейс с WSDL, действия потока, переменные XML и отвечает за компенсацию. BPEL использует WSDL для обращения к обмениваемым сообщениям, вызванным операциям и типам портов. Действия с потоком используют общие переменные XML, так что компенсационные обработчики (compensation handlers) должны сохранять снимки данных, которые могут быть использованы обработчиком. Компенсационные обработчики могут отменить шаги, которые были уже завершены.

BPEL includes basic and structured activities. (В BPEL включены основные и структурированные действия). Основные действия состоят из индивидуальных шагов для взаимодействия с сервисом, манипулирования обмениваемыми данными или обработки исключительных состояний, с которыми сталкиваются в течение выполнения. Структурированные действия определяют последовательность выполнения и описывают создание процесса, транслируя выполняемые ими действия в структуры; в состав этих структур включены поток данных, шаблоны управления, обработка внешних событий, обработка ошибок и координация сообщений.

Exception management. (Управление исключительными ситуациями). Управление исключительными ситуациями имеет дело с синхронными ошибками, асинхронным управлением исключительными ситуациями и компенсацией бизнес-транзакций. Для того чтобы автоматизировать бизнес-процессы, большие усилия сосредоточены на управлении исключительными ситуациями, и BPEL упрощает управление исключительными ситуациями для Web-сервисов. При возникновении исключительных ситуаций вызываются локальные обработчики ошибки, связанные с Web-сервисами, и асинхронные сервисы уведомляются об этих исключительных ситуациях.

Порталы и жизненные циклы

21.02.2002

Portal Lifecycle Management

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

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

Идеологию, пригодную для построения динамической схемы жизненного цикла портала, можно найти в [12]. В отчете, подготовленном аналитическом Delphi Group использованы материалы компании Mongoose Technology, предлагающей средства для разработки и эксплуатации порталов. Автор отчета представляет цикл жизни портала как замкнутый и повторяющийся, что противопоставляется обычному отношению к приложениям, которые иронически называются: «целься, пли, готово». Ударным трудом с фиксированной датой окончания порталы не строятся, это не продукт, имеющий окончательные потребительские качества, следовательно, требуется долговременные и методичные усилия по развитию и совершенствованию, через последовательность итераций.
В [13] приводится еще одно интересное наблюдение, вывод из которого имеет большое практическое значение. Обычно в процессе проектирования портала большинство участников составляют заинтересованные представители менеджмента компании, а ИТ-персонал — меньшинство. После того, как портал внедрен, пропорция радикально меняется, менеджерам он остается нужным в качестве инструмента, и они теряют к нему интерес, а большинство переходит к ИТ-специалистам, далеким от понимания функциональности. Отход менеджеров от выполнения миссии по совершенствованию опасен деградацией портала.

Каждый из витков жизненного цикла портала состоит из четырех периодов.

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

Рис. 2. Жизненный цикл портала

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

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

Сегодня предложение средств для менеджмента порталов на рынке программного обеспечения еще невелико. Одно из наиболее известных — пакет PortalStudio Interactive Development Environment от компании Mongoose Technology, который представляет собой среду, позволяющую архитекторам порталов применить интегрированный подход к PLM. В состав пакета входит визуальная среда, библиотека компонентов, набор различных портальных заготовок. Пакет может быть использован в процессе создания и поддержки порталов на всем их жизненном цикле. В октябре 2001 года Mongoose Technology выпустила PortalStudio Enterprise Edition 2.0. Технология, предлагаемая компанией, соответствует стандартам J2EE, что обеспечивает ей нейтральность по отношению к вендорам портальных платформ. Существует возможность работы Mongoose PortalStudio совместно с BEA WebLogic, Oracle9i AS, Orion, Macromedia Jrun и IBM WebSphere.

Портал как средство для создания виртуальных сообществ

Работы, которые ведутся в Mongoose, не ограничены чисто технологическими аспектами, остающимися пока наиболее привычными для ИТ-специалистов. В PortalStudio 2.0 включен компонент RealCommunities, относящийся к новому поколению средств для групповой работы, так называемых коллаборационных приложений, основанных на использовании Web-служб для организации межличностного общения. Обращение к изучению этой категории коллективов и созданию средств их создания вызвано довольно простой мыслью. Эволюции человека в физическом пространстве проходила в процессе создания разного рода объединений, от стада до демократического государства, вся индустриальная история — это, в конечном итоге, история производственных коллективов.

Выйдя в виртуальное пространство, человечество с неизбежностью повторит этот опыт, поэтому и Web проходит три этапа.

Первым было представление его в виде огромной энциклопедии, главным на этом этапе является контент. Второй этап - электронная коммерция, построенная на транзакционных принципах (один к одному). Третий этап - образование сообществ.

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

P = ({[(Ri - Ci) х Li] - Si},

где

P — суммарная прибыль; Ri — доход от одного клиента; Ci — затраты на одного клиента; Li — время жизни одного клиента;
Si — затраты на получение одного клиента.

В этой формуле самым значимым параметром оказывается время вхождения клиента в сообщество потребителей. Если максимизация других параметров зависит от ряда других обстоятельств, время, пока потребитель остается верен поставщику, напрямую зависит от качества организации сообщества. Совершенно аналогичные рассуждения можно приложить к системам категорий SCM, CVM и другим. Понимая это, в Mongoose предлагают пакет RealCommunities, который позволяет объединить инфраструктуру и прикладные службы для построения Web-сообществ и взаимодействие каждого с каждым (peer-to-peer) внутри корпоративного портала. Схема работы RealCommunities удивительным образом напоминает каноническое представление о функционировании Web-служб, но в качестве объектов в ней выступают не приложения, а реальные люди. RealCommunities включает в свой состав модули:

Expertise & Skills Directory - каталог знаний и практического опыта, построенный по принципу Web-служб, позволяющий найти специалиста или коллектив исполнителей, отвечающих необходимым требованиям; Engagement & Feedback - после того, как найдены исполнители, необходимо снабдить их службами для взаимодействия, для этой цели есть модуль взаимодействия и обратной связи; Messages & Chat - средство для непосредственно общения, в том числе доски объявлений, чаты и мгновенная передача сообщений; Question & Answer - механизм постановки вопросов и получения ответов (может быть как частным, так и публичным); File Sharing & Collaboration - разделяемый доступ к файлам; Review & Recommend - возможность взаимной оценки качества работы для соучастников одного проекта; Rewards & Incentives - поле, на котором выставляются награды и стимулы.

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

Литература

Стивен Теллин, "Интранет и Адаптивные Инновации: переход от управления к координации в современных сетях", JetInfo, № 21-22, 1996 Steven L. Tellen, "Intranets as Knowledge Management Systems basic concepts and definitions", 1997, http://www.dhs.vic.gov.au/phkb

Bruce Robertson, Val Sribar, "The Adaptive Enterprise: IT Infrastructure Strategies to Manage Change and Enable Growth". Intel Press, IT Best Practices Series, 2001 Леонид Черняк. "Управление кораблем корпорации", журнал БОСС, 1997, № 1 "Corporate portals: A Simple View of a Complex World", Plumtree Software, 1998 Леонид Черняк. "Корпоративный портал", http://kis.pcweek.ru/kis/win/techno/p.html

David Reed, "The Law of the Pack". Harvard Business Review, 2000, February "Best Practices in Enterprise Portals", KMWorld, 2001, July/August, www.kmworld.com

Paolo Magrassi, Bill Rosser, "The Productivity Paradox". Gartner Group European Symposium/Itxpo, 2001 "A Framework for Assessing Return on Investment for a Corporate Portal Deployment. The Industry's First Comprehensive Overview of Corporate Portal ROI", Plumtree Software, 2001 Erick Rivas. "Maximize Enterprise Portal ROI", KMWorld, 2001, July/August "Portal Lifecycle Management: Addressing the Hidden Cost of Portal Ownership", Delphi Group, 2001, January Paolo Magrassi, Bill Rosser "The Productivity Paradox", Gartner Group European Symposium/Itxpo, 2001 "The 12 Principles of collaboration, Guidelines for Designing Interaction Management Services", Mongoose Technology