Front page | perl.perl5.porters |
Postings from July 2001
Case for XML-RPC
From:
Nathan Torkington
Date:
July 17, 2001 11:01
Subject:
Case for XML-RPC
Message ID:
15188.32059.18000.301941@gargle.gargle.HOWL
I've written up my arguments for including an XML-RPC module in the
core. I also plan to ply Jarkko with booze at TPC :-) Note that I'm
not a pro-XML-RPC radical--I don't think it's the solution to every
problem, it's not going to get you laid, and it probably isn't going
to get you a job. It's just going to solve some problems for us.
Nat
*** What is XML-RPC? ***
XML-RPC provides a standard way for clients to make procedure calls on
remote servers. It is built on compatible subsets of HTTP and XML.
It uses HTTP because HTTP is a known quantity for most firewalls (thus
clients from behind a firewall can make function calls to a server
outside the firewall). It uses XML because XML is trendy, and also
because many programming languages have XML parsers these days.
XML-RPC was developed by a small group of companies, including
Microsoft and Dave Winer's Userland. There are implementations in
many languages (including PHP, Python, Ruby, C++, C, Java) and
interoperability is high. It's a fixed standard (frozen and
untouchable by the companies who created it), with all extensions and
new development required to take place in projects with other names
(they can't be called XML-RPC unless they're purely XML-RPC).
*** How does XML-RPC compare to SOAP? ***
SOAP has loftier goals. SOAP is object-oriented (providing a
transportation layer that lets a client say to the server "create an
object of this class and give me a handle to it", then "call this
method on the object whose handle is XYZ"), and uses many more
features built on top of XML. The messages exchanged between clients
and servers are correspondingly heavier, and decoding them more
complex--SOAP uses XML namespaces, for instance, which means it
requires a more complex parser.
SOAP is being pushed by Microsoft and IBM, with WSDL (the API
description language) and UDDI (the service location protocol) built
on top. It's seen by some as bloated, and interoperability is slow to
arrive. It's also a moving target--SOAP 1.2 is on its way, and more
versions are expected to follow.
*** Is it all just hype? ***
It's not vaporware, as implementations exist and there are services
that use it. The first web services have tended to provide the same
data currently offered through web pages--you don't have to concern
yourself with parsing ever-changing HTML, you simply get the data you
want as the results of a (remote) function call. For instance,
Meerkat (http://www.oreillynet.com/meerkat/) has an XML-RPC interface
to let you search and download syndicated RSS stories, and several
site-hosting services (Macrobyte, WebCrossing) let you update your
news pages, journals, calendars, forums, etc. Dave Winer's Userland
(http://www.userland.com/) site/service makes heavy use of XML-RPC
internally (for distributing user preferences) and externally (for
web-based email and website management).
But there are also other services springing up. For instance, the
Stuffed Dog Speller (http://www.stuffeddog.com/speller/doc/rpc.html)
lets you submit a document and have it spell checked.
Commercial services are the things that aren't there now--services
that are business-critical. For instance, you could imagine a service
that processes credit card transactions for you. That implies a
commercial relationship between the client and server, involving
authentication, guarantees of uptime, and so on. XML-RPC doesn't
claim to handle any of that--you can authenticate and encrypt using
HTTP's basic authentication and SSL, but you're expected to define and
manage those above and beyond the XML-RPC spec. So in many ways,
XML-RPC isn't ready for *business* primetime, but I don't think that's
relevant to the case for XML-RPC to be in the Perl core.
*** Why not make Perl work with CORBA? ***
Perl already does (mostly) work with a number of CORBA ORBs. I'm not
arguing for the incorporation of CORBA into the core, I'm arguing for
XML-RPC. If you want to add CORBA to the Perl core, go ahead. But
XML-RPC doesn't require CORBA and the two systems aren't mutually
exclusive, so I don't think CORBA is relevant to the debate. Saying
CORBA exists so why add XML-RPC is like saying "the web exists, why
run an FTP site?" They're different, serve different needs, and
whether we like it or not both exist in the real world.
*** Why would a project choose XML-RPC over CORBA? ***
CORBA is larger than XML-RPC, and correspondingly more complex to work
with. CORBA requires you to write a description of your interface in
a language called IDL ("interface description language", cryptically
enough), whereas there's no such process for XML-RPC. CORBA is
object-oriented, XML-RPC is not.
There's also the perception that CORBA is old and dull while XML-RPC
is young and hot. I'm not saying this is why we should put it in the
core, I'm simply saying that this is why some people might prefer to
use XML-RPC over CORBA.
*** Why should XML-RPC be in the core? ***
Once XML-RPC is a standard part of the core, we can begin to integrate
networked services with standard Perl tools. This happens now,
without XML-RPC, but it happens by constant reinvention of one-off
protocols. Take, for example, the case of WAIT (the full-text CPAN
search in CPAN.pm), which has its own port and often is unusable
behind a firewall without the hassle of contacting the network
administrator and justifying the hole in the firewall.
Without a standard RPC mechanism in the core, every new service will
write its own, meaning everyone who wants to write a client will need
to have the custom RPC module installed.
With a standard RPC mechanism in the core, we can write new services
and know that the technology to access it already comes with Perl.
Some sample applications:
* go out over the network to look for documentation if it's
not installed locally (as Randy Kobes' SOAP-enabled perldoc does)
* replace WAIT with an XML-RPC service and fix the service problmes
* full-text search all CPAN documentation without needing to have it
installed locally, from the commandline a-la perldoc
* perlbug that doesn't require e-mail
* O'Reilly, Manning, etc. could open up its book indexes, so perldoc
could also tell you which pages of which books to go for
information
*** Wouldn't this mean we have to put expat and LWP into the core? ***
No.
We've long wanted a stand-alone pure-Perl XML parser in the core, and
this might be the reason to create one. If we can't find/write a
pure-Perl XML parser, we do have the option of parsing the minimal
subset of XML that XML-RPC requires. In that case, the XML parsing
almost definitely wouldn't be provided as a separate module intended
to be used by everyone for XML parsing--that'd be asking people to use
a known incomplete module.
LWP is trickier. Randy Ray reckons he can decouple an XML-RPC client
library from LWP dependence, although it might still be needed to
write servers. We'd be looking at shipping a module that works out of
the box for writing clients, but which requires LWP before you can
write servers.
*** Why should I make myself dependent on web services provided by
someone else? ***
(These last two questions are more about the use of web services in
businesses and not about XML-RPC in particular)
You already make yourself dependent upon services provided by others.
Most people don't hook directly to the backbone of the network. Most
people don't run their own banking institution. Most people have a
phone line. Some things we are forced to hand over to others, some
things we choose to hand over to others (e.g., "outsourcing") because
they're too complex to handle ourselves (e.g., not everyone runs their
own CPAN mirror).
*** Won't my PHBs want to pay for a guarantee of service if we do
mission-critical things with someone else's web services? ***
Probably. That doesn't have much to do with whether XML-RPC should be
in the core, though.