В этой статье я расскажу о том, что такое WSDL-файл, зачем он нужен и как с ним работать.

Карта статьи

Что такое WSDL

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

Путь к wsdl-файлу обычно имеет вид http://host/services/wsdl/gbdar-v2-2.wsdl

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

SoapUi

Одним из таких инструментов является soapUi (). Установив дистрибутив, предназначенный для вашей платформы, вы сможете создать новый проект командой File/New SoapUi project. В диалоге создания нового проекта оставляем включенной галочку Create sample requests

Выполнение запросов

В новом проекте будут автоматически созданы шаблоны запросов для сервиса, описание которого содержится в wsdl-файле. Слева в дереве Вы увидите перечень функций, содержащихся в WSDL-файле. Я раскрою функцию Replication. Внутри нее присутствует запрос Request1, дважды щелкнув по которому, мы увидим диалог с шаблоном запроса, вместо параметров по умолчанию будут проставлены знаки вопроса. Чтобы функция корректно выполнилась, необходимо заполнить все параметры, не помеченные тегом Optional, после чего нажать зеленый треугольник в верхнем левом углу диалога.

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

SoapUi предоставляет возможность просмотра параметров WSDL-файла, для этого необходимо дважды щелкнуть по наименованию интерфейса (помечен зеленой иконкой в дереве WSDL-файла, у меня — gdbar-v2-2SOAP). В диалоговом окне вы можете найти:

  • Вкладка OverView — описание общих параметров WSDL, список функций и связанных с ними действий сервера
  • Вкладка Service Endpoints — путь к серверу и прочие параметры
  • WSDL Content — дерево навигации по файлу
  • WS-I Compliance — здесь можно создать WS-I отчет по интерфейсу

Генерация документации

SoapUi позволяет нам генерировать документацию по функциям WSDL. Для этого щелкните правой кнопкой по интерфейсу и вызовите команду Generate Documentation. В результате получим подробный мануал в html-формате.

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

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

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

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

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

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

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

Рассмотрев практическое применение веб-сервисов, обратимся к стандартам, лежащим в основе этих сервисов.

стандарты

Как мы уже знаем, в основе веб-сервисов лежат Internet-стандарты. Эти стандарты определяют протоколы, а не способы их реализации. Такое утверждение является залогом успеха Internet - ни одна компания не может влиять на Internet-стандарты и задавать собственные правила игры. Например, стандарты веб-сервисов разрабатываются совместно такими компаниями, как IBM, Microsoft, Ariba и некоторыми другими, и обсуждаются комитетом World Wide Web Consortium (W3C).

Веб-сервисы базируются на трех основных веб-стандартах:

SOAP (Simple Object Access Protocol) - протокол для посылки сообщений по протоколу HTTP и другим Internet-протоколам;

WSDL (Web Services Description Language) - язык для описания программных интерфейсов веб-сервисов;

UDDI (Universal Description, Discovery and Integration) - стандарт для индексации веб-сервисов.

Серверы приложений являются хранилищами веб-сервисов и делают их доступными через протоколы HTTP GET, HTTP POST и HTTP SOAP.

Существующие веб-сервисы описываются в WSDL-документах, которые располагаются либо на сервере приложений, либо в специальных XML-хранилищах. WSDL-документ может ссылаться на другие WSDL-документы и документы XSD (XML Schema), в которых описаны типы данных, используемые веб-сервисами. XML-хранилища используются для управления WSDL-документами. Внутри WSDL-документа находится адрес (URL) веб-сервиса. Веб-сервисы описаны и проиндексированы в бизнес-реестре, содержащем адреса (URL) WSDL-документов.

В следующих разделах мы рассмотрим три основных веб-стандарта, на которых базируются веб-сервисы - SOAP, WSDL и UDDI - более подробно.

SOAP - Simple Object Access Protocol

