Главная » Java, Web, XML » Развитие Web Services

0

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

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

Протокол SOAP

Близится к завершению работа над версией 1.2 протокола SOAP. Сейчас, когда вы читаете эти строки, уже должна выйти ее окончательная редакция. Описание протокола, сделанное в главе 3, основано на черновой редакции SOAP 1.2, опубликованной в июне 2002 года. Не думаю, что эта редакция будет сильно изменена, поскольку всякие дополнения к протоколу сейчас оформляются в виде отдельных документов — расширений (extensions) протокола SOAP.

В версию SOAP 1.2 внесено много мелких изменений: исключен атрибут encodingStyle из корневого элемента <Envelope>, атрибут actor заменен атрибутом role, значения атрибута mustUnderstand записываются словами "true" и "false". Введены новые элементы и атрибуты, исключен HTTP- заголовок SOAPAction, определен ЮЫЙ MIME-ТИП application/soap+xml, изменено содержимое элемента  Все это подробно изложено

в главе 3.

Пока не выпущена окончательная редакция SOAP 1.2, производители программных продуктов, реализующих протокол SOAP, вынуждены основывать их на версии SOAP 1.1. Впрочем, уже в первой версии Apache Axis реализовано большинство конструкций SOAP 1.2. Как только версия 1.2 будет утверждена, производители сразу же воплотят ее в новых версиях своих продуктов.

Протокол SOAP, по-видимому, будет в дальнейшем заменен общим протоколом пересылки любых документов XML, названным "XMLP" (XML Protocol). Но разработка этого протокола сильно затянулась, она еще не вышла из начальной стадии. Вероятнее всего, Web-службы еще некоторое время будут действовать в рамках протокола SOAP 1.2. Его текущее состояние и процесс разработки можно посмотреть на сайте http://www.w3.org/TR/xp/.

Описание на языке WSDL

Во время написания книги действовала версия 1.1 языка описания Web- служб WSDL, но в июле 2002 года был опубликован черновой вариант версии WSDL 1.2. Он доступен по адресу http://www.w3.org/TR/wsdI12.

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

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

Текущее состояние языка WSDL непрерывно отражается на сайте http://www.w3.org/ws/desc/.

Реестр UDDI

Реестры UDDI пока создаются и развиваются, основываясь на спецификации UDDI 2.0, изложенной в нескольких документах. В июле 2002 года вышла версия 3.0 спецификации UDDI. Она записана в одном документе "UDDI Version 3.0 Published Specification", доступном по адресу http://uddi.org/pubs/uddi_v3.htm.

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

цию хранящихся в нем сведений.

Спецификация UDDI 3.0 вносит и другие изменения в структуру сведений, хранящихся в реестре, например, введены дополнительные правила поиска и сортировки с помощью шаблонов. Обеспечена согласованность документов UDDI с описанием Web-службы, сделанном на языке WSDL. Значительно расширен интерфейс UDDI API, в него внесено много новых функций. Эти изменения приведены в главе 5, описывающей версию UDDI 3.0.

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

Текущее состояние дел по разработке спецификации UDDI всегда можно посмотреть на сайте http://www.uddi.org/.

Фирменные разработки

Правила создания и функционирования Web-служб описываются не только протоколом SOAP, языком WSDL и реестром UDDI. Определение Web Services, приведенное в главе 2, вообще ничего не говорит об этих "трех китах". Оно даже не упоминает протокол HTTP. По этому определению для Web-служб характерно только использование документов XML и технологии WWW. Многие фирмы создают свои протоколы и спецификации Web- служб, основанные лишь на XML и WWW. В предыдущих главах уже упоминались протоколы и спецификации XML-RPC, DIME, WS-Routing, WS-

Inspection, WS-Security. Большинство нововведений принадлежит фирмам IBM и Microsoft и сообществу OASIS. Познакомимся подробнее с их деятельностью.

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

Языкописания потоков работWSFL

Язык описания потоков работ WSFL (Web Services Flow Language) создан фирмой IBM с двумя целями: описать последовательность обработки информации несколькими Web-службами, образующую бизнес-процесс (flow model), и описать взаимодействие Web-служб в этом процессе (global model). Для этого устанавливаются связи между SEI-интерфейсами взаимодействующих Web-служб. При этом активно используется WSDL-описание этих Web-служб.

