Фальстарт

• Проекты
  • Пускач
  • Менеджер горячих клавиш
• Библиотека
• Обратная связь

Спецификация языка WSDL 1.1

1. Введение
   1. Пример WSDL-документа
   2. Соглашение об обозначениях
2. Определение службы
   1. Структура WSDL-документа
      1. Именование и включение документов
      2. Стиль составления документа
      3. Расширение языка и связывание
      4. Документирование
   2. Тип
   3. Сообщение
      1. Часть сообщения
      2. Абстрактные / конкретные сообщения
   4. Тип порта
      1. Однонаправленный запрос
      2. Запрос-ответ
      3. Просьба-ответ
      4. Уведомление
      5. Имена элементов в рамках операции
      6. Порядок параметров в рамках операции
   5. Связывание
   6. Порт
   7. Служба

Введение

Поскольку транспортные протоколы и форматы сообщений были стандартизованы web-сообществом, появилась возможность и необходимость описания взаимодействия систем в структурированном виде. Эту задачу решает WSDL — язык на базе XML, который описывает службу как набор конечных точек, способных обмениваться сообщениями. WSDL документирует и определяет в комплексе детали взаимодействия распределённых систем в удобном для машинной обработки виде.

WSDL определяет службу (service), как набор конечных точек (endpoint), или портов (port). При этом специфичные параметры реализации — формат данных, настройки транспортного протокола — отделены от определения абстрактных сообщений (message), операций (operation) и типов портов (port type), что позволяет переиспользовать эти определения. Конкретный тип порта с указанным протоколом передачи и форматом сообщений образует связывание (binding), ассоциация связывания с конкретным сетевым адресом образует порт, а множество портов образует службу. Отсюда для описания службы в WSDL используются следующие сущности:

Тип (type)

Контейнер для описания типов данных с помощью какого-либо языка (например, XSD).

Сообщение (message)

Абстрактное типизированное определение данных для обмена.

Операция (operation)

Абстрактное описание поддерживаемого службой действия или функции.

Тип порта (port type)

Абстрактный набор операций, поддерживаемых одной или несколькими конечными точками.

Связывание (binding)

Спецификация транспортного протокола и формата данных для конкретного типа порта.

Порт (port)

Единичная конечная точка, определённая путём задания связывания и конкретного сетевого адреса.

Служба (service)

Множество связанных конечных точек.

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

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

В дополнение к описанию самого механизма определения служб эта спецификация даёт введение в расширения связывания (binding extension) для следующих протоколов и форматов сообщений:

• SOAP 1.1
• HTTP GET / POST
• MIME

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

Пример WSDL-документа

Ниже приведён пример WSDL для простой сетевой службы, которая предоставляет информацию о котировках на бирже. Она поддерживает одну операцию GetLastTradePrice, которая разворачивается в сети с использованием SOAP 1.1 поверх HTTP-транспорта. Запрос включает аббревиатуру ценной бумаги строкового типа, а ответ цену дробного типа.

1. <?xml version="1.0"?>
2. <definitions name="StockQuote"
3. targetNamespace="http://example.com/stockquote.wsdl"
4. xmlns:tns="http://example.com/stockquote.wsdl"
5. xmlns:xsd1="http://example.com/stockquote.xsd"
6. xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
7. xmlns="http://schemas.xmlsoap.org/wsdl/">
8. <types>
9. <schema targetNamespace="http://example.com/stockquote.xsd"
10. xmlns="http://www.w3.org/2000/10/XMLSchema">
11. <element name="TradePriceRequest">
12. <complexType>
13. <all>
14. <element name="tickerSymbol" type="string"/>
15. </all>
16. </complexType>
17. </element>
18. <element name="TradePrice">
19. <complexType>
20. <all>
21. <element name="price" type="float"/>
22. </all>
23. </complexType>
24. </element>
25. </schema>
26. </types>
28. <message name="GetLastTradePriceInput">
29. <part name="body" element="xsd1:TradePriceRequest"/>
30. </message>
32. <message name="GetLastTradePriceOutput">
33. <part name="body" element="xsd1:TradePrice"/>
34. </message>
36. <portType name="StockQuotePortType">
37. <operation name="GetLastTradePrice">
38. <input message="tns:GetLastTradePriceInput"/>
39. <output message="tns:GetLastTradePriceOutput"/>
40. </operation>
41. </portType>
43. <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
44. <soap:binding style="document"
45. transport="http://schemas.xmlsoap.org/soap/http"/>
46. <operation name="GetLastTradePrice">
47. <soap:operation soapAction="http://example.com/GetLastTradePrice"/>
48. <input>
49. <soap:body use="literal"/>
50. </input>
51. <output>
52. <soap:body use="literal"/>
53. </output>
54. </operation>
55. </binding>
57. <service name="StockQuoteService">
58. <documentation>My first service</documentation>
59. <port name="StockQuotePort" binding="tns:StockQuoteBinding">
60. <soap:address location="http://example.com/stockquote"/>
61. </port>
62. </service>
63. </definitions>