SOAP - это стандарт для отсылки и получения сообщений по Internet. Изначально этот протокол был предложен фирмой Microsoft в качестве средства для удаленного вызова процедур (RPC, Remote Procedure Call) по протоколу HTTP, а спецификация SOAP 1.0 (Userland, Microsoft, Developmentor) была тесно связана с Component Object Model. Фирма IBM и ряд других компаний, в том числе Lotus, внесли определенный вклад в развитие этого протокола, и его спецификация была направлена на рассмотрение комитетом W3C.

Спецификация SOAP определяет XML-«конверт» для передачи сообщений, метод для кодирования программных структур данных в формате XML, а также средства связи по протоколу HTTP.

SOAP-сообщения бывают двух типов: запрос (Request) и ответ (Response). Запрос вызывает метод удаленного объекта, ответ возвращает результат выполнения данного метода. Приведем пример запроса в формате SOAP:







HST

А вот ответ:



xmlns:SOAP-ENV="http:///envelope"
SOAP-ENV:encodingStyle="http:///encoding//"


48.6

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

WSDL - Web Services Description Language

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

Для описания этой информации было предложено несколько языков. Одним из них был язык Service Description Language (SDL), разработанный Microsoft и входивший в первую версию Microsoft SOAP Toolkit. Компания IBM переработала спецификацию и, использовав спецификацию Network Accessible Service Specification Language (NASSL), выпустила NASSL Toolkit как часть SOAP4J. Идеи, реализованные в NASSL, повлияли на спецификацию языка SOAP Contract Language (SCL), предложенную Microsoft. В настоящее время обе спецификации (NASSL и SDL/SCL), а также предложения других фирм учтены в спецификации языка WSDL. Для описания бизнес-логики IBM и Microsoft работают над спецификацией языка Web Services Flow Language (WSFL). Вот пример скелета описания сервисов на языке WSDL:


xmlns:soap="http://(soaporg)/wsdl/soap"
xmlns="http://(soaporg)/wsdl/">

...

...
...


...
...


...

Как мы видим, описание сервисов представляет собой XML-документ, состоящий из нескольких элементов, в том числе из описания пространства имен (namespace), описания типов и элементов, сообщений, порта, а также возможных операций - запросов и ответов.

UDDI - Universal Description, Discovery and Integration

Задача UDDI - предоставить механизм для обнаружения веб-сервисов. UDDI задает бизнес-реестр, в котором провайдеры веб-сервисов могут регистрировать сервисы, а разработчики - искать необходимые им сервисы. Компании IBM, Microsoft и Ariba создали собственные UDDI-реестры (в скором времени эти реестры будут объединены в веб-реестр), в одном из которых разработчики могут зарегистрировать свои веб-сервисы, после чего данные будут автоматически реплицированы в другие реестры.

UDDI базируется на элементах четырех типов: Business Entity, Business Service, Binding Template и Technology Model.

Элемент Business Entity описывает индустрию, предоставляющую данный веб-сервис. Этот элемент может включать описания категорий для данной индустрии, облегчающие более детальный поиск сервисов.

Business Service - это класс сервисов в рамках определенной отрасли промышленности или услуг. Каждая отрасль принадлежит определенному элементу Business Entity.

Вместе Binding Template и Technology Model определяют веб-сервис. Technology Model содержит абстрактное описание, а Binding Template - конкретную спецификацию сервиса. Каждый элемент Binding Template принадлежит определенному элементу Business Service, но несколько элементов Binding Template могут ссылаться на один элемент Technology Model.

Бизнес-реестр UDDI сам является SOAP веб-сервисом. Он поддерживает операции создания, модификации, удаления и поиска элементов всех четырех рассмотренных выше типов.

Реферат слушателя ИКСИ, научный руководитель – Сергей Кунегин

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

WSDL (Web Services Description Language ) версии 1.1 был опубликован 15 марта 2001 года. WSDL - это формат, базирующийся на XML и использующийся для описания сетевых cервисов, при помощи сообщений, содержащих информация о том как осуществлять доступ к конкретному веб-сервису. WSDL расширяем, что позволяет описывать услуги (сервисы) и их сообщения независимо от того, какие форматы сообщений или сетевые протоколы используются для транспорта, однако, чаще всего используется WSDL 1.1 вместе с SOAP 1.1, HTTP GET/POST и MIME. Поскольку WSDL был разработан совместно с SOAP, в его разработке участвовали все те же фирмы Microsoft, Ariba и IBM. Если рассматривать документ WSDL интуитивно, то можно сказать, что он позволяет ответить на 4 вопроса :

