ОБЗОРЫ

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

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

Для создания относительно несложных систем этих трех стандартов достаточно. Однако уже сколько-нибудь нетривиальные решения (а именно такие, как правило, и нужны в корпоративной среде) требуют использования таких вещей, как гарантированная асинхронная доставка сообщений, управление транзакциями, шифрование пересылаемых между системами данных и обеспечение их неподдельности (подробнее эти вопросы рассматривались во второй части обзора "Интеграция: новое решение старых проблем", PC Week, N 36/2003, с. 31). Все эти направления так или иначе родственны WS, и активно создается некоторая надстройка разных спецификаций, позволяющая вписать эти технологии в мир WS. (Они давно применялись и безо всяких Web-сервисов, но зачастую встраивались в плохо совместимые фирменные продукты вендоров.)

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

Рынок взрослеет: в результате конкурентной борьбы разные производители объединились в несколько группировок, состязающихся теперь между собой. На разных направлениях WS этот набор группировок свой. Например, в области управления транзакциями и бизнес-процессами объединились IBM, BEA и Microsoft (условно IBM+) против Sun, Fujitsu и Oracle. Конечно, такое "кучкование" сократило темп роста числа спецификаций, но их все равно много и они не очень-то совместимы, что подрывает основу идеологии мира WS. В данном обзоре я постараюсь выделить и описать по крайней мере главные из предложенных технологий.

Компоненты базового набора

SOAP (Simple Object Access Protocol)

Назначение: транспортный протокол, удаленный вызов функционала.

Разрабатывается: XML Protocol Working Group консорциума W3C.

Статус: версия 2.0 утверждена OASIS, фактически отраслевой стандарт.

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

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

SOAP является простым "мостиком", обеспечивающим взаимодействие приложений: в него заложена парадигма однонаправленного обмена сообщениями, без поддержки сохранения состояния этого обмена. Потому для создания систем со сложными последовательностями обмена информацией требуются дополнительные средства, обеспечивающие пересечение границ брандмауэров, многоузловую маршрутизацию, гарантированную доставку. Однако SOAP задает инфраструктуру, в рамках которой частная для каждого приложения инфраструктура может быть описана в относительно унифицированной форме. Кроме того, в стандарте изложены общие принципы, по которым может быть осуществлена привязка SOAP-сообщений к абстрактному транспортному протоколу (необходимая для этого информация будет содержаться в заголовке сообщений), описана общая схема создания SOAP-оболочек для RPC-ориентирированных интерфейсов (удаленный вызов процедур), приведены конкретные механизмы (в первую очередь способы возврата сообщений о сбоях), а также зафиксирована конкретная реализация способа оформления сообщений SOAP в качестве содержимого команд GET и POST протокола HTTP.

Примечание 1. Привязка к определенному транспортному протоколу позволяет сократить объем программирования, необходимого для написания SOAP-ориентированного приложения, а также уменьшить объем трафика. Иначе говоря, в точке отправления из исходного сообщения изымается определенная информация и размещается средствами транспортного протокола в его пакетах, а в точке получения сообщение реконструируется в исходном виде.

Например, протокол HTTP уже имеет средства для обеспечения корреляции сообщений (т. е. средства логического связывания запроса и ответа), и программисту не нужно заботиться о корреляции запрос - ответ. Привязка к HTTP также позволяет сделать Web-сервисы более соответствующими общему стилю WWW и четче передавать сообщения об ошибках. Скажем, сервис класса "только для чтения" может идентифицироваться в Web некоторым адресом URI и по команде GET, не имеющей параметров, выдавать уже SOAP-отформатированную информацию. Но такая привязка действительна только между двумя соседними узлами, поддерживающими транспортный протокол.

Примечание 2. Группа спецификаций SOAP 1.2 сегодня содержит две основные части (SOAP 1.2 Part 1: Messaging Framework и SOAP 1.2 Part 2: Adjuncts), три вспомогательных документа (SOAP 1.2 Message Normalization, SOAP 1.2 E-mail Bindings, Specification Assertions and Test Collection) и "Введение" (SOAP 1.2 Primer).

Типичное SOAP-сообщение (пример из SOAP Version

1.2 Message Normalization)

WSDL (Web Services Description Language)

Назначение: описание свойств сервиса.

Разрабатывается: W3C.

