Шрифт:
• транспортный протокол (позволяющий обмениваться информацией между клиентом и Web-сервисом XML).
Мы рассмотрим подробно каждый элемент инфраструктуры в процессе изучения материала этой главы. Но для начала обсуждения ниже предлагается краткий обзор указанных технологий поддержки.
Служба поиска Web-сервиса XML
Перед тем как клиент сможет использовать функциональные возможности Web-сервиса, ему нужно узнать о существовании и месте размещения этого сервиса. Если вы являетесь создателем и клиента, и Web-сервиса XML, фаза поиска оказывается очень простой, поскольку вы сами являетесь источником нужной информации. Но что делать, если вы хотите сделать возможности вашего Web-сервиса открытыми для всех?
Для этого вы можете зарегистрировать свой Web-сервис XML на сервере UDDI (Universal Description, Discovery, and Integration – универсальное описание, поиск и взаимодействие). Клиенты могут послать запрос к каталогу UDDI, чтобы получить список всех Web-сервисов, соответствующих заданным критериям поиска (например, "найти все Web-сервисы, связанные с получением метеорологических данных в реальном времени"). Идентифицировав подходящий Web-сервер в списке, возвращенном в результате UDDI-запроса, вы можете выяснить все возможности этого сервера. Если хотите, можете назвать UDDI "белой книгой" Web-сервисов XML.
В дополнение к UDDI-поиску, Web-сервис XML, построенный в рамках .NET, можно найти с помощью DISCO – этот несколько искусственный акроним расшифровывается, как Discovery of Web Services (поиск Web-сервисов). Используя файл статического поиска (*.disco) или динамического поиска (*.vsdisco), вы можете "афишировать" набор Web-сервисов XML, размещенных по конкретному адресу URL. Потенциальные клиенты Web-сервисов могут перейти к файлу *.disco Web-сервера, чтобы проверить связи всех опубликованных Web-сервисов XML.
Следует учитывать то, что по умолчанию динамический поиск отключен, поскольку имеется потенциальный риск нарушения защиты, если позволить IIS открыть весь набор Web-сервисов XML всем интересующимся объектам. В связи с этим службы DISCO здесь обсуждаться не будут.
Замечание. Если вы захотите активизировать поддержку динамического поиска для Web-сервера, прочитайте статью Q307303 базы знаний Microsoft на страницах http://support.microsoft.com
Служба описания Web-сервиса XML
Итак, клиент знает, где размещен Web-сервис XML. Теперь клиент должен узнать функциональные возможности этого сервиса. Например, клиент должен иметь возможность узнать, что сервис имеет метод GetWeatherReport, предполагающий использование некоторого набора параметров и возвращающий некоторое значение, чтобы клиент мог вызвать этот метод. Вы, возможно, догадываетесь, что это предполагает использование некоторого метаязыка, нейтрального в отношении всех платформ, языков и операционных систем. XML-метаданные, используемые для описания Web-сервисов XML, создаются на языке WSDL (Web Services Description Language – язык описания Web-сервисов).
Во многих случаях WSDL-описание Web-сервиса XML автоматически генерируется сервером IIS Microsoft, если поступающий запрос имеет суффикс ?wsdl. Вы увидите, что первичными потребителями WSDL-контрактов являются инструменты генерирования агентов. Например, утилита командной строки wsdl.exe (ее обсуждение будет предложено позже) генерирует клиентский C#-класс агента на основе имеющегося WSDL-документа.
В более сложных случаях (обычно с целью гарантии совместимости) при построении Web-сервисов многие разработчики используют подход, в рамках которого сначала вручную определяется WSDL-документ, поскольку упомянутая выше утилита командной строки wsdl.exe может генерировать описания интерфейса для Web-сервиса XML и на основе WSDL-определения.
Транспортный протокол
После создания типа агента для взаимодействия с Web-сервисом XML клиент может вызывать доступные методы. Как уже подчеркивалось, соответствующие данные передаются с помощью сетевого протокола HTTP. В частности, для обмена информацией между потребителями и Web-сервисами можно использовать HTTP-методы GET и POST или SOAP.
В общем, основным вариантом выбора обычно оказывается SOAP, поскольку, как вы вскоре убедитесь, сообщения SOAP могут содержать XML-описания сложных типов (включая пользовательские типы и типы из библиотек базовых классов .NET), При использовании HTTP-протоколов GET и POST вам придется ограничиться более узким множеством типов XML-схемы.
Пространства имен .NET для Web-сервисов XML
Теперь, когда у вас есть база для понимания принципов функционирования Web-сервисов XML, мы с вами можем заняться построением такого объекта в рамках платформы .NET. Библиотеки базовых классов определяют целый ряд пространств имен, обеспечивающих взаимодействие с любой из доступных технологий использования Web-сервисов (табл. 25.1).
Таблица 25.1. Пространства имен для работы с Web-сервисами XML
| Пространство имен | Описание |
|---|---|
| System.Web.Services | Содержит базовые типы (включая очень важный атрибут [WebMethod]), необходимые для построения любого Web-сервиса XML |
| System.Web.Services.Configuration | Содержит типы, позволяющие настроить поведение Web-сервиса XML в среде выполнения ASP.NET |
| System.Web.Services.Description | Содержит типы, обеспечивающие программное взаимодействие с WSDL-документом, предлагающим описание данного Web-сервиса |
| System.Web.Services.Discovery | Содержит типы, позволяющие потребителям Web-сервисов выполнять программный поиск Web-сервисов на соответствующей машине |
| System.Web.Services.Protocols | Определяет ряд типов, представляющих "атомы" различных протоколов связи Web-сервисов XML (HTTP-методы get и POST, а также SOAP) |