□ Тестирование Web-службы.

□ Построение клиента, использующего Web-службы.

□ Асинхронный вызов Web-службы.

□ Отправка и прием сообщений.

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

Предшественники Web-служб

Соединение компьютеров для передачи данных стало важной концепцией уже в 1969 г, когда телефонными линиями связи были соединены четыре компьютера, образуя ARPANET (Advanced Research Projects Agency Network - сеть управления перспективных исследовательских программ). В 1976 г. был изобретен протокол TCP/IP. Для упрощения использования этого протокола Университет Беркли создал модель сокетов для программирования сетевых задач.

При выполнении программирования с помощью интерфейса Sockets API клиент должен был инициировать подключение к серверу, после чего он мог отправлять и принимать данные. Для вызова некоторых операций на сервере с целью получения результатов требуются дополнительные протоколы для описания кодов запроса и ответа. Примерами таких протоколов приложений являются FTP (File Transfer Protocol - протокол передачи файлов). Telnet и HTTP (Hypertext Transfer Protocol - протокол передачи гипертекста). Протокол FTP используется для получения файлов с сервера и для помещения файлов на сервер. Он поддерживает коды запросов, такие как GET и PUT, которые пересылаются по линии связи от клиента к серверу. Сервер анализирует принимаемый поток данных и в соответствии с кодами запроса вызывает соответствующий метод. Работа протокола HTTP очень похожа на работу протокола FTP

Вызов удаленных процедур (RPC)

При использовании интерфейса Sockets API и протокола TCP/IP, вызывающего специализированные методы на сервере, программист должен был создавать средства, с помощью которых сервер анализировал потоки данных для вызова соответствующего метода. Чтобы облегчить решение этой задачи, ряд компаний создал протокол RPC (remote procedure calls - вызов удаленных процедур), примером которого служит все еще популярный протокол DCE - RPC (Distributed Computing Environment - среда распределенных вычислений), разработанный фондом OSF (Open Software Foundation - Фонд открытого программного обеспечения). Впоследствии эта организация была переименована в Open Group (www.opengroup.org). Используя RPC, можно определять в формате IDL (Interface Defmition Language - язык определения интерфейса) методы, которые сервер должен реализовать, и которые клиент может вызывать. Теперь для вызова методов больше не нужно определять нестандартный протокол и анализировать коды запросов. Эта задача выполняется специальной программой, называемой заглушкой (stub), сгенерированной компилятором интерфейса.

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

CORBA

В 1991 г. группа OMG (Object Management Group - группа по управлению объектами; www.omg.org) инициировала создание модели CORBA (Common Object Request Broker Architecture - общая архитектура брокера объектных запросов), чтобы перенести концепцию ООП в решение сетевых задач. Многие поставщики, такие как Digital Equipment, HP, IBM и другие, реализовали серверы CORBA. Однако поскольку OMG не определила эталонную реализацию, а только спецификацию модели, серверы этих поставщиков в действительности не могли взаимодействовать друг с другом. Сервер HP нуждался в клиенте HP, сервер IBM - в клиенте IBM и т.д.

DCOM

С выходом на рынок ОС Windows NT 4 компания Microsoft дополнила протокол DCE - RPC объектно-ориентированными функциональными возможностями. Протокол DCOM (Distributed СОМ - распределенная модель СОМ) позволяет вызывать компоненты СОМ через сеть и используется в приложениях СОМ+. По прошествии нескольких лет, в течение которых операционные системы Microsoft были обязательным условием возможности использования модели DCOM, компания Microsoft открыла протокол для применения в других средах, дополнив его компонентами Active Group. DCOM стал доступным для систем UNIX, VMS и IBM. Протокол DCOM интенсивно использовался в средах Microsoft, но инициатива по его переносу в другие системы оказалась не совсем успешной. Что же требуется администратору мэйнфрейма IBM для добавления технологии Microsoft в управляемую им систему?

Компания Sun Microsystems пошла другим путем, используя свои технологии Java. В чистом мире Java протокол RMI (Remote Method Invocation - вызов удаленного метода) можно использовать для удаленного вызова объектов. Компания Sun добавила несколько мостов для мира CORBA и СОМ, но основной ее целью было склонить основных пользователей к применению решения на базе только языка Java.

SOAP

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

Поэтому в 1999 г. несколько компаний, включая Microsoft и UserLand Software (www.userland.com), создали протокол SOAP в качестве нового способа вызова объектов по Internet - способа, который работает на основе уже принятых стандартных протоколов. Для описания методов и параметров, необходимых для выполнения удаленных вызовов по сети, SOAP использует формат на основе языка XML. В системе СОМ сервер SOAP мог бы преобразовывать SOAP-сообщения в СОМ-вызовы, а в системе CORBA он преобразует их в CORBA-вызовы. Первоначально в определении SOAP протокол HTTP применялся для выполнения SOAP-вызовов через Internet.

С появлением версии SOAP 1.2 Web-службы стали независимыми от протокола HTTP. Можно использовать любой транспортный протокол, но до настоящего времени HTTP остается наиболее часто применяемым транспортным протоколом для Web-служб.

Эта глава посвящена Web-службам, которые могут быть созданы с помощью шаблона проекта Visual Studio 2008 и используют протоколы SOAP и HTTP

Спецификации SOAP можно найти на Web-сайте www, w3. org/TR/SOAP.

Применение Web-служб

Чтобы взглянуть на Web-службы под еще одним углом, можно сделать различие между обменом данными между пользователем и приложением и между приложениями. Начнем с рассмотрения примера обмена данными между пользователем и приложением: получение информации о погоде из Web. Несколько Web-сайтов, таких как weather. msn. com и www. weather. com, представляют читателю информацию о погоде в легко систематизируемом формате. Обычно пользователь читает эти страницы непосредственно.

Если же нужно было создать мощное клиентское приложение для отображения информации о погоде (выполняющее обмен данными между приложениями), приложение должно было бы подключаться к Web-сайту посредством строки URL-адреса, содержащей название интересующего города. Результирующее HTML-сообщение, возвращенное Web-сайтом, нужно было бы проанализировать для получения информации о температуре и погодных условиях, после чего информацию, наконец, можно было бы отобразить в соответствующем формате клиентского приложения.

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

Для решения проблемы обработки HTML-данных Web-служба предоставляет полезные средства возврата только запрошенных данных. Для этого достаточно вызвать метод на удаленном сервере и получить необходимую информацию, которая может непосредственно обрабатываться клиентским приложением. К счастью, в этом случае приходится иметь дело с предварительно сформатированным текстом, предназначенным для интерфейса пользователя, поскольку Web-служба представляет информацию в формате XML, а для обработки XML-данных уже существует набор инструментальных средств. Единственное, что требуется от клиентского приложения - вызов ряда методов XML-классов каркаса .NET Framework для получения информации. Более того, при создании клиентского приложения для Web-службы .NET на языке С# для этого даже не требуется написание кода - существуют средства, которые сгенерируют код С# автоматически.

Подобное приложение отображения информации о погоде - один из примеров множества возможных применений Web-служб.

Сценарий использования приложения бюро путешествий

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