Статус: W3C Working Draft, 26 марта 2004, фактически отраслевой стандарт.

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

Согласно этому стандарту WSDL-описание сервиса состоит из пяти частей.

1. При помощи нотаций XML Schema описываются типы данных, используемые сервисом (раздел <wsdl:types>).

2. Задается описание входных WSDL-сообщений (<wsdl:message>), состоящих из элементов, имеющих типы, описанные в <wsdl:types>.

3. Описываются порты (<wsdl:portType>) - их имена, названия и спецификации допустимых по ним операций (<wsdl:operation>). Каждая такая операция характеризуется тройкой сообщений - входным, выходным и сообщением о сбое. В стандарте задано четыре типа операций - однонаправленные, запрос - ответ, подтверждение - ответ и уведомление (две последние являются инверсиями двух первых). Соответственно, WSDL-порт может быть однонаправленным и двунаправленным. Информирование о сбоях - функция двунаправленных портов.

4. Задается привязка (<wsdl:binding>) к транспортному протоколу. Здесь происходит переход от логической модели данных к реальной физической модели, т. е. тому, как именно передаются данные по SOAP. Для описания перехода используются так называемые SOAP-расширения WSDL (определены также привязки WSDL к HTTP и MIME). С помощью этих расширений можно, например, просто указать серверу, что для формирования реального SOAP-документа в его тело требуется скопировать тела описанных WSDL-сообщений. Здесь же задается адрес сервиса в WWW.

5. Группируются описания сервиса (<wsdl:service>) - сводятся вместе имя сервиса, данные о портах, привязках и человеко-читаемый комментарий о целях сервиса. С помощью этого раздела сервис можно привязать к нескольким альтернативным зеркалам.

Примечание. Группа спецификаций WSDL 2.0 состоит из трех основных документов - WSDL Part 1:Core language ("Основной язык"), WSDL Part 2: Message exchange patterns ("Шаблоны обмена сообщениями"), WSDL Part 2: Bindings ("Привязки"). Имеется также неоконченное "Введение".

UDDI (Universal Description Discovery & Integration)

Назначение: стандарт на функционал и структуру базы данных описаний сервисов.

Статус: OASIS UDDI Spec Technical Committee Specification, 14 октября 2003.

Вместе с SOAP и WSDL образует тройку базовых стандартов Web-сервисов. Представляет собой стандарт на внутреннее устройство и внешние интерфейсы базы данных (репозитория), хранящей описания сервисов. Задает модель данных и стандартизует API, в том числе Web-сервисный. Все описания в БД хранятся в виде XML-записей.

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

В то время как версия UDDI 2.0 предназначалась для поддержки каталогов электронного бизнеса, версия 3.0 ориентирована и на внутрикорпоративное использование - для построения корпоративных систем в рамках идеологии Service Oriented Architecture. Поэтому она допускает создание реестров нескольких типов (общедоступный, частный и с разделяемым доступом).

Пример репликации реестров UDDI

Для упрощения поиска UDDI-реестр предлагает стандартные механизм для классификации, каталогирования, поиска и управления web-сервисами:

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

2) UDDI позволяет публикаторам информации расширять число способов классифицирования любого элемента. При этом есть возможность проверки соотвествия данных элемента требованиям классификатора;

3) UDDI Inquiry API позволяет указывать в параметрах поиска классификатор и классификационные признаки, а также проводить соединение данных разных поисковых запросов.

Примечание. UDDI опирается на WSDL и XML Schema.

Оптимизации базовых спецификаций

В стандартном виде SOAP оказался очень неэффективной с точки зрения потребления вычислительных ресурсов технологией. Например, сообщение EDI (electronic data interchange - электронный обмен данными), описывающее данные накладной, имеет длину около 80 байт, в то время как аналогичное XML-сообщение уже 1,5 Кб. SOAP добавит к нему заголовок и теги разметки, что еще больше увеличит его размер. Если в теле SOAP-сообщения оказываются мультимедийные данные, то ситуация становится совсем катастрофической.

Вот только некоторые из возникающих проблем:

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

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

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

Поэтому были созданы несколько спецификаций, описывающих правила оптимизации трафика.

SOAP 1.2 Attachment Feature

Назначение: описывает абстрактную модель формирования SOAP-сообщений с вложениями.

Статус: W3C Working Group Note 8 June 2004.

