Протокол SOAP

Так, сперва программы взаимодействовали друг с другом по кабельному соединению через параллельный или последовательный порт, затем по сети, используя сетевые протоколы. Позднее были реализованы различные варианты удаленного вызова процедур (RPC, Remote Procedure Call), что давало возможности разработчику ПО в общем-то не беспокоиться о том, как информация между модулями программы передается по сети. Потом на базе RPC создали протокол ORPC, в котором используются технологии DCOM, CORBA/IIOP или RMI (Remote Method Invocation). ORPC позволяет организовать взаимодействие по сети уже на уровне объектов.

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

Новое — это хорошо переработанное старое

Если же для вызова методов и передачи информации применить стандартный протокол высокого уровня HTTP, а для описания данных — не менее распространенный стандарт XML, то появится SOAP (Simple Object Access Protocol) — способ удаленного вызова объектов по глобальным сетям.

Как он работает? Зная URL, клиент на языке описания сервиса SDL (Service Description Language) запрашивает у сервера информацию о нем (предоставляемые методы, параметры и т. д.). В ответ он получает SDL-файл с нужными сведениями о том, какие услуги (методы) ему будут предоставлены и как ими пользоваться.

Методы вызываются с помощью HTTP-запросов (Request) и ответов (Response). В запрос вкладывается XML-текст с описанием требующегося метода и перечнем передаваемых на сервер параметров, а в XML-ответе приходят обратно результаты обработки запроса или код ошибки.

Главное достоинство SOAP заключается в том, что и клиент, и сервер могут быть реализованы на всевозможных языках программирования (например, Perl, VBScript, Cи++ или Java), функционировать на любых платформах (от КПК до мэйнфреймов), работать с самым разным клиентским и серверным ПО (в частности, Apache или IIS). А поскольку они основаны на общих для разных платформ стандартах HTTP и XML, не возникает каких-либо препятствий для их успешного взаимодействия. Уже сейчас существуют реализации SOAP для множества ОС.

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

Корпорация Microsoft выпустила для разработчиков, использующих Microsoft Visual Studio, SOAP Toolkit — набор, включающий утилиты и библиотеки, существенно облегчающие процесс написания программ. Можно применять его и с другими средствами разработки, поддерживающими COM-технологию.

Процедура реализации решения на основе SOAP может быть следующей. На клиенте нужно создать объект ROPE.Proxy (объект Proxy библиотеки ROPE). Затем с применением объектной модели библиотеки ROPE (Remote Object Proxy Engine) следует запросить с сервера SDL-файл с информацией о сервере, на основе которой библиотека автоматически реализует объект-заглушку, методы и свойства которого описаны в SDL-файле.

Когда клиент примет ссылку на полученный объект, то может вызывать его методы и получать сведения о свойствах. Причем всякий вызов будет передаваться с помощью библиотеки ROPE и протокола SOAP на сервер, где любой SOAP-запрос встретит модуль Listener (Прослушиватель), определяющий его тип и должным образом реагирующий. Если происходит запрос SDL-файла, то возвращается такой файл, а если вызов метода или свойства объекта, то Listener выделяет его из пришедшего XML-файла, выполняет запрос к расположенному на сервере COM-объекту, получает результат, используя ROPE, «запаковывает» его в XML и отсылает обратно.

На клиентской машине созданием и разбором XML-сообщений занимается та же библиотека ROPE.

Создаем приложение-калькулятор

Для примера напишем маленькое приложение-калькулятор, позволяющее переводить денежные единицы по текущим котировкам на бирже. Кто-то может возразить, что для этого не нужно создавать приложение, связывающееся с сервером по какому-то протоколу (будь то SOAP или какой-либо иной), гораздо целесообразнее написать страницу на HTML, предоставляющую практически такой же пользовательский интерфейс. Для простого приложения вроде калькулятора это, возможно, и оправдано. Однако, когда подобная задача ставится в сложном программном комплексе, HTML-интерфейс (как, впрочем, и любой другой пользовательский интерфейс) не подойдет, поскольку обращение к серверу за текущими котировками будет происходить из программы, без участия пользователя. Именно для этих случаев и предназначен SOAP.

Начнем с программы-сервера

Пусть для простоты (ведь цель — всего лишь показать, как реализовать решение с протоколом SOAP, а не как обращаться к базе данных за текущими котировками), объект, возвращающий котировки валюты, будет передавать всегда одни и те же числа (горе биржевым спекулянтам!). Здесь будут взяты только три денежные единицы: рубль (RUR), американский доллар (USD) и Евро (EUR) в соотношении, сложившемся на текущий момент времени.

На сервере у объекта будет только один возвращающий текущие котировки спроса метод GetQuotation со следующими параметрами:

* CurID1 — идентификатор для первой валюты;

* CurID2 — для второй.

Они примут одно значение из трех возможных, заданных в Enum (листинг 1).

Листинг 1. Тип валюты

Public Enum CurrencyID
    curRUR
    curUSD
    curEUR
End Enum

Текущие значения будут передаваться через параметр возврата. Конечно, имело бы смысл приблизить этот объект к жизни и возвращать за один вызов котировки спроса и предложения. Они бы пересылались через Out-параметры (аналогично тому, как передаются параметры по ссылке в Си++). Но, к сожалению, в имеющейся версии SOAP Toolkit Out-параметры отсутствуют. (Следует учесть, что рассматривается лишь предварительный вариант этого продукта, а его широкое применение начнется тогда, когда SOAP станет неотъемлемой частью средств разработки следующего поколения — Visual Studio .Net).

