As the canon of Web service-related specifications begins to resemble the U.S. tax code, it’s helpful to remember that you have the original XML communications protocol to fall back on when you want to get a service up and running quickly. XML-RPC (remote procedure call) was developed in the late 1990s and was the genesis of what later evolved into SOAP. But while its specification stayed put as SOAP, WSDL and the other protocols began to expand. I’m talking about a specification that’s still in use, but that hasn’t been altered since 1999.

The specification
You can read the details on this specification on the XML-RPC Specification Web site. Instead of rehashing the details, let’s look at the sample real-world request and response messages in Listing A and see what they can tell us about the specification.

One of the first things you might notice from the samples is that there are absolutely no attributes in the XML. Only elements are used. And you’ll quickly figure out that every request message is inside a <methodCall> element, with the method name in a child <methodName> element. Similarly, every response message is inside a <methodResponse> element.

Beyond that, you can see that <value> gets passed inside <param> elements, and the type of value can be specified using the data type elements <int>, <double>, and <string>, just to name a few. For passing more data, such as when you have a variable number of parameters or when you want your parameter to be a compound structure, you can see from the example that XML-RPC also supports <array> and <struct> data types.

What about namespaces? Multiple actors? Routing instructions to different endpoints? Protocol bindings? No such things. XML-RPC is a point A to point B specification that operates using one delivery mechanism: HTTP POST. There is just one method call per request message and one return value, which can be an array or structure to send multiple values, per response message.

Server and client are the only actors in the show, and they need to know up front what they are doing. There’s no UDDI available to find things you don’t already know about, and there’s no WSDL available to describe things you don’t already understand.

How much of a hindrance is this for you? Probably not much. The majority of things you plan to accomplish using Web services can and will be clearly defined with your customers and other business partners. Its lack of concern for metadata might not make XML-RPC useful to the evolving semantic Web, but it’s plenty useful for what you’re doing today.

Implementations
Though such a simple specification makes it easy to read and hand-code your messages, you won’t want to be doing that day in, day out. Luckily, just about every active programming language has an XML-RPC implementation available somewhere for free. The short samples here are in Java, using Apache’s XML-RPC package, but links to implementations for AppleScript, ASP, Delphi, Eiffel, Perl, Python, .NET, and many others can be found at the XML-RPC site.

An XML-RPC implementation for your language will help you in two ways:

  • ·        It shields you from the HTTP and takes care of all the networking aspects of the message calls and responses. Your code can just wait for return values or catch exceptions to determine if network activity is succeeding.
  • ·        It allows you to define parameters, make method calls, and return values using the syntax and data types that you’re already accustomed to in your language of choice. The XML-RPC implementation handles the details of how all of that gets mapped to XML messages.

Listing B performs the same sample method calls as the verbose XML in Listing A, but accomplishes this in just a few lines of Java. Behind the scenes, of course, the Apache XML-RPC implementation is working hard, doing things such as interacting with the Java.net classes and parsing XML messages. But as far as the Java programmer who uses the implementation is concerned, he or she is just making a few typical method calls.

Serving up XML-RPC
These examples have concentrated on client XML-RPC calls, but what about creating XML-RPC servers? As you’d expect, servers get a bit more complicated, but not because of anything inherent in XML-RPC. It’s the usual network overhead that makes it more complicated with things such as polling the TCP port, responding to multiple requests, etc. Third-party implementations can help with that as well.

The Apache implementation, for example, includes its own mini Web server. You basically just tell it what port to listen on and give it an instance of some class of yours (i.e., a handler) that it should use when it receives a request. When a request comes in, it looks at the <methodName> and then tries to find a method of the same name in the handler you gave it. It maps the message’s <param> to Java equivalents that your handler method expects. It then calls your handler method, which returns the response message as an XML string, or raises an exception if something is wrong. If you raise an exception, the Apache Web server class will catch it and send a special <fault> response back to the client.

Simple stability
You should consider building an XML-RPC Web service solution if your project has these characteristics:

  • ·        The users are a known community—such as clients or other business partners—rather than the general public, which would rely on discovery mechanisms and loads of metadata to become familiar with the service.
  • ·        The data being passed around is fairly simple. This doesn’t mean it has to be scalar (or even plain text, since a <base64> data type is supported), but XML-RPC is probably not the right choice if elaborate and marked-up documents are being passed around.
  • ·        You don’t need requests to pass through multiple servers. If any kind of routing of messages comes into play, and you want your handling of the routing to be based on standards, use SOAP.

XML-RPC is a simple, stable, and well-understood specification. It’s not a moving target like so many other Web service specifications. It also has longevity, because the only things that it depends on are technologies such as HTTP and XML, and basic programming constructs such as arrays, structures, and scalars. None of those things is going away any time soon. And since everything related to XML-RPC is freely available and downloadable, you can have a Web service up and running in a single afternoon.