Со времени начала бурного развития сетевых технологий в конце 80-х годов разработчики стремились вывести методы программирования за пределы одного компьютера. Так, сперва программы взаимодействовали друг с другом по кабельному соединению через параллельный или последовательный порт, затем по сети, используя сетевые протоколы. Позднее были реализованы различные варианты удаленного вызова процедур (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, Си++ или Java), функционировать на любых платформах (от КПК до мэйнфреймов), работать с самым разным клиентским и серверным ПО (в частности, Apache или IIS). А поскольку они основаны на общих для разных платформ стандартах HTTP и XML. не возникает каких-либо препятствий для их успешного взаимодействия. Уже сейчас существуют реализации SOAP для множества ОС.
Вот как можно использовать SOAP уже сейчас. Взяв за основу его спецификацию, напишем серверное ПО, анализирующее входящие HTTP-запросы с XML-фрагментами, которое будет отсылать HTTP-ответы, а также клиентские программы, создающие запросы и анализирующее ответы на них. Это задача сложная, хотя и вполне выполнимая. Но можно поступить проще.
Корпорация Microsoft выпустила для разработчиков, использующих Microsoft Visual Studio, SOAP Toolkit — набор, включающий утилиты и библиотеки, существенно облегчающие процесс написания программ. Можно применять его и с другими средствами разработки, поддерживающими СОМ-технологию.
Процедура реализации решения на основе SOAP может быть следующей. На клиенте нужно создать объект ROPE.Proxy (объект Proxy библиотеки ROPE). Затем с применением объектной модели библиотеки ROPE (Remote Object Proxy Engine) следует запросить с сервера SDL-файл с информацией о сервере, на основе которой библиотека автоматически реализует объект-заглушку, методы и свойства которого описаны в SDL-файле.
Когда клиент примет ссылку на полученный объект, то может вызывать его методы и получать сведения о свойствах. Причем всякий вызов будет передаваться с помощью библиотеки ROPE и протокола SOAP на сервер, где любой SOAP-запрос встретит модуль Listener (Проелушиватель), определяющий его тип и должным образом реагирующий. Если происходит запрос SDL-файла, то возвращается такой файл, а если вызов метода или свойства объекта, то Listener выделяет его из пришедшего XML-файла, выполняет запрос к расположенному на сервере СОМ-объекту, получает результат, используя ROPE, «запаковывает» его в XML и отсылает обратно.
На клиентской машине созданием и разбором XML-сообшений занимается та же библиотека ROPE.
Александр Ложечкин
