对象代理的XML-RPC

有没有什么理由不将XML-RPC用于对象代理服务器/客户端架构？也许类似"没有它已经过时,现在有X".

为了提供更多细节:我想构建一个框架,允许标准化交互和许多小工具(例如命令行工具)之间的结果交换.如果有人想要集成另一个工具,她会为此目的编写一个包装器.例如,包装器可以将工具的STDOUT转换为架构可用的对象.

目前我正在考虑用Python编写概念证明服务器.之后它可以用C/C++重写.为了确保客户端可以用尽可能多的语言编写,我想到了使用XML-RPC.CORBA似乎过于臃肿,因为服务器不应该太复杂.

感谢您的建议和意见,Rainer

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仍然是最好的解决方案,这将是一个非常合理的结论,取决于你想要实现的目标.