В главе 2 мы говорили о том, что после создания Web-службы на сервере в виде сервлета, страницы JSP, JWS-файла, компонента EJB или другого объекта, следует описать состав и возможности Web-службы на языке, не зависящем от платформы, операционной системы, системы программирования, использованной при создании Web-службы. Это описание регистрируется в общедоступном месте Интернета, например, реестре UDDI или ebXML, или хранится на сервере Web-службы. Описание должно содержать полную и точную информацию обо всех услугах, предоставляемых Web-службой, способы получения услуг, содержимое запроса на получение услуги, формат предоставляемой информации.
Одно из средств точного и единообразного описания Web-услуг - язык WSDL, созданный консорциумом W3C. Этот язык - еще одна реализация XML. Его последняя рекомендованная спецификация всегда публикуется на странице http://www.w3.org/TR/wsdI . Во время написания книги на черновой стадии была версия WSDL 1.2, которую мы и опишем в этой главе.
Состав документа WSDL
Корневым элементом документа XML - описания WSDL - служит элемент
Описания WSDL активно используют различные пространства имен. Кроме собственных имен, язык WSDL часто использует имена типов и элементов языка описания схем XSD (см. главу 1) и имена языка протокола SOAP. Пространство имен языка WSDL часто описывается как пространство имен по умолчанию. Идентификатор пространства имен последней на время написания этих строк версии WSDL 1.2 был равен http://www.w3.org/2002/07/wsdl . Целевое пространство имен, идентификатор которого определяется атрибутом обычно получает префикс tns (target namespace).
В корневой элемент
?
?
?
?
?
? < service > - указывает местоположение Web-службы как один или несколько портов. Каждый порт описывается вложенным элементом
Кроме этих шести основных элементов есть еще два вспомогательных элемента.
?
Комментарий. Его можно включить в любой элемент
описания WSDL.
Можно сказать, что элементы
Элементы
Наконец, элементы
Структура документа WSDL показана в листинге 4.1. Символы в квадратных скобках не содержатся в документе. Они показывают повторяемость элемента или атрибута в описании Web-службы:
Символ [?] означает, что элемент или атрибут может появиться в документе нуль или один раз;
Символ [*] означает, что элемент может появиться нуль или несколько раз;
Символ [+] означает, что элемент может появиться один или несколько раз;
Отсутствие символа в квадратных скобках означает, что атрибут должен появиться ровно один раз.
j Листинг 4.1. Схема WSDL-документа
targetNamespace="nfleH l ra«iij location="URI-aflpec" /> [*] Произвольный комментарий Описания сложных и нестандартных типов.
Абстрактное описание SOAP-послания как набора составляющих его частей.
Абстрактное описание Web-службы как набора операций (услуг). Описание услуги как получения (input) и отправки (output, fault) посланий. Получаемое послание. Отправляемое message="nMH соотв. элемента Отправляемое сообщение об ошибке. type="MMH соотв. элемента Детали конкретного протокола. Они определяются в схеме этого протокола. -> Сюда записываются элементы, описывающие детали конкретной операции. -> Сюда записываются элементы, описывающие детали конкретного получаемого послания. -> Сюда записываются элементы, описывающие детали конкретного отправляемого послания. ->
Сюда записываются элементы, описывающие детали конкретного сообщения об ошибке. ->
serviceType="MMH соотв. элемента Описание интерфейса Web-службы как набора портов. binding="nMH соотв. элемента Сюда записывается обязательный и единственный адрес интерфейса Web-службы, записанный по правилам протокола, указанного в элементе
Каждый конкретный протокол пересылки посланий - SOAP, HTTP, FTP, SMTP - добавляет к шести основным и двум вспомогательным элементам языка WSDL свои дополнительные элементы, описывающие особенности данного протокола.
Приведем простой пример. В листинге 3.14 мы записали в виде класса Java простейшую Web-службу, возвращающую без всякой обработки присланный запрос:
public class EchoService{
public String getEcho (String req) { return req;
В листинге 4.2 приведено описание этой Web-службы на языке WSDL, использующее протокол SOAP.
Листинг 4.2. Описание Web-службы EchoService
version="1.0" encoding="UTF-8" ?>
targetNamespace="http://echoservice.com/echoservice.wsdl" xmlns="http://www.w3.org/2002/07/wsdl" xmlns:tns="http://echoservice.com/echoservice.wsdl" xmlns:soap="http://www.w3.org/2002/07/wsdl/soapl2" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
transport="http://schemas.xmlsoap.org/soap/http" /> "http://schemas.xmlsoap.org/soap/encoding/" namespace= "http: //echoservice. ccm/echcservice .wsdl" use="encoded" /> ^oapKbocy enccdingStyle= "http: //schemas .xmlsoap. org/soap/encoding/" namespace= "http: //echoservice. c^/ech^service .wsdl" use="encoded" /> "http://localhost:8080/axis/EchoService.jws" /> В листинге 4.2 мы в элементе Имена "getEchoRequest" И "getEchoResponse" ИСПОЛЬЗОВаны В следующем элементе txarspcrt^=^"ht:tp^://?cheпas^.>пlscap^.c^rc^/?cap^/ht:tp^" /> Если применяется документный стиль SOAP, то в атрибуте style записывается значение "document". Наконец, в элементе В листинге 4.2 имена с префиксом soap конкретизировали описание послания и способы его пересылки. Посмотрим, какие конкретные протоколы предлагает спецификация WSDL 1.2. Литература:
Хабибуллин И. Ш. Разработка Web-служб средствами Java. - СПб.: БХВ-Петербург, 2003. - 400 с: ил.
Страница 2 из 3 SOAP работает очень хорошо, если о Web-службе все известно. Однако это не всегда так. Средством описания интерфейса для доступа к Web-службе является язык WSDL (Web Services Description Language - язык описания Web-служб). Этот стандарт совместно разработан компаниями IBM, Microsoft и webMethods. У каждой из этих трех компаний был собственный подход к разработке стандарта для описания Web-служб: IBM создала NASSL, Microsoft разработала SCL, а компания webMethods придумала WIDL. Результатом их сотрудничества стала версия 1.1 языка WSDL, По поводу W3C следует отметить, что так же как и с SOAP, консорциум W3C на основе версии 1.1 разработал версию WSDL 1.2, которая теперь является рекомендацией W3C. WSDL-описание Web-службы содержит всю необходимую для использования этой службы информацию, включая доступные методы и их параметры. Эта информация содержится в следующих пяти элементах: Вся эта информация хранится в корневом элементе WSDL-описания Да уж... без стаканА не разберёшся, а ведь это один из самых простеньких(!) WSDL файлов. К сожалению, один из недостатков SOAP-расширения для РНР 5 связан с тем, что в отличие от других реализаций SOAP, оно не позволяет создавать WSDL-описания автоматически (во всяком случае, пока что). Наверняка этот недостаток исправят в будущих версиях РНР. Кстати!
Для автоматического создания WSDL-описания вы можете использовать альтернативные реализации протокола SOAP в РНР: Теперь, после того как мы знаем, как получать информацию о Web-службе и как ее запрашивать, нужно научиться находить такую службу. Для этой цели существует нечто похожее на "Желтые страницы", а именно - реестры UBR (Universal Business Registries - универсальные бизнес-реестры) - справочники Web-служб. Существует несколько таких реестров, среди которых реестры компаний IBM, Microsoft, NTT-Com и SAP. Эти реестры синхронизируют свои данные, поэтому можно пользоваться любым из них. Текущей версией стандарта UDDI является версия UDDI 3.0, хотя большинство реализаций используют версию 2. Среди разработчиков этого стандарта такие компании-гиганты, как HP, Intel, Microsoft и Sun. Для взаимодействия с UBR существует два типа API-интерфейсов: Inquiry API и Publish API
.
Интерфейс Inquiry API (Запрос) предназначен для запроса
служб в реестрах UBR, а интерфейс Publish API (Публикация) позволяет разработчикам регистрировать свои службы
. Похоже, что заполнение содержимого реестров спамом - это только вопрос времени:) Кстати!
Существуют тестовые реестры, предназначенные для тестирования регистрации служб перед их размещением в "настоящих" реестрах. В примере выше видно, что UDDI-запрос инкапсулирован в SOAP-сообщение, поэтому выглядит он довольно знакомым. Ответом на запрос является также SOAP-документ, показанный ниже:
Установить SOAP-расширение для PHP5 довольно легко. В Windows этот модуль находится в подкаталоге ext каталога установки РНР. Для его использования необходимо в файл php.ini добавить следующую строку: extension=php_soap.dll
Для работы этому модулю требуется, которая включена в РНР 5 по умолчанию, по крайней мере, в Windows-версии. Каждая web-служба предоставляет документ WSDL
(Web Service Description Language - язык описания web-службы), в котором описывается все, что клиенту необходимо знать об этой службе. WSDL
-документ служит тем же целям, что и файл IDL
( Interface Definition
Language - язык определения интерфейса) для компонента CORBA
или СОМ
: он определяет интерфейс web-службы. Указанный документ, по сути, представляет собой контракт между клиентом и web-службой, где декларируется, что "если вы вызовете такой-то метод с такими-то параметрами, то в качестве возвращаемой величины получите такие-то данные". Во многих отношениях web-службы даже проще, чем создаваемые для CORBA
или СОМ
компоненты. Например, в web-службах отсутствует возможность поддержки нескольких интерфейсов - каждый класс web-службы обеспечивает только один набор открытых (public
) методов. С другой стороны, документ WSDL
немного сложнее своего IDL
-эквивалента, поскольку он является платформонезависимым и поддерживает коммуникационные протоколы, отличные от SOAP
и HTTP
. Это означает, что каждый WSDL
-файл для web-службы .NET
содержит значительный объем стереотипного кода, служащего для обеспечения поддержки базового уровня коммуникации (в соответствии с протоколом SOAP
или методами GET
и POST
протокола HTTP
). ПРИМЕЧАНИЕ В процессе .NET
-программирования нет необходимости создавать свой собственный WSDL
-документ. Каждая web-служба .NET
генерирует такой документ автоматически. Его можно увидеть с помощью поддерживающего XML браузера. Некоторые разработчики утверждают, что стандарт WSDL
для web-служб не нужен, поскольку сообщения SOAP
являются самодостаточными и точно специфицируют типы данных любых содержащихся в них величин. Однако WSDL
-документ предоставляет простой и последовательный способ задания разработчиком синтаксиса вызова любого web-метода. Более того, этот документ позволяет использовать инструменты автоматического генерирования прокси-классов, подобные включенным в среды Visual Studio .NET
и .NET Framework
. Благодаря указанным средствам использование web-службы является таким же простым, как и применение локального класса. WSDL
-документ имеет основанный на XML
формат, в соответствии с которым информация подразделяется на пять групп. Первые три группы представляют собой абстрактные определения, не зависящие от особенностей платформы, сети или языка, а оставшиеся две группы включают конкретные описания. Связь между web-службами и их клиентами осуществляется посредством сообщений в формате XML
. SOAP
(Simple Object Access Protocol - простой протокол доступа к объектам) представляет собой протокол сообщений для выбора web-служб. Использование слова Object
в названии данного протокола является не совсем корректным, поскольку сообщения SOAP
не направляются объектам. Основная идея стандарта SOAP
заключается в том, что сообщения должны быть закодированы в стандартизированном XML
-формате. Можно сказать, что формат SOAP
идеально подходит для технологии RPC
(Remote Procedure Call
- вызов удаленной процедуры), так как SOAP
-сообщение содержит направляемые клиентом параметры или отсылаемую службой возвращаемую величину. Нет ничего удивительного в том, что другие программные продукты (скажем, сервер BizTalk
компании Microsoft) применяют протокол SOAP
для передачи иных типов информации. Аналогично, SOAP
-сообщения могут использоваться не только при передаче по протоколу HTTP
, но также при пересылке через сокеты, именованные каналы и даже по протоколу SMTP
электронной почты. Кроме сообщений SOAP
, для обмена данными с web-службами .NET
можно использовать методы GET
и POST
протокола HTTP
. Теоретически при передаче информации методом POST
вы можете по-прежнему применять формат SOAP
, но в этом случае данные проще передавать в виде набора имя-значение без указания их типа. Давайте рассмотрим преимущества применения формата SOAP
. Кодировать в XML
структуры данных и наборы DataSet
с использованием SOAP
так же легко, как и данные простых типов (скажем, целого или строкового). При использовании SOAP
-сообщений предоставляются дополнительные инструменты, позволяющие легко добавлять, например, функции обеспечения безопасности или трассировки. Истинная межплатформенность Протокол SOAP
лучше всего подходит для получения .NET
-услуги на обычном клиенте. Имеются наборы инструментов SOAP
для различных языков программирования (и даже для предыдущих версий Microsoft C++
и Visual Basic
). Чтобы обеспечить связь с web-службой посредством методов GET
и POST
протокола HTTP
, придется, очевидно, вручную сконструировать строку запроса, а затем вручную провести синтаксический разбор ответа, что, согласитесь, является не самым элегантным решением. Стандарт DISCO
предоставляет простейший способ получения доступа к файлам манифестов, позволяющий группировать ссылки на web-службы. Поскольку основной целью web-служб является обеспечение В2В-взаимодействия, требуется такой инструмент, который давал бы возможность не только создавать полезные функции, но и использовать их совместно с другими организациями. Информация о коммуникации с единственной web-службой может быть достаточно простой, но если у вас имеется сложная комбинация web-служб, которые расположены в различных приложениях ASP .NET
и предназначены для различных клиентов, намного сложнее уследить за тем, чтобы клиенты получили требуемую информацию. Один из методов обеспечения связей с различными web-службами состоит в создании специальной HTML-страницы. Однако такой подход не стандартизирован, требует формирования базового пользовательского интерфейса и может сбить с толку потребителей, которые просматривают web-узел. Возможны другие способы обмена информацией, в частности посредством электронной почты или телефона, но такие методы неэффективны. Технология DISCO
позволяет избежать данных проблем. DISCO
-файл - это не просто список web-служб и соответствующих связей, представленных в XML-формате. Такой файл может включать файлы различных web-серверов и поддерживает "динамический поиск" - автоматический поиск каталога файлов web-службы на сервере. Инструменты .NET
, например Visual Studio .NET
, содержат средства обработки файлов манифестов и предоставляют простой способ их просмотра, а также обеспечивают подключение группы связанных служб к клиенту. Чтобы использовать web-службу, клиенту необходимо знать адрес web-узла соответствующей компании либо адрес URL
файла манифеста. Файлы манифеста полезны тем, что объединяют множество web-служб в единственном списке, однако они не позволяют клиентам отыскивать web-службы определенного типа без указания наименования компании-разработчика. Спецификация UDDI
(Universal Description, Discovery, and Integration - универсальное описание, поиск и интеграция) позволяет избежать указанных проблем посредством использования специального хранилища (репозитория), где предприятия и организации могут размещать данные о предоставляемых ими web-службах. Инициаторами создания технологии UDDI
стали более 100 компаний (полный список можно найти по адресу http://www.uddi.org/community.html), включая основных конкурентов - Sun и Microsoft. Объединив свои усилия, эти компании разработали проект спецификации UDDI
, которая по истечении 18 месяцев была стандартизирована. Конечно, информация в подобном репозитории должна обновляться вручную. С этой целью некоторые "узловые операторы" хранят идентичные копии репозитория UDDI
. Эти компании обеспечивают хранение указанного репозитория и бесплатный доступ к нему для популяризации web-служб. Кроме того, Microsoft включила версию UDDI
в программное
обеспечение сервера Windows .NET
для
использования в корпоративных сетях интранета. В хранилище UDDI
содержатся сведения о предприятиях, предоставляющих web-службы, о типе каждой службы и связях с информацией и спецификациями, относящимися к этим службам. Любопытным фактом является то, что интерфейс UDDI
сам по себе представляет собой web-службу. Для регистрации или поиска службы следует отправить SOAP
-сообщение. Элементы расширения связывания используются для указания конкретной грамматики для входящих (3) и исходящих (4) сообщений, сообщений об ошибках (5). Также может указываться информация уровня операции (2) и уровня связывания (1). Элемент связывания operation содержит данные для одноимённой операции связанного типа порта. Однако имя операции в общем случае не является уникальным (пример: перегрузка методов / функций — использование одинаковых имён с различными сигнатурами), потому его может быть недостаточно для однозначного определения целевой операции типа порта. В таких случаях целевая операция адресуется с помощью дополнительного задания соответствующих имён элементов wsdl:input и wsdl:output с помощью атрибута name . Связывание должно
устанавливать только один протокол. Связывание не должно
содержать информации об адресе. Порт определяет отдельную конечную точку посредством установки адреса для связывания. Атрибут name задаёт уникальное имя среди всех портов в рамках WSDL-документа. Атрибут binding типа QName содержит ссылку на связывание (см.). Элементы расширения (1) используются для задания адреса. Порт не должен
задавать более одного адреса. Порт не должен
содержать любую информацию связывания, отличную от адреса. Служба объединяет вместе набор связанных портов. Атрибут name задаёт уникальное имя среди всех служб, определённых в рамках WSDL-документа. Порты внутри службы связаны следующим образом: Как WSDL 1.1 определяет Web-сервисы, и как создать модели на языке Java для верификации и преобразования WSDL-документов Web-сервисы ― важная функция технологии Java™ в корпоративных вычислениях. В этом цикле статей консультант по XML и Web-сервисам Денис Сосновский рассказывает об основных структурах и технологиях, ценных для Java-разработчиков, использующих Web-сервисы. Следите за статьями цикла, чтобы быть в курсе последних разработок в данной области и знать, как применить их в своих собственных проектах. Web-сервисы для корпоративных приложений в значительной степени зависят от использования определений сервисов. Определения сервисов описывают основное соглашение между поставщиком услуг и любым потенциальным потребителем, детализируя типы функций, предоставляемых сервисом, и сообщения в рамках каждой функции. Поставщики и потребители свободны в выборе способа реализации своих объектов обмена в той мере, в какой фактические сообщения, которые они посылают, соответствуют определению сервиса. Использование определения сервиса с описанием способа обмена XML-сообщениями ― это то, что отличает Web-сервисы от более ранних технологий распределенного программирования. Предлагались различные методы определения Web-сервисов, но наиболее широко используемым подходом остается WSDL 1.1. WSDL 1.1 имеет некоторые недостатки, в том числе чрезмерно сложную структуру, которая затрудняет его чтение для непосвященных. Он страдает также от отсутствия авторитетного формального определения, что привело к последовательным «уточнениям», которые заполняют некоторые пробелы в исходном документе спецификации. В результате стеки Web-сервисов стараются обрабатывать документы WSDL 1.1 как можно более гибко. Эта гибкость может усилить путаницу в понимании WSDL 1.1, так как разработчики видят широкий спектр WSDL-структур без каких-либо указаний на то, какой подход предпочтительнее. В этой статье мы покажем, как разобрать документы WSDL 1.1, и рассмотрим первые части модели Java для проверки WSDL-документов и их преобразования в стандартную форму. В этой статье используются: Редакция 1.1 WSDL, опубликованная в начале 2001 года, технически заменена рекомендациями W3C WSDL 2.0, опубликованными в 2007 году. WSDL 2.0 предлагает более четкую структуру, чем WSDL 1.1, наряду с большей гибкостью. Но WSDL 2.0 страдает от проблемы курицы и яйца: WSDL 2.0 не используется широко, потому что не поддерживается широко, а так как он широко не используется, у разработчиков стеков Web-сервисов мало стимулов его поддерживать. Несмотря на все его недостатки, для большинства целей WSDL 1.1 достаточно хорош. Оригинальная спецификация WSDL 1.1 была неточной в отношении количества используемых функций. Так как в центре внимания WSDL была работа с определениями служб SOAP, он включал также поддержку функций SOAP (таких как кодирование rpc), которые позднее оказались нежелательными. Организация Web Services Interoperability Organization (WS-I) решила эти проблемы в Базовом профиле (BP), который содержит практические рекомендации по Web-сервисам с использованием SOAP и WSDL. BP 1.0 был утвержден в 2004 году, а в 2006 году вышла редакция BP 1.1. В этой статье рассматривается WSDL 1.1 на базе рекомендаций BP WS-I и не затрагиваются фактически устаревшие функции, такие как кодирование rpc для SOAP. Предполагается, что структура XML-документов задается определениями XML-схемы. В первоначальную спецификацию WSDL 1.1 входит описание схемы, но эта схема в нескольких отношениях не соответствует текстовым описаниям. Позже это было исправлено в модифицированной версии схемы, но документ WSDL 1.1 не был отредактирован с учетом этого изменения. Затем группа BP WS-I решила внести еще больше изменений в схему WSDL и создала то, что преподносится как практические рекомендации к этой скользкой схеме. Документы, написанные для одной версии схемы, как правило, не совместимы с другими версиями (несмотря на то, что используется одно и то же пространство имен), но к счастью, большинство инструментов Web-сервисов в основном игнорирует схему и принимает все, что выглядит разумным. (См. ссылки на многие схемы WSDL в разделе ). Даже версия BP WS-I схемы WSDL 1.1 не очень помогает гарантировать соответствие спецификации документов WSDL 1.1. Схема не отражает всех ограничений BP WS-I, особенно в отношении порядка следования компонентов. Кроме того, XML-схема не способна обработать многие типы легко устанавливаемых ограничений в документах (такие как альтернативные атрибуты или необходимые дополнительные элементы из отдельной схемы). Поэтому проверка соответствия документа WSDL 1.1 спецификации WSDL 1.1 (с поправками, внесенными BP WS-I) включает в себя гораздо больше, чем просто выполнение валидации XML-схемы. Мы еще вернемся к данной теме в этой статье. Но сначала рассмотрим структуру описаний сервиса WSDL 1.1. В документах WSDL 1.1 используется фиксированный корневой элемент с удобным названием Существует также элемент Для полного описания сервиса, как правило, требуется, по крайней мере, один элемент каждого из этих типов, за исключением В листингах 1 и показан пример описания сервиса WSDL, разбитого на два WSDL-документа, так что компоненты описания интерфейса содержится в файле BookServerInterface.wsdl, а компоненты реализации ― в файле BookServerImpl.wsdl. В листинге 1 показан BookServerInterface.wsdl. В листинге 2 показан BookServerImpl.wsdl. Элемент Помимо определений элементов (и атрибутов) в пространстве имен WSDL 1.1, WSDL 1.1 определяет также дополнительные элементы. Они предназначены для заполнения конкретных ячеек в описаниях сервисов WSDL 1.1 для передачи дополнительной информации, необходимой для конкретного типа сервисов. Единственные дополнительные элементы WSDL 1.1, которые все еще широко используются, это привязки для SOAP 1.1 (они представлены в , в элементах Элемент Поскольку один элемент Помимо Сообщения, представленные элементами Элементы WSDL 1.1 определяет несколько шаблонов взаимодействия между клиентом и поставщиком услуг, представленных различными последовательностями дочерних элементов Каждый элемент Во многих отношениях SOAP 1.1 широко используется для Web-сервисов с момента опубликования спецификации в 2000 году. Версия SOAP 1.2 разработана при более широкой поддержке отрасли через W3C и опубликована в качестве официального стандарта W3C в 2007 году. SOAP 1.2 лучше документирована и чище, чем SOAP 1.1, причем некоторые уродливые аспекты 1.1 хирургически удалены. Несмотря на эту очищенную структуру, для большинства Web-сервисов практических различий между ними немного. Вероятно, наиболее существенная особенность SOAP 1.2 заключается в том, что это единственный официально поддерживаемый способ использования расширенной поддержки SOAP-вложений XML-binary Optimized Packaging (XOP) и SOAP Message Transmission Optimization Mechanism (MTOM). В цикле Web-сервисы Java
я до сих пор использовал SOAP 1.1, потому что некоторые старые стеки не поддерживают SOAP 1.2, но для разработки новых Web-сервисов 1.2, вероятно, является лучшим выбором. Элементы Дочерние элементы Расширения, определяемые WSDL, вступают в игру в Внутри каждого дочернего элемента Последним компонентом описания сервиса WSDL является элемент Не удивительно, что при всех вариациях схем и правил для документов WSDL 1.1 многие документы не соответствуют практическим рекомендациям BP WS-I. Поддержка всеми стеками Web-сервисов многих отклонений от практических рекомендаций помогла увековечить использование устаревших или неправильных конструкций, что привело к распространению дурной практики по всей отрасли. И я определенно не застрахован от этой инфекции – просматривая WSDL-документы, которые я приводил в качестве примеров кода для этого цикла, я к своему удивлению обнаружил, что ни один из них не является полностью корректным. Так что когда я решил написать эту статью, я подумал, что было бы хорошо включить в нее инструмент, с помощью которого можно проверять WSDL-документы на соответствие практическим рекомендациям. Казалось бы, отсюда всего один шаг до преобразования WSDL-документов в правильную форму, при условии, что оригинальный WSDL свободен от ошибок. Но работы оказалось значительно больше, чем я первоначально планировал, и полную информацию об этой модели я включу в следующие две статьи этого цикла. Для работы с WSDL-документами на языке Java построено множество различных моделей, в том числе широко используемый язык описания Web-сервисов для Java Toolkit (WSDL4J), который представляет собой эталонную реализацию JSR 110 (см. раздел ). Ни одна из этих моделей не соответствует тому, что я собирался сделать, ввиду двоякой постановки задачи: во-первых, чтение WSDL-документов в любой полуразумной форме и сообщение об ошибках и отклонениях от практических рекомендаций, и во-вторых, написание безошибочных WSDL-документов, переформатированных в форму, соответствующую практическим рекомендациям. WSDL4J, например, не сохраняет порядок вводимых элементов, так чтобы можно было сообщать о проблемах порядка их следования, и не обрабатывает определения схемы, так что его нельзя напрямую использовать для проверки ссылок из элементов В этой статье я использую термин верификация
для обозначения проверки правильности WSDL-документа, потому что альтернативный термин валидация
, обычно используемый для XML-документов, означает проверку документов на соответствие определению схемы. Ранее я уже частично реализовал модель WSDL для использования с привязкой данных JiBX в рамках проекта JiBX/WS. Эта модель предназначена только для вывода и включает относительно небольшое число классов, которые в некоторых случаях объединяют данные из вложенных элементов структуры WSDL XML ( Еще один вариант ― генерирование кода из схемы BP WS-I для WSDL 1.1. Увидев это, я понял, что простое использование созданных классов напрямую приведет к путанице, так как схема включает избыточные типы, а также некоторые неудобные конструкции, которые используются для представления различных моделей обмена сообщениями (некоторые из которых затем были запрещены текстом BP WS-I). Так что в конечном итоге я составил классы вручную, хотя результат оказался почти таким же, как если бы я начал с кода, сгенерированного из схемы, и просто сократил ненужное дублирование и сложность. Привязка данных JiBX поддерживает несколько связей с одними и теми же классами, так что мне удалось создать привязку ввода для обработки всего спектра вариантов, допускаемых любой версией WSDL 1.1, хотя настройка привязки выхода для вывода WSDL была только в форме, соответствующей практическим рекомендациям. В листинге 3 показана часть класса Definitions , соответствующая корневому элементу Организация данных дочерних элементов в показывает, каким образом модель поддерживает как общую форму ввода, так и форму вывода в соответствии с практическими рекомендациями. Вместо единого списка дочерних элементов всех типов, используются отдельные списки для каждого типа. Привязка ввода JiBX обрабатывает дочерние элементы как неупорядоченный набор, вызывая специфический для данного типа элементов set-метод всякий раз, когда дочерний элемент находится не на своем месте. Вместо того чтобы заменять какое-либо из предшествующий значений, set-метод добавляет экземпляр в типизированный список, как видно из set-метода addMessage() , который используется для дочерних элементов В любом из элементов WSDL разрешены дополнительные атрибуты и элементы (как правило, все атрибуты или элементы, которые не используют пространство имен WSDL 1.1). Примером таких дополнительных элементов служат конфигурации WS-Policy, встроенные в WSDL-документы из предыдущих статей данного цикла, как и ссылки на фактические политики. Лучше всего, чтобы эти дополнительные элементы предшествовали любым дочерним элементам из пространства имен WSDL 1.1, и именно так они обрабатываются в привязке вывода. Привязка ввода обрабатывает дополнительные элементы и атрибуты с помощью кода базового класса из классов элементов WSDL, не показанного в , и позволяет элементам следовать в любом порядке (генерируя предупреждение, если они следуют за элементом из пространства имен WSDL 1.1). Модель обрабатывает известные элементы, используя отдельные привязки для каждого дополнительного пространства имен, каждая из которых имеет свой собственный набор классов. Я рассмотрю обработку этих дополнительных элементов более подробно в следующем выпуске Web-вервисов Java
, где будет подробнее представлен и исходный код. Некоторая базовая верификация данных WSDL выполняется по мере добавления немаршаллизованных объектов, соответствующих элементам, в древовидную структуру WSDL-документа, как показано в коде addMessage() в конце . Этот код использует метод checkAdd() для проверки порядка следования дочерних элементов и метод addName() для проверки того, что представлено допустимое имя (текст соответствует типу схемы NCName и значение уникально в пределах типа элемента), и отображения имени на объект. Но это только проверка самой основной информации для отдельного элемента; для проверки других свойств каждого элемента и взаимосвязей между элементами необходим дополнительный код верификации. JiBX позволяет вызывать обработчики пользовательских расширений в рамках процесса маршаллинга и демаршаллинга. Для исполнения логики верификации модель WSDL использует один из таких дополнительных обработчиков, метод post-set. Метод post-set вызывается после завершения демаршаллинга связанного объекта, так что это часто хороший способ выполнения проверок типа верификации объектов. В случае проверки WSDL простейший подход – это выполнение всей верификации объектов из одного метода post-set для корневого элемента В этой статье изложены основы структуры и использования WSDL и введение в модель данных Java для WSDL, предназначенную для поддержки верификации WSDL-документов и их преобразования в форму, соответствующую практическим рекомендациям. Следующая статья продолжит эту тему, рассматривая проблемы, часто встречающиеся при написании утверждений WS-Policy и WS-SecurityPolicy. Кроме того, в ней будет более подробно рассмотрена модель WSDL и процесс верификации, в том числе расширение модели с включением утверждений WS-Policy/WS-SecurityPolicy, встроенных в WSDL.Описание с помощью WSDL
WSDL-описание Web-службы
Поиск в справочнике с помощью UDDI
Так выглядит запрос Web-службы:
Установка
Протокол SOAP
Стандарт DISCO
Спецификация UDDI
Порт
Служба
Серия контента:
Об этом цикле статей
Разбор WSDL 1.1
Используемые пространства имен
Компоненты описания
Листинг 1. BookServerInterface.wsdl
Листинг 2. BookServerImpl.wsdl
Детали компонентов
Рисунок 1. Связи между компонентами WSDL
Сравнение SOAP 1.1 и 1.2
Работа с WSDL
Модель WSDL
Валидация и верификация
Листинг 3. Класс Definitions (частично)
public class Definitions extends ElementBase
{
/** Перечисление дочерних элементов в ожидаемом порядке. */
static enum AddState {
invalid, imports, types, message, portType, binding, service };
/** Список разрешенных имен атрибутов. */
public static final StringArray s_allowedAttributes =
new StringArray(new String { "name", "targetNamespace" });
/** Валидация используемого контекста. */
private ValidationContextВерификация модели
Другие дополнения