Транспортный слой WS-архитектуры

ОБЗОРЫ

Единства в области гарантированной доставки данных Web-сервисов нет, но в средствах маршрутизации наметился консенсус

_____

Продолжение. Начало в PC Week, N 27/ 2004, с. 20.

Спецификации, определяющие правила гарантированной доставки сообщений SOAP

Гарантированная доставка - критическая функция для Web-сервисной инфраструктуры. Если участники обмена сообщениями не уверены, что их сообщение доставлено, то они не смогут решить ни одной серьезной бизнес-задачи. Есть три пути решения этой проблемы: либо задача решается единообразно на уровне стандартов, либо она решается на уровне транспортного слоя, либо каждое приложение решает ее своим, уникальным способом на уровне бизнес-логики. Третий подход перекладывает на слой бизнес-логики несвойственные ей задачи транспортного уровня. Второй подход уже давно используется - для этого служат прикладное ПО вроде IBM WebSphere MQ, Sonic MQ, Microsoft MSMQ или реализации спецификации Sun Java JMS, но хотелось бы решать задачу единообразно по всей инфраструктуре WS.

Стандартизованный подход к надежной доставке на уровне Web-сервисов повысил бы эффективность и других WS-стандартов в области безопасности, транзакций и бизнес-процессов. Однако консенсуса в этой области достичь не удалось - образовалось две группы, ведомые группами IBM+ и Sun+Oracle, кроме того, в игре участвуют консорциумы, разрабатывающие пакеты бизнес-протоколов - ebXML и RosettaNet.

Web Services Reliable Messaging Protocol (WS-ReliableMessaging)

Статус: авторская спецификация.

Авторы: IBM, Microsoft, TIBCO, BEA.

Спецификация описывает протокол, который позволяет гарантированно доставлять WS-сообщения между компонентами распределенных приложений даже в случае программных, аппаратных и сетевых сбоев. Протокол описывается в терминах, не зависящих от конкретной транспортной среды, что позволяет применять его, когда для доставки сообщения последовательно используется несколько транспортных механизмов. Для обеспечения совместимости Web-сервисов в спецификации описывается привязка к SOAP. Гарантия доставки обеспечивается отсылкой подтверждения. Применяется четыре политики гарантирования: максимум однократная доставка (гарантия отсутствия дублирования), минимум однократная доставка (может быть дублирование, но нет потерь), точно однократная (нет потерь и дублирования), точно в заданном порядке следования (может комбинироваться с другими политиками). Спецификация позволяет задавать времена устаревания сообщения, интервал, после которого инициируется повторная передача, и т. п.

Последовательность обмена сообщениями в WS Reliable Messaging

Этот протокол не является полностью независимым - он опирается на спецификацию WS Addressing для идентификации "конечных точек", а также на WS-Policy, WS-PolicyAttachment и WS-PolicyAssertions для определения свойств и возможностей "конечных точек".

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

     Web services Reliability (WS-Reliability)

Статус: рассматривается OASIS.

Авторы: WebMethods, Sun, Oracle, Fujitsu, NEC.

Основанный на SOAP протокол для гарантированной доставки SOAP-сообщений, обеспечения отсутствия дубликатов и сохранения порядка следования сообщений. Конкурент WS-Reliable Messaging, в целом аналогичен ему, но имеет свои особенности.

WS-Reliability активно использует наработки ранее созданных протоколов гарантированной доставки, в частности ebXML Message Service (ebMS). Однако он содержит модификации, необходимые для работы в домене WS, например, вводится концепция разных уровней качества доставки, которая может быть обсуждена между клиентом и сервисом (аналогично политикам гарантирования в WS-Reliable Messaging). Для гарантирования доставки также используются подтверждения, при отсутствии их получения сообщение должно быть послано повторно. Вся информация об идентификаторе сообщения, последовательности сообщений и т. п. встраивается в блоки заголовка SOAP-сообщения в пространство имен rm.

Отличается от WS-Reliable Messaging еще и тем, что позволяет отправлять гарантированные сообщения по одиночке. WSRM же всегда требует оформления серии сообщений, что приводит к росту нагрузки на вычислительные ресурсы.

Кроме того, этот протокол является свободно используемым, в отличие от WS-ReliableMessaging.

Наборы спецификаций консорциумов ebXML и RosettaNet

Пакеты: RosettaNet Implementation Framework versions 1.1 and 2.0 и ebXML messaging service 1.0 and 2.0

Части набора спецификаций ebXML 2.0 и RosettaNet. Решают задачу гарантированной доставки на уровне пакета протоколов бизнес-логики. В целом методы гарантированной доставки аналогичны тем, что используются в WS-Reliability. Однако эти протоколы не являются исключительно ориентированными на SOAP, а предназначены в первую очередь для гарантированной доставки бизнес-ориентированных XML-документов (накладных, запросов и т. п.), описываемых наборами соглашений ebXML и RosettaNet. Поддерживается многими платформами интеграции приложений.

Маршрутизация сообщений и адресация "конечных точек"

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

Точки маршрутизации на пути SOAP-сообщения

Маршрутизация позволяет обеспечить виртуализацию ресурсов сети, когда пользователю не нужно знать, с каким именно объектом во внутренней сети он общается (например, для безопасности или балансировки нагрузки).

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

WS Routing

Назначение: описание маршрута движения SOAP-сообщений (последовательность узлов).

Статус: предложения Microsoft и IBM, 2001-2003, на сегодняшний день устарела и имеет лишь унаследованное значение.

Спецификация касается вопросов маршрутизации, т. е. доставки сообщений через серию промежуточных узлов. WS Routing - это также протокол, который определяет, как SOAP-сообщения могут быть переданы через разные транспортные среды (например, от HTTP к E-mail и далее по TCP). Маршрутная информация передается в заголовке SOAP.

