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

Моя компания некоторое время использует 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 кажется довольно распространенным, но не совсем повсеместным, и я не впечатлен поддержкой его в С++ и PHP. У меня были проблемы со всеми библиотеками, которые я пробовал на обоих языках.

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

Итак, каково значение-добавление XML-RPC?

ОТВЕТЫ

Ответ 1

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

Тем не менее, XmlRpc пользуется большей поддержкой библиотек, которые используют функции метапрограммирования (отражения) языка для сопоставления вызовов XmlRpc, напрямую (ну, никогда не на 100% напрямую) на вызовы функций уровня языка. Причина в том, что XmlRpc лучше поддерживает XMLRpc, чем простой XML: либо a) историческая авария/результат маркетинга со стороны сторонников XmlRpc, либо (б) сумма незначительных проблем перевода, перечисленных ниже, подсказывает масштабы в пользу XmlRpc.

С другой стороны, XmlRpc страдает от двух основных недостатков: (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". С помощью Plain XML тег корня node обычно используется для этой цели, хотя возможны альтернативы.

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

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

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

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

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

. NET - Java - Python

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

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

  • Как упоминалось в вопросе, это ужасно ожирение

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

Ответ 4

Легко: XML RPC предоставляет

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

Все это по стандарту XML.

Ответ 5

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

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

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

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