是否有充分的理由不将XML-RPC用于对象代理服务器/客户端体系结构？也许类似“没有，它已经过时了，现在有X”。
为了给您更多细节：我想建立一个框架，该框架允许标准化的交互以及许多小工具（例如命令行工具）之间的结果交换。万一有人要集成另一个工具，她为此编写了一个包装器。包装可以，例如。例如，将工具的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仍然是最佳的解决方案，根据您要实现的目标，这将是一个完全合理的结论。
关于python - 用于对象代理的XML-RPC，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4022311/