CodeIgniter User Guide Version 2.1.0

CodeIgniter Home › User Guide Home › XML-RPC and XML-RPC Server Classes

Классы XML-RPC и XML-RPC Server

Классы XML-RPC позволяют вам отправлять запросы на другой сервер, или установить собственный сервер XML-RPC для того, чтобы принимать запросы.

Что такое XML-RPC?

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

Например, используя MetaWeblog API, XML-RPC клиент (обычно десктопная программа для публикаций) будет отправлять запросы XML-RPC серверу, запущенному на вашем сайте. Этот запрос может быть новой записью веб-блога для публикации, или запрос на изменение записи для редактирования. Когда XML-RPC сервер принимает этот запрос, он будет изучать его, чтобы определить, какой класс и метод должны быть вызваны для обработки запроса. После обработки сервер отправит обратно ответное сообщение.

За детальными спецификациями вы можете посетить сайт XML-RPC.

Инициализация класса

Как и большинство других классов в CodeIgniter, классы XML-RPC и XML-RPCS инициализируются в вашем контроллере посредством функции :

Чтобы загрузить класс XML-RPC, используйте:

Загруженный объект класса XML-RPC доступен к использованию как

Чтобы загрузить класс XML-RPC Server, используйте:

Загруженный объект класса XML-RPCs доступен к использованию как

Примечание: При использовании класса XML-RPC Server вы должны загрузить оба класса — XML-RPC и XML-RPC Server.

Отправка запросов XML-RPC

Чтобы отправить запросы XML-RPC серверу, вы должны указать следующую информацию:

• URL сервера
• Метод сервера, который вы хотите вызвать
• Данные запроса (разъяснены ниже).

Вот основной пример, как отправить простой пинг Weblogs.com к Ping-o-Matic

