Home/ Questions/Q 3303454
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T20:57:31+00:00

is there any good reason not to use XML-RPC for an object-broker server/client architecture?

  • 0

is there any good reason not to use XML-RPC for an object-broker server/client architecture? Maybe something like “no it’s already outfashioned, there is X for that now”.

To give you more details: I want to build a framework which allows for standardized interaction and the exchange of results between many little tools (e. g. command-line tools). In case someone wants to integrate another tool she writes a wrapper for that purpose. The wrapper could, e. g., convert the STDOUT of a tool into objects usable by the architecture.

Currently I’m thinking of writing the proof-of-concept server in Python. Later it could be rewritten in C/C++. Just to make sure clients can be written in as many languages as possible I thought of using XML-RPC. CORBA seems to be too bloated for that purpose, since the server shouldn’t be too complex.

Thanks for your advice and opinions,
Rainer

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    XML-RPC has a lot going for it. It’s simple to create and to consume, easy to understand and easy to code for.

    I’d say avoid SOAP and CORBA like the plague. They are way too complex, and with SOAP you have endless problems because only implementations from single vendors tend to interact nicely – probably because the complexity of the standard leads to varying interpretations.

    You may want to consider a RESTful architecture. REST and XML-RPC cannot be directly compared. XML-RPC is a specific implementation of RPC, and REST is an architectural style. REST does not mandate anything much – it’s more a style of approach with a bunch of conventions and suggestions. REST can look a lot like XML-RPC, but it doesn’t have to.

    Have a look at http://en.wikipedia.org/wiki/Representational_State_Transfer and some of the externally linked articles.

    One of the goals of REST is that by creating a stateless interface over HTTP, you allow the use of standard caching mechanisms and load balancing mechanisms without having to invent new ways of doing what has already been well solved by HTTP.

    Having read about REST, which hopefully is an interesting read, you may decide that for your project XML-RPC is still the best solution, which would be a perfectly reasonable conclusion depending on what exactly you are trying to achieve.

    • 0