1) что вы делаете? Ответ на этот вопрос дается в форме пригодной как для восприятия человеком так и форме воспринимаемой машиной. Ответ для чел-ка в тегах: <name />, <documentation />, для машины - <message />, <pointType >

2) на каком языке вы разговариваете? (какие типы вы используете?)Ответ в теге: <types />

3) как я буду с вами общаться? (как клиент будет обращаться к веб-службе?):HTTP или SMTP. Ответ находится в <binding />

4) где мне вас найти? (где я могу найти эту веб-службу или какой у нее URL?). Ответ находится: <service />

Структура:

Каждый документ WSDL можно разбить на три логические части:

1. определение типов данных - определение вида отправляемых и получаемых сервисом XML сообщений

2. абстрактные операции - список операций, которые могут быть выполнены с сообщениями

3. связывание сервисов - способ, которым сообщение будет доставлено

Документы WSDL можно создавать вручную, однако строгая формализация языка WSDL позволяет автоматизировать процесс написания WSDL -документов. Многие интсрументальные средства создания Web-служб содержат утилиты, которые автоматичеки создают WSDL -файлы, описывающие готовые Web-службы. Например средство создания Web-служб Apache Axis содержит в своем составе класс Java2WSDL , создающий WSDL -файл по классу или интерфейсу Java, описывающему Web-службу. Пакет IBM WSTK, в состав которого входит Axis , содержит утилиту java2wsdl , создающую и запускающую объект из этого класса. Она работает из командной строки.

Элементы WSDL-документа

Опишем наиболее часто употребляемые теги WSDL:

Тег – это корневой тег всех WSDL-документов. Он определяет несколько пространств имен:

1)target Name space – это пространство имен нашей веб-службы

2)xmlns – стандартное пространство имен документа WSDL

3)xmlns: SOAP_ENC – пространство имен используемое для описания кодировки SOAP


4)xmlns: impl и intf – пространство имен реализации и определения нашей веб-службы

· Документ для определения веб-службы

· Документ для реализации веб-службы

Для простоты, как правило, используют 1 файл, который содержит всю информацию

Элемент - предоставляет информацию о данных, которые передаются от одной конечной точки к другой.

Для описания вызова RPC необходимо создать входной сообщение и выходное сообщение.

В рамках этого элемента можно указать параметры метода с помощью элемента

Элемент описывает и определяет операции или методы поддерживаемые веб-службой

Операции могут иметь входные сообщения, а также сообщения об ошибках.

Элемент - описывает, как операции определенные в типе порта будут передаваться по сети. Т.к. элемент использует тип порта, то он должен указывать тип определенный где-то ранее в документе.

Элемент - указывает где найти веб службу

Элемент import . Очень часто элемент service выделяется в свой wsdl документ из соображений практичности.

Для того, чтобы позволить собрать из нескольких wsdl документов один используется элемент import. Он позволяет включать один wsdl документ в другой.

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

WSDL поддерживает 4 режима операций:

· операции типа one-way или односторонние операции. Сообщение посылается конечной точке службы. В этом случае операция описывается только одним входным сообщением.

· Request-Response – режим запрос-ответ. Этот режим операции является наиболее общим. В этом режиме описание операции содержит входное и выходное сообщение и необязательное сообщение об ошибке.

· Операция типа требование-ответ. В этом режиме конечной точкой является клиент другой конечной точки. Формат операции похож на режим запрос-ответ, но выходные данные перечисляются перед входными данными.

· Операция уведомление. Этот режим – еще одна версия примитива односторонней передачи, в которой конечная точка посылает сообщение а не получает его. Операция содержит только выходное сообщение.

Язык описания Web-сервисов (WSDL)

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

Имя Web-метода XML;

