Главная » Java, Web, XML » Протокол XML-RPC

0

Самое простое применение языка XML для сборки аргументов вызываемой удаленной процедуры, и пересылки результатов ее работы было сделано в 1999 году Дейвом Винером (Dave Winer), который вместе со своими друзьями создал протокол XML-RPC — реализацию XML и написал спецификацию XML-RPC. Она доступна по адресу http://www.xmlrpc.com/spec. В том же году был написан сервер XML-RPC, названный Frontier (http://www.userland.com/). С тех пор написано множество клиентов и серверов XML-RPC на разных языках: Java, Perl, Python, C/C+ + , Ruby.

Спецификация XML-RPC очень проста, она вводит не более двадцати элементов XML.

Пусть мы хотим получить прогноз погоды на завтра и обращаемся к процедуре

public String getWeatherForecast (String location);

выполняющейся на сервере метеослужбы. В процедуру заносится название местности location, она возвращает строку с прогнозом. Код процедуры нас сейчас не интересует.

Собранные по протоколу XML-RPC аргументы вызова этой удаленной процедуры, готовые к пересылке на сервер, выглядят так:

<?xml version=" 1. 0" ?> <methcdCall>

<methodName>getWeatherForecast</methodName> <params>

<param>

<value>

<string>rafl!OKHHO</string> </value> </param>

</params>

</methodCall>

Корневой элемент вызова удаленной процедуры называется <methodCall>. В него вложен элемент           в теле которого записывается имя

процедуры, и необязательный элемент                     тело которого содержит

список аргументов процедуры.

Тело элемента                      содержит строку символов, состоящую из букв

A—Z, a—z, арабских цифр 0—9, знаков подчеркивания, точек, двоеточий и слешей.

В элемент              вложены нуль или несколько элементов <param>, опи

сывающих аргументы процедуры.

Каждый элемент <param> описывает один аргумент процедуры вложенным элементом    В него вкладывается элемент, описывающий тип аргу

мента. В табл. 2.1 приведен список этих элементов.

Таблица 2.1. Типы аргументов XML-RPC

Элемент

Тип

<i4> или <int>

Целое 4-байтовое число

<boolean>

0 (false) или 1 (true)

<string>

Строка символов ASCII

<double>

8-байтовое вещественное число

<dateTime . iso8 601>

Дата и время в формате CCYYMMDDTHH:MM:SS

<base64>

Строка кода Base 64

<array>

Массив

<struct>

Структура

По умолчанию аргумент относится к типу <string>.

Как видно из таблицы 2.1, аргумент процедуры может быть массивом или структурой.

Аргумент-массив выглядит так: <аггау>

<data>

<valuexint>12</intx/value> <value>rafltoKimo</value> <value><boolean>0< /boolean>< /value> <value><i4>-3K/i4x/value > </data>

</array>

В элемент <array> вкладывается один элемент <data>, в котором элементами        перечисляются элементы массива. Как видно из примера, элементы массива могут быть разных типов, в том числе снова массивы или структуры. Элементы массива различаются своими порядковыми номерами, поэтому порядок их записи очень важен.

Аргумент-структура оформляется в следующем виде:

<struct>

<member>

<name>day</name>

<valuexi 4>18</i 4x/value> </member>

<menfcer>

<name>month</name> <valuexi4>ll</i4x/value> </member»

</struct>

Структура подобна структуре языка С или записи языка Pascal. Она состоит из нескольких членов, описываемых элементами <member>. У каждого члена есть имя <name> — строка символов, и значение              любого типа, кото

рым может быть и массив и другая структура. Члены структуры различаются по именам, поэтому порядок их записи не имеет значения.

Собранные аргументы процедуры в виде документа XML с корневым элементом <methodCall> пересылаются серверу по протоколу HTTP методом POST с типом содержимого

Content-Type: text/xml

Сервер оформляет ответ, содержащий результат выполнения процедуры, как документ XML вида

<?xml version="l.0"?>

<methodResponse>

<params>

<param>

<value>ByflyT дожди</уа1ие>

</param>

</params>

</methodResponse>

В случае удачного выполнения процедуры в корневой элемент ответа вкладывается один элемент <params>, содержащий один элемент <param> с единственным элементом

Если при выполнении процедуры возникли ошибки, то в элемент <methodResponse> вместо элемента <params> вкладывается элемент <fault>. В этом случае ответ выглядит так:

<?xml version="1.0"?>

<methodResponse> <fault> <value>

<struct>

<member>

<name>faultCode</name> <valuexint>4</intx/value> </member>

<membe r>

<name>faultString</name>

<value>Tbo many parameters .</value> </member>

</struct>

</value> </fault> </methodResponse>

В элемент <fault> вкладывается элемент <value>, содержащий структуру с двумя членами, имеющими фиксированные имена faultCode и faultstring. Эти члены содержат целочисленный код ошибки и строковое сообщение об ошибке. Спецификация не определяет никакие коды ошибок — это остается на долю реализации протокола.

Вот и все описание протокола XML-RPC. Как видите, он предельно прост, но описан неточно. Его спецификация не дает даже описания DTD определенных в ней элементов XML. При таком расплывчатом описании клиентскую и серверную части, реализующие этот протокол, должна делать одна команда программистов, одинаково понимающих все недоговоренности спецификации.

Кроме того, средств протокола XML-RPC явно недостаточно для вызова процедур со специфичными типами аргументов, с аргументами по умолчанию. Еще менее он приспособлен для вызова методов распределенных объектов. Поэтому теми же авторами в то же время был создан протокол SOAP.

Литература:

Хабибуллин И. Ш. Разработка Web-служб средствами Java. — СПб.: БХВ-Петербург, 2003. — 400 с: ил.

По теме:

  • Комментарии