WS-Routing позволяет определить узлы прямого маршрута и (опционально) обратный маршрут для пересылки ответа на сообщение, а также средства для корреляции двух сообщений. Благодаря этому он поддерживает однонаправленный и двунаправленный (запрос - ответ) обмен сообщениями, одноранговый обмен (peer-to-peer) и длительные (long-running) диалоги. Фактически речь идет о динамической маршрутизации. WS-Routing не определяет средств для гарантированной доставки или безопасного обмена.

В соответствии с требованиями SOAP маршрутизаторы вдоль пути следования сообщения обязаны обрабатывать информацию в заголовке сообщения, в данном случае блока WS-Routing. Например, они должны удалять первый элемент типа "через" (<r:via>) и отсылать сообщение следующему узлу на основе данных второго элемента <r:via>. Это продолжается, пока сообщение не достигнет конечного узла, определяемого элементом <r:to>. По мере движения сообщения марштрутизаторы строят в SOAP-заголовке и обратный маршрут.

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

Примечание. В версии пакета WSE 2.0, вышедшей летом 2004, Microsoft отказалась от поддержки WS-Routing в пользу WS-Addressing.

WS-Addressing

Назначение: позволяет еще больше (по сравнению с WSDL) развязать логическую модель сервиса и его физическую реализацию, задает правила маршрутизации.

Статус: авторская спецификация.

Авторы: IBM, BEA, Microsoft.

WS-Addressing задает стандартный формат описания ссылок на реальный адрес сервиса в Сети ("конечную точку", endpoint reference, EPR). Напомним, что такую ссылку можно разместить и в WSDL-описании, но это неудобно, так как ссылка может меняться и тогда нужно менять описание сервиса целиком.

При помощи WS-Addressing описание "конечной точки" можно разместить в отдельном файле, а в WSDL оставить только ссылку на этот файл. Кроме того, на него можно ссылаться и из других мест, например из сценариев BPEL4WS. Иначе говоря, можно дать псевдоним сервису, скажем <MyService>, и ссылаться на это название из файлов сценариев. Конкретная же ссылка на объект, реализующий сервис, может быть довольно большой. Так, WS-Adrressing стандартизует способ ссылок на поток исполнения (instances) сервиса, а именно позволяет описать идентификатор этого потока в заголовке SOAP (<wsa:Address> подраздел <wsa:ReferenceProperty>). Такой подход обеспечивает, в частности, большую независимость от транспортного протокола - для выбора правильного потока более не нужно указывать его ID в URI, как это делалось ранее.

Упрощенная схема гарантии обмена сообщениями с высылкой подтверждения

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

В частности, можно указать: идентификатор сообщения, необходимый для обеспечения корреляции сообщений в протоколе обмена; исходящий адрес сообщения (<wsa:From>); адрес, куда можно отправить ответ на сообщение (<wsa:ReplyTo>); адрес, по которому можно слать сообщения об ошибках (<esa:FaultTo>); ссылку на ID другого сообщения (<wsa:ReferTo>) и пр.

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

WS-Addressing наследует и замещает WS-Routing. По требованиям безопасности из нее исключены элементы, обозначающие абсолютный и относительный пути (<r:path>, <r:fwd> и <r:rev>). Предполагается, что для маршрутизации пользователи будут полагаться на поход "next hop" ("следующая пересадка"). Но большинство элементов WS-Addressing в области маршрутизации по смыслу эквивалентны аналогичным элементам WS-Routing.

Примечание. Спецификация защищена авторскими правами и не может свободно использоваться.

WS-Referral (Global XML Web Services Referral Protocol)

Статус: фирменная спецификация.

Автор: Microsoft, 2001-2004.

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

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

Это частная технология Microsoft используется вместе с WS-Addressing и WS- Routing.

WS-MetadataExchange, WS-EndpointResolution, WS-TransmissionControl

Статус: анонсированные, но еще не опубликованные спецификации.

Авторы: Microsoft, IBM и пр.

WS-MetadataExchange предлагает набор WS-механизмов для обмена между участниками, политиками, WSDL-описаниями, схемами и другими метаданными.

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

WS-TransmissionControl предоставляет конструкции для контроля обмена сообщениями между сервисами, для увеличения надежности обмена и предотвращения их потери в случае недоступности сервиса, переполнения очередей сообщений и других причин.

WS-Inspection

Статус: авторская спецификация, 2001 г., используется редко.

Авторы: IBM, Microsoft.

Строго говоря, является не средством описания "конечных точек", а аналогом реестра сервисов. Предлагает XML-формат, помогающий описать сервисы, доступные на Web-сайте, и правила потребления их услуг. Наследник старых технологий DISCO и ADS. Стандарт WS-Inspection предлагает средства для сбора ссылок на существующие документы разных форматов, содержащие характеристики сервисов, а также добавления собственной информации. Спецификация описывает работу с WSDL и реестрами UDDI.

Полученные составные документы становятся доступны в точке "предложения сервиса", а также через URL-ссылки, которые можно разместить внутри HTML-страниц.

Формат разумно применять, когда на сайте нет большого числа сервисов. В противном случае стоит пользоваться дорогостоящими реестрами UDDI. С развитием UDDI он утратил первоначальное значение.

***

Эти спецификации закрывают все проблемы инфраструктурного слоя Web-сервисной среды. Более высокоуровневые спецификации описывают правила формирования составных Web-сервисов и опирающихся на WS бизнес-процессов. Они будут рассмотрены в следующей части.

(Продолжение следует)