В предыдущей статье ("WSDL: взгляд изнутри, часть I") автор привел общее описание процесса проектирования Web-сервисов. В ней отмечалось, что Язык описания Web-сервисов (Web Services Description Language, WSDL) только определяет синтаксис того, как Web-сервис может быть вызван; он не говорит ничего о его семантике. В этой статье этот вопрос получит дальнейшее рассмотрение.
В настоящий момент наиболее широко используется версия WSDL 1.1, опубликованная в качестве Примечания консорциума W3C (W3C Note). Она не является официальным стандартом. WSDL 1.1 предлагает широкие возможности для вызова Web-сервисов. При этом поддержка инструментов осуществляется посредством "патчей". Эта версия WSDL была встречена недоброжелательно, поскольку явила собой компромисс между выразительностью и гибкостью, с одной стороны, и многословностью и сложностью, с другой. Прежде чем продолжить, автор вынужден признаться, что он не представляет, как написать действительно четкий, точный WSDL.
Перед тем, как вдаваться в подробности, давайте рассмотрим инструмены, которые могут помочь. Во-первых, при написании WSDL можно воспользоваться XML-редактором, желательно с возможностью проверки валидности WSDL-документа. Модифицируя WSDL для существующих Web-сервисов, автор обнаружил, что очень полезно уметь генерировать, посылать и получать сообщения из редактора; XML Spy от Altova выполняет это для Web-сервисов, использующих SOAP и HTTP. Благодаря этому интерактивные разработка, тестирование и отладка WSDL получают практический смысл. К сожалению, XML Spy не предоставляет такую возможность для других протоколов. Важная функциональность, которое, похоже, отсутствует в сегодняшних инструментах - это возможность проверять ответ сервера на допустимость согласно описанию Web-сервиса.
Применяя ключевое слово import, можно разделить WSDL на документы-модули. Пример, приведенный в Примечании консорциума W3C состоит из трех документов, которые содержат, соответственно, определения типов данных, абстрактные определения и специфические связывания сервиса. Эти специфичные или конкретные определения сервисов зависят от абстрактных определений сервиса, которые в свою очередь зависят от определений типов данных.
Помимо улучшения читабельности этот подход может также повысить возможность расширения и повторного использования некоторых типов: одни и те же определения типов данных могут быть использованы во многих абстрактных сервисах, а одни и те же абстрактные сервисы могут быть использованы во многих различных связываниях по многим адресам.
Вначале множество Web-сервисов может быть представлено в виде набора из трех документов. Однако, по мере того, как сервис развивается, это может вылиться в дерево документов, у которого в корне находятся определениями типов данных, а его ветви расходятся к нескольким документам абстрактных сервисов и далее к конкретным сервисам.
Элемент portTypes - это набор семантически связанных операций, во многом подобный интерфейсу в языке программировании. Элемент binding не обязан охватывать все элементы operation данного portType. Например, определенные в одном portType элементы operation могут использовать различные транспортные протоколы. Поскольку service - это набор элементов port, а port ссылается на отдельный binding, можно определять сервисы, которые не предлагают все operation, определенные в portType. Однако, наличие таких сервисов является признаком плохо разделенных элементов portType.
Отдельный сервис может быть составлен из множества интерфейсов, каждый из которых представляет отдельный аспект этого сервиса. Например, у сервиса может быть порт для своей бизнес логики и еще один порт для доступа к функциям управления.
Описания Web-сервиса, как только они согласованы, должны быть зафиксированы. WSDL 1.1 предусматривает необязательное использование целевого пространства имен. Однако, удобно назначать пространство имен для недвусмысленной идентификации сервисов и их версий - как принято делать в случае спецификаций стандартов. Сложность состоит в том, что WSDL 1.1 не очень четок относительно того, что подразумевается под целевым пространством имен. Другими словами, что точно вкладывается в это понятие? По мнению автора, под ним понималось те же правила, что и в W3C XML Schema.
Напомним кратко эти правила: то, что помещается в целевое пространство имен регулируется атрибутом form в элементах element и attribute. При отсутствии такого атрибута управление передается набору значений по умолчанию в атрибутах elementFormDefault и attributeFormDefault, находящихся в корневом элементе schema. При отсутствии явного задания значений по умолчанию в силу вступают неявные значения по умолчанию: к пространству имен относятся только элементы, определенные глобально.
В каком виде эти правила W3C XML Schema нашли свое отражение в WSDL 1.1? Во-первых, в WSDL не задействованы элементы element и attribute. Во-вторых, элементами верхнего уровня в WSDL являются messages, portTypes, bindings и services, являющиеся сущностями (entity), которые должны быть помещены в целевое пространство. Очевидно, в данном случае type не релевантны. В-третьих, несмотря на то, что теоретически атрибут form мог бы использоваться с любыми элементами, определенными в WSDL, это не является принятой практикой. В-четвертых, аналогично сказанному, атрибуты elementFormDefault и attributeFormDefault могли бы использоваться в элементе definitions, но автор с этим не сталкивался.
Таким образом, можно утверждать, что все message, portType, binding и service оказываются в целевом пространстве имен, а их потомки - нет.
Удобно ли это правило? А имеет ли это значение? Это имеет смысл, когда сообщения зашифрованы так, что - за исключением этого правила - пространство описания Web-сервиса могло бы "просочиться" в сообщение. Действительно, автор потратил достаточно времени, чтобы выяснить, что пространства имен, которые находились в зашифрованном SOAP-сообщениях, не были в пространстве имен WSDL из-за того, что, согласно принятой, но обескураживающей практике, то же самое пространство имен используется в качестве входного для шифрования SOAP. Непосредственным результатом указанного правила пространства имен является отсутствие элементов и атрибутов сообщения в пространстве имен описания Web-сервиса, если только они не помещены туда пространством имен шифрования SOAP.
Если описание Web-сервиса разложено на модули, согласно приведенной выше рекомендации, каждому документу должно быть назначено пространство имен. Описания Web-сервиса не должны импортировать (import) определения с одинаковым пространством имен. Спецификация WSDL не формулирует это правило явно, но опять-таки, по мнению автора, наличие элемента import в W3C XML Schema явился причиной появление одноименного элемента в WSDL и расширения тех же правил. Schema не разрешает импортирующей и импортируемой схеме совместно использовать пространство имен. По оценке автора, это очень удобное правило, поскольку сложно рассуждать о пространстве имен, если нет уверенности, что определение полное.
Возможно, единственно наиболее важное отличие между демо- и готовым сервисом заключается в качестве обработки ошибок. Тем не менее, в литературе этому вопросу удаляется мало внимания.
Определение отдельных сообщений с целью установления различных сбойных ситуаций может быть удобно - структура таких сообщений может меняться согласно возникшей сбойной ситуации. В Листинге определен Web-сервис, который приведет в бешенство системных администраторов: он запускает двоичный код (binary), по запросу вызывающей программой. Читатель, возможно, будет разочарован, не обнаружив примеров использования пространств имен и разделения на модули - этот пример не рассматривает эти особенности. Он иллюстрирует обработку ошибок - при проектировании была предусмотрена возможность появления двух ошибок: первая - если недостаточно памяти, в этом случае возвращается область выделенной динамической памяти и количество используемой памяти; вторая - если программа попытается разыменовывать нулевой указатель, в этой случае возвращается запись стека.
Типы сообщения о сбоях получены из абстрактного типа. Причина использования абстрактных типов может быть объяснена желанием провести аналогию с отображением ошибочных действий в иерархию наследования во многих языках программирования. Поэтому исправленный Листинг - это более компактное описание Web-сервиса. Разница между наборами сообщений о сбоях, которые допустимы согласно соответствующим документам, незначительны.
Замысел, однако, намного яснее в первом документе. Разработчики клиентской реализации, работая со вторым документом вероятно смогут предположить, что может быть возвращено и сообщение OutOfMemoryException. Но из спецификации неясно, имеет ли это значение. Также они не могут быть уверенными, что код клиентской реализации охватывает все сбойные ситуации, поскольку абстрактный класс tException может быть расширен типами, отличными от перечисленных во втором документе.
Автор сталкивался с гибридным подходом, при котором сложный тип не объявлен абстрактным. В этом случае сообщения о сбоях могут быть определены в описании Web-сервиса как производный тип, иногда определяется сложный тип. В результате, возникает еще большая неопределенность относительно точного формата, который получит клиент - автор не рекомендует этот подход.
Здравый смысл предписывает использовать текстовый формат передачи при вызове документа и кодированный при использовании RPC (Remote Procedure Call, Удаленный вызов процедуры). Однако, фундаментальных причин, почему необходимо следовать этому правилу, нет - это скорее исторически сложившиеся стечение обстоятельств, что инструменты, как правило, поддерживают эти комбинации.
Выбор осуществляется между сложностью модели программирования и сложностью маршалинга (marshalling) сообщений. RPC предлагает удобную модель программирования. Она не без изъянов, как отмечалось в предыдущей статье. Однако, также важно знать об обязательствах, которые форматы передачи, используемые с RPC, накладывают на маршалеров: различие между literal и encoded - это различие между составителем и читателем. Это означает, что у второго формата передачи может быть множество различных представлений для семантически эквивалентных сообщений.
Классический пример - поддержка кодирования SOAP для независимых и встроенных элементов. Понимать все представления - дело получателя. В предыдущем разделе уже говорилось о важности максимально точного определения формата сообщения. Причина тому - высокая стоимость принятия правильного решения читателем. Это, возможно, не имеет значения в средах, в которых доступны сложные инструменты генерации клиентской заглушки (client stub), но при работе на гетерогенных платформах это не всегда так.
Как уже отмечалось, WSDL 1.1 не имеет статуса стандарта. И все же эта спецификация широко используется, часто не оправдывая надежд на возможность взаимодействия. Именно это и является причиной появления Организации по развитию возможности взаимодействия Web-сервисов (WS-I) - не получить право собственности на стандарт WSDL, а определить очертания, "состоящие из набора некоммерческих спецификаций Web-сервисов наряду с уточнениями и поправками к тем спецификациям, которые способствуют возможности взаимодействия".
Конечно, наличие еще одной организации стандартизации вызывает раздражение. Несмотря на заявленные цели, автор не может отделаться от ощущения, что деятельность организаций, схожих с WS-I, может привести к появлению взаимоисключающих стандартов. Тем не менее, он посоветовал бы ознакомиться с разделом 5 "Рабочего проекта принятия Basic Profile" (Basic Profile Approval Draft), в котором содержатся отличное разъяснение некоторых "дыр" WSDL 1.1. И все же автор не одобряет то, что организация уделяет максимум внимания SOAP.
В предыдущей статье также говорилось о Техническим комитете OASIS "Защищенность Web-сервисов" (OASIS WSS TC), который, кажется, становится лидером в области определения стандартов защищенности Web-сервисов. Это еще одна организация, которая решает часть поставленной выше задачи. Но смогут ли подойти друг к другу эти части, и кто собирается их объединять?
Право собственности на будущие версии WSDL, похоже, однозначно остается у консорциума W3C, где Рабочая группа по описанию Web-сервисов (Web Service Description Working Group) занята написанием WSDL 1.2. Согласно ее уставу, выход этой версии запланирован на май 2003 года. Эта срок, очевидно, будет сорван. Тем не менее, группа время от времени публикует рабочие проекты будущей редакции. Так, что же будет со "слабыми сторонами" WSDL , о которых шла речь выше?
Если судить по проекту, доступному на момент написания этой статьи, похоже, подтверждается интерпретация того, что происходит в целевом пространстве имен описания Web-сервисов. В нем говорится, что "информационная единица атрибута targetNamespace определяет присоединение пространства имен для компонентов верхнего уровня, определенных в этой информационной единице элемента definitions. Сообщения, типы порта, связывания и сервисы являются компонентами верхнего уровня". Будет ли WSDL 1.2 поддерживать реализацию нескольких интерфейсов является предметом жарких дебатов. В проекте WSDL 1.2 явно указано, что для используемых пространств имен с импортированными документами применяются те же правила как и в XML Schema. С другой стороны, альтернативный подход по разделению описаний на модули обеспечивается посредством элемента include, моделируемого по элементу include XML Schema, который не допускает совместного использования пространств имен.
XML Spy - зарегистрированная торговая марка компании Altova. Как обычно, особая благодарность Кэролайн Гринмен (Caroline Greenman) за критические замечания.
Ценную информацию о WSDL можно почерпнуть из следующих материалов:
Крепким духом и не только стоит прочитать "Примечание WSDL 1.1" консорциума W3C (WSDL 1.1). Обратите внимание на раздел 5 "Рабочего проекта принятия Basic Profile" (Basic Profile Approval Draft), поскольку в нем поясняются многие положения WSDL 1.1. Рабочая группа по описанию Web-сервисов (Web Service Description Working Group) занимается написанием спецификации WSDL 1.2. Время от времени группа публикует редакции рабочего проекта.