An Interview with Simon St.Laurent, Joe Johnston, and
Edd Dumbill
by Bruce Stewart
06/11/2001
XML-RPC is a simple yet powerful system built on XML and HTTP that lets
developers connect programs running on different computers with a
minimum of fuss. With XML-RPC, developers can provide access to functionality
without having to worry about the system on the other end, so it becomes easy
to create Web services.
Simon St.Laurent, Joe Johnston, and Edd Dumbill have just finished writing
Programming Web Services
with XML-RPC, which will be released later this month. Oreilly.com's Bruce Stewart recently talked to all three authors about Web services, XML-RPC, and the benefits and limitations of this technology.
Stewart:
Web services seem to be on everyone's radar screen these days, but
there is some confusion over what exactly is meant by
the term. What are some good examples of Web services?
St.Laurent:
Web services is a difficult term for me. A lot of the marketing around Web
services suggests that this is an enhancement of the Web when in many ways
it's really about making Web infrastructures provide services programmers
can use to connect programs.
In the case of XML-RPC, it lets developers build APIs on method calls, which
are transmitted using Web protocols. Reusing the Web makes it really easy for
a first wave of programmers to build standardized interfaces for handling
XML-RPC, letting the rest of us walk up to APIs exposed by XML-RPC and use
them like any other API. There are all kinds of things you can do once you
have a facility for exposing APIs to other computers on a network--I'm not
sure there's a canonical "good example."
Dumbill:
Web services turns out to be a misleading label in a sense. In the
short to medium term, the big wins from Web services are in more
predictable environments than the World Wide Web. Application
integration and controlled external relationships are where XML-RPC and
SOAP are finding most employment--and yielding most benefit--right now.
On the World Wide Web itself the scenario is a little less well
defined. The technology turns out to be the easy bit--there are many
business-process and legal issues to figure out before we see Web
services being used on a wide scale over the Internet.
Johnston:
Web services allow software robots to easily talk to each other
and those robots can be written in almost any programming language.
Web services can be used to create gateways to proprietary applications,
for example, twiddling an MS Access database from a Linux Perl script,
or even to building middleware that allows existing applications to scale
better. Web services are interesting because they greatly facilitate
engineering applications with multiple languages, which is becoming the
norm in Web development.
Stewart:
What is XML-RPC, and how does it fit into the Web services model?
Dumbill:
XML-RPC is a protocol that standardizes making calls between
applications over a network. It uses the ubiquitous and well understood
standards XML and HTTP to take the fuss out of implementation. It adds
the least possible overhead to implement basic data types.
Because of its simple-to-understand nature, XML-RPC is broadly
implemented--there are over 34 implementations at the last count. If you want
to make a Web site or a database application expose raw data or functionality
then it's a great place to start.
Johnston:
XML-RPC is a simple, procedural protocol that allows a program
on one machine to call a procedure on another. Although a simple protocol,
XML-RPC is robust enough to handle very complex data structures and a
fairly rich set of data types. Most importantly, XML-RPC is simple to
use and simple to debug.
Stewart:
Who is your book, Programming Web Services with XML-RPC, written for?
What skill level, or knowledge of XML is presumed?
St.Laurent:
We wrote Programming Web Services with XML-RPC with a few different
categories of developer in mind. The book includes appendixes explaining
the limited amount of XML and HTTP developers should have available if they
want to implement the XML-RPC protocol itself, or debug XML-RPC
messages. There's no need for developers who want to use XML-RPC to
understand XML in depth, and they may even be able to work with XML-RPC
exclusively through one or more of the implementations we discuss in our book. Developers really need a basic background in networking, along
with an understanding of one or more of the languages used for the
implementations in the book.
Johnston:
If the reader is just learning how to program, this book will not
be particularly accessible.
Stewart:
It sounds like XML-RPC is just a new way of combining the existing
technologies of RPC, XML, and HTTP. What is it about this combination that
makes it especially useful or powerful?
St.Laurent:
XML and HTTP make it easy to build an infrastructure cheaply and openly,
while RPC is a pretty familiar technique to programmers. Reusing XML and
HTTP makes it easy to add XML-RPC to existing networks, while the RPC
approach makes it easy for programmers to figure out how to use it.
Check out XML.com on the O'Reilly
Network for all the latest developments in XML.
Johnston:
There are two good reasons why XML-RPC is worth learning. The first
is that the protocol is done. There is no huge bureaucracy trying to define
a general-purpose framework for delivering arbitrary messages in XML over
any high-level network-application protocol. So, XML-RPC is open for business
today. The other important strength of XML-RPC is the number of languages
that have XML-RPC libraries. If people are using a language, it probably has
an XML-RPC implementation. Check out the XML-RPC Home Page for details.
Stewart:
In some ways, XML-RPC's reliance on HTTP seems like both a blessing and
a curse. Can you discuss the trade-offs involved with using the HTTP
protocol?
St.Laurent:
Well, the IETF isn't very
happy about HTTP reuse for these kinds of projects. HTTP was built to let
client browsers retrieve Web pages from servers, and that usage has given
network administrators an expectation that HTTP is relatively safe. Now HTTP
traffic may be carrying a very different kind of payload, and there's
potential for trouble...but the next generation of firewalls will probably
catch up anyway.
HTTP isn't especially efficient for these kinds of exchanges either, but it
works well enough if time isn't critical.
Dumbill:
HTTP is a stateless, connectionless, protocol. This places some
restrictions on what you can do, and means that RPC calls to
coarser-grained functions will work a lot better than fine-grained
functionality because of the roundtrip overhead.
Johnston:
HTTP is sort of a slow protocol compared with doing direct socket
hockey with UPD or TCP. However, HTTP is well understood and there is a lot of
infrastructure that supports good ol' port 80 traffic. Also, it's nice
to be able to let Apache do the heavy network lifting, so that your
little XML-RPC server doesn't have to.
Stewart:
What are the limitations of XML-RPC? Is XML-RPC only applicable to
client-server applications, or can it also support peer-to-peer
communication?
St.Laurent:
XML-RPC builds on top of HTTP's client-server framework, but machines can
always be both clients and servers in a peer-to-peer framework. It's
pretty easy to do both, in many cases, though you can fall back to
client-server if necessary.
Dumbill:
You might find XML-RPC limited if you want to use it to create a
more fully featured, distributed-computing environment, as it lacks
various things such as IDL and service-discovery features. But that's
not really where XML-RPC is aimed at in the first place. You can do an
incredible amount before you get to the point of needing all the
machinery of full-fledged distributed computing.
Johnston:
Heck, it's just software. It can do anything you want, with enough
spit and will.
Stewart:
What is the relationship between XML-RPC and SOAP? Do you think SOAP
will eventually replace XML-RPC?
St.Laurent:
I think a fair number of people are actually turning back from SOAP and
taking a closer look at XML-RPC. It does a lot less, but XML-RPC does it a
lot simpler. I tend to think that XML-RPC is great for the simple function
calls with parameters, and that some kind of generic XML messaging makes a
lot more sense for complex operations. SOAP feels too complex to me for
the kind of functionality it provides.
Johnston:
SOAP is an electric toothbrush. Some people have the kind of
poor dental hygiene that requires the mechanical advantage these
brushes provide. Many of us can make due with ordinary toothbrushes.
It's good to have options.
Stewart:
Are there scalability issues with applications built on XML-RPC?
St.Laurent:
Certainly! HTTP isn't renowned as a highly efficient protocol, and
there's no inherent limit to how long a server can take to process an
XML-RPC request. Developers who want to use XML-RPC should remember that
calls across networks are almost always slower than calls within computers,
and that there's no guaranteed response time on XML-RPC requests.
Johnston:
XML doesn't stream. That is to say, XML parsers need the whole XML
document (or at least see the closing tag of the current element) before
they can do anything. This means smaller XML documents work better. Also,
XML-RPC is transmitted, like normal Web traffic, as clear text. Sensitive
payloads will need to be encrypted.
St.Laurent:
Actually, you could write an XML-RPC processor that did process things
as they came in, and rolled them back if there was a problem. I just don't
think there's enough benefit in doing that at this point.
Stewart:
How about security issues? How secure is XML-RPC?
Dumbill:
XML-RPC, like SOAP, has no security features of its own. As it uses
HTTP, you can use SSL (Secure Socket Layer) in the same way you would for
secure Web page transactions (Not all XML-RPC implementations provide this
functionality.). Additionally, you can add implement whatever security
mechanisms you desire as part of your XML-RPC API.
So, in short, it's as secure as browsing SSL-enabled Web sites.
Stewart:
Is the main purpose for using HTTP as the transport just a way to make
it traverse firewalls or proxy servers?
St.Laurent:
In my experience, that's more or less a side effect that's sometimes
beneficial and sometimes not. XML-RPC's reuse of HTTP makes it a lot
easier to establish communications between systems using prefabricated and
well-understood parts. While writing to sockets might be easier or purer,
it's a lot easier to use GET and POST in existing frameworks and Web
servers.
Stewart:
Doesn't the ability of XML-RPC to break through firewalls by reusing
HTTP put fear in the hearts of network managers?
St.Laurent:
For now, it might. Network administrators who are leaving port 80 open for
everything, though, should probably have a refresher course in security. I
don't expect XML-RPC's "magical firewall breakthrough" to last beyond the
next round of books on network security or the next generation of firewall
software. It's not that difficult to disrupt or block XML-RPC
transactions. On the other hand, it may have set off the next arms race
between protocols and network administrators since developers now know to
take a closer look at HTTP as a useful means of shuttling information past
firewalls.
Johnston:
Fiddlesticks. Network administrators need to worry more about using FTP
and Telnet than XML-RPC. Rolling out any public network service should
make network administrators reach for their stash of antacids.
On the contrary, XML-RPC can help maintain network security by
providing a limited and controllable access point
to an internal resource. Instead of sticking an Oracle server outside
the network DMZ, only the XML-RPC server needs to be on a public host.
If the XML-RPC machine gets compromised, the database system isn't
immediately in danger--although you may need to buy both your network
administrator and your DBA more antacids.
St.Laurent:
If all network administrators spent their time following security issues, I'd
agree with you. Unfortunately, there are lots of administrators whose time is
pretty thin and they're the ones most vulnerable to unpleasant XML-RPC
surprises popping up in their HTTP traffic.
Stewart:
What are some examples of distributed applications where it wouldn't
make sense to use XML-RPC?
Johnston:
An application that requires transactional integrity would be a
poor XML-RPC candidate. For instance, banks aren't running to switch
their ATM machines to using XML-RPC to talk to their mainframes.
Building a Napster-like client that transports huge (5Mb) payloads would
probably not work well. Still, given enough incentive, these problems
have workarounds.
St.Laurent:
You could always use XML-RPC to control another channel where the main body
of data was flowing, but that seems like a stretch. I also ask people if
working from a pure API perspective is OK with them. If they're content
with calling methods with parameters and getting results back, they're in
good shape. If they want to ship objects or business logic around, it's
probably the wrong tool for them.
Stewart:
Is there an official mail list or workgroup for XML-RPC? Where would
you point people to who want to stay abreast of developments in XML-RPC?
St.Laurent:
The main site is www.xmlrpc.com. The specification and a large
collection of implementations (34 last I counted, of which we cover five in
the book) are available from there, as is a mailing list. Many of the
implementations also have their own mailing lists.
Dumbill:
The
Yahoo! Groups xml-rpc list is the central mailing list.
Simon St.Laurent is an associate editor with O'Reilly &
Associates. Simon's books include XML: A Primer, Third Edition (Hungry Minds), XML Elements of Style, and Building XML Applications (both from Osborne). He is a
contributing editor to XMLhack.com and an occasional contributor to
XML.com.
Joe Johnston
is a software engineer at O'Reilly & Associates. A graduate of the
University of Massachusetts in Boston with a B.A. in computer science, he is a
teacher, a Web designer, and an author of articles for
Perl Journal and for the Web. He can
be emailed at jjohn@cs.umb.edu.
Edd Dumbill is the managing editor of
XML.com, part of the O'Reilly Network,
and founding editor of XMLhack.com, a daily news site for XML developers. He lives in
York, England, and maintains the XML-RPC support classes for the PHP scripting
language.
