В чем преимущество XML-RPC над простым XML?

Question

Моя компания давно использует XML-RPC, но в последнее время мне интересно, какое преимущество имеет XML-RPC по сравнению с простым XML. Во-первых, это ужасно "ожирение", считает:

<struct> 
    <member> 
     <name>ROOM_ID</name> 
     <value> 
      <int>1</int> 
     </value> 
    </member> 

    <member> 
     <name>CODE</name> 
     <value> 
      <string>MR-101</string> 
     </value> 
    </member> 

    <member> 
     <name>NAME</name> 
     <value> 
      <string>Math Room</string> 
     </value> 
    </member> 

    <member> 
     <name>CAPACITY</name> 
     <value> 
      <int>30</int> 
     </value> 
    </member> 
</struct> 

По сравнению с этим:

<room><ROOM_ID>1</ROOM_ID><CODE>MR-101</CODE> 
<NAME>Math Room</NAME><CAPACITY>30</CAPACITY></room> 

Или даже так:

<room ROOM_ID=1 CODE=MR-101 NAME=”Math Room” CAPACITY=30 /> 

Во-вторых, XML-RPC кажется довольно широко распространен, но не совсем повсеместно, и я не впечатлен поддержкой этого в C++ и PHP. У меня были проблемы со всеми библиотеками, которые я пробовал на обоих языках.

В-третьих, мне кажется, что я мог делать удаленные вызовы процедур с простым XML так же легко, как с XML-RPC. {(9/9/2009): на каждом языке есть библиотеки для сериализации объектов уровня языка в XML. Как XML, так и XML-RPC требуют, чтобы схемы уровня приложений определялись, например, как должны быть написаны поля, но не требуется какая-либо дополнительная схема. Многие люди делают вызовы RPC с простым XML.}

Итак, что же представляет собой добавление XML-RPC?

Answer 1

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

Однако XmlRpc пользуется большей поддержкой со стороны библиотек, которые используют функции метапрограммирования (отражения) языка для сопоставления вызовов XmlRpc, напрямую (ну, никогда не на 100% напрямую) на вызовы функций уровня языка. Причина в том, что XmlRpc лучше поддерживает XMLRpc, чем простой XML: либо a) историческая авария/результат маркетинга со стороны сторонников 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 был специально разработан для facilitat е создание библиотек, которые автоматически сериализация/unserialise объектов языка на уровне в RPC вызовов, и как таковой он имеют некоторые незначительные преимущества при использовании таким образом:

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

2. XmlRpc определяет стандартный формат времени и даты. {Хотя обработка временных интервалов и чистых временных или чистых дат времени определяется на уровне приложения.}

3. XmlRpc позволяет передавать аргументы функции без их именования; Для простых вызовов XML RPC требуется, чтобы вы назвали каждый аргумент.

4. XmlRpc определяет стандартный способ назвать вызываемый метод: "methodName". С Plain XML тег корневого узла обычно используется для этой цели, хотя возможны альтернативы.

5. XmlRpc определяет простую систему типов: целые числа, строки и т. Д.{Обратите внимание, что со статически типизированными языками типы все равно должны быть скомпилированы в целевой объект и, следовательно, известны и с динамически типизированными языками, часто можно использовать переменные int и float и строки; обратите внимание также, что система типа XmlRpc, как правило, плохо подходит для системы типов целевого языка, которая может иметь несколько целых типов и т. д.}

6. Библиотеки XmlRpc обычно интегрируются непосредственно с библиотекой Http, тогда как Xml библиотеки сериализации все (?) требуют, чтобы программист приложения передавал XML-текст в Http-вызов. В более современных языках, таких как Java/Python/C#, это тривиальный вопрос, но не так, например. C++.

7. Существует «маркетинговое восприятие», которое XML описывает «документы», тогда как XmlRpc предназначен для вызовов процедур. Понимание состоит в том, что отправка сообщения XmlRpc содержит обязательство для сервера выполнять какое-либо действие, тогда как это восприятие не столь сильное с простым XML.

Некоторые люди скажут «кто заботится - разбор данных XML с помощью рекурсивного спуска/DOM/SAX довольно легко в любом случае», в этом случае большинство из вышеперечисленных возражений не имеют никакого отношения.

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

.NET - Java - Python

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

Недостатки XmlRpc являются:

• Как упомянуто в вопросе, это ужасно тучным

• Поддержка простого XML вездесуща и обычно не требует интеграции с крупными библиотеками 3 участника. Многие приложения требуют преобразования автоматически создаваемых объектов в собственные объекты приложения в любом случае.

• Многие реализации XmlRpc не могут создавать истинные объекты уровня языка, которые программисты сортировки ожидали бы и требовали бы, например, временные запросы полей или дополнительный синтаксис.

• Если для проверки вызовов RPC, например DTD-файла, используется документ определения схемы, то вы теряете возможность проверки схемы уровня приложения - файл DTD просто скажет вам, что «это действительно XmlRpc ». Насколько мне известно, стандартный способ определения схемы уровня приложения с протоколом на основе XmlRpc.

Answer 2

Позвольте мне начать с конца и идти в обратном направлении:

3) Да, вы могли бы сделать удаленный вызов процедур с простым XML (или простыми строками, или бинарного протокола). Разница в том, что XmlRpc - это хорошо определенный протокол со многими доступными реализациями, что означает: a) вам не нужно писать столько кода и b) вы могли бы взаимодействовать с кем бы он ни находился на другом конце провода без вам или им приходится иметь дело с кодом друг друга. XmlRpc служит мостом.

2) Я бы сказал, что это quite ubiquitous :-) Я работал с XmlRpc в Java, поэтому не могу комментировать проблемы с реализацией C++/PHP.

1) из-за (3) выше. Многословие протокола является следствием и причиной его функциональной совместимости.

Answer 3

Главное преимущество заключается в том, что кто-то уже разработал схему вызова для вас. Это особенно полезно в языках с рефлексией, где вы можете просто слепо передать, скажем, сложную структуру вызова RPC, и он будет работать над тем, как перевести это в XML для вас. Это менее ценно, скажем, на C++, где вам нужно сообщить библиотеке XML-RPC, что все типы данных явно.

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

Answer 4

Основное значение XmlRpc заключается в том, что вам не нужно писать код для генерации и анализа XML-документов, передаваемых по HTTP, поскольку XML-RPC является предопределенной схемой XML для представления вызовов функций.

Даже с менее оптимальными библиотеками существует дополнительное производное значение, поскольку использование этого типа системы позволяет вам определять ваши удаленные интерфейсы в качестве базовых языковых интерфейсов (C++ Abstract Class, интерфейсы Java и т. Д.), Которые не зависят от проводной протокол, используемый для связи между компонентами.

Отделив определения интерфейсов от проводного протокола (XML-RPC, SOAP и т. Д.), Вы, в случае необходимости, можете заменить альтернативные протоколы. Например, в нашей системе у нас есть службы, которые отображаются с помощью Hessian для наших интерфейсов Flex и SOAP для наших интерфейсов .NET (у библиотеки Hessian .Net есть запрещенная лицензия).

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

Answer 5

Easy: XML RPC предоставляет

• стандартный способ передать имя метода
• система ввода. Я часто работаю с телефонными номерами, это строки, а не цифры.
• стандартный способ возврата ошибок
• интроспекции (почти) для свободного

Все это по сравнению со стандартными XML.