Спецификация WSFL опубликована в документе http://www-4.ibm.com/ software/soIutions/webservices/pdf/WSFL.pdf.

Описание WSFL выполняется в виде документа XML с корневым элементом        в который вкладывается любое число необязательных элементов описывающих поток информации, и элементов <globalModel>, описывающих взаимные связи Web-служб. Кроме того, в корневой элемент можно вложить необязательные элементы <import> и <serviceProviderType>.

Бизнес-поток описывается элементами, вложенными в элемент Начало потока указывается элементом <flowSource>, конец потока — элементом <fiowSink>. Элементы <serviceProvider> СПИСЫВжТ Web-СЛужбы, вовлеченные в поток, а элементы <activity> — операции, выполняемые этими Web-службами. Операции связаны либо по управлению, либо по обрабатываемым данным. Связь по управлению описывается элементом <controlLink>, связь по данным — элементом <dataLink>. Имена входящей в эту связь и выходящей из нее Web-службы задаются атрибутами source и target этих элементов.

Взаимодействие Web-служб описывается элементами, вложенными в элемент <giobalModei>. Сами Web-службы описываются элементами <serviceProvider>, а связи между ними — элементами <plugLink>, в которые вкладываются элементы <source> и <target>, описывающие две Web- службы, между которыми устанавливается связь.

В листинге 9.1 приведена схема вложенности элементов языка WSFL.

‘ Листинг9.1, Вложенность элементов языка WSFL

definitions name="">

<import namespace="" location="" /> [*]

<serviceProviderType name=""> [*]

<portType name="" /> [*]

location="" /> [*]

</serviceProviderType>

<serviceProvider name=""> <portType name="" />

<flowModel name="" serviceProviderType=""> [*]

<flowSource name=""> [?]

<output name=" " message="" /> </flowSource>

<flowSink name=""> [?]

<input narne="" message="" /> </flowSink>

<serviceProvider name="" type="" /> [+] <export lifecycleAction=" "> [*]

<SOurce portType="" operation=""> [?]

<target portType="" operation=""> [?] />

</target> <ref >

<plugLink> [?]

csource portType^"" operation = "" /> [?] <target portType^"" operation="" /> [?] <map /> [?]

<locator> [?] </plugLink>

</export>

<activity name=""> [*]

<input name="" message="" /> <output name="" message="" /> <performedBy serviceProvider="" />

<implement>

<internal> ) <export>

<export portType="" operation="">

<map /> </export> </implement>

<join condition="" />

<materialize>

<mapPolicy> j <construction> </materialize>

</activity>

<datalink name="" source= "" target="" /> [*] <controlLink name="" source="" target="" /> [*]

</flowModel>

<globalModel name="" serviceproviderType="">

<serviceProvider name="" serviceProviderType="">

<export>

<source portType="" operation="" /> <target portType="" operation="" /> </export>

<locator type="" service="" /> <plugLink>

<source serviceProvider="" portType="" operation^"" /> <target serviceProvider="" portType="" operation="" /> </plugLink>

</globalModel>

</definitions>

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

Корпорация Microsoft создала свой язык описания бизнес-процессов, непохожий на язык WSFL. Он называется XLANG и разработан для сервера BizTalk. С языком XLANG можно ознакомиться на сайте http://msdn.microsoft.com/library/.

Язык описания бизнес-процессов BPEL4WS

Фирма IBM откликнулась на язык XLANG созданием языка BPEL4WS (Business Process Execution Language for Web Services), призванного объединить языки WSFL и XLANG. Спецификация языка BPEL4WS доступна по адресу http://www-106.ibm.com/developerworks/library/ws-bpel/.

Язык BPEL4WS создает композицию Web-служб, участвующих в бизнес- процессе, и описывает ее как одну Web-службу элементами <portType> языка WSDL. Такая композиция называется процессом BPEL4fVSи записывается в теле элемента <process>. Каждый шаг процесса называется действием (activity). В число действий входит обращение к какой-либо Web- службе для выполнения Web-услуги <invoke>, ожидание результата <wait>, получение запроса от клиента <receive>, создание ответа <reply>, копирование данных <assign>.

Действия, описанные элементами <sequence>, <switch>, <whiie>, <flow>, <pick>, позволяют задать сложный нелинейный алгоритм обработки данных Web-службами, входящими в процесс BPEL4WS.

