NexxDigital - компьютеры и операционные системы

Как 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-документов и их преобразования в стандартную форму.

Разбор WSDL 1.1

Используемые пространства имен

В этой статье используются:

  • префикс wsdl для представления пространства имен WSDL 1.1 http://schemas.xmlsoap.org/wsdl/ ;
  • префикс soap для пространства имен http://schemas.xmlsoap.org/wsdl/soap/ , используемого расширением SOAP 1.1 для WSDL 1.1;
  • префикс xs для пространства имен http://www.w3.org/2001/XMLSchema , используемого для определений XML-схемы.

Редакция 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 используется фиксированный корневой элемент с удобным названием . В пределах этого корневого элемента в пространстве имен WSDL 1.1 определены один «пассивный» дочерний элемент (просто ссылка на отдельные документы WSDL 1.1) и пять «активных» дочерних элементов (которые собственно и составляют описание сервиса):

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

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

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

В листингах 1 и показан пример описания сервиса WSDL, разбитого на два WSDL-документа, так что компоненты описания интерфейса содержится в файле BookServerInterface.wsdl, а компоненты реализации ― в файле BookServerImpl.wsdl. В листинге 1 показан BookServerInterface.wsdl.

Листинг 1. BookServerInterface.wsdl
Book service interface definition. ... ... Book service implementation. This creates an initial library of books when the class is loaded, then supports method calls to access the library information (including adding new books). Get the book with a particular ISBN. ... Add a new book.

В листинге 2 показан BookServerImpl.wsdl. Элемент в начале импортирует описание интерфейса BookServerInterface.wsdl.

Листинг 2. BookServerImpl.wsdl
Definition of actual book service implementation. ...

Помимо определений элементов (и атрибутов) в пространстве имен WSDL 1.1, WSDL 1.1 определяет также дополнительные элементы. Они предназначены для заполнения конкретных ячеек в описаниях сервисов WSDL 1.1 для передачи дополнительной информации, необходимой для конкретного типа сервисов. Единственные дополнительные элементы WSDL 1.1, которые все еще широко используются, это привязки для SOAP 1.1 (они представлены в , в элементах и ), которые были определены в первоначальной спецификации WSDL 1.1, и для SOAP 1.2, определенные отдельной спецификацией в 2006 году.

Детали компонентов

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

Поскольку один элемент может содержать любое количество определений схемы, нет никаких причин использовать в документе WSDL более одного элемента . В элемент находится в верхней части BookServerInterface.wsdl.

Помимо и , всем компонентам верхнего уровня документа WSDL присвоены отдельные имена с использованием обязательного атрибута name . При использовании атрибута targetNamespace в корневом элементе документа (что обычно лучше всего), имена этих компонентов определены в этом целевом пространстве имен. Это означает, что при определении имени достаточно присвоить простую, или «локальную», часть имени, но ссылки на этот компонент должны уточнять имя с помощью префикса пространства имен или с помощью пространства имен по умолчанию. На рисунке 1 показаны наиболее важные связи между компонентами WSDL, причем сплошные линии соответствуют ссылкам по полному имени, а пунктирные ― по имени, используемому для идентификации без уточнения пространства имен.

Рисунок 1. Связи между компонентами WSDL

Сообщения, представленные элементами , расположены в ядре описаний сервисов WSDL. Элементы - это описания XML-данных, передаваемых между клиентом и поставщиком услуг. Каждый элемент содержит ноль или более (обычно один) дочерних элементов . Для каждого элемента part требуется собственный атрибут name (уникальный в пределах ) и один из атрибутов element или type , ссылающийся на определение схемы XML-данных. Несколько элементов показаны в , после элемента в BookServerInterface.wsdl.

Элементы определяют абстрактный интерфейс сервиса в части сообщений, передаваемых сервису и принимаемых от него. Элементы содержат любое количество дочерних элементов . Каждому дочернему элементу требуется собственный атрибут name (BP WS-I требует, чтобы он был уникальным в пределах ), и в нем содержится один или несколько дочерних элементов, описывающих сообщения, используемые операцией. Дочерние элементы бывают трех типов, соответствующих разным способам использования:

  • : данные, отправляемые клиентом поставщику услуг в качестве входных данных для операции;
  • : данные, возвращаемые клиенту поставщиком услуг как результат операции;
  • : данные, возвращаемые клиенту поставщиком услуг при возникновении ошибки в процессе обработки.

WSDL 1.1 определяет несколько шаблонов взаимодействия между клиентом и поставщиком услуг, представленных различными последовательностями дочерних элементов и , но не все модели достаточно хорошо определены, чтобы их можно было реализовать. BP WS-I допускает всего две модели: операций типа запрос-ответ, где за следует , и односторонние операции, содержащие только . В случае операций типа запрос-ответ (на сегодняшний день наиболее распространенный тип) за элементами и может следовать любое количество элементов .

