Что такое WEB-сервис и с чего начиналось его развитие ? Ещё задолго до появления понятия WEB-сервисов уже существовали технологии взаимодействия удаленных приложений. Согласно этим технологиям одна программа может вызвать какой-либо метод в другой программе, запущенной на удаленном компьютере. Сокращенно это называется удаленный вызов процедур RPC (Remote Procedure Calling). Однако формат обмена данными при классической модели RPC (DCOM, CORBA) бинарный. А следовательно, работать с данными сложнее и он не слишком подходит, если надо организовать работу распределенной системы, где между отдельными участками сети стоят firewall/прокси-серверы. Технология DCOM реализована только для Windows-систем, CORBA же функционирует на разных платформах, но наиболее полноценна ее реализация на J2EE. Недостатком CORBA является то, что она работает через какие-то свои сетевые протоколы вместо простого HTTP, который проходит через firewall. Значит, всегда найдется такая конфигурация сети/платформ, что реализация распределенной системы будет очень затруднительна.

Концепция WEB-сервиса связана с созданием такого RPC, который можно включить в HTTP пакеты. Таким образом началась разработка стандарта, определяющего процесс взаимодействия приложений по протоколу HTTP, чтобы приложения могли функционировать на разных аппаратно-программных платформах и использовать различные технологии и языки разработки. С появлением WEB-сервисов началось развитие сервис-ориентированной архитектуры веб-приложений SOA (Service Oriented Architecture). Наибольшее распространение получили следующие протоколы реализации WEB-сервисов :

XML-RPC	XML-вызов удалённых процедур
SOAP	Simple Object Access Protocol
REST	Representational State Transfer

Практический пример создания клиента WEB-сервиса SOAP с отправкой сообщений и получением ответов представлен здесь.

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

Применение XML для описания данных существенно упрощает разработку распределенных приложений, снижаются требования к клиенту и серверу. Программы разбора (парсинга) XML сейчас существуют практически для всех операционных систем и на всех языках программирования.

Протокол WEB-сервиса XML-RPC

Протокол WEB-сервиса XML-RPC, разработанный Дэйвом Винером из компании «UserLand Software» в сотрудничестве с Майкрософт в 1998 году, использует в качестве транспортого механизма протокол HTTP и в качестве формата передаваемых данных XML. Это снимает ограничения, налагаемые как на конфигурацию сети, так и на маршрут следования пакетов. Вызовы XML-RPC представляют собой простой тип данных text/xml и свободно проходят сквозь шлюзы везде, где допускается ретрансляция http-трафика. Однако корпорация Майкрософт вскоре сочла этот протокол слишком упрощённым, и начала расширять его функциональность. После нескольких циклов по расширению функциональности, появилась система, ныне известная как SOAP.

Сообщения XML-RPC передаются методом POST протокола HTTP и бывают трех типов: запрос, ответ и сообщение об ошибке.

Пример запроса, вызов метода CheckWord

POST /RPC2 HTTP/1.0
User-Agent: MyAPP-Word/5.1.2 (WinNT)
Host: server.localnet.com
Content-Type: text/xml
Content-length: 172
<? xml version="1.0"?>
<methodCall>
    <methodName>CheckWord</methodName>
    <params>
        <param>
            <value>
                <string>Спецификация</string>
            </value>
        </param>
    </params>
</methodCall>

Сначала определяется стандартный заголовок http-запроса, MIME-тип данных (Content-Type) которых должен быть text/xml. Размер Content-length должен присутствовать обязательно и иметь корректное значение, равное длине передаваемого сообщения.

Корневой узел определяется тегом <methodCall> и не допускает вложенности, а следовательно в запросе можно вызвать только один метод. Тегом <methodName> определяется название вызываемого метода. Формат названия метода предполагает необязательное наименование класса и наименование метода, разделенные точкой. Можно также включить путь и наименование программы. В примере вызывается метод CheckWord некоторого объекта.

