What is the benefit of XML-RPC over plain XML?

Question

My company has been using XML-RPC for a while, but lately I'm wondering what the benefit is of XML-RPC compared to plain XML. Firstly, it's horrible "obese", consider:

<struct>
    <member>
        <name>ROOM_ID</name>
        <value>
            <int>1</int>
        </value>
    </member>

    <member>
        <name>CODE</name>
        <value>
            <string>MR-101</string>
        </value>
    </member>

    <member>
        <name>NAME</name>
        <value>
            <string>Math Room</string>
        </value>
    </member>

    <member>
        <name>CAPACITY</name>
        <value>
            <int>30</int>
        </value>
    </member>
</struct>

Compared to this:

<room><ROOM_ID>1</ROOM_ID><CODE>MR-101</CODE>
<NAME>Math Room</NAME><CAPACITY>30</CAPACITY></room>

Or even this:

<room ROOM_ID=1 CODE=MR-101 NAME=”Math Room” CAPACITY=30 />

Secondly, XML-RPC seems fairly widespread but not quite ubiquitous and I'm not that impressed with the support for it in C++ and PHP. I've had problems with all the libraries that I tried in both languages.

Thirdly, it seems to me that I could make remote procedure calls with plain XML as easily as with XML-RPC. {(9/9/2009): Every language has libraries for serialising language-level objects into XML. Both XML and XML-RPC require application-level schemas to be defined, for example, how the fields should be spelt, but neither needs any additional schema to be defined. Many people make RPC calls with plain XML.}

So what is the value-add of XML-RPC?

Answer 1

The short answer is: Both protocols can be used to make remote procedure calls (RPC). Both protocols require an application-level schema to be defined, and generally speaking, neither protocol requires any additional schema for defining how to serialise language-level objects (see below for some details).

However, XmlRpc enjoys greater support from libraries which use meta-programming (reflection) features of language to map XmlRpc calls, directly (well, never 100% directly) to language level function calls. The reason there is better support for XmlRpc than plain XML is either (a) a historical accident/result of marketing on the part of the XmlRpc proponents, or (b) the sum of the minor translation issues listed below tip the scales in favour of XmlRpc.

On the other hand, XmlRpc suffers from 2 main disadvantages: (1) it requires approximately 4 times as much bandwidth, and (2) it subverts the intent of XML schema-validation tools: every packet will simply be stamped as "yes, this is valid XmlRpc", regardless of spelling mistakes and omissions in application-level fields.

The long answer:

Contrary to popular belief, you don't need a standard to define how to encode language level objects in plain XML - there is generally just one "sensible" way (provided the application level schema defines whether you use XML attributes or not), e.g.:

class Room {
    int id=1;
    String code="MR-101";
    String name="Maths room";
    int capacity=30;
};

encoded as:

<Room>
    <id>1</id>
    <code>MR-101</code>
    <name>Maths room</name>
    <capacity>30</capacity>
</Room>

XmlRpc was specifically designed to facilitate the creation of libraries which automatically serialise/unserialise language-level objects in RPC calls, and as such it has some minor advantages when used in this way:

1. With plain XML, it's possible for a struct with a single member to be confused with an array with a single element.

2. XmlRpc defines a standard time/date format. {Although treatment of timezones and pure time or pure date timestamps is defined at the application level.}

3. XmlRpc lets you pass arguments to the function without naming them; Plain XML RPC calls require that you name each argument.

4. XmlRpc defines a standard way to name the method being called: "methodName". With Plain XML, the tag of the root node would typically be used for this purpose, although alternatives are possible.

5. XmlRpc defines a simple type system: integers, strings, and so on. {Note that with statically typed languages, the types have to be compiled into the destination object anyway, and therefore are known, and with dynamically typed languages, often int's and float's and strings can be used interchangeably; note also that the XmlRpc type system would typically be a poor match for the type system of the destination language which may have multiple integer types, and so on.}

6. XmlRpc libraries generally integrate directly with an Http library, whereas Xml serialisation libraries all(?) require the application programmer to pass the XML text to the Http call. In more modern languages such as Java/Python/C#, this is a trivial matter, but not so for e.g. C++.

7. There is a "marketing perception" that XML describes "documents", whereas XmlRpc is designed for procedure calls. The perception is that sending an XmlRpc message contains an obligation for the server to perform some action, whereas this perception is not as strong with plain XML.

Some people will say "who cares - parsing XML data using recursive descent/DOM/SAX is pretty easy anyway", in which case most of the above objections are irrelevant.

For those who still prefer the ease of use of getting native language objects created automatically, many major languages have libraries which automatically serialise language-level objects into XML without resorting to XmlRpc, e.g.:

.NET - Java - Python

It may be that the success of XmlRpc, such as it is, stems from the availability of the libraries which automatically create language-level objects, and in turn these libraries have an advantage over their plain XML counterparts due to the list of issues above.

Disadvantages of XmlRpc are:

• As mentioned in the question, it is horribly obese

• Support for plain XML is ubiquitous and usually does not require integration with large 3rd party libraries. Many applications require a conversion of the automatically created objects to the application's own objects anyway.

• Many XmlRpc implementations fail to produce true language-level objects of the sort programmers would expect and instead require e.g. run-time lookups of fields or extra syntax.

• If a schema definition document is used to validate the RPC calls, such as a DTD file, then you lose the ability to check the application-level schema - the DTD file will simply tell you that "this is valid XmlRpc". There is not to my knowledge any standard way to define an application-level schema with an XmlRpc based protocol.

Answer 2

The primary advantage is that someone's already worked out the calling schema for you. This is especially helpful in languages with reflection, where you can just blindly pass, say, a complicated structure to the RPC call, and it will work out how to translate that into XML for you. It's less valuable in, say, C++, where you're having to tell the XML-RPC library what all the data types are explicitly.

You're right that it hasn't taken the world by storm. The oddities you're finding in the libraries are due to this low level of interest. I've used two myself, and found bugs in both. And both were abandonware, so there's nowhere I could send patches back to, so I have private patched versions of both. Sigh.

Answer 3

Easy: XML RPC provides

• a standard way to pass the method name
• a typing system. I work with phone numbers quite often, those are strings, NOT numbers.
• a standard way to return errors
• introspection (almost) for free

All this over standard XML.

Answer 4

The primary value of XmlRpc is that you don't have to write the code to generate and parse the XML documents being passed over HTTP, since XML-RPC is a predefined XML Schema for representing function calls.

Even with less than optimal libraries, there is an additional derived value since using this type of system allows you to define your remote interfaces as basic language interfaces (C++ Abstract Class, Java interfaces, etc.), that are independent of the wire protocol used to communicate between components.

Separating the interface definitions from the wire protocol (XML-RPC, SOAP, etc.) allows you to eventually substitute in alternate protocols where appropriate. For example, in our system, we have services that are exposed using Hessian for our Flex front ends, and SOAP for our .NET front ends (the Hessian .Net library has a disallowed license).

By sticking with XML-RPC now, you have the option of switching to some other protocol in the future with minimal amounts of refactoring.