« The Java ceiling | Main | Strassman v Microsoft (but it's all in the graph) »

XML-RPC case study

0xDECAFBAD: XML-RPC, a mini case study

Interesting contrast to the effbot's.

It's good to see reasoned assessments of these technologies in the field. Discussions about SOAP|REST|XML-RPC tend to degenerate.

Paul Prescod goes into the limitations of XML-RPC in more detail in response to this study. After my experience using XML-RPC my thoughts are as follows:

  • XML-RPC is tied to HTTP. This more than anything else, makes it architecturally distinct from SOAP.

  • A lazy way to send lists and dictionaries around. This is ok if you own both endpoints or just need to send list and dictionaries. If you don't, or have more complex data structures, you might want to look elsewhere.

  • Very quick to setup. SOAP toolkits do not come close. In Propylon we've used XML-RPC in the past to quickly hook up two machines that were part of a messaging system. And I do mean quickly- it took a few hours to get a Python endpoint pushing XML messages from a BizTalk framework into J2EE. I suspect this is the key appeal of XML-RPC. If your data is a dictionary say, it's probably quicker to install XML-RPC that use HTTP POST and write serializers for that dictionary structure.

  • No Unicode. IMO this is the second most brain damaged aspect of XML-RPC. But since character encoding is such an alround pita, it's understandable to see a drop-down to ASCII, if not really forgivable. At least with a Unicode base you have a fighting chance of getting in and of Latin-1; with an ASCII baseline you're stuffed.

  • Extensibility, which Paul takes issue with, wasn't really a problem for me. You only have to read the spec to see that's not what is was designed for. In other words don't use XML-RPC for communications whose form you think is unstable or liable to change over time.

  • XML payloads might end up being base 64'd (if you're not sending the specified structures around). This is most brain damaged aspect of XML-RPC. I imagine this was done to avoid problems with namespaces or because no-one thought about using XML-RPC to send documents around, but it could have be solved by using Java style packagespace names for the XML-RPC elements and a looser spec. Note that SOAP has to deal with this problem with namespaces too as does any XML envelope format. The answer of course is to use a MIME carrier format as SwA, BEEP, SMTP or HTTP does - of course then maybe you're wondering (like me) what you needed an XML envelope format architected on namespaces for in the first place.

Overall I'd say XML-RPC has the properties of something like a neat Perl hack. It's good for small quick things and prototyping, but not something you'd extend or manage, or use where requirements are unstable. But if you're weren't sure about which way to go the web services kerfuffle, and the above points don't affect you XML-RPC is a good fence to sit on.

December 1, 2002 05:47 PM