是否有充分的理由不将 XML-RPC 用于对象代理服务器/客户端架构？也许像“不，它已经过时了，现在有 X”。
给你更多细节：我想建立一个框架，允许标准化交互和许多小工具（例如命令行工具）之间的结果交换。如果有人想集成另一个工具，她会为此编写一个包装器。包装器可以，例如。 g.，将工具的 STDOUT 转换为架构可用的对象。
目前我正在考虑用 Python 编写概念验证服务器。后来它可以用 C/C++ 重写。为了确保客户端可以用尽可能多的语言编写，我想到了使用 XML-RPC。为此目的，CORBA 似乎过于臃肿，因为服务器不应该太复杂。
感谢您的建议和意见， 雷纳
【问题讨论】：
XML-RPC 有很多用途。它易于创建和使用，易于理解且易于编码。
我会说像瘟疫一样避免使用 SOAP 和 CORBA。它们太复杂了，而使用 SOAP，您会遇到无穷无尽的问题，因为只有来自单一供应商的实现才能很好地交互 - 可能是因为标准的复杂性导致了不同的解释。
您可能需要考虑 RESTful 架构。 REST 和 XML-RPC 不能直接比较。 XML-RPC 是 RPC 的具体实现，REST 是一种架构风格。 REST 并没有太多的要求——它更像是一种带有一堆约定和建议的方法。 REST 看起来很像 XML-RPC，但并非必须如此。
查看http://en.wikipedia.org/wiki/Representational_State_Transfer 和一些外部链接的文章。
REST 的一个目标是，通过在 HTTP 上创建无状态接口，您可以使用标准缓存机制和负载平衡机制，而无需发明新的方法来完成 HTTP 已经很好解决的问题。
阅读了有关 REST 的文章（希望这本书很有趣），您可能会认为对于您的项目而言，XML-RPC 仍然是最佳解决方案，这将是一个完全合理的结论，具体取决于您想要实现的目标。
【讨论】：