XML-RPC is a very simple specification that details how to make remote procedure calls over a http connection
A program making an xml-rpc call will open a http connection to the server providing the xml-rpc service, send an xml document describing the procedure call and the parameters being passed, and then receive an xml document as a reply. The use of http as the transport mechanism means that existing code can be used for both client and server sides. XML documents can be parsed using the usual tools, and so the only part that requires much effor when implementing xml-rpc is the marshaling of language specific data structures into and out of the xml-rpc encoded format. An xml-rpc server can use an existing http server library, or even be implemented as a simple cgi allowing any web server (e.g. Apache) to be used for the http transport.
This ease of construction of xml-rpc software has led to the creation of a large number of implementations in many languages, which means that your desire to provide or make use of xml-rpc services does not have to control your language choice. The simplicity with which you can use xml-rpc is probably best described in a short python example:
#!/usr/local/bin/python
import xmlrpclib
remoteServer = xmlrpclib.Server ('http://www.oreillynet.com/meerkat/xml-rpc/server.php');
print "All categories:"
categories = remoteServer.meerkat.getCategories()
for category in categories:
print category
As you can see from this example (which returns a list of categories provided by the meerkat service) it takes very few lines of code to make an xml-rpc call, and it is almost transparent that you are going over a network connection. This example shows a couple of other useful points:
While making xml-rpc calls and providing xml-rpc services is very easy, it is not in fact perfectly transparent. When making a call you have to bear in mind issues such as what happens if the network is down or the server crashes part way through serving your request. On the other side of the coin when writing a server you have to consider what happens if a client disappears part way through a session, will any server side data be left in a consistent state? Then there is the issue of discovering services, security, load-balancing, and making xml-rpc available to statically linked languages like C. Currently making xml-rpc calls in C and C++ is more cumbersome because you have to setup all the arguments and the procedure name manually and pass them to an appropriate function to make the xml-rpc call.
These issues have got many solutions available from previous implementations of RPC and distributed computing. Producing a description of an RPC procedure in an Interface Definition Language (IDL) allows static languages to more seamlessly make rpc calls. Versioning of interfaces allow for the server side to be upgraded without breaking old clients. If http is your transport layer then you could instead use https to increase the security of your rpc calls. There are currently many efforts underway to bring these solutions to xml-rpc and it's big brother soap. The result of these efforts will eventually lead to the sort of mature solutions that exist for corba and COM, although hopefully without all the complexity.
In my mind XML-RPC has two really good uses:
When trying to get two systems to integrate and talk to one another you invariably have to write programs that will interface with each systems API. Sometimes this is done on the incredibly crude level of writing log files and parsing these files. Sometimes it means talking a propriety protocol over TCP sockets. Often the only solution is to write programs in the same language as the systems were originally written in so that library calls can be made to the API. In this case you have to invent your own protocol for communicating between the two wrappers!
Many systems are now providing XML based interfaces onto their APIs. The XML documents will be passed around either via http or raw TCP sockets, and there will be a different DTD for each system that you come across. While it is preferable to any of the methods above it still takes considerable time to implement clients for the systems, and even longer to write the servers for them. It is in situations like this that XML-RPC suddenly shouts out as an obvious solution. With XML-RPC you can offer people a simple API built of procedures that they can call from any language. If they don't trust or can not find available any XML-RPC implementations they can still construct the XML documents themselves and parse the results because the specification is so simple.
This use of XML-RPC in this context does not receive much press attention, being over shadowed by "web services" and Microsoft's .NET initiative. This is a shame because XML-RPC is probably one of the best ways of exposing an API onto your system. Only if you require guaranteed delivery or application bus functionality do you need the more heavy weight solutions. If you are considering offering an XML based interface to your system, stop and take a look at XML-RPC (after reading my major complaint about XML-RPC further on).
The publishing of information via XML-RPC is closely related to web services. Personally I think that web services as often considered at the moment will not last - I don't want my spell checker on a server somewhere - I want it on my local machine where I can get at it! The sorts of web service that do take off will be ones where essentially you are using XML-RPC or SOAP to interface 2 systems as discussed above. It will allow for things like direct ordering of courier or travel services from your corporate web site/order management system without a huge investment in coding and design.
The sort of information that will be published via XML-RPC will be dynamic. Things like headline summaries and aggregation (as done by meerkat), weather reports, stock quotes, and other such dynamic rapidly changing information. XML-RPC allows applications to pull in up-to-date information for display to the user or for programmatic use in a very simple way. The travel web site can show the temperature and weather conditions in the area you are reading about, without having to setup complex systems to link in the live sources.
Several people have pointed out areas where XML-RPC could be improved, but only one of them is really a show stopper. Despite using XML as it's encoding language the XML-RPC Specification defines strings as ASCII, rather than using the encoding that the XML document is encoded as. There has been no attempt to fix this problem in the specification, and so most implementations just ignore this restriction to enable none ASCII strings to be used.
The full list of my published Software
Made with PubTal 3.5
Copyright 2021 Colin StewartEmail: colin at owlfish.com