Каждый элемент , или ссылается на описание сообщения посредством обязательного атрибута message . Это ссылка с уточнением пространства имен, поэтому она обычно требует добавления префикса. Примеры можно увидеть в : например, когда элемент используется в описании операции getBook . (Префикс tns служит определением корневого элемента с тем же пространством имен URI, что и у атрибута targetNamespace .)

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

Сравнение SOAP 1.1 и 1.2

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, вероятно, является лучшим выбором.

Элементы представляют собой экземпляр абстрактного интерфейса, определенного , который виден в в начале BookServerImpl.wsdl. Атрибут type содержит полное имя типа порта, реализованного в привязке.

Дочерние элементы содержат подробную информацию о способе реализации типа порта. Дочерние элементы из пространства имен WSDL соответствуют элементам и должны использовать то же значение name – а не ссылки с уточнением пространства имен, как в случае . эта связь показана пунктирными линиями на уровне . Та же связь по имени относится и к дочерним элементам / / элементов . Несмотря на такое повторное использование одних и тех же имен элементов, содержание этих элементов значительно различается, когда это дочерние элементы , а не элемента .

Расширения, определяемые WSDL, вступают в игру в . Дочерний элемент используется в определении сервиса SOAP (единственный тип сервиса, допускаемый BP WS-I, хотя WSDL 1.1 допускает еще и привязки HTTP). Этот элемент использует обязательный атрибут transport для определения вида транспорта, используемого привязкой. (HTTP, как видно из значения http://schemas.xmlsoap.org/soap/http в , - это единственный выбор, разрешенный ВР WS-I.) Необязательный атрибут style позволяет выбирать между стилями rpc и document для представления XML-данных (наиболее распространенное значение document соответствует сообщениям с использованием элементов определения схемы, а не типа).

Внутри каждого дочернего элемента элемента элемент может использоваться для указания значения SOAPAction с целью идентификации запросов вызова этой операции (и потенциально также для переопределения выбора стиля document или rpc, указанного элементом , хотя BP WS-I запрещает такое использование). Каждый дочерний элемент / / содержит другой дополнительный элемент, который в всегда является элементом (указывающим, что данные сообщения передаются в теле сообщения SOAP – данные и даже ошибки можно передавать также в заголовках SOAP, хотя я не рекомендую это) для или , или его эквивалент , используемый с .

Последним компонентом описания сервиса 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

Валидация и верификация

В этой статье я использую термин верификация для обозначения проверки правильности WSDL-документа, потому что альтернативный термин валидация , обычно используемый для XML-документов, означает проверку документов на соответствие определению схемы.

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

Еще один вариант ― генерирование кода из схемы BP WS-I для WSDL 1.1. Увидев это, я понял, что простое использование созданных классов напрямую приведет к путанице, так как схема включает избыточные типы, а также некоторые неудобные конструкции, которые используются для представления различных моделей обмена сообщениями (некоторые из которых затем были запрещены текстом BP WS-I).

Так что в конечном итоге я составил классы вручную, хотя результат оказался почти таким же, как если бы я начал с кода, сгенерированного из схемы, и просто сократил ненужное дублирование и сложность. Привязка данных JiBX поддерживает несколько связей с одними и теми же классами, так что мне удалось создать привязку ввода для обработки всего спектра вариантов, допускаемых любой версией WSDL 1.1, хотя настройка привязки выхода для вывода WSDL была только в форме, соответствующей практическим рекомендациям.

В листинге 3 показана часть класса Definitions , соответствующая корневому элементу .

Листинг 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 m_validationContext; /** Текущее состояние (используется для проверки порядка, в котором добавляются*/ /** дочерние элементы). */ private AddState m_state; /** Имя этого определения. */ private String m_name; /** Целевое пространство имен WSDL. */ private String m_targetNamespace; /** Список всех импортируемых дочерних элементов. */ private List m_imports = new ArrayList(); /** Список всех типов дочерних элементов. */ private List m_types = new ArrayList(); /** Список всех сообщений дочерних элементов. */ private List m_messages = new ArrayList(); /** Список всех дочерних элементов portType. */ private ListM_portTypes = new ArrayList(); /** Список всех привязок дочерних элементов. */ private List m_bindings = new ArrayList(); /** Список всех сервисов дочерних элементов. */ private List m_services = new ArrayList m_nameMessageMap = new HashMap(); /** Отображение квалифицированного имени на тип порта в этом определении. */ private Map m_namePortTypeMap = new HashMap(); /** Отображение квалифицированного имени на сообщение в этом определении. */ private Map m_nameBindingMap = new HashMap(); /** Отображение квалифицированного имени на сервис в этом определении. */ private Map m_nameServiceMap = new HashMap(); ... /** * Проверка переходных состояний между различными типами дочерних элементов. * Если элементы не находятся в ожидаемом порядке, * для отчета отмечается первый элемент вне ожидаемого порядка. * @param state new add state * @param comp element component */ private void checkAdd(AddState state, ElementBase comp) { if (m_state != state) { if (m_state == null || (m_state != AddState.invalid && state.ordinal() > m_state.ordinal())) { // переход к другому типу дочерних элементов m_state = state; } else if (state.ordinal() < m_state.ordinal()) { // отчет о дочерних элементах вне ожидаемого порядка m_validationContext.addWarning ("Child element of wsdl:definitions out of order", comp); m_state = AddState.invalid; } } } ... /** * Добавление немаршаллизированного дочернего элемента wsdl:message. * Здесь же сообщение индексируется по имени для доступа с целью валидации. * * @param child */ public void addMessage(Message child) { checkAdd(AddState.message, child); m_messages.add(child); addName(child.getName(), child, m_nameMessageMap); } ...

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

В любом из элементов 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-документа, когда компоненты не следуют в ожидаемом порядке.

Другие дополнения

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

Следующая статья продолжит эту тему, рассматривая проблемы, часто встречающиеся при написании утверждений WS-Policy и WS-SecurityPolicy. Кроме того, в ней будет более подробно рассмотрена модель WSDL и процесс верификации, в том числе расширение модели с включением утверждений WS-Policy/WS-SecurityPolicy, встроенных в WSDL.

Страница 2 из 3

Описание с помощью WSDL

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-службы содержит всю необходимую для использования этой службы информацию, включая доступные методы и их параметры. Эта информация содержится в следующих пяти элементах:

  • - поддерживаемые протоколы.
  • - сообщения Web-службы (запрос, ответ).
  • Все доступные методы.
  • - URI службы.
  • - используемые типы данных.

Вся эта информация хранится в корневом элементе WSDL-описания , В листинге ниже представлен пример WSDL-описания Web-службы.

WSDL-описание Web-службы

Да уж... без стаканА не разберёшся, а ведь это один из самых простеньких(!) WSDL файлов. К сожалению, один из недостатков SOAP-расширения для РНР 5 связан с тем, что в отличие от других реализаций SOAP, оно не позволяет создавать WSDL-описания автоматически (во всяком случае, пока что). Наверняка этот недостаток исправят в будущих версиях РНР.

Кстати!

Для автоматического создания WSDL-описания вы можете использовать альтернативные реализации протокола SOAP в РНР:

Поиск в справочнике с помощью UDDI

Теперь, после того как мы знаем, как получать информацию о 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 (Публикация) позволяет разработчикам регистрировать свои службы . Похоже, что заполнение содержимого реестров спамом - это только вопрос времени:)

Кстати!

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

Так выглядит запрос Web-службы:

sortByNameAsc sortByDateDesc %guid%

В примере выше видно, что UDDI-запрос инкапсулирован в SOAP-сообщение, поэтому выглядит он довольно знакомым. Ответом на запрос является также SOAP-документ, показанный ниже:

Web Services Guided Tour Sample Web services for Guided Tourbook Guided Tour StockQuote Service

Установка

Установить SOAP-расширение для PHP5 довольно легко. В Windows этот модуль находится в подкаталоге ext каталога установки РНР. Для его использования необходимо в файл php.ini добавить следующую строку: extension=php_soap.dll Для работы этому модулю требуется, которая включена в РНР 5 по умолчанию, по крайней мере, в Windows-версии.

Элементы расширения связывания используются для указания конкретной грамматики для входящих (3) и исходящих (4) сообщений, сообщений об ошибках (5). Также может указываться информация уровня операции (2) и уровня связывания (1).

Элемент связывания operation содержит данные для одноимённой операции связанного типа порта. Однако имя операции в общем случае не является уникальным (пример: перегрузка методов / функций — использование одинаковых имён с различными сигнатурами), потому его может быть недостаточно для однозначного определения целевой операции типа порта. В таких случаях целевая операция адресуется с помощью дополнительного задания соответствующих имён элементов wsdl:input и wsdl:output с помощью атрибута name .

Связывание должно устанавливать только один протокол.

Связывание не должно содержать информации об адресе.

Порт

Порт определяет отдельную конечную точку посредством установки адреса для связывания.

  1. <wsdl :definitions .... >
  2. <wsdl :service .... > *
  3. <wsdl :port name = "nmtoken" binding = "qname" > *
  4. <-- extensibility element (1) -->
  5. wsdl :port >
  6. wsdl :service >
  7. wsdl :definitions >

Атрибут name задаёт уникальное имя среди всех портов в рамках WSDL-документа. Атрибут binding типа QName содержит ссылку на связывание (см.).

Элементы расширения (1) используются для задания адреса.

Порт не должен задавать более одного адреса.

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

Служба

Служба объединяет вместе набор связанных портов.

  1. <wsdl :definitions .... >
  2. <wsdl :service name = "nmtoken" > *
  3. <wsdl :port .... /> *
  4. wsdl :service >
  5. wsdl :definitions >

Атрибут name задаёт уникальное имя среди всех служб, определённых в рамках WSDL-документа.

Порты внутри службы связаны следующим образом:

  • Порты не взаимодействуют друг с другом (т.е. выход одного порта не является входом другого).
  • Если служба имеет несколько портов, которые разделяют общий тип порта, но используют разные связывания, либо имеют различные адреса, такие порты являются альтернативными. Каждый такой порт реализует логически эквивалентное поведение (в рамках ограничений транспорта и формата сообщений, накладываемых соответствующим связыванием). Это позволяет клиенту выбирать конкретный порт для обмена на основе различных критериев (поддержка транспортного протокола и т.д.).
  • Рассмотрев порты, можно определить поддерживаемые службой типы портов. На основе этих данных клиент может определить возможность взаимодействия с конкретной службой. Это полезно, если подразумевается связь между операциями из разных типов портов, и для выполнения определённой задачи требуется поддержка службой всех необходимых типов портов.
  1. Это вольный, частичный, дополненный перевод документа Web Services Description Language (WSDL) 1.1 от 15 Марта 2001
  2. Несклоняемыми написанными латиницей терминами оперировать крайне неудобно, к тому же они однозначно переводятся. Поэтому исходное имя даётся только при введении нового термина, а далее по тексту используется русский перевод.

Заголовок топика – это действительно вопрос, т.к. я сам не знаю, что это и впервые попробую поработать с этим в рамках настоящей статьи. Единственное, что могу гарантировать, что код, представленный ниже, будет работать, однако мои фразы будут лишь предположениями и догадками о том, как я сам все это понимаю. Итак, поехали…

Введение

Начать надо с того, для чего создавалась концепция веб-сервисов. К моменту появления этого понятия в мире уже существовали технологии, позволяющие приложениям взаимодействовать на расстоянии, где одна программа могла вызвать какой-нибудь метод в другой программе, которая при этом могла быть запущена на компьютере, расположенном в другом городе или даже стране. Все этого сокращенно называется RPC (Remote Procedure Calling – удаленный вызов процедур). В качестве примеров можно привести технологии CORBA, а для Java – RMI (Remote Method Invoking – удаленный вызов методов). И все вроде в них хорошо, особенно в CORBA, т.к. с ней можно работать на любом языке программирования, но чего-то все же не хватало. Полагаю, что минусом CORBA является то, что она работает через какие-то свои сетевые протоколы вместо простого HTTP, который пролезет через любой firewall. Идея веб-сервиса заключалась в создании такого RPC, который будет засовываться в HTTP пакеты. Так началась разработка стандарта. Какие у этого стандарта базовые понятия:
  1. SOAP . Прежде чем вызвать удаленную процедуру, нужно этот вызов описать в XML файле формата SOAP. SOAP – это просто одна из многочисленных XML разметок, которая используется в веб-сервисах. Все, что мы хотим куда-то отправить через HTTP, сначала превращается в XML описание SOAP, потом засовывается в HTTP пакет и посылается на другой компьютер в сети по TCP/IP.
  2. WSDL . Есть веб-сервис, т.е. программа, методы которой можно удаленно вызывать. Но стандарт требует, чтобы к этой программе прилагалось описание, в котором сказано, что «да, вы не ошиблись – это действительно веб-сервис и можно у него вызвать такие-то такие-то методы». Такое описание представляется еще одним файлом XML, который имеет другой формат, а именно WSDL. Т.е. WSDL – это просто XML файл описания веб-сервиса и больше ничего.
Почему так кратко спросите вы? А по подробней нельзя? Наверное можно, но для этого придется обратиться к таким книгам как Машнин Т. «Web-сервисы Java». Там на протяжении первых 200 страниц идет подробнейшее описание каждого тега стандартов SOAP и WSDL. Стоит ли это делать? На мой взгляд нет, т.к. все это на Java создается автоматически, а вам нужно лишь написать содержимое методов, которые предполагается удалено вызывать. Так вот, в Java появился такой API, как JAX-RPC. Если кто не знает, когда говорят, что в Java есть такой-то API, это означает, что есть пакет с набором классов, которые инкапсулируют рассматриваемую технологию. JAX-RPC долго развивался от версии к версии и в конечном итоге превратился в JAX-WS. WS, очевидно, означает WebService и можно подумать, что это простое переименование RPC в популярное нынче словечко. Это не так, т.к. теперь веб-сервисы отошли от первоначальной задумки и позволяют не просто вызывать удаленные методы, но и просто посылать сообщения-документы в формате SOAP. Зачем это нужно я пока не знаю, вряд ли ответ здесь будет «на всякий случай, вдруг понадобится». Сам бы хотел узнать от более опытных товарищей. Ну и последнее, далее появился еще JAX-RS для так называемых RESTful веб-сервисов, но это тема отдельной статьи. На этом введение можно заканчивать, т.к. далее мы будем учиться работать с JAX-WS.

Общий подход

В веб-сервисах всегда есть клиент и сервер. Сервер – это и есть наш веб-сервис и иногда его называют endpoint (типа как, конечная точка, куда доходят SOAP сообщения от клиента). Нам нужно сделать следующее:
  1. Описать интерфейс нашего веб-сервиса
  2. Реализовать этот интерфейс
  3. Запустить наш веб-сервис
  4. Написать клиента и удаленно вызвать нужный метод веб-сервиса
Запуск веб-сервиса можно производить разными способами: либо описать класс с методом main и запустить веб-сервис непосредственно, как сервер, либо задеплоить его на сервер типа Tomcat или любой другой. Во втором случае мы сами не запускаем новый сервер и не открываем еще один порт на компьютере, а просто говорим контейнеру сервлетов Tomcat, что «мы написали тут классы веб-сервиса, опубликуй их, пожалуйста, чтобы все, кто к тебе обратиться, могли нашим веб-сервисом воспользоваться». В независимости от способа запуска веб-сервиса, клиент у нас будет один и тот же.

Сервер

Запустим IDEA и создадим новый проект Create New Project . Укажем имя HelloWebService и нажмем кнопку Next , далее кнопку Finish . В папке src создадим пакет ru.javarush.ws . В этом пакете создадим интерфейс HelloWebService: package ru. javarush. ws; // это аннотации, т.е. способ отметить наши классы и методы, // как связанные с веб-сервисной технологией import javax. jws. WebMethod; import javax. jws. WebService; import javax. jws. soap. SOAPBinding; // говорим, что наш интерфейс будет работать как веб-сервис @WebService // говорим, что веб-сервис будет использоваться для вызова методов @SOAPBinding (style = SOAPBinding. Style. RPC) public interface HelloWebService { // говорим, что этот метод можно вызывать удаленно @WebMethod public String getHelloString (String name) ; } В этом коде классы WebService и WebMethod являются так называемыми аннотациям и ничего не делают, кроме как помечают наш интерфейс и его метод, как веб-сервис. Это же относится и к классу SOAPBinding . Разница лишь в том, что SOAPBinding – это аннотация с параметрами. В данном случае используется параметр style со значением, говорящим, что веб-сервис будет работать не через сообщения-документы, а как классический RPC, т.е. для вызова метода. Давайте реализуем логику нашего интерфейса и создадим в нашем пакете класс HelloWebServiceImpl . Кстати, замечу, что окончание класса на Impl – это соглашение в Java, по которому так обозначают реализацию интерфейсов (Impl – от слова implementation, т.е. реализация). Это не требование и вы вольны назвать класс как хотите, но правила хорошего тона того требуют: package ru. javarush. ws; // таже аннотация, что и при описании интерфейса, import javax. jws. WebService; // но здесь используется с параметром endpointInterface, // указывающим полное имя класса интерфейса нашего веб-сервиса @WebService (endpointInterface = "ru.javarush.ws.HelloWebService" ) public class HelloWebServiceImpl implements HelloWebService { @Override public String getHelloString (String name) { // просто возвращаем приветствие return "Hello, " + name + "!" ; } } Запустим наш веб-сервис как самостоятельный сервер, т.е. без участия всяких Tomcat и серверов приложений (это тема отдельного разговора). Для этого в структуре проекта в папке src создадим пакет ru.javarush.endpoint , а в нем создадим класс HelloWebServicePublisher с методом main: package ru. javarush. endpoint; // класс, для запуска веб-сервера с веб-сервисами import javax. xml. ws. Endpoint; // класс нашего веб-сервиса import ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher { public static void main (String. . . args) { // запускаем веб-сервер на порту 1986 // и по адресу, указанному в первом аргументе, // запускаем веб-сервис, передаваемый во втором аргументе Endpoint. publish ("http://localhost:1986/wss/hello" , new HelloWebServiceImpl () ) ; } } Теперь запустим этот класс, нажав Shift+F10 . В консоли ничего не появится, но сервер запущен. В этом можно убедиться набрав в браузере строку http://localhost:1986/wss/hello?wsdl . Открывшаяся страница, с одной стороны, доказывает, что у нас на компьютере (localhost) запустился веб-сервер (http://) на порту 1986, а, с другой стороны, показывает WSDL описание нашего веб-сервиса. Если вы остановите приложение, то описание станет недоступно, как и сам веб-сервис, поэтому делать этого не будем, а перейдем к написанию клиента.

Клиент

В папке проекта src создадим пакет ru.javarush.client , а в нем класс HelloWebServiceClient с методом main: package ru. javarush. client; // нужно, чтобы получить wsdl описание и через него // дотянуться до самого веб-сервиса import java. net. URL; // такой эксепшн возникнет при работе с объектом URL import java. net. MalformedURLException; // классы, чтобы пропарсить xml-ку c wsdl описанием // и дотянуться до тега service в нем import javax. xml. namespace. QName; import javax. xml. ws. Service; // интерфейс нашего веб-сервиса (нам больше и нужно) import ru. javarush. ws. HelloWebService; public class HelloWebServiceClient { public static void main (String args) throws MalformedURLException { // создаем ссылку на wsdl описание URL url = new URL ("http://localhost:1986/wss/hello?wsdl" ) ; // Параметры следующего конструктора смотрим в самом первом теге WSDL описания - definitions // 1-ый аргумент смотрим в атрибуте targetNamespace // 2-ой аргумент смотрим в атрибуте name QName qname = new QName ("http://ws.javarush.ru/" , "HelloWebServiceImplService" ) ; // Теперь мы можем дотянуться до тега service в wsdl описании, Service service = Service. create (url, qname) ; // а далее и до вложенного в него тега port, чтобы // получить ссылку на удаленный от нас объект веб-сервиса HelloWebService hello = service. getPort (HelloWebService. class ) ; // Ура! Теперь можно вызывать удаленный метод System. out. println (hello. getHelloString ("JavaRush" ) ) ; } } Максимум комментариев по коду я дал в листинге. Добавить мне нечего, поэтому запускаем (Shift+F10). Мы должны в консоли увидеть текст: Hello, JavaRush! Если не увидели, то видимо забыли запустить веб-сервис.

Заключение

В данном топике был представлен краткий экскурс в веб-сервисы. Еще раз скажу, что многое из того, что я написал – это мои догадки по поводу того, как это работает, и поэтому мне не стоит сильно доверять. Буду признателен, если знающие люди меня поправят, ведь тогда я чему-нибудь научусь. UPD.

Предисловие

Заказчики заказчиков попросили заказчиков xsd файлы для структур, передаваемых реализуемыми Web-сервисами. Заказчики в ответ предложили заказчикам заказчиков сделать WSDL-ки. Т.о. неожиданно «на ровном месте» возникла необходимость сделать не просто xsd-схемы для валидации данных, а «целые WSDL-ки». Обычно WSDL-ки используются для SOAP, а у нас REST…

Ранее я уже писал про

Введение

Термин Web-сервисы обычно ассоциируется с operation- или action-based сервисами, базирующимися на SOAP или WS* стандартах, таких как WS-Addressing или WS-Security. Термин REST Web-сервисы обычно относится к resource-based архитектуре Web-сервисов, передающих XML через HTTP. Каждый из этих архитектурных стилей имеет собственное место, но до недавнего времени, WSDL стандарт не поддерживал оба эти стиля. WSDL 1.1 HTTP binding был неадекватен для описания взаимодействия с помощью XML по HTTP, т.о. не было формального способа описать REST Web-сервисы с помощью WSDL. Публикация стандарта WSDL 2.0 (который был разработан с учётом необходимости описания REST Web-сервисов) в статусе рекомендации World Wide Web Consortium (W3C) дала язык для описания REST Web-сервисов.

REST — архитектурный стиль трактующий Web как resource-centric приложение. Практически, это означает, что каждый URL в RESTful приложении представляет собой ресурс. URL-и просто понимать и запоминать. Например, книжный магазин может определить URL http://www.bookstore.com/books/ для списка продаваемых книг и http://www.bookstore.com/books/0321396855/ для деталей о конкретной книге с ISBN 0321396855. Это контрастирует с action-centric приложениями, обычно имеющими длинные сложношифованные URL-и, описывающими действия, которые необходимо выполнить, например http://www.bookstore.com/action/query?t=b&id=11117645532&qp=0321396855 . Параметры запроса используются для выбора необходимых данных. Используя пример книжного магазина, указание параметра subject ограничивает тематику книги. Например физика или детективы или к примеру URL http://www.bookstore.com/books/?subject=computers/eclipse — запрос возвращающий список книг про платформу Eclipse.

Термин REST придумал Roy Fielding в своей кандидатской диссертации. Он рассматривал гиперссылки как средство для изменения (хранения) состояния приложения. Гиперлинки хранятся в ресурсах приложения и являются методом изменения состояния приложения, редиректа из одного состояния в другое. Обычно гиперлинки в (X)HTML предназначены для использования людьми, они не использовались в XML, который был предназначен для машинной обработки. Также как и (X)HTML, REST Web-сервисы испльзуют гиперлинки в XML.

Традиционные Web-приложения получают доступ к ресурсам посредством HTTP GET или POST операций. RESTfull приложения работают с ресурсами в стиле «create, read, update, and delete (CRUD)» используя полные возможности HTTP протокола (POST, GET, PUT, and DELETE).

Ещё одно важное замечание о REST приложении: RESTful приложения должны быть stateless. Это означает, что REST приложение не сохраняет никакого состояния сессии на стороне сервера. Вся информация, необходимая для выполнения запроса, передается в самом запросе. (Поэтому на повторяющиеся запросы сервер обязан отвечать одинаково прим. переводчика). Соответственно клиент может кешировать полученные ресурсы, что может значительно ускорить скорость работы приложения там, где сервис явно разрешает это. Чтобы узнать больше про REST, см ссылки к статье.

WSDL и REST

WSDL содержит все детали о веб-сервисе, включая:

    URL веб-сервиса
    Механизмы коммуникации, корые понимает веб-сервис
    Операции, которые может выполнять веб-сервис
    Структура сообщений веб-сервиса

Клиенты могут использовать перечисленные детали для взамодействия с сервисом.

WSDL 2.0 был объявлен рекомендацией W3C в июне 2007. Эта версия WSDL стандарта была выпущена для решения проблем стандарта WSDL 1.1, многие из которых были обнаружены организацией Web Services Interoperability (WS-I). Кроме того в WSDL 2.0 улучшена поддержка HTTP bindings.

WSDL сам является XML — подмножеством формально описывающим веб-сервис. Рассматривайте WSDL описание веб-сервиса как его API контракт с клиентом. В WSDL указывается адрес, допустимые способы передачи информации, интерфейса и типы сообщений веб-сервиса. Короче говоря, описание WSDL содержит всю информацию, необходимую клиенту для использования веб-сервиса.

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

  • Генерирование исходного кода клиентского приложения и сервера для веб-сервиса на разных языках программирования
  • Публикация веб-сервиса
  • Динамическое тестирование веб-сервиса

Большинство программных средств для работы с веб-сервисами включают в себя поддержку WSDL 1.1. Последнее время растёт количество средств разработки веб-сервисов, поддерживающих WSDL 2.0. Проект Apache Web services состоит из двух подпроектов, которые в настоящее время поддерживают WSDL 2.0. Woden — парсер-валидатор WSDL 2.0 на базе Java. Apache Web services проект также предоставляет XSL (XSLT) трансформацию WSDL 2.0 под названием WSDL 2.0 pretty printer , обеспечивающую лучшую человекочитаемость документа WSDL. Axis2 популярный engine веб-сервисов, (тоже от Apache) реализующий генерацию клиентского и серверного Java кода из документа WSDL 2.0.

Описание REST веб-сервиса с помощью WSDL 2.0

Вы создаете книжный магазин, который с продвинутым URL: http://www.bookstore.com . Вы уже создали две службы REST Web:

  • book list — сервис получает список продаваемых у вас книг.
  • book details — сервис получает информацию о конкретной книги.

Ответ возвращается в XML-документах.

Элемент interface определяет список операций веб-сервиса, включая описание входных, выходных сообщений и сообщений об ошибках для операций, а также порядка передачи.

Элемент binding определяет, средства коммуникации клиента с веб-сервисом. В случае REST веб-сервисов, в качестве средства коммуникации указывается HTTP.

Элемент service ассоциирует адреса веб-сервиса с конкретными интерфейсами (interface) и средствами коммуникации (binding). (Т.е. задает соответствие URL операции веб-сервиса и элементу binding ).

Привязываем book list к HTTP

Элемент binding задает привязку веб-сервиса к конкретному протоколу передачи данных. Для привязки book list сервиса к HTTP нужно указать значение http://www.w3.org/ns/wsdl/http для атрибута type элемента binding .

Элемент binding может опционально ссылаться на interface . Оставьте атрибут interface пустым. Вы создадите его в следующем разделе. Если interface ассоциирован с binding , тогда binding элемент может опционально определять дочерний элемент operation , являющийся зеркальным для interface operation элемента. Вам нужно создать заглушку элемента operation и заполнить ссылку на operation позже после создания interface .

Существует 4 HTTP communication метода

  • DELETE

Book list сервис читает запрос и соответственно оперирует с помощью HTTP GET. Установите метод GET для элемента operatioin используя атрибут method из WSDL 2.0 HTTP namespace. Для использования этого атрибута, вам нужно сначала определить namespace http://www.w3.org/ns/wsdl/http в элементе description .

Book list сервис binding определен на нижеследующем листинге. Укажите теперь binding в элементе endpoint : tns:BookListHTTPBinding.

The bookstore"s book list service.

Определение book list service operation

So far you’ve learned how to address and communicate with the book list Web service. Next you specify the book list service operation, which describes what the book list service does.

Итак, вы научились задавать address и задавать binding (способ коммуникации) для веб-сервиса. Далее необходимо задать service operation, определяющую что делает book list веб-сервис.

Элемент interface и его дочерний operation элемент используются для определения сервисных операций. В случае с book list, вы определяете одну операцию getBookList, возвращающую список книг.

Затем определите три атрибута для элемента operation:

Pattern

Используется для указания шаблона обмена сообщениями message exchange pattern (MEP) для операции. MEP определяет последовательность сообщений для операции и их направление. В этом случае необходимо указать значение http://www.w3.org/ns/wsdl/in-out чтобы указать, что веб-сервис получает одно входное сообщение просьбой о списке книг, и посылает одно выходное сообщение со списком книг. Для поддержки этого MEP, указажите дочерние элементы input и output для элемента operation . Эти элементы используют элементы описанные в XML schema, определяющие структуры сообщений. Подробности в следующем разделе.

Style

Используется для указания дополнительной информации о работе. Укажите значение http://www.w3.org/ns/wsdl/style/iri , накладывающее ограничения на содержание входных элементов, такие как требование, что это только использовать XML schema элементы.

wsdlx:safe

wsdlx:safe: From the WSDL extensions namespace, this attribute declares that this operation is idempotent. This type of operation doesn’t modify the resource and can therefore be called many times with the same results. To make use of this element, declare the WSDL extensions namespace http://www.w3.org/ns/wsdl-extensions on the description element.

Этот атрибут из WSDL extentions namespace. Он определяет, что операция является idempotent . Эта операция не модифицирует ресурс, поэтому может быть вызвана многократно с одинаковыми результатами. Чтобы использовать этот элемент, нужно объявить namespace WSDL extentions http://www.w3.org/ns/wsdl-extensions в корневом элементе (элементе description).

Вы можете найти предопределенные Message Exchange Patterns, styles и wsdlx:safe определения по ссылке WSDL 2.0 Part 2: Adjuncts

Ниже приведено определение book list сервиса с добавленным описанием interface . После добавления interface теперь можно изменить binding operation элемент чтобы указать ссылки на описанные interface и operation.

The RESTful HTTP binding for the book list service. The bookstore"s book list service.

Определение сообщений сервиса book list operation

Веб-сервис book list использует два сообщения: входное и выходное. Вы должны описать структуры этих сообщений, чтобы клиентские программы знали что отправлять в адрес сервиса и что ожидать обратно.

WSDL 2.0 supports multiple type systems for describing the message content, but XML schema is the only one in use. This section doesn’t cover the details of XML schema. XML schema is used in many other applications, like WSDL 1.1, and there are many good articles about it. This section highlights how to use XML schema for the book list REST Web service and how to use additional attributes defined by WSDL 2.0 to annotate a schema attribute.

WSDL 2.0 поддерживает множество систем определения типов, но на практике используются только XML schema. Эта статья не вдается в детали XML schema. XML schema используется во многих других приложениях, например, WSDL 1.1, и есть много хороших статей о нем. (). В этом разделе демонстрируется, применение XML schema применительно к конкретному примеру REST сервиса book list, а также использование дополнительных атрибутов определенных в WSDL 2.0 для аннотации schema атрибута.

Чтобы описать 2 сообщения для book list, необходимо описать 2 глобальных элемента.

  • getBookList представляет собой входное сообщение. Он содержит последовательность элементов, включая каждый параметр запроса, позволенный для сервиса: uthor, title, publisher, subject и language . Внутри getBookList сообщения могут использоваться только элементы, потому что выбран IRI style для interface operation.
  • bookList представляет собой выходное сообщение. Он содержит последовательность book элементов. Каждый book элемент в свою очередь содержит title и url атрибуты. Атрибут title не требует пояснений. Атрибут url это линк на сервис book details, возвращающий детальную информацию о конкретной книге.

Ваше определение атрибута url использует в свою очередь 2 атрибута из WSDL extensions namespace. Атрибуты wsdlx:interface и wsdlx:binding задают interface и binding для сервиса. Программное обеспечение может использовать эту информацию для автоматического нахождения сервиса. Для использования этих атрибутов, укажите WSDL extentions namespace для элемента schema . Также включите book details namespace из его WSDL 2.0 описания.

XML schema для book list сервиса приведена ниже.

The request element for the book list service. The response element for the book list service.

Для ссылки на input и output элементы, вы должны импортировать схему в ваш WSDL документ. Для импортирования сземы, используйте schema import элемент в разделе types как показано на листинге ниже. Кроме того, необходимо добавить ссылки на getBookList и Booklist элементы в interface operation input и output элементах и добавить пространства имен book list XML schema в корневой элемент WSDL.

Готовый WSDL для book list веб-сервиса.

This is a WSDL 2.0 description of a sample bookstore service listing for obtaining book information. This operation returns a list of books. The RESTful HTTP binding for the book list service. The bookstore"s book list service.

Примечание переводчика

Я позволил себе не переводить summary и ссылки. И то и другое смотреть у автора. в оригинальной статье . Надо сказать язык оригинала весьма тяжёл. Однако, надеюсь, статья окажется полезной.



Если заметили ошибку, выделите фрагмент текста и нажмите Ctrl+Enter
ПОДЕЛИТЬСЯ:
NexxDigital - компьютеры и операционные системы