XML-RPC Liberation

After working with SOAP on my most recent project, I’m happy to be working with XML-RPC this time. Why the switch? Well, the last client was driven by several factors to select SOAP, one of which was the requirements for B2B. They had several potential partners that needed to integrate, and those future partners liked SOAP.

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 Apache’s library, and large cross-language support.

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 XStream. It is how all Java frameworks should be: no config files, no JavaBean-driven empty constructor/accessor,/mutator requirements, and fast. It Just Works (TM).