Действия <throw> и <catch> позволяют обработать исключительные ситуации, возникающие при выполнении других действий, основываясь на элементах       описания WSDL.

Процесс BPEL4WS описывается, как всякая Web-служба, документом WSDL, в который записываются дополнительные элементы <serviceLinkType>, определенные в пространстве имен с идентификатором http://schemas.xmlsoap.org/ws/2002/07/service-link/. Эти элементы вкладываются непосредственно в корневой элемент <definitions> WSDL-описания. Они содержат один или два элемента        содержащих ссылки на

WSDL-описание тех Web-служб, которые выполняют действия, составляющие процесс.

Само же описание Web-служб, выполняющих действие, производится элементами <partner>, вложенными в элемент <partners>, который, в свою очередь, вкладывается в элемент <process>.

В листинге 9.2 показана схема вложенности элемента <process>.

Листинг 9.2. Элемент process> языка BPEL4WS

<process>

<partners> [?]

<partner name="" serviceLinkType="" myRole="" /> [+]

</partners>

<containers> [?]

<container пме="" messageType="" /> [ + ] <message> [*]

</container>

</containers>

<faultHanclers> [?]

<catch faultName="" faultContainer="">

<reply partner="" portType="" operation=""

container»"" faultName="" /> [*]

</catch>

<catchAll> [?]

</faultHandlers>

<correlationSets> [?]

ccorrelationSet name="" properties=""> [+] </correlationSets>

<compensationHandler>

<compensate> | <Действия> </compensationHandler>

<flow>

<links>

<link name="" /> [*] </links>

<pick> [*]

<onMessage> [+] <onAlarm> I*]

</pick>

<sequence> [*] <assign> <copy>

<from container="" part="" /> <to container="" part="" /> </copy>

</assign>

cinvoke partner="" portType="" operation=""

inputContainer="" outputContainer=" "> />

<correlations> [?] <catch> [*]

<catchAll> [ + ]

[?]

</invoke>

<receive partner="" portType="" operation="" container="">

<source linkName="" /> [*]

</receive>

<reply partner=" " portType="" operation="" container="">

<correlations> [?]

<target linkName="" /> [*]

</reply>

</sequence>

<switch> [*]

<case condition="" /> [+] [?]

</switch>

cthrow faultName="" faultContainer="" />

<wait for="" until="" />

<while condition=""> [*]

</flow>

</process>

Фирма IBM активно продвигает язык BPEL4WS в качестве стандарта для описания взаимодействия Web-служб в бизнес-процессах. Она уже выпустила программный продукт BPWS4J, реализующий спецификацию BPEL4WS. Кроме интерфейсов и классов, реализующих BPEL4WS, в состав продукта входят примеры описаний на языке                                     простой редактор

для создания файлов с описаниями                     утилиты для проверки доку

ментов BPEL4WS. Пакет BPWS4J свободно доступен по адресу http://www.alphaworks.ibm.com/tech/bpws4j/.

Спецификация WS-Coordination

Спецификация WS-Coordination, разработанная фирмами IBM, Microsoft и BEA Systems, описывает самые общие правила взаимодействия компонентов распределенного приложения, которые можно затем детализировать другими, более конкретными спецификациями. Ее можно посмотреть на сайте http://www.ibm.com/developerworks/library/ws-coor/.

Компоненты распределенного приложения [10] часто работают на разном, плохо совместимом оборудовании и используют самые разные протоколы. Для координации их деятельности создаются специальные согласующие протоколы (coordination protocols). Главная задача спецификации — установить общие правила регистрации и активизации согласующих протоколов. Эту задачу должна решить Web-служба координации (coordination service). Она содержит в себе службу активизации и службу регистрации. У каждого компонента может быть своя Web-служба координации.

Web-служба координации активизируется при получении SOAP-послания от клиента с блоком заголовка <CreateCoordinationContext>. При этом происходит обращение к службе активизации, адрес порта которой записан во вложенном элементе <Activationservice>. Еще два вложенных элемента <CoordinationType> И <RequesterReference> описывают ТИП согласующего протокола и адрес клиента, приславшего запрос. Эти элементы и другие элементы, введенные в спецификацию, определены в пространстве имен с идентификатором http://schemas.xmlsoap.org/ws/2002/08/wscoor.

