17

我的公司使用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-RPC 一样轻松地使用纯 XML 进行远程过程调用。{(9/9/2009)：每种语言都有用于将语言级对象序列化为 XML 的库。XML 和 XML-RPC 都需要定义应用程序级别的模式，例如，字段应该如何拼写，但都不需要定义任何额外的模式。许多人使用纯 XML 进行 RPC 调用。}

那么 XML-RPC 的附加值是什么？

4

5 回答 5

20

简短的回答是：这两种协议都可用于进行远程过程调用 (RPC)。两种协议都需要定义应用程序级别的模式，一般来说，两种协议都不需要任何额外的模式来定义如何序列化语言级别的对象（请参阅下面的一些详细信息）。

但是，XmlRpc 得到了库的更大支持，这些库使用语言的元编程（反射）特性将 XmlRpc 调用直接（嗯，永远不会 100% 直接）映射到语言级函数调用。对 XmlRpc 的支持比纯 XML 更好的原因是 (a) XmlRpc 支持者的市场营销的历史意外/结果，或者 (b) 下面列出的小翻译问题的总和使天平倾向于支持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 调用中自动序列化/反序列化语言级对象的库的创建，因此在以这种方式使用时它具有一些小优势：

  1. 使用纯 XML，具有单个成员的结构可能会与具有单个元素的数组混淆。

  2. XmlRpc 定义标准时间/日期格式。{虽然时区和纯时间或纯日期时间戳的处理是在应用程序级别定义的。}

  3. XmlRpc 允许您将参数传递给函数而不用命名它们；纯 XML RPC 调用要求您命名每个参数。

  4. XmlRpc 定义了一种标准方法来命名被调用的方法：“methodName”。使用纯 XML，根节点的标记通常用于此目的，但也可以使用替代方法。

  5. XmlRpc 定义了一个简单的类型系统：整数、字符串等。{请注意，对于静态类型语言，无论如何都必须将类型编译到目标对象中，因此是已知的，对于动态类型语言，通常 int 和 float 以及字符串可以互换使用；另请注意，XmlRpc 类型系统通常与可能具有多个整数类型的目标语言的类型系统匹配不佳，依此类推。}

  6. XmlRpc 库通常直接与 Http 库集成，而 Xml 序列化库 all(?) 要求应用程序程序员将 XML 文本传递给 Http 调用。在更现代的语言（如 Java/Python/C#）中，这是一件微不足道的事情，但对于 C++ 而言并非如此。

  7. 有一种“营销观念”，即 XML 描述“文档”，而 XmlRpc 是为过程调用而设计的。这种感觉是发送 XmlRpc 消息包含服务器执行某些操作的义务，而这种感觉对于纯 XML 并不那么强烈。

有些人会说“谁在乎——无论如何，使用递归下降/DOM/SAX 解析 XML 数据非常容易”，在这种情况下，上述大多数反对意见都是无关紧要的。

对于那些仍然喜欢自动创建本地语言对象的易用性的人来说，许多主要语言都有库，这些库可以自动将语言级对象序列化为 XML，而无需求助于 XmlRpc，例如：

.NET - Java - Python

XmlRpc 的成功可能源于自动创建语言级对象的库的可用性，而由于上述问题列表，这些库相对于它们的普通 XML 对应物具有优势。

XmlRpc 的缺点是：

  • 如问题中所述，它非常肥胖

  • 对纯 XML 的支持无处不在，通常不需要与大型 3rd 方库集成。无论如何，许多应用程序都需要将自动创建的对象转换为应用程序自己的对象。

  • 许多 XmlRpc 实现未能产生程序员所期望的那种真正的语言级对象，而是需要例如运行时字段查找或额外的语法。

  • 如果使用模式定义文档（例如 DTD 文件）来验证 RPC 调用，那么您将无法检查应用程序级模式 - DTD 文件只会告诉您“这是有效的 XmlRpc”。据我所知，没有任何标准方法可以使用基于 XmlRpc 的协议来定义应用程序级架构。

于 2009-11-14T03:40:09.853 回答
10

主要优点是有人已经为您制定了调用模式。这在具有反射的语言中特别有用，在这种语言中，您可以盲目地将复杂的结构传递给 RPC 调用，它会为您解决如何将其转换为 XML 的问题。例如，在 C++ 中，它的价值较低，您必须明确告诉 XML-RPC 库所有数据类型是什么。

你是对的，它并没有席卷世界。您在图书馆中发现的奇怪之处在于这种低水平的兴趣。我自己用过两个，都发现了两个错误。两者都是废弃软件，所以我无法将补丁发回，所以我有两者的私有补丁版本。叹。

于 2009-09-04T00:46:09.863 回答
3

简单：XML RPC 提供

  • 传递方法名称的标准方法
  • 打字系统。我经常使用电话号码，那些是字符串，而不是数字。
  • 返回错误的标准方法
  • 内省（几乎）免费

所有这些都基于标准 XML。

于 2010-10-19T07:55:20.093 回答
2

XmlRpc 的主要价值是您不必编写代码来生成和解析通过 HTTP 传递的 XML 文档，因为 XML-RPC 是用于表示函数调用的预定义 XML 模式。

即使库不是最佳的，也有一个额外的派生值，因为使用这种类型的系统允许您将远程接口定义为基本语言接口（C++ 抽象类、Java 接口等），这些接口独立于所使用的有线协议组件之间进行通信。

将接口定义与有线协议（XML-RPC、SOAP 等）分开允许您最终在适当的地方替换为替代协议。例如，在我们的系统中，我们的 Flex 前端使用Hessian公开服务， .NET 前端使用 SOAP（Hessian .Net 库有一个不允许的许可证）。

通过现在坚持使用 XML-RPC，您可以选择在将来切换到其他一些协议，而只需进行最少的重构。

于 2009-09-04T00:47:19.523 回答
1

让我从头开始，然后倒退：

3) 是的，您可以使用纯 XML（或纯字符串或二进制协议）进行远程过程调用。不同之处在于，XmlRpc 是一个定义明确的协议，具有许多可用的实现，这意味着 a) 您不必编写尽可能多的代码 b) 您可以与线路另一端的任何人进行互操作，而无需您或他们必须处理彼此的代码。XmlRpc 充当桥梁。

2) 我想说它无处不在:-) 我在 Java 中使用过 XmlRpc，因此无法评论 C++/PHP 实现问题。

1）是由于上述（3）。协议的冗长既是其互操作性的结果，也是其原因。

于 2009-09-04T00:45:49.130 回答