by kate rhodes
Within the world of XML there are two main ways to implement a Remote Procedure Call (RPC). XML-RPC and SOAP. This document will explore the differences between these two methods in order to help you decide which is best suited to your needs.
"...a spec ( http://www.xmlrpc.com/spec ) and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet.
It's remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned." - xmlrpc.com
"We wanted a clean, extensible format that's very simple. It should be possible for an HTML coder to be able to look at a file containing an XML-RPC procedure call, understand what it's doing, and be able to modify it and have it work on the first or second try... We also wanted it to be an easy to implement protocol that could quickly be adapted to run in other environments or on other operating systems." - xmlrpc.com
"SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses." - the SOAP spec.
SOAP makes extensive use of namespacing and attribute specification tags in almost every element of a message. For example when mixing data types within an array you have to set the SOAP-ENC:arrayType to indicate mixed data types within the array in addition to specifying the type of each element of the array.
Weighing in at 40 pages the SOAP spec is complex and filled with little gems like, "Using SOAP for RPC is orthogonal to the SOAP protocol binding." If you ask me, it isn't even remotely something I would call "lightweight" and they threw out the most important feature of XML-RPC, its ease of use.
Contrary to popular belief, SOAP has not been ratified by the W3C. As of this writing it is just a submission, which, essentially, means they thought it was nifty enough to start a discussion about it.
XML-RPC arrays define an anonymous grouping of elements with no limitation mixing data types like integers and strings within the same array. "An <array> contains a single <data> element, which can contain any number of <value>s."
An accessor "...that can polymorphically access values of several types, each type being available at run time. A polymorphic accessor instance MUST contain an "xsi:type" attribute that describes the type of the actual value."
Ex. <cost xsi:type="xsd:float">29.95</cost>
Based on the "XML Schema Part 2: Datatypes" ( http://www.w3.org/TR/xmlschema-2/ ), which is still just a recommendation, a SOAP enumeration is "...a list of distinct values appropriate to the base type." It is supported for all simple types except boolean.
SOAP's greatest feature is its ability to step past XML-RPC's limitations and customize every portion of the message. This ability to customize allows developers to describe exactly what they want within their message. The downside of this is that the more you customize a message the more work it will take to make a foreign system do anything beyond simply parsing it.
SOAPs two biggest developers are Microsoft and IBM. Microsoft has incorporated SOAP into it's latest OS and Visual Studio. As usual though, MS has decided that they don't need to adhere to the whole spec. In their SOAP for Java SDK they modify the namespace (which breaks some other implementations), use a limited combination of 1.0 and 1.1 fault codes (and improperly document it), and include many serious bugs. IBM seems to have gotten almost everything right in their implementation.
XML-RPC calls methods via its methodName property which "may only contain identifier characters, upper and lower-case A-Z, the numeric characters, 0-9, underscore, dot, colon and slash." For most purposes this is just fine, however it makes it particularly difficult when you need to pass an object as an argument.
The structs (hashes) and arrays are always anonymous. When passing multiple structs or arrays programmers need to rely on the order of the parameters (<param>) they are contained in to differentiate between each struct or array. This isn't a significant problem but there are cases when being able to name your structs and arrays would be nice.
As noted above, simplicity is also XML-RPC's greatest limitation. Although most all of your RPC needs can be accomplished with it, there are some things that you just can't do without bending over backwards, like passing an object as an argument to a function, or specifying which portion of a receiving application the message is intended for.
Currently SOAP 1.1 is a submission to the W3C ( http://www.w3.org ). This means it is not an official standard and its specifications can, and almost assuredly will, change at any time. There are a lot of cooks in the kitchen right now.
Last updated in May the SOAP spec is filled with mistakes and contradictions and points to other specs which are themselves moving targets. According to Dave Winer, one of the spec's authors, Microsoft and IBM have taken it upon themselves to add in the WSDL ( http://www.w3.org/TR/wsdl ) layer without consulting the other authors. This doesn't bode well for developers who need something they can count on remaining unchanged, or almost unchanged, for the forseeable future. Any current SOAP implementation may be incompatible with future revisions of the spec, although it should be noted that SOAP is far enough along that most of its spec should remain essentially the same.
When you get right down to it XML-RPC is about simple, easy to understand, requests and responses. It is a lowest common denominator form of communication that allows you to get almost any job done with a minimum amount of complexity. SOAP, on the other hand, is designed for transferring far more complex sets of information. It requires profuse attribute specification tags, namespaces, and other complexities, to describe exactly what is being sent. This has its advantages and disadvantages. SOAP involves significantly more overhead but adds much more information about what is being sent. If you require complex user defined data types and the ability to have each message define how it should be processed then SOAP is a better solution than XML-RPC (be sure to check out language specific solutions to this problem like java's RMI ( http://java.sun.com/products/jdk/rmi/ )). But, if standard data types and simple method calls are all you need then XML-RPC will give you a faster app with far fewer headaches.
"Make sure you don't use and overly complex package to address what may be your rather simple needs" -Brett McLaughlin ( email@example.com )