Число, тип и порядок следования параметров (если таковые имеются);

Тип возвращаемого значения (если таковое предусмотрено);

Условия вызова HTTP GET, HTTP POST и SOAP.

В большинстве случаев WSDL-документы генерируются автоматически соответствующим Web-сервером. Напомним, что при добавлении суффикса?wsdl к адресу URL, указывающему на файл *.asmx, Web-сервер генерирует WSDL-документ для указанного Web-сервиса XML.

http://locаlhost/SomeWS/theWS.asmx?wsdl

Но если IIS автоматически генерирует WSDL-документ для данного Web-сервиса XML, зачем тогда нужно глубокое понимание синтаксиса генерируемых WSDL-данных? Ответ обычно зависит от того, как ваш сервис будет использоваться внешними приложениями. В случае Web-сервисов XML, предназначенных для "внутреннего" использования, сгенерированного Web-сервером WSDL-кода будет, как правило, достаточно.

Между тем. вполне возможно начать разработку Web-сервиса XML с создания WSDL-документа вручную (об этом уже говорилось выше). Главная идея начала разработки с создания WSDL-документа связана с вопросами совместимости. Вспомните о том, что до появления спецификации WSI различные инструменты построения Web-сервисов нередко генерировали несовместимые WSDL-описания. Если начинать разработку с WSDL-кода, вы можете построить документ так, как требуется.

Как вы можете догадаться, для начала разработки Web-сервиса XML с создания WSDL-документа требуется очень хорошее знание грамматики WSDL, обсуждение которой в контексте этой главы не предусмотрено. Но мы рассмотрим базовую структуру WSDL-документа. Разобравшись в основах, вы сможете оценить пользу утилиты командной строки wsdl.exe.

Замечание. Самую свежую информацию о языке WSDL можно найти на страницах http://www.w3.org/tr/wsdl .

Определение WSDL-документа

