Элемент ‹types›

Сначала мы рассмотрим элемент ‹types›, который содержит описания всех типов данных, предлагаемых Web-сервисом. Вы, возможно, знаете, что язык XML сам определяет ряд "базовых" типов данных, и все они определены в рамках пространства имен XML http://www.w3.org/2001/XMLSchema (которое должно быть указано в контексте корневого элемента ‹definitions›). Возьмем, например, метод Subtract() нашего Web-сервиса калькулятора, имеющий два входных параметра целочисленного типа. В терминах WSDL тип System.Int32 среды CLR описывается в контексте элемента ‹complexType›.

‹s:еlement name= "Subtract"›

 <s:comlexType>

  ‹s:sequence›

   ‹s:element minOccurs="1" maxOccurs="1" name="x" type="s:int" /›

   ‹s:element minOccurs=''1" maxOccurs="1" name="y" type="s:int" /›

  ‹/s:sequence›

 ‹/s:complexType›

‹/s:element›

Целое число, возвращаемое методом Subtract(), также описывается в рамках элемента ‹types›.

‹s:element name= "SubtractResponse"›

 ‹s:complexType›

  ‹s:sequence›

   ‹s:element minOccurs="1" maxOccurs="1" name="SubtractResult" type="s:int"/›

  ‹/s:sequence›

 ‹/s:complexType›

‹/s:element›

Если вы имеете Web-метод, возвращающий или получающий пользовательские типы данных, они также появятся в контексте элемента ‹complexType›. Детали того, как с помощью Web-метода сделать доступными пользовательские типы данных .NET, мы рассмотрим позже. Для примера предположим, что вы определили Web-мeтод, возвращающий структуру с именем Point.

public struct Point {

 public int x;

 public int y;

 public string pointName;

}

WSDL-описание для этой "сложной структуры" будет выглядеть примерно так.

‹s:complexType name="Point"›

 ‹s:sequence›

  ‹s:element minOccurs="1" maxOccurs="1" name="x" type="s:int" /›

  ‹s:element minOccurs="1'' maxOccurs="1" name="y" type= "s:int" /›

  ‹s:element minOccurs="0" maxOccurs="1" name="рointName" type="s:string" /›

 ‹/s:sequence›

‹/s:complexType›

Элемент ‹message›

Элемент ‹message› используется для определения формата обмена запросами и ответами данного Web-метода. Поскольку один Web-сервис позволяет передачу множества сообщений между отправителем и получателем, одному WSDL-документу позволяется определять множество элементов ‹message›. Как правило, в этих определениях используются типы, указанные в рамках элемента ‹types›.

Независимо от количества элементов ‹message›, определенных в документе WSDL, они обычно "присутствуют" парами. Первое определение представляет входной формат сообщения, а второе – выходной формат того же сообщения. Например, метод Subtract() Web-сервиса CalculatorWebService определяет следующие элементы ‹message›.

‹wsdl:message name="SubtractSoapIn"›

 ‹wsdl:part name="parameters" element="tns:Subtract" /›

‹/wsdl:message›

‹wsdl: message name="SubtractSoapOut"›

 ‹wsdl:part name="parameters" element="tns:SubtractResponse" /›

‹/wsdl:message›

Здесь вы видите только связь SOAP соответствующего сервиса. Как говорилось в начале этой главы, Web-сервисы XML могут вызываться с помощью SOAP или HTTP-методов GET и POST. Но если вы разрешите связь HTTP POST (соответствующие объяснения будут предложены позже), генерируемый WSDL-код должен продемонстрировать следующие данные ‹message›.

‹wsdl: message name="SubtractHttpPostIn"›

 ‹part name="n1" type="s:string" /›

 ‹part name="n2" type="s:string" /›

‹wsdl:/message›

‹wsdl:message name="SubtractHttpPostOut"›

 ‹part name="Body" element="s0:int" /›

‹wsdl:/message›

Элементы ‹message› сами по себе не слишком полезны. Однако на эти определения сообщений ссылаются другие части WSDL-документа.

Замечание. Не все Web-методы требуют и запроса, и ответа. Если Web-метод является "односторонним", для него необходим только элемент ‹message› запроса. Обозначить Web-метод, как односторонний, можно с помощью атрибута [SoapDocumentMethod].