Короткий ответ: оба протокола можно использовать для выполнения удаленных вызовов процедур (RPC). Оба протокола требуют определения схемы на уровне приложения, и, вообще говоря, ни один из протоколов не требует какой-либо дополнительной схемы для определения того, как сериализовать объекты на уровне языка (некоторые подробности см. ниже).
Однако XmlRpc пользуется большей поддержкой со стороны библиотек, которые используют функции метапрограммирования (рефлексии) языка для сопоставления вызовов XmlRpc напрямую (ну, никогда не на 100% напрямую) с вызовами функций на уровне языка. Причина лучшей поддержки XmlRpc, чем простой XML, заключается либо в (а) исторической случайности/результате маркетинга со стороны сторонников XmlRpc, либо (б) сумме незначительных проблем с переводом, перечисленных ниже, склоняющих чашу весов в пользу XmlRpc.
С другой стороны, XmlRpc имеет 2 основных недостатка: (1) он требует примерно в 4 раза большей пропускной способности и (2) он подрывает цель инструментов проверки XML-схемы: каждый пакет будет просто помечен как «да, это является действительным XmlRpc", независимо от орфографических ошибок и пропусков в полях уровня приложения.
Длинный ответ:
Вопреки распространенному мнению, вам не нужен стандарт для определения того, как кодировать объекты языкового уровня в простом XML - обычно есть только один «разумный» способ (при условии, что схема уровня приложения определяет, используете ли вы атрибуты XML или нет), например :
class Room {
int id=1;
String code="MR-101";
String name="Maths room";
int capacity=30;
};
закодировано как:
<Room>
<id>1</id>
<code>MR-101</code>
<name>Maths room</name>
<capacity>30</capacity>
</Room>
XmlRpc был специально разработан для облегчения создания библиотек, которые автоматически сериализуют/десериализуют объекты языкового уровня в вызовах RPC, и поэтому при таком использовании он имеет некоторые незначительные преимущества:
В простом XML структуру с одним членом можно спутать с массивом с одним элементом.
XmlRpc определяет стандартный формат времени/даты. {Хотя обработка часовых поясов и временных меток чистого времени или чистой даты определяется на уровне приложения.}
XmlRpc позволяет передавать аргументы функции, не называя их; Обычные вызовы XML RPC требуют, чтобы вы назвали каждый аргумент.
XmlRpc определяет стандартный способ именования вызываемого метода: «methodName». В обычном XML для этой цели обычно используется тег корневого узла, хотя возможны и альтернативные варианты.
XmlRpc определяет простую систему типов: целые числа, строки и т. д. {Обратите внимание, что в языках со статической типизацией типы в любом случае должны быть скомпилированы в целевой объект, и поэтому они известны, а в языках с динамической типизацией часто int, float и строки могут использоваться взаимозаменяемо; обратите также внимание на то, что система типов XmlRpc, как правило, не соответствует системе типов целевого языка, который может иметь несколько целочисленных типов, и т. д.}
Библиотеки XmlRpc обычно напрямую интегрируются с библиотекой Http, тогда как все библиотеки сериализации Xml (?) требуют, чтобы программист приложения передал текст XML в вызов Http. В более современных языках, таких как Java/Python/C#, это тривиальный вопрос, но не так, например. С++.
Существует «маркетинговое мнение», что XML описывает «документы», тогда как XmlRpc предназначен для вызовов процедур. Считается, что отправка сообщения XmlRpc содержит обязательство сервера выполнить какое-то действие, в то время как это восприятие не так сильно с обычным XML.
Некоторые люди скажут "какая разница - синтаксический анализ XML-данных с использованием рекурсивного спуска/DOM/SAX в любом случае довольно прост", и в этом случае большинство приведенных выше возражений неуместны.
Для тех, кто по-прежнему предпочитает простоту использования автоматического создания объектов на родном языке, многие основные языки имеют библиотеки, которые автоматически сериализуют объекты языкового уровня в XML, не прибегая к XmlRpc, например:
.NET — Java — Питон
Возможно, успех XmlRpc в его нынешнем виде связан с доступностью библиотек, которые автоматически создают объекты языкового уровня, и, в свою очередь, эти библиотеки имеют преимущество перед своими обычными XML-аналогами из-за перечисленных выше проблем.
Недостатки XmlRpc:
Как упоминалось в вопросе, он ужасно толстый
Поддержка простого XML повсеместна и обычно не требует интеграции с крупными сторонними библиотеками. Во многих приложениях в любом случае требуется преобразование автоматически созданных объектов в собственные объекты приложения.
Многие реализации XmlRpc не могут создавать истинные объекты языкового уровня, ожидаемые программистами, и вместо этого требуют, например, поиск полей во время выполнения или дополнительный синтаксис.
Если документ определения схемы используется для проверки вызовов RPC, например файл DTD, вы теряете возможность проверить схему уровня приложения — файл DTD просто сообщит вам, что «это допустимый XmlRpc». Насколько мне известно, не существует стандартного способа определения схемы уровня приложения с помощью протокола на основе XmlRpc.
person
Tim Cooper
schedule
14.11.2009