Решает две первые из перечисленных выше проблем, вводя модель формирования составных SOAP-сообщений (конверт SOAP плюс вложения).

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

Составная структура не является ни обобщением структурной модели SOAP, ни обобщением конверта SOAP и не определяет модель обработки основного сообщения (все эти задачи отводятся спецификации SOAP). Это просто абстрактная модель, базовые "правила игры", которым нужно следовать при дальнейшей реализации привязок SOAP к конкретному транспортному протоколу. В действительности спецификация склоняется к привязкам к протоколу HTTP.

Составное сообщение в соответствии со спецификацией SOAP Attachments Feature

Вот примеры возможного применения SOAP Attachment Feature:

- главная часть и JPEG-картинка могут быть инкапсулированы в одно DIME-сообщение (см. WS-Attachments) и переданы через TCP или HTTP;

- главная часть и JPEG-картинка могут быть инкапсулированы в MIME Multipart/Related message и переданы через HTTP;

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

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

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

 

     WS-Attachments и DIME

Назначение: оптимизация двоичных вложений в SOAP-документах и формат их передачи

Статус: авторская спецификация, рабочий документ Internet Engineering Task Force (IETF), 17 июня 2002.

Авторы: IBM, Microsoft.

Спецификация опирается на SOAP Attachment Feature и решает дополнительно третью из перечисленных во введении в раздел проблем. Фактически она является реализацией SOAP AF. Авторы отмечают, что применение MIME (технологии широкого назначения) приводит к росту затрат на синтаксический разбор, например, ресурсоемким оказывается выделение различных частей в MIME-пакете. Поэтому они предлагают свой специализированный и облегченный формат: DIME (Direct Internet Message Exchange).

Спецификация WS-Attachments позволяет оформлять SOAP-сообщения и их двоичные вложения в блоки DIME-данных. DIME рассматривается как наследник MIME-multipart. Он опирается на записи фиксированной длины, что более эффективно, чем использование разделителей в MIME. У него есть заголовок с содержанием, а это позволяет, в частности, обеспечить к отдельным записям не последовательный, а произвольный доступ. Получается, что DIME - это механизм упаковки набора произвольно отформатированных записей в поток данных.

XOP (XML-binary Optimized Packaging Mechanism)

Назначение: оптимизация объемов XML-документа и представления в нем данных (кодирование).

Статус: W3C Working Draft, 8 июня 2004.

Задает альтернативный общепринятому способ сериализации XML Infoset. Полезен, когда внутри SOAP-сообщений передается мультимедийный и прочий двоичный контент. В обычной форме этот контент должен быть закодирован в виде base64 и помещен в тело SOAP. При помощи XOP его можно вынести в последовательность MIME-блоков, находящихся за пределами конверта SOAP-документа. В теле же документа остаются лишь ссылки на эти данные.

Диаграмма состояния XOP

    

Примечание. Формат применим не только к SOAP, но и любому XML-документу.

SOAP Message Transmission Optimization Mechanism

Назначение: оптимизация SOAP-трафика.

Статус: W3C Working Draft 8 June 2004.

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

Развивает направление экономии трафика и сетевых ресурсов. Описывает Abstract Transmission Optimization Feature - очень неконкретный механизм привязки SOAP к транспортному протоколу, позволяющий кодировать части сообщений SOAP, сохраняя соответствие требованиям XML Infoset. Оптимизация для тех элементов контента, которые являются каноническими XML-представлениями данных в формате xs:base64Binary. В частности, определяется структура и порядок кодирования ATO-сообщений, а также правила их раскодирования. Алгоритмов, как именно это делать, не дается, формулируются только общие положения - какими полями какие данные размечать.

Хотя спецификация описывает и более конкретные вещи - реализации ATO. Так, рассматривается способ оптимальной сериализации SOAP-сообщения для передачи его в виде последовательности блоков MIME-кодированного текста, привязка к HTTP и тип MIME-данных application/soap_xop+xml. Для решения этих задач активно используется формат XOP (XML-binary Optimized Packaging Mechanism), фактически спецификация задает его адаптацию к ATO.

SOAP Resource Representation Header

Назначение: расширение SOAP для оптимизации трафика.

Статус: W3C Working Draft, 28 апреля 2004.

Авторы: Oracle, Microsoft, W3C.

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

***

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

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