ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://IntertechTraining.com/")]
public partial class SalesInfoDetails {
 private string infoField;
 private string urlField;
 private System.DateTime dateExpiredField;
 public string info {
 get { return this.infoField; }
 set { this.infoField = value; }
 }
 public string Url {
 get { return this.urlField; }
 set { this.urlField = value; }
 }
 [System.Xml.Serialization.XmlAttributeAttribute]
 public System.DateTime dateExpired {
 get { return this.dateExpiredField; }
 set { this.dateExpiredField = value; }
 }
}

При этом, конечно, следует понимать, что подобно случаю удаленного взаимодействия .NET, типы, сериализация которых выполняется по сети в формате XML, не сохраняют логику реализации. Поэтому, если структура SalesInfoDetails поддерживала ряд открытых методов, генератор агента учесть это не сможет (прежде всего, потому, что эти методы не отражены в документе WSDL!). Однако если вы установите компоновочный блок клиента, который будет содержать программный код реализации типа клиента, вы сможете использовать программную логику типа. Но при этом требуется, чтобы соответствующая машина обеспечивала поддержку .NET.

Исходный код. Проект CarSaleslnfoClient размещен в подкаталоге, соответствующем главе 25.

Стандарт поиска и взаимодействия (протокол UDDI)

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

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

UDDI (Universal Description, Discovery and Integration – универсальное описание, поиск и взаимодействие, стандарт UDDI) является инициативой, позволяющей разработчикам Web-сервисов "выставить" коммерческий Web-сервис в общеизвестном хранилище. Независимо от того, что вы могли сейчас подумать, UDDI не является технологией, поддерживаемой исключительно фирмой Microsoft. На самом деле IBM и Sun Microsystems имеют не меньшую заинтересованность в успexe инициативы UDDI. Как и следует ожидать, UDDI-каталоги обслуживаются многими поставщиками. Например, посвященный UDDI официальный Web-сайт Microsoft доступен по адресуОфициальный Web-сайт UDDI предлагает множество "белых книг" и SDK, которые позволяют строить внутренние UDDI-серверы.

Взаимодействие с UDDI в Visual Studio 2005

Вспомните о том, что диалоговое окно Add Web Reference позволяет не только получить список всех Web-сервисов XML, размещенных на вашей локальной машине (а также по известному URL), но и предъявить запрос к UDDI-серверу. Как правило, вы имеете на выбор следующие варианты.

• Выполнить обзор UDDI-сервера во внутренней сети вашей компании.

• Выполнить обзор спонсируемого фирмой Microsoft производственного UDDI-сервера.

• Выполнить обзор спонсируемого фирмой Microsoft тестового UDDI-сервера.

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

• Есть ли у вас Web-сервисы, имеющие отношение к погодным данным?

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

Для примера создайте новый проект консольного приложения и активизируйте диалоговое окно Add Web Reference. Затем выберите ссылку Test Microsoft UDDI Directory, которая приведет вас к тестовому UDDI-серверу Microsoft. После этого укажите слово weather (погода) в качестве критерия поиска. После выполнения запроса UDDI-каталогом вы получите список всех соответствующих Web-сервисов XML. Обнаружив Web-сервис XML который подойдет вам для использования в разработке, добавьте ссылку на этот сервис в свой проект. Как вы и должны ожидать, "сырой" WSDL-код будет проанализирован соответствующим инструментом разработки, и вы получите соответствующий агент на языке C#.

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

Резюме

В этой главе были рассмотрены базовые компоненты Web-сервисов и основные этапы их построения в пределах платформы .NET. Глава начинается с рассмотрений пространств имен (и базовых типов в этих пространствах имен), используемых при создании Web-сервисов. Вы узнали, что для разработки Web-сервиса в .NET требуется лишь немногим большее, чем применение атрибута [WebMethod] к каждому члену, который вы хотите сделать доступным в рамках типа, представляющего данный Web-cервис XML. Вы также можете (но это необязательно) сделать соответствующие типы производными от System.Web.Services.WebService, чтобы (среди прочего) получить доступ к свойствам Application и Session. В связи с основной темой обсуждения этой главы были также рассмотрены три взаимосвязанные ключевые технологии – это механизм поиска (UDDI), язык описания (WSDL) и протоколы связи (GET, POST или SOAP).

После создания любого числа членов с атрибутами [WebMethod] вы можете начать взаимодействие с Web-сервисом посредством промежуточного агента. Такой агент может быть сгенерирован с помощью утилиты wsdl.exe, а сам агент может использоваться клиентом подобно любому другому типу C#. Альтернативой инструменту командной строки wsdl.exe является использование Visual Studio 2005, где аналогичные возможности предлагает диалоговое окно Add Web Reference.