Соглашение об обозначениях

В этом документе используются следующие пространства имен с префиксами:

Префикс	URI пространства имен	Определение
wsdl	http://schemas.xmlsoap.org/wsdl/	Пространство имен фреймворка WSDL
soap	http://schemas.xmlsoap.org/wsdl/soap/	WSDL-пространство имен для SOAP binding
http	http://schemas.xmlsoap.org/wsdl/http/	WSDL-пространство имен для HTTP GET и POST связывания
mime	http://schemas.xmlsoap.org/wsdl/mime/	WSDL-пространство имен для MIME связывания
soapenc	http://schemas.xmlsoap.org/soap/encoding/	Пространство имен для атрибутики, относящейся к кодированию (сериализации) SOAP-сообщений, определено в SOAP 1.1
soapenv	http://schemas.xmlsoap.org/soap/envelope/	Пространство имен SOAP-конверта (envelope), определено в SOAP 1.1
xsd	http://www.w3.org/2000/10/XMLSchema	Пространство имен XML схемы, определено в спецификации XSD
xsi	http://www.w3.org/2000/10/XMLSchema-instance	Пространство имен, ориентированное на использование в любых XML-документах для указания XSD-специфичных атрибутов, но не относящихся к непосредственному определению типов; определено в спецификации XSD
tns	любой	По соглашению префикс tns (от «this namespace») используется для обращения к пространству имен текущего документа
остальные	любой	Все остальные префиксы пространств имен используются только для примеров, в частности URI, начинающийся с http://example.com, используется для представления некоторого независимого от приложения URI

В текущей спецификации используется свободный синтаксис для описания XML-грамматики WSDL:

• Вместо использования строгой грамматики типы XML-сущностей, используемые в WSDL, описываются с помощью фрагментов XML с примерами этих сущностей.
• Имена элементов, заканчивающиеся на ..., означают, что элементы или атрибуты, не имеющие значения в данном контексте, были опущены: <element...>.
• За XML-элементами и атрибутами следуют количественные квантификаторы: ? (0 или 1), * (0 или более), + (1 или более).
• Конструкции, упоминаемые впервые, либо представляющие основной интерес в контексте конкретного примера выделяются цветом фона.
• Комментарий <-- extensibility element --> указывает на то, что в этой точке возможно включение элементов расширения из другого пространства имен (соответствует ##other в XSD)
• Примеры, начинающиеся в <?xml, содержат достаточные данные и соответствуют данной спецификации, остальные примеры являются фрагментами документов.

Определение службы

Структура WSDL-документа

1. <wsdl:definitions name="nmtoken"? targetNamespace="uri"?>
2. <import namespace="uri" location="uri"/> *
4. <wsdl:documentation .... /> ?
6. <wsdl:types> ?
7. <wsdl:documentation .... /> ?
8. <xsd:schema .... /> *
9. <-- extensibility element --> *
10. </wsdl:types>
12. <wsdl:message name="nmtoken"> *
13. <wsdl:documentation .... /> ?
14. <part name="nmtoken" element="qname"? type="qname"?/> *
15. </wsdl:message>
17. <wsdl:portType name="nmtoken"> *
18. <wsdl:documentation .... /> ?
19. <wsdl:operation name="nmtoken"> *
20. <wsdl:documentation .... /> ?
21. <wsdl:input name="nmtoken"? message="qname"> ?
22. <wsdl:documentation .... /> ?
23. </wsdl:input>
24. <wsdl:output name="nmtoken"? message="qname"> ?
25. <wsdl:documentation .... /> ?
26. </wsdl:output>
27. <wsdl:fault name="nmtoken" message="qname"> *
28. <wsdl:documentation .... /> ?
29. </wsdl:fault>
30. </wsdl:operation>
31. </wsdl:portType>
33. <wsdl:binding name="nmtoken" type="qname"> *
34. <wsdl:documentation .... /> ?
35. <-- extensibility element --> *
36. <wsdl:operation name="nmtoken"> *
37. <wsdl:documentation .... /> ?
38. <-- extensibility element --> *
39. <wsdl:input> ?
40. <wsdl:documentation .... /> ?
41. <-- extensibility element --> *
42. </wsdl:input>
43. <wsdl:output> ?
44. <wsdl:documentation .... /> ?
45. <-- extensibility element --> *
46. </wsdl:output>
47. <wsdl:fault name="nmtoken"> *
48. <wsdl:documentation .... /> ?
49. <-- extensibility element --> *
50. </wsdl:fault>
51. </wsdl:operation>
52. </wsdl:binding>
54. <wsdl:service name="nmtoken"> *
55. <wsdl:documentation .... /> ?
56. <wsdl:port name="nmtoken" binding="qname"> *
57. <wsdl:documentation .... /> ?
58. <-- extensibility element --> *
59. </wsdl:port>
60. <-- extensibility element --> *
61. </wsdl:service>
63. <-- extensibility element --> *
64. </wsdl:definitions>

Для определения службы используются шесть основных XML-элементов:

• types служит для определения базовых типов данных, которые далее используются для определения сообщений.
• message — для определения абстрактных сообщений, каждое из которых состоит из логических частей, определяемых с использованием какой-либо системы типизации.
• portType — набор абстрактных операций, для каждой из которых определены типы входящих и исходящих сообщений.
• binding — устанавливает транспортный протокол и формат данных для операций и сообщений конкретного portType.
• port — задает адрес для конкретного связывания, тем самым определяет единичную конечную точку.
• service используется для группировки логически связанных портов, образующих службу.

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

Именование и включение документов

Для справочных целей WSDL-документу может быть присвоено опциональное имя, оно задается в атрибуте name типа NCNAME. Также для документа может быть задан опциональный атрибут targetNamespace типа URI, который должен содержать абсолютный URI целевого пространства имён.

WSDL позволяет ассоциировать пространство имён (namespace) с адресом размещения документа (location) с помощью конструкции импорта:

1. <definitions .... >
2. <import namespace="uri" location="uri"/> *
3. </definitions>

Адресация определений из подключенного документа выполняются по QName. Можно обращаться к следующим определениям импортированного документа:

• Определения, введённые WSDL: service, port, binding, portType, message
• Прочие определения, добавленные посредством использования механизма расширения

Области имён определений разных видов не пересекаются — так, например, допустимо существования порта и сообщения с одинаковыми именами, но имена однотипных определений должны быть уникальны в рамках WSDL-документа.

Разрешение QName в WSDL выполняется аналогично их разрешению, описанному в спецификации XML Schema.

Стиль составления документа

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

Доработаем определение службы из первого примера — разнесём его по трём документам: определение базовых типов данных, абстрактное определение службы и связывание абстрактного определения со специфичными параметрами формата сообщений и транспорта.

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

1. <?xml version="1.0"?>
2. <schema targetNamespace="http://example.com/stockquote/schemas"
3. xmlns="http://www.w3.org/2000/10/XMLSchema">
5. <element name="TradePriceRequest">
6. <complexType>
7. <all>
8. <element name="tickerSymbol" type="string"/>
9. </all>
10. </complexType>
11. </element>
12. <element name="TradePrice">
13. <complexType>
14. <all>
15. <element name="price" type="float"/>
16. </all>
17. </complexType>
18. </element>
19. </schema>

1. <?xml version="1.0"?>
2. <definitions name="StockQuote"
3. targetNamespace="http://example.com/stockquote/definitions"
4. xmlns:tns="http://example.com/stockquote/definitions"
5. xmlns:xsd1="http://example.com/stockquote/schemas"
6. xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
7. xmlns="http://schemas.xmlsoap.org/wsdl/">
9. <import namespace="http://example.com/stockquote/schemas"
10. location="http://example.com/stockquote/stockquote.xsd"/>
12. <message name="GetLastTradePriceInput">
13. <part name="body" element="xsd1:TradePriceRequest"/>
14. </message>
16. <message name="GetLastTradePriceOutput">
17. <part name="body" element="xsd1:TradePrice"/>
18. </message>
20. <portType name="StockQuotePortType">
21. <operation name="GetLastTradePrice">
22. <input message="tns:GetLastTradePriceInput"/>
23. <output message="tns:GetLastTradePriceOutput"/>
24. </operation>
25. </portType>
26. </definitions>

1. <?xml version="1.0"?>
2. <definitions name="StockQuote"
3. targetNamespace="http://example.com/stockquote/service"
4. xmlns:tns="http://example.com/stockquote/service"
5. xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
6. xmlns:defs="http://example.com/stockquote/definitions"
7. xmlns="http://schemas.xmlsoap.org/wsdl/">
9. <import namespace="http://example.com/stockquote/definitions"
10. location="http://example.com/stockquote/stockquote.wsdl"/>
12. <binding name="StockQuoteSoapBinding" type="defs:StockQuotePortType">
13. <soap:binding style="document"
14. transport="http://schemas.xmlsoap.org/soap/http"/>
15. <operation name="GetLastTradePrice">
16. <soap:operation soapAction="http://example.com/GetLastTradePrice"/>
17. <input>
18. <soap:body use="literal"/>
19. </input>
20. <output>
21. <soap:body use="literal"/>
22. </output>
23. </operation>
24. </binding>
26. <service name="StockQuoteService">
27. <documentation>My first service</documentation>
28. <port name="StockQuotePort" binding="tns:StockQuoteBinding">
29. <soap:address location="http://example.com/stockquote"/>
30. </port>
31. </service>
32. </definitions>

Расширение языка и связывание

Термин «связывание» в WSDL означает ассоциацаю параметров транспорта и формата данных с абстрактными определениями — сообщениями, операциями, типами портов. Под определёнными спецификацией стандартными элементами разрешается размещать элементы расширения, представляющие специфичные технологии. Как правило, эти точки расширения используются для задания параметров транспортного протокола и формата сообщений, однако их область применения этим не ограничивается. Пространство имён элементов расширения должно быть отличным от пространства имён WSDL.

Обычно элементы расширения используются для задания параметров связывания, специфичных для применяемой технологии передачи. Чтобы различать ситуации, когда учёт этих параметров является обязательным для обмена сообщениями, элемент расширения может содержать атрибут wsdl:required логического типа. Он определён в пространстве имён WSDL и по умолчанию равен false.

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

Документирование

Для создания пользовательской документации WSDL позволяет использовать элемент wsdl:document, содержащий произвольный текст и XML-элементы («mixed content» в терминах XSD). Он может лежать под любым элементом из WSDL.

Тип

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

1. <definitions .... >
2. <types>
3. <xsd:schema .... /> *
4. </types>
5. </definitions>

Система типизации XSD может быть использована для определения типов данных в сообщениях независимо от того, будут ли сообщения передаваться в формате XML, или в каком-либо специфическом формате — в любом случае XSD-схема может быть использована для проверки структуры сообщений. Возможны случаи, когда для одного абстрактного сообщения имеются различные связывания, либо одно связывание, но не имеющее своей распространённой системы типизации. В этих случаях рекомендуется придерживаться следующих правил при описании абстрактных типов данных с помощью XSD:

• Используйте элементную форму (не атрибутную)
• Не используйте служебные атрибуты или элементы, специфичные для конкретного формата передачи, непосредственно не относящиеся к определению содержимого сообщения. Например, soap:root, soap:encodingStyle, xmi:id, xmi:name.
• Типы массивов должны наследоваться от типа Array, определённого в схеме SOAP v1.1 encoding http://schemas.xmlsoap.org/soap/encoding/, независимо от того, будет ли сообщение передаваться в виде, описанном в разделе 5 спецификации SOAP v1.1. Используйте имя типа ArrayOfXXX, где XXX — тип элементов массива. Тип элементов и размерность массива задаются через значение по умолчанию для атрибута soapenc:arrayType. На момент написания этого документа спецификация XSD не поддерживала механизма установки значения по умолчанию для атрибута, содержащего QName. Для обхода этого ограничения в WSDL был введён атрибут wsdl:arrayType, расширяющий XSD-схему, который задаёт значение по умолчанию. В случае внесения исправлений в XSD для поддержки такой возможности, стандартный механизм из XSD следует использовать вместо атрибута wsdl:arrayType из WSDL.
• Используйте xsd:anyType как тип поля / параметра, который может иметь любой тип.

Необоснованно ожидать, что в настоящем и будущем для определения типов данных будет использоваться только одна грамматика. Поэтому WSDL позволяет подключать другие системы типизации с помощью элементов расширения. Элемент расширения может быть добавлен под элемент types — он будет служить для идентификации системы типизации и для организации контейнера для определений типов. Роль такого элемента аналогична элементу schema языка XML Schema.

1. <definitions ... >
2. <types>
3. <-- type-system extensibility element --> *
4. </types>
5. </definitions>

Сообщение

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

• element — ссылается на XSD-элемент по QName.
• type — ссылается на XSD-определение simpleType или complexType по QName.

Другие атрибуты типизации сообщений могут быть определены в пространстве имён, отличном от WSDL. Элементы расширения связывания также могут использовать атрибуты типизации.

1. <definitions ... >
2. <message name="nmtoken"> *
3. <part name="nmtoken" element="qname"? type="qname"?/> *
4. </message>
5. </definitions>

Атрибут name элемента message должен содержать уникальное имя сообщение в рамках текущего WSDL-документа. Атрибут name элемента part — уникальное имя части в рамках сообщения.

Часть сообщения

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

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

1. <definitions .... >
2. <types>
3. <schema .... >
4. <element name="PO" type="tns:POType"/>
5. <complexType name="POType">
6. <all>
7. <element name="id" type="string"/>
8. <element name="name" type="string"/>
9. <element name="items">
10. <complexType>
11. <all>
12. <element name="item" type="tns:Item"
13. minOccurs="0"
14. maxOccurs="unbounded"/>
15. </all>
16. </complexType>
17. </element>
18. </all>
19. </complexType>
21. <complexType name="Item">
22. <all>
23. <element name="quantity" type="int"/>
24. <element name="product" type="string"/>
25. </all>
26. </complexType>
28. <element name="Invoice" type="tns:InvoiceType"/>
29. <complexType name="InvoiceType">
30. <all>
31. <element name="id" type="string"/>
32. </all>
33. </complexType>
34. </schema>
35. </types>
37. <message name="PO">
38. <part name="po" element="tns:PO"/>
39. <part name="invoice" element="tns:Invoice"/>
40. </message>
41. </definitions>

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

1. <definitions .... >
2. <types>
3. <schema .... >
4. <!-- POType и InvoiceType - типы из прошлого примера -->
5. <complexType name="Composite">
6. <choice>
7. <element name="PO" type="tns:POType"
8. minOccurs="1" maxOccurs="1"/>
9. <element name="Invoice" type="tns:InvoiceType"
10. minOccurs="0" maxOccurs="unbounded"/>
11. </choice>
12. </complexType>
13. </schema>
14. </types>
16. <message name="PO">
17. <part name="composite" type="tns:Composite"/>
18. </message>
19. </definitions>

Абстрактные / конкретные сообщения

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

Тип порта

Тип порта — это именованный набор абстрактных операций, ссылающихся на задействованные в обмене абстрактные сообщения.

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

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

В WSDL имеется четыре примитива организации способа взаимодействия, которые может поддерживать конечная точка:

• Однонаправленный запрос (one-way) — конечная точка принимает сообщение.
• Запрос-ответ (request-response) — конечная точка принимает сообщение и отправляет связанное сообщение.
• Просьба-ответ (solicit-response) — конечная точка отправляет сообщение и получает связанное сообщение.
• Уведомление (notification) — конечная точка отправляет сообщение.

WSDL рассматривает эти примитивы как операции (operation). Конечно, операции типа запрос-ответ и просьба-ответ могут быть смоделированы с использованием двух однонаправленных сообщений, однако полезно иметь такие операции как примитивы, так как:

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

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

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

Однонаправленный запрос

Грамматика определения операции следующая:

1. <wsdl:portType .... >
2. <wsdl:operation name="nmtoken">
3. <wsdl:input name="nmtoken"? message="qname"/>
4. </wsdl:operation>
5. </wsdl:portType>

Элемент input задает абстрактное содержание сообщения-запроса.

Запрос-ответ

1. <wsdl:portType .... >
2. <wsdl:operation name="nmtoken" parameterOrder="nmtokens">
3. <wsdl:input name="nmtoken"? message="qname"/>
4. <wsdl:output name="nmtoken"? message="qname"/>
5. <wsdl:fault name="nmtoken" message="qname"/> *
6. </wsdl:operation>
7. </wsdl:portType>

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

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

Просьба-ответ

1. <wsdl:portType .... >
2. <wsdl:operation name="nmtoken" parameterOrder="nmtokens">
3. <wsdl:output name="nmtoken"? message="qname"/>
4. <wsdl:input name="nmtoken"? message="qname"/>
5. <wsdl:fault name="nmtoken" message="qname"/> *
6. </wsdl:operation>
7. </wsdl:portType>

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

Уведомление

1. <wsdl:portType .... >
2. <wsdl:operation name="nmtoken">
3. <wsdl:output name="nmtoken"? message="qname"/>
4. </wsdl:operation>
5. </wsdl:portType>

Элемент output задает абстрактное содержание сообщения-уведомления.

Имена элементов в рамках операции

Атрибут name элементов input и output содержит уникальное имя среди всех таких элементов в рамках типа порта.

Чтобы избежать необходимости именования всех элементов input и output WSDL предоставляет им имена по умолчанию на основе имени операции. Если не указано имя сообщения однонаправленной операции, оно будет равно по умолчанию имени операции. Если не указано имя сообщения операции запрос-ответ, либо просьба-ответ, оно будет равно имени операции с суффиксом Request, Solicit или Response соответственно.

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

Порядок параметров в рамках операции

На уровне операции не настраивается, будет ли она использоваться вместе с RPC-связыванием. Однако при использовании операции с RPC-связыванием полезно зафиксировать сигнатуру оригинальной функции. Для этой цели операции запрос-ответ и просьба-ответ могут содержать список имён параметров в атрибуте parameterOrder типа nmtokens. Значение атрибута — список имён частей сообщения, разделённых одиночными пробелами. Значение должно соответствовать следующим правилам:

• Порядок имён частей сообщения должен отражать порядок параметров RPC-сигнатуры.
• В списке нет отдельной части для указания возвращаемого значения.
• Если имя части есть во входящем и исходящем сообщениях, это in/out-параметр удалённой процедуры.
• Если имя части есть только во входящем сообщении, это in-параметр.
• Если только в исходящем — out-параметр.

Обратите внимание, что эта информация служит только как «подсказка», поэтому может быть безопасно проигнорирована в случае незаинтересованности в RPC-сигнатуре. Кроме того она является необязательной даже в случае использования операции с RPC-связыванием.

Связывание

Связывание определяет формат сообщений и детали протокола для операций и сообщений конкретного типа порта. Одному типу порта могут соответствовать несколько разных связываний. Грамматика определения связывания следующая:

1. <wsdl:definitions .... >
2. <wsdl:binding name="nmtoken" type="qname"> *
3. <-- extensibility element (1) --> *
4. <wsdl:operation name="nmtoken"> *
5. <-- extensibility element (2) --> *
6. <wsdl:input name="nmtoken"?> ?
7. <-- extensibility element (3) -->
8. </wsdl:input>
9. <wsdl:output name="nmtoken"?> ?
10. <-- extensibility element (4) --> *
11. </wsdl:output>
12. <wsdl:fault name="nmtoken"> *
13. <-- extensibility element (5) --> *
14. </wsdl:fault>
15. </wsdl:operation>
16. </wsdl:binding>
17. </wsdl:definitions>

Атрибут name задаёт имя связывания, уникальное среди всех связываний WSDL-документа. Связывание ссылается на тип порта с помощью атрибута type типа QName (см. Раздел 2.1.1).

Элементы расширения связывания используются для указания конкретной грамматики для входящих (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 содержит ссылку на связывание (см. Раздел 2.1.1).

Элементы расширения (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. Несклоняемыми написанными латиницей терминами оперировать крайне неудобно, к тому же они однозначно переводятся. Поэтому исходное имя даётся только при введении нового термина, а далее по тексту используется русский перевод.