После активизации Web-служба координации посылает ответное SOAP- послание С блоком заголовка <CreateCoordinationContextResponse>, В КОторый вложен элемент                                                              а также элемент

содержащий сведения о созданном контексте Web- службы координации, в частности, ее адрес.

В каждое SOAP-послание, использующее Web-службу координации, вставляется блок заголовка <coordinationcontext>. В элемент <CoordinationContext> вкладывается элемент <CoordinationType>, ОПИСЫваЮЩИЙ ТИП согласующего Протокола, И Элемент <RegistrationService>, В котором, во вложенном элементе <Address>, записывается                                        порта

Web-службы координации.

Получив ответ, клиент регистрируется в Web-службе координации с помощью службы регистрации. Для этого он посылает Web-службе SOAP- послание с блоком заголовка <Register>, в который вложен элемент <Registrationservice> с содержимым, полученным от Web-службы координации, и элемент <Protocolldentifier>, который указывает тип согласующего протокола. Кроме того, вкладывается элемент <Participant Protocol Service», в котором указан адрес Web-службы, реализующей согласующий протокол, выбранный клиентом, и уже знакомый ЭЛеменТ <RequesterReference>.

На это Web-служба координации отвечает SOAP-посланием с блоком заголовка <RegisterResponse>, содержащим элемент <RequesterReference> и элемент                                                               содержащий адрес Web-

службы, реализующей согласующий протокол, выбранный Web-службой координации.

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

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

СпецификацияWS-Transaction

Спецификация                         созданная фирмами IBM, Microsoft и

Systems, предлагает две модели, детализирующие правила WS-Coordination: модель недолговременной транзакции с ограниченным числом участников AT (Atomic Transaction) и модель долговременной транзакции с большим числом участников ВА (Business Activity). Спецификация представлена на сайте http://www.ibm.com/developerworks/library/ws-transpec/.

Модель AT управляет одной транзакцией по принципу "все или ничего". Согласующий протокол транзакции регистрируется по правилам спецификации WS-Coordination. В элементе <wscoor:CoordinationType>, определяющем тип согласующего протокола, указывается строка

ws/2002/08/wstx. Спецификация устанавливает правила завершения и отката транзакции, например, предлагается двухфазная фиксация [10] транзакции.

После регистрации согласующего протокола по правилам спецификации WS-Coordination, клиенты начинают управление транзакцией, записывая в SOAP-ПОСЛаниях элементы <Prepare>, <ReadOnly>, <Commit>, <Rollback>, <OnePhaseCoramit>, <phasezero>, определенные в пространстве имен с идентификатором http://schemas.xmlsoap.org/ws/2002/08/wstx. Web-служба координации отвечает SOAP-посланиями с элементами <Prepared>, <Aborted>, <Committed>, <Notified>, <PhaseZeroCompleted>, <Unknown>. В каждый ИЗ этих элементов вкладываются элементы <SourceProtocolService> и <TargetProtocolService>, содержащие адреса портов Web-служб, реализующих соответствующие протоколы. Для создания и выполнения транзакции в рамках Web-службы координации создаются соответствующие службы, выполняющие описанные этими элементами действия.

Модель ВА охватывает, как правило, несколько транзакций, образующих бизнес-процесс, описанный, возможно, на языке BPEL4WS. Во время активизации и регистрации, в элементе                                               определяющем тип согласующего протокола, указывается строка http://schemas.xmlsoap.org/ws/2002/08/wstx.

Модель ВА задает правила распределения ресурсов между участниками бизнес-процесса и правила освобождения ресурсов, не используемых ими. Для этого спецификация WS-Transaction определяет элементы <Complete>, <Close>, <Cancel>, <Compensate>, <Forget>, используемые Web-службой координации для опроса участников бизнес-просесса, и элементы <Completed>, <Closed>, <Compensated>, <Faulted>, <Exited>, <Unknown>, Применяемые участниками бизнес-процесса для ответа. Все эти элементы определены в пространстве имен с идентификатором http://schemas.xmlsoap.org/ ws/2002/08/wsba Получив ответ участника, Web-служба координации распоряжается ресурсами.

Литература:

Хабибуллин И. Ш. Разработка Web-служб средствами Java. — СПб.: БХВ-Петербург, 2003. — 400 с: ил.

По теме:

  • Комментарии