Реализация объекта предельно проста и ничем не отличается от любого другого COM-объекта на Visual Basic.

Создается проект ActiveX dll, в который добавляется один класс, исходный текст которого приведен в листинге 2. Конечно, не существует препятствий для создания этого объекта на другом языке программирования и в другой среде.

Чтобы с полученным COM-объектом можно было общаться, вызывая методы по протоколу SOAP, требуется следующее:

• сгенерировать с помощью программы SDLWizard.exe служебный ASP-файл (Active Server Pages) и XML-файл с SDL-описанием сервера. Они будут называться так же, как COM-объект, но иметь расширения asp и xml соответственно;
• скопировать их, а также Listener (в виде ASP-файла) в отдельную папку;
• с помощью Internet Information Services создать виртуальный каталог IIS.

Теперь SOAP-сервер готов обрабатывать запросы клиентов. Может также потребоваться незначительная настройка утилиты Component Services (настройка параметров COM+ в Windows 2000), подробно изложенная в документации к SOAP Toolkit.

Описанная выше последовательность действий относится к ситуации, когда Listener представлен в виде ASP-модуля. Если же Listener реализован на ISAPI, то инструкции подробно даны в файле помощи, поставляемом с SOAP Toolkit.

Возьмемся за клиента

Рис. 1. Экран приложения-клиента, основанного на протоколе SOAP

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

Внешний вид окна приложения-клиента приведен на рис. 1. При нажатии на кнопку Connect устанавливается связь с SOAP-сервером. В строке URL можно ввести его имя, затем с помощью двух наборов кнопок с зависимой фиксацией выбрать тип валюты, а отметив кнопку Get Quotation, получить в поле Quotation значение курса.

Этот пример достаточно прост, но тем не менее позволяет продемонстрировать основные возможности, предоставляемые протоколом SOAP и библиотекой ROPE.

По шагам

Рассмотрим подробнее процесс взаимодействия клиента и сервера (рис. 2).

Рис. 2. Схема взаимодействия клиента и сервера по протоколу SOAP

? После нажатия на кнопку Connect происходит обращение клиента к библиотеке ROPE для установления соединения с сервером и получения SDL-файла. Текст программы, обрабатывающей нажатие на кнопку приведен в листинге 3.

Листинг 4

Библиотека ROPE посылает запрос по Web-адресу, предоставленному клиентом, и запрашивает у сервера SDL-файл. Запрос попадает к программе Listener, которая может быть написана как с использованием технологии ASP, так и с применением Internet Server API (ISAPI). Независимо от реализации клиенту будет отправлен SDL-файл.

• Библиотека ROPE на основе SDL-файла создает объект Proxy, с помощью которого клиент может вызвать какой-либо метод серверного объекта, в частности по нажатию на кнопку Get Quotation метод Proxy.
• Метод объекта транслируется библиотекой и отправляется в виде HTTP-запроса на сервер.
• Listener и в этот раз перехватывает и переправляет этот запрос библиотеке ROPE, которая, разобрав посланный XML-текст, вызывает серверный объект с необходимыми параметрами и возвращает клиенту «упакованные» в XML результаты работы.

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

* * *

Протокол SOAP будет «встроен» в ожидаемую в ближайшее время версию Visual Studio, и тогда разработчики смогут использовать технологию Web-сервисов (Web Service) с помощью SOAP точно так же, как они реализуют обычные COM-серверы и COM-клиенты. Microsoft планомерно проводит в жизнь свой лозунг «Focus on business problem, not on plumbing» (сосредоточьтесь на бизнесе, а не на прокладке водопроводов), только теперь логика функционирования системы выходит на новый уровень — глобальных сетей и огромных корпоративных систем. А чтобы не затеряться в этом новом компьютерном мире, представление о нем лучше получить уже сейчас.

Дополнительные сведения

? SOAP Toolkit для Visual Studio 6.0. (В его составе есть файл справки с подробным описанием библиотеки ROPE): http://msdn.microsoft.com/xml/general/toolkit_intro.asp

? Caron R. Develop a Web Service: Up and Running with the SOAP Toolkit for Visual Studio//MSDN Magazine.2000. N8. (Посвящена использованию SOAP Toolkit. Снабжена интересным примером.): http://msdn.microsoft.com/msdnmag/issues/0800/ webservice/webservice.asp

? Box D. A Young Person?s Guide to The Simple Object Access Protocol: SOAP Increases Interoperability Across Platforms and Languages//MSDN Magazine. 2000. N8. (Статья известного автора с подробным описанием SOAP.): http://msdn.microsoft.com/msdnmag/ issues/0300/soap/soap.asp

? Спецификация протокола SOAP: http://msdn.microsoft.com/xml/general/soapspec.asp

? Конференция, посвященная SOAP и SOAP Toolkit: news://msnews.microsoft.com/ microsoft.public.msdn.soaptoolkit

? Информация о следующей версии Visual Studio: http://msdn.microsoft.com/vstudio/nextgen/

Об АВТОРЕ

Александр Ложечкин — системный аналитик компании Digital Design, e-mail: alozhechkin@hotmail.com

Требования к конфигурации компьютера для использования SOAP Toolkit