Действительный документ WSDL открывается и закрывается корневым элементом ‹definitions›. В открывающем дескрипторе обычно определяются различные атрибуты xmlns. Они задают пространства имен XML, определяющие различные подчиненные элементы. Как минимум, элемент ‹definitions› должен указать пространство имен, где определены сами элементы WSDL (http://schemas.xmlsoap.org/wsdl). Для того чтобы быть полезным, открывающий дескриптор ‹definitions› должен, кроме того, указать пространства имен XML, определяющие простые типы данных WSDL, типы XML-схемы, элементы SOAP, а также целевое пространство имен. Например, вот как выглядит раздел ‹definitions› для нашего Web-сервиса калькулятора.

‹wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns-mime="http://schemas.xmlsoap.org/wsdl/mime/"

xmlns:tns="http://www.IntertechTraining.com/"

xmlns:s="http://www.w3.org/2001/XMLSchema"

xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"

xmlns:http="http://schemes.xmlsoap.оrg/wsdl/http/"

targetNamespace="http://www.IntertechTraining.com/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"›

‹/wsdl :definitions›

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

‹?xml version="1.0" encoding="utf-8"?›

‹wsdl:definitions …›

‹wsdl:types›

‹!-- Список типов, доступных для данного Web-сервиса - -›

‹wsdl:/types›

‹wsdl:message›

‹!-- Формат сообщений - -›

‹wsdl:/message›

‹wsdl:portType›

‹!-- Информация портов - -›

‹wsdl:/portType›

‹wsdl:binding›

‹!-- Информация связывания - -›

‹wsdl:/binding›

‹wsdl:service›

‹!-– Информация о самом Web-сервисе XML - -›

‹wsdl:/service›

‹wsdl:/definitions›

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

Элемент ‹types›

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

‹s:еlement name= "Subtract"›

‹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 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-метод, как односторонний, можно с помощью атрибута .

Элемент ‹portType›

Элемент ‹portType› определяет различные связи, которые могут возникать между клиентом и сервером, и каждая такая связь представляется вложенным элементом ‹operation›. Несложно догадаться, что самыми типичными операциями здесь должны быть SOAP, HTTP GET и HTTP POST. Однако есть и другие операции. Например, односторонняя операция позволяет клиенту отправить сообщение данному Web-серверу, но не получить ответ (это похоже на вызов метода без ожидания возвращаемого значения). Операция "требование-ответ" позволяет серверу отправить, запрос во время ответа клиента (что можно рассматривать, как дополнение операции "запрос-ответ").

Чтобы проиллюстрировать формат необязательного вложенного элемента ‹operation›, рассмотрим WSDL-определение для метода Subtract().

‹wsdl portType name="CalculatorWebServiceSoap "›

‹wsdl:operation name="Subtract "›

‹wsdl:input message="tns:SubtractSoapIn " /›

‹wsdl:output message="tns:SubtractSoapOut " /›

‹ /wsdl:operation›

‹wsdl:/portType›

Обратите внимание на то, как элементы ‹input› и ‹output› ссылаются на соответствующее имя сообщения, определенное в рамках элемента ‹message›. Если бы для метода Subtract() был разрешен HTTP-метод POST, вы бы увидели следующий дополнительный элемент ‹operation›.

‹wsdl:portType name="CalculatorWebServiceHttpPost"›

‹wsdl:input message="s0:SubtractHttpPostIn " /›

‹wsdl:output message= "s0:SubtractHttpPostOut " /›

‹ wsdl:/operation›

‹wsdl:/portType›

Наконец, учтите то, что если данный Web-метод описан с помощью свойства Description, элемент ‹operation› будет содержать вложенный элемент ‹documentation›.

Элемент ‹binding›

Этот элемент указывает точный формат обмена GET, POST и SOAP. Это самый "многословный" из всех элементов, содержащихся в контексте корневого элемента ‹definition›. Вот, например, определение элемента ‹binding› с описанием того, как вызывающая сторона может взаимодействовать с Web-методом MyMethod(). используя SOAP.

‹wsdl:binding name="СаlculatorWebServiceSoap12" type="tns:CalculatorWebServiceSoap "›

‹soap12:binding transport="http://schemas.xmlsoap.org/soap/http " /›

‹wsdl:operation name= "Subtract "›

‹soap12:operation soapAction="http://www.IntertechTraining.com/Subtract " style="document" /›

‹wsdl:input›

‹soap12:body use="literal " /›

‹/wsdl:input›

‹wsdl:output›

‹soap12:body use="literal " /›

‹/wsdl:output›

‹/wsdl:operation›

‹/wsdl:binding›

Элемент ‹service›

Наконец, у нас есть элемент ‹service›, который указывает характеристики самого Web-сервиса (например, его URL). Главной задачей этого элемента является описание множества портов, открытых данным Web-сервером. Для этого элемент ‹services› может использовать любое число вложенных элементов ‹port› (не путайте их с элементом ‹portType›). Вот как выглядит элемент ‹service› для CalculatorWebService.

‹wsdl:service name="CalculatorWebService "›

‹wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"›

Чудесный Web-сервис калькулятора

‹/wsdl:documentation›

‹wsdl:port name="CalculatorWebServiceSoap" binding="tns :CalculatorWebServiceSoap" ›

‹soap:address location="http://localhost:1109/CalculatorWebService/ Service.asmx" /›

‹/wsdl:port›

‹wsdl:port name="CalculatorWebServiceSoap12" binding= "tns :CalculatorWebServiceSoap12 "›

‹soap12:address location="http://localhost:1109/CalculatorWebService/Service.asmx" /›

‹/wsdl:port›

‹/wsdl:service›

Итак, как видите, WSDL-код, автоматически возвращаемый сервером ITS, не является сверхсложным, но, поскольку WSDL представляет собой грамматику на основе XML, этот код достаточно "многословен". Тем не менее, теперь вы должны лучше понимать роль WSDL, так что давайте рассмотрим немного подробнее протоколы связи Web-сервисов XML.

Замечание. Напомним, что пространство имен System.Web.Services.Description содержит множество типов, которые позволяют программно читать и обрабатывать "сырой" WSDL-код (можете проверить сами, если вас это интересует).