В секцию <params> включают передаваемые параметры, которых может быть несколько и которые описываются тегом <param>. Значение параметра включено в тег <value>. В примере методу передается один параметр в виде текстовой строки «Спецификация», заключенное тегом <string>. Согласно спецификации XML все теги должны иметь соответствующие закрывающие элементы. XML-RPC не включает одиночных тегов.

Типы данных

Для передачи методу параметров и получение возвращаемых значений протокол XML-RPC определяет два сложных и семь простых типов данных, которые используются в реальных языках программирования. Сложные типы данных, например, как объекты, нужно заменять структурами или передавать в двоичном виде.

Тип данных	Описание	Пример
array	Массив значений Массивы описываются секцией <array> и включают один элемент <data>. Значения массива описываются тегом <value>. Элементом массива могут выступать любые типы, а также массивы - что позволяет описывать многомерные массивы.	<array> <data> <value> <string> Текстовая строка </string> </value> <value><i2>1234</i2></value> <value><i1>15</i1></value> </data> </array>
struct	Структура данных Структура определяется корневым элементом <struct>, включающего произвольное количество элементов <member>, которые определяют отдельный элемент структуры. Элемент структуры описывается двумя тегами: наименование <name> и значение <value>.	<struct> <member> <name>qty</name> <value><i4>12</i4></value> </member> <member> <name>price</name> <value><i7>23</i7></value> </member> </struct>
string	Текстовая строка ASCII-строка символов определяется тегом <string>. В качестве символов нельзя использовать служебные знаки HTML "<" и "&"; их следует передавать кодами < и & соответственно.	<string>XML-RPC</string>
integer	Целые числа Целочисленные значения определяются тегом <i4> или <int> и представляются 4-байтовыми целыми числами со знаком. Отрицательное значение определяется знаком "-".	<i4>123</i4>
boolean	Логическое значение Логический тип данных определяется тегом <boolean> и может принимать значения 0 (false) или 1 (true). Можно использовать как 1/0, так и true/false соответственно.	<boolean>1</boolean>
date/time	Дата и время Значение даты и времени определяется тегом <dateTime.iso8601>.	<dateTime.iso8601>19980717T14:08:55</dateTime.iso8601>
double	Числа с плавающей точкой Вещественные значения задаются тегом <double> и представляют собой числа с плавающей точкой двойной точности. Пробелы недопустимы.	<double>-12.34</double>
base64	Кодированные данные Двоичные данные передаются в закодированном виде и описываются тегом <base64>.	<base64>eW91IGNhbid0IHJlYWQgdGhpcyE=</base64>

Пример ответа на вызов метода CheckWord

HTTP/1.1 200 OK
Connection: close
Content-Length: 166
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: MyWordCheckSerwer/5.1.2-WinNT
<? xml version="1.0"?>
<methodResponse>
    <params>
        <param>
            <value>
                <boolean>true</boolean>
            </value>
        </param>
    </params>
</methodResponse>

Ответ включает стандартный http заголовок сервера. MIME-тип данных должен быть text/xml, длина Content-Length должна обязательно присутствовать и иметь значение, равное длине передаваемого сообщения.

Корневой узел ответа начинается с тега <methodResponse> и не допускает вложенности. Теги <params> и <param> аналогичны запросу и включают один или более элементов <value>, которые содержат возвращенное методом значение.

Если сервер отвечает HTTP-кодом 200 ОК, то это значит, что запрос успешно обработан. Т.е. данные по сети переданы корректно и сервер сумел их обработать. Но метод может вернуть ошибку, которая не будет связана с протоколом, а будет ошибкой бизнес-логики приложения. В этом случае передается соответствующее сообщение и структура, которая описывает код ошибки. Пример возвращения кода ошибки :

<methodResponse>
    <fault>
        <value>
            <struct>
                <member>
                    <name>faultCode</name>
                    <value>
                        <int>2</int>
                    </value>
                </member>
                <member>
                    <name>faultString</name>
                    <value>
                        <string>Too many рarameters</string>
                    </value>
                </member>
            </struct>
        </value>
    </fault>
</methodResponse>

В примере ошибка передается в виде структуры из двух элементов: первый элемент содержит код ошибки 2, а второй элемент описывает ошибку.