XML-RPC Liberation
After working with SOAP on my most recent project, I’m happy to be working with
My new project is going to be architected in a similiar manner: loosely-coupled, service-oriented. Why not SOAP? Because their customers don’t write software, so we won’t need to externalize the API beyond the firewall. Internally, there are a number of languages used to build their software: Java web apps (using J2EE light), C/C++ command-line tools, and soon a little Ruby script or two (more if I have my way). So, we need language interoperability but not the overhead. We already designed the system to utilize a service-oriented approach with clear interfaces and a container to manage their lifecycle (Spring), so now we simply need a light wrapper that these other subsystems can call into – hello XML-RPC.
I must say, it is liberating to utilize a technology that doesn’t have spec after spec weighing it down. I’ve only found a few drawbacks, namely lack of industry tool support (industry ‘heart’ SOAP) and lack of arbitraty message types (only Vectors of Hashtables). Those drawbacks, at least for this project, are outweighed by fast performance, easy customization using
No RMI stubs and skeletons, no WS-* specs to teach developers trying to use or enhance the services, and no XML namespaces. Life is good.
Oh, and if you need something like Castor without the headaches, try
Popularity: 1% [