$this->xmlrpc->server(‘http://rpc.pingomatic.com/’, 80);
$this->xmlrpc->method(‘weblogUpdates.ping’);

$request = array(‘My Photoblog’, ‘http://www.my-site.com/photoblog/’);
$this->xmlrpc->request($request);

if ( ! $this->xmlrpc->send_request())
<
echo $this->xmlrpc->display_error();
>

Объяснение

Код выше инициализирует класс XML-RPC, устанавливает серверный URL и метод, который будет вызван (weblogUpdates.ping). Запрос (в этом случае, заголовок и URL вашего сайта) размещаются в массиве для транспортировки, скомпилированного с использованием функции request(). Наконец, полный запрос отправлен. Если метод возвращает FALSE, мы отображаем сообщение об ошибке, возвращенное XML-RPC сервером.

Анатомия запроса

XML-RPC это просто данные, которые вы отправляете XML-RPC серверу. каждый кусок данных в запросе называется . Пример выше имеет два параметра: URL и заголовок вашего сайта. Когда XML-RPC сервер принимает ваш запрос, он будет смотреть на параметры, которые ему требуются.

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

Вот пример простого массива с тремя параметрами:

$request = array(‘John’, ‘Doe’, ‘www.some-site.com’);
$this->xmlrpc->request($request);

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

$request = array (
array(‘John’, ‘string’),
array(‘Doe’, ‘string’),
array(FALSE, ‘boolean’),
array(12345, ‘int’)
);
$this->xmlrpc->request($request); Раздел Типы данных ниже содержит полный список доступных типов данных.

Создание сервера XML-RPC

Сервер XML-RPC работает как дорожный инспектор, ожидая входящие запросы и направляя их в соответствующие функции для обработки.

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

$config[‘functions’][‘ new_post ‘] = array(‘function’ => »),
$config[‘functions’][‘ update_post ‘] = array(‘function’ => »);
$config[‘object’] = $this;

Пример выше содержит массив, который предусматривает два типа запросов, разрешенных Сервером. Разрешенные методы в левой части массива. Когда получен любой из них, они будут направлены в класс и метод, указанные справа.

Ключ ‘ object ‘ это специальный ключ, который вы передаете экземпляру класса объекта при необходимости, когда метод, на который вы делаете направление, не является частью суперобъекта CodeIgniter.

Другими словами, если XML-RPC клиент отправляет запрос методу new_post , ваш сервер загружает класс и вызывает функцию . Если пришел запрос методу update_post , ваш сервер загружает класс и вызывает функцию .

Имена функций в примере выше произвольные. Вы решаете, как они будут называться на вашем сервере, или вы можете использовать стандартизированные API, такие как Blogger или MetaWeblog API.

Есть два дополнительных ключа конфигурации, которые вы можете использовать при инициализации серверного класса: debug может бысть установлен в TRUE, чтобы включить отладку, и xss_clean может быть установлено в FALSE, чтобы предотвратить отправку данных через функцию xss_clean библиотеки безопасности.

Обработка серверного запроса

Когда сервер XML-RPC принимает запрос и загружает класс/метод для обработки, он будет передавать объект этому методу, содержащий данные, отправленные клиентом.

Используя пример выше, если запрашивается метод new_post , сервер будет ожидать существующий класс, соответствующий этому прототипу:

class My_blog extends CI_Controller <

function new_post ( $request )
<

Переменная $request это объект, скомпилированный сервером, который содержат данные, отправленные клиентом XML-RPC. Используя этот объект, вы получите доступ к параметрам запроса, позволяющим вам обработать запрос. Когда вы завершите обработку, вы отправите обратно клиенту.

Ниже пример из реального мира, использующий Blogger API. Один из методов Blogger API это . Используя этот метод, клиент XML-RPC может отправлять серверу имя пользователя и пароль, в ответ сервер присылает назад информацию о конкретном пользователе (nickname, user ID, email address и так далее). Вот как может выглядеть функция обработки:

class My_blog extends CI_Controller <

function getUserInfo ( $request )
<
$username = ‘smitty’;
$password = ‘secretsmittypass’;

if ($parameters[‘1’] != $username AND $parameters[‘2’] != $password)
<
return $this->xmlrpc->send_error_message(‘100’, ‘Invalid Access’);
>

$response = array(array(‘nickname’ => array(‘Smitty’,’string’),
‘userid’ => array(’99’,’string’),
‘url’ => array(‘http://yoursite.com’,’string’),
’email’ => array(‘jsmith@yoursite.com’,’string’),
‘lastname’ => array(‘Smith’,’string’),
‘firstname’ => array(‘John’,’string’)
),
‘struct’);

Примечания

Функция получает индексированный массив, соответствующий параметрам запроса, отправленных клиентом. В примере выше, параметры вывода будут именем пользователя и паролем.

Если имя пользователя и пароль, отправленные клиентом, не правильные, будет возвращено сообщение об ошибке, используя .

Если операция была успешной, клиент пришлет назад ответный массив, содержащий информацию о пользователе.

Форматирование ответа

Также как и с запросами, ответы должны форматироваться массивом. Однако, в отличие от запроса, ответ это массив, который содержит единственный элемент. Этот элемент может быть массивом с несколькими дополнительными массивами, но он должен иметь единственный первичный индекс. другими словами, основной прототип выглядит так:

$response = array(‘Response data’, ‘array’);

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

$response = array (
array(
‘first_name’ => array(‘John’, ‘string’),
‘last_name’ => array(‘Doe’, ‘string’),
‘member_id’ => array(123435, ‘int’),
‘todo_list’ => array(array(‘clean house’, ‘call mom’, ‘water plants’), ‘array’),
),
‘struct’
);

Обратите внимание, что массив выше форматирован как . Это один из наиболее частых типов данных для ответов.

Как и с запросами, ответы могут быть одного из семи типов данных перечисленных в разделе Типы данных.

Отправка ответа с ошибкой

Если вам нужно отправить клиенту сообщение об ошибке, вы будете использовать следующее:

return $this->xmlrpc->send_error_message(‘123’, ‘Requested data not available’);

Первый параметр это номер ошибки, а второй параметр это текст сообщения об ошибке.

Создание ваших собственных клиента и сервера

Чтобы помочь понять все, о чем мы сейчас говорили, давайте создадим пару контроллеров, которые действуют как XML-RPC клиент и сервер. Вы будете использовать клиент для отправки запроса серверу, и получения ответа.

Клиент

Используя текстовый редактор, создайте контроллер . В него поместите этот код и сохраните его в директорию applications/controllers/ :

Примечание: В коде выше мы использовали помощник URL. Вы можете найти больше информации о нем на странице Функции-помощники.

Сервер

Используя текстовый редактор, создайте контроллер, называемый . В него поместите этот код и сохраните его в вашей директории applications/controllers/ :

Попробуйте!

Теперь посетите ваш сайт, используя URL соответствующий этому:

Вы должны увидеть сообщение, отправленное серверу, и его ответ.

Клиент, которого вы создали, отправляет сообщение («How is it going?») серверу, вместе с запросом метода «Greetings». Сервер принимает запрос и отправляет его функции «process», где ответ отправляется обратно.

Использование ассоциативных массивов в параметре запроса

Если вы хотите использовать ассоциативный массив в вашем методе параметров, вам будет нужна следующая структура:

$request = array(
array(
// Param 0
array(
‘name’=>’John’
),
‘struct’
),
array(
// Param 1
array(
‘size’=>’large’,
‘shape’=>’round’
),
‘struct’
)
);
$this->xmlrpc->request($request);

Вы можете получить ассоциативный массив при обработке запроса на сервере.

$parameters = $request->output_parameters();
$name = $parameters[‘0’][‘name’];
$size = $parameters[‘1’][‘size’];
$size = $parameters[‘1’][‘shape’];

Справка по функциям XML-RPC

$this->xmlrpc->server()

Устанавливает URL и номер порта к серверу, который принимает запросы:

$this->xmlrpc->timeout()

Устанавливает таймаут (в секундах), после которого запрос будет отменен:

$this->xmlrpc->method()

Устанавливает метод, который будет запрошен на XML-RPC сервере:

Где method это имя метода.

$this->xmlrpc->request()

Принимает массив данных и строит запрос, чтобы отправить его XML-RPC серверу:

$request = array(array(‘My Photoblog’, ‘string’), ‘http://www.yoursite.com/photoblog/’);
$this->xmlrpc->request($request);

$this->xmlrpc->send_request()

Функция отправки запроса. Возвращает булево TRUE или FALSE в зависимости от успеха или неудачи, позволяя использовать функцию в условии.

$this->xmlrpc->set_debug(TRUE);

Включает отладку, которая будет отображать множество информации и данных ошибок, полезных для отладки при разработке.

$this->xmlrpc->display_error()

Возвращает сообщение об ошибке в виде строки, если ваш запрос не был выполнен по некоторым причинам.

$this->xmlrpc->display_response()

Возвращает ответ от удаленного сервера на полученный запрос. Ответ обычно будет в виде ассоциативного массива.

$this->xmlrpc->send_error_message()

Эта фунция позволяет вам отправить сообщение об ошибке от вашего сервера клиенту. Первый параметр это номер ошибки, а второй параметр содержит текст сообщения об ошибке.

return $this->xmlrpc->send_error_message(‘123’, ‘Requested data not available’);

$this->xmlrpc->send_response()

Позволяет вам отправлять ответ от вашего сервера клиенту. С этим методом должен быть отправлен массив корректных данных.

$response = array(
array(
‘error’ => array(FALSE, ‘boolean’),
‘message’ => «Thanks for the ping!»
)
‘struct’);
return $this->xmlrpc->send_response($response);

Типы данных

В соответствии со спецификацией XML-RPC spec есть семь типов значений, которые вы можете отправлять, используя XML-RPC:

Xml rpc windows с

RPC расшифровывается как Remote Procedure Call — удаленный вызов процедур с помощью XML. Как же работает XML-RPC и каковы его отличия от стандарта SOAP?

На сцене — XML-RPC

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

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

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

Хорошо, предположим, у нас есть возможность удаленно вызывать процедуры и функции — чего же нам еще? А вот чего. Формат обмена данными при классической модели RPC (DCOM, CORBA) остается бинарным — а значит, работать с ним сложнее, он не слишком подходит, если надо организовать работу распределенной системы, где между отдельными участками сети стоят firewall/прокси-серверы. Технология DCOM, например, реализована для Windows-систем, CORBA функционирует на разных платформах, но наиболее полноценна ее реализация на J2EE. Значит, всегда найдется (и действительно находится) такая конфигурация сети/платформ, чтобы для реализации распределенной системы в ней ни одна технология не подходила. Так что же делать?

Задавшись этим вопросом, компания UserLand Software Inc. создала технологию XML-RPC. Основным транспортом в ней является протокол HTTP; формат данных — XML. Это снимает ограничения, налагаемые как на конфигурацию сети, так и на маршрут следования пакетов,- вызовы XML-RPC представляют собой простой тип данных text/xml и свободно проходят сквозь шлюзы везде, где допускается ретрансляция http-трафика.

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

Что же это такое?

Рассмотрение XML-RPC проведем на упрощенном тестовом примере. Для снижения затрат мы разворачиваем систему, где на один компьютер (сервер) ставится мощное ПО для перевода, проверка синтаксиса и грамматики, а все клиенты обращаются к нему посредством XML-RPC. (Конечно, этот пример выдуман, чтобы легче было познакомить читателя с технологией — но, господа программисты, кто мешает реально сделать такую систему?)

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

Запрос
XML-RPC запрос	Описание
POST /RPC2 HTTP/1.0 User-Agent: MyAPP-Word/5.1.2 (WinNT) Host: server.localnet.com Content-Type: text/xml Content-length: 172 CheckWord	Сначала идет стандартный заголовок http-запроса. MIME-тип данных должен быть text/xml, длина также обязательно должна присутствовать и иметь корректное значение, равное длине передаваемого сообщения. Стандартный заголовок любого корректного XML-документа. Корневой узел. Не допускается вложенности тегов — значит, одним запросом мы можем вызвать только один метод. Тег указывает на объект и название метода, который вызывается. Можно указывать так, как принято в языках программирования вызывать свойства класса: имя метода — через точку после имени класса. Можно также передавать пути и имя программы. Мы вызываем метод CheckWord объекта OrfoCheck. В секции задаются параметры, которые передаются в метод. Секция может содержать произвольное число подэлементов , содержащих параметр, который описывается тегом . Параметры и типы данных мы рассмотрим чуть дальше. В нашем варианте методу передается один параметр, слово (оно заключено в тег ), которое надо проверить на правильность написания. Все теги, согласно спецификации XML, должны иметь соответствующие закрывающие элементы — в XML-RPC нет одиночных тегов.

Типы данных

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

Целые числа — задаются тегом или и представляются 4-байтовыми целыми числами со знаком. Для задания отрицательных чисел ставится знак «-«, например 34, 344, -15.

Логический тип данных представляется тегом и может иметь значения 0 (false) или 1 (true). Можно использовать как 1/0, так и символьные константы true/false.

ASCII-строка — тип данных, принимаемый по умолчанию. Представляет собой просто строку символов, заключенную в теги . В качестве символов нельзя использовать служебные знаки » и представляют собой числа с плавающей точкой двойной точности. Как разделитель целой и дробной части используется знак «,». Пробелы недопустимы. Отрицательные числа задаются знаком «-» перед числом.

Дата/время. Для передачи времени/даты служит тег . Пример времени — 19980717T14:08:55 (в спецификации написано, что сервер сам должен определять, как посылать время/дату. Использовать этот тип данных, пользоваться структурой или же просто передавать дату как строку не рекомендуется).

Двоичные данные передаются в закодированном (base64) виде и описываются тегом .

Структуры. Для передачи структурированных данных можно конструировать свои структуры. Структура определяется корневым элементом , который может содержать произвольное количество элементов , определяющих каждый член структуры. Член структуры описывается двумя тегами: первый, , описывает имя члена, второй, содержит значение члена (вместе с тегом, описывающим тип данных). Например, так описывается структура с двух строковых элементов:

Ответ сервера
XML-RPC ответ	Описание
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 Тело ответа при ошибке приложения faultCode 4 faultString Too many рarameters.	Сначала идет стандартный заголовок http-ответа сервера. MIME-тип данных должен быть text/xml, длина также должна обязательно присутствовать и иметь корректное значение, равное длине передаваемого сообщения. Стандартный заголовок любого корректного XML-документа. Корневой узел. Не допускается вложенности тегов . Теги аналогичны запросу и включают один или более элементов , которые содержат значение, возвращенное методом. Если сервер отвечает HTTP-кодом 200 ОК — это значит, что запрос успешно обработан. Он уведомляет лишь о том, что данные по сети переданы правильно и сервер сумел их корректно обработать. Но метод также может вернуть ошибку — и это уже будет ошибка не протокола, а логики приложения. В таком случае передается сообщение и структура, которая описывает код ошибки и текстовое объяснение. В нашем примере передается структура из двух элементов: первый элемент содержит целочисленный код ошибки (4), второй элемент — текстовая строка, описывающая ошибку (Too many рarameters — неправильное число параметров).

Окончательный вариант

Теперь можно окончательно описать работу нашего тестового примера. Итак, приложение MyAppWord (текстовый редактор) хочет перевести на английский, например, слово «world». Программа формирует запрос к серверу, вызывая процедуру перевода TranslateWord. Процедуре передается структура, содержащая слово, которое следует перевести, и направление перевода, которое задается символьной строкой — «en-ru».

POST /RPC2 HTTP/1.0
User-Agent: MyAppWord/5.1.2 (WinNT)
Host: server.localnet.com
Content-Type: text/xml
Content-length: 172

TranslateWord

Сервер, приняв наш запрос, передает его программе-демону, которая производит парсинг запроса, выделяет из него нужные данные и, найдя (например, по таблице) ссылку на нужный метод, вызывает его с переданными параметрами. Если тип и количество параметров правильные, то по окончании работы метода программа-демон принимает возвращенное значение, преобразует его в XML-описание и формирует ответ.

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

MyAppWord
Сообщение об ошибке:

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

faultCode
10

faultString

Перевод невозможен. Слово отсутствует в словаре.

Приложение получит такое сообщение, когда запрос на перевод не может быть удовлетворен, поскольку слова нет в словаре.

Хотя наш пример, на первый взгляд, кажется надуманным и простым, тем не менее, на нем показано, как можно уже сегодня использовать XML-RPC для решения конкретных задач. Конечно, его возможности намного шире, и можно, например, представить себе распределенную ОС, построенную на XML-RPC, или системы визуализации данных, построенные по архитектуре X Window, но с применением все того же XML-RPC.

XML-RPC vs SOAP

Если для реализации удаленного вызова вы используете XML, то у вас есть выбор: использовать XML-RPC или же SOAP (Simple Object Access Protocol). О последней уже написано множество статей, поэтому предлагаем только сравнить обе технологии.

Вот некоторые характеристики, которые определяют различия XML-RPC или же SOAP:

Характеристика	XML-RPC	SOAP
Скалярные типы данных	+	+
Структуры	+	+
Массивы	+	+
Именованные массивы и структуры	—	+
Определяемые разработчиком кодировки	—	+
Определяемые разработчиком типы данных	—	+
Детализация ошибок	+	+
Легкость освоения и практического применения	+	—

Конечно, на первый взгляд «минус» в столбце SOAP встречается только единожды. Это создает иллюзию «всереализуемости всего» в нем. Но давайте присмотримся внимательнее. Основные типы данных у обоих конкурентов одинаковые. Но в XML-RPC отсутствует возможность задавать имена для массивов и структур (все структуры и массивы являются «анонимными»). Возможно, это упущение разработчиков, но решить эту проблему можно и самому, например вводя еще одну строковую переменную с именем массива или структуры (в случае, если таких объектов много, можно завести специальный массив «имен массивов»).

С «определяемыми разработчиком кодировками» ситуация уже серьезнее. Сам механизм подобного ограничения не совсем ясен — ни стандарт XML, ни, тем более, транспортный уровень (протокол HTTP) таких ограничений не имеют. Да и стремление сделать клиент/сервер XML-RPC как можно более простым тоже не привело бы к возникновению подобного ограничения. Хотя, с другой стороны, SOAP тоже не блещет поддержкой кодировок (US-ASCII, UTF-8, UTF-16). Правда, в обеих технологиях есть возможность обойти все эти недостатки сразу — тип данных base64. Но выход ли это?

Посмотрим теперь на пункт «легкость в освоении и применении». В свете сегодняшних темпов развития технологий и стандартов, особенно Web, этот пункт приобретает большую важность. Реальна ситуация, когда крупный проект начинает разрабатываться на самой передовой основе — а в конце работы новый стандарт не только «уже не новый», но и «уже не стандарт вообще». Недавно W3C опубликовала черновой вариант SOAP Version 1.2 — поверьте, и объем, и сложность документации впечатляют. Трудности возникают даже на этапе ознакомительного чтения, не говоря уже о разработке. А вот спецификация XML-RPC занимает около трех страниц А4 и предельно проста.

Да, ни одна из этих технологий не является панацеей от всех бед и не претендует на полноту. Большинство программистов и разработчиков спецификаций сходятся на том, что:

• если вам нужна система для работы со сложной логикой, если вы передаете большие комплексные структуры данных, если вам нужна полная информация о клиенте, если вы хотите, чтобы запрос содержал в себе инструкции по его обработке, и, наконец, если для вас важно, чтобы за стандартом стояли гранды индустрии (Microsoft, IBM, Sun) — вам следует остановить свой выбор на SOAP;
• если же данные являются относительно простыми, а приложения должны работать на множестве платформ и на разных языках, если важна скорость работы и логика системы не нуждается в сложных командах — используйте XML-RPC.

Выбрав SOAP, сразу смиритесь с тем, что у вашей команды разработчиков (или у вас самих) впереди много головной боли, которая начнется уже с момента чтения спецификаций. Но ведь зато вы будете иметь возможность в конце концов построить систему практически любой сложности и функциональности.

Если выберете XML-RPC — написать программу клиента/сервера не составит труда даже начинающему программисту. Да и о выборе ПО можете не задумываться — хоть Borland Delphi/Kylix, хоть Phyton. Но не все задачи будут решаться сразу, а некоторые не будут решаться вообще.

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