有没有充分的理由不将XML-RPC用于对象代理服务器/客户端架构？也许类似“没有它已经过时了，现在有X就可以了”。
为您提供更多详细信息：我想构建一个框架，允许标准化交互和许多小工具（例如命令行工具）之间的结果交换。如果有人想要集成另一个工具，她会为此目的编写一个包装器。包装器可以，例如。例如，将工具的STDOUT转换为架构可用的对象。
目前我正在考虑用Python编写概念验证服务器。之后它可以用C / C ++重写。为了确保客户端可以用尽可能多的语言编写，我想到了使用XML-RPC。 CORBA似乎过于臃肿，因为服务器不应该太复杂。
感谢您的建议和意见， 赖
答案 0 :(得分：5)
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仍然是最好的解决方案，这将是一个非常合理的结论，取决于你想要实现的目标。