By Bas Rutten
Eindhoven University of Technology
What this paper is about
The previous lecture covered the topic of
software that is used to “glue together”
a collection of heterogeneous and distributed applications.
There are several approaches to
a middleware application, and one of these approaches uses RPCs, or
ne program can use to request a service from a
program located in another computer in a network without having to understand network
Like a regular or local procedure call, an RPC is
the requesting program to be
suspended until the results of the remote procedure are returned
. Again, there are several ways to implement RPC. This paper will look
at two of those approaches for implementing RPC based on the HTTP protocol: XML
and SOAP and com
both to each other and to other middleware solutions.
RPC and SOAP work in a
make use of the standard
Text Transfer Protocol (HTTP), more specifically they make use of this protocol’s
(the same that is commonly used in HTML forms)
to send a request containing to a
remote server. This request contains information about which method to invoke and with
which parameters to invoke it. The server receives this request, carries out the de
procedure, and returns the result to the c
lient that posted the request.
Both the request and the
result are encoded in XML. Both XML
SOAP have been implemented in
of applications and a number of languages, like PERL, Java, C, C++ et
As an example, consider the following request to call the procedure
returns the difference between two floating point numbers.
This is how the request would look in XML
RPC. The SOAP alternative would look
somewhat similar, except for some differences which we’ll cover late
This request is sent to
a server on which the procedure math.getdistance is located. The server processes the request,
and returns something along the lines of
As you can see, this kind of communication tends to get quite verbose, but fortunately it’s
usually possible to reduce the size of the requests and responses using some kind of kind of
compression algorithm. The requests, being plain t
ing many repeated
, tend to compress very well.
Of course, this compression
decrease the speed of
The biggest advantages of using XML
based RPC are as follows:
It’s based on XM
L, which is a widely recognised and used language that has already
proven its use.
It’s relatively easy to implement and doesn’t require as much special knowledge like
her middleware approaches like
CORBA or (D)Com.
In theory, XML
RPC is easy
t somebody with knowledge o
f HTML should be able to pick
in a matter of minutes.
There are a wide number of (often free) libraries available that allow you to easily use
based RPC in your applications.
means that no changes will be made to the protocol anymore.
It uses the HTTP protocol, which is usually able to bypass firewalls.
This can make
communication a lot easier.
(Of course, the ability to bypass firewalls could also be
since it lessens control over what’s going on).
Then again, the relative simplicity of XML
based RPC is also one of its biggest advantages,
since it doesn’t allow for some more complex or subtle options that other middleware variants
do provide. XML
ed RPC allows for a wide number of standard data types like integer,
float, string etc, and also allows for rudimentary containers like arrays and structs (C/C++
name for “record”), but more complex things like hierarchical structures are much harder to
plement, since XML
based RPC doesn’t allow for pointers.
A short list of some of XML
RPC’s shortcomings, taken mostly from [Mime
RPC doesn’t support function overloading, and the exact types of all parameters
must be known in advance.
doesn’t support pointers, which can lead to redundant data duplication, or
questions about the identity of certain structures (are they supposed to be the same, or
do they just happen to contain the same data).
RPC doesn’t work over email (since it ca
n only use HTTP, not SMTP), were
apparently other RPC implementations like Mime
RPC do work.
RPC doesn’t work well with more c
omplex data types, like JPEGs,
is: parameters of type “XML”
), or used
defined data types.
RPC is slow and bulky
compared to other alternatives.
Of course, it’s somewhat debatable how big these disadvantages are. Most of them don’t
appear to be real show
stoppers unless you want to do something fairly complicated or
specific. For the more generic applications, none
of the above really sounds like a huge
There are, however, some other problems regarding the XML
RPC specification, which is
inconsistent regarding a number of things, like the handling of strings.
Object Access Protoc
ol) is an RPC
variant that is in many ways similar to
RPC, but it offers a number of refinements and improvements, like user
namespaces, and greater customisability.
Overall, SOAP is
more flexible and allow
s a lot of things that XML
RPC doesn’t allow.
However, the price one has to pay for these improvements/refinements is rather high.
has been adopted by the World Wide Web Consortium, which tends to produce
recommendations that are quite verbose and pr
etty complicated for the things that they do,
and SOAP is no exception:
just check out the specification at [W3C], which contains lots of
attributes and features of which the practical use seems rather limited. Also, SOAP code looks
a lot more cluttered
even more verbose than XML
RPC code. An additional
disadvantage (albeit a temporary one) is the fact the SOAP is still “under construction” (while
RPC is stable) which means that applications that use SOAP may need to be updated
lso, both Microsoft and IBM have chosen to adopt SOAP in their applications,
but neither of them seems to be too concerned with the W3C specification and both have been
known to deviate from it.
icularly interesting difference between SOAP and XM
RDF is the fact that SOAP
uses named variables, whereas XML
uses unnamed parameters and
based on their position. The SOAP
approach is more flexible, but it also makes
required to decod
e the request more c
omplicated (since the parameters can
now be passed in any order). It’s doubtful whether this additional flexibility really adds
something significant to the
language, while at the same time introducing extra complexity.
This example is illustrative for S
OAP: it can do a lot more than XML
RDF, but often this
extra functionality seems to be doing more harm (in making everything needlessly complex)
it actually helps.
RPC seems to be the preferred solution if you just
want to do somet
hing relatively simple or quick, and SOAP should only be used if you really
need it to do something that XML
RPC really can’t.
RPC is a very useful way of implementing RPC. It is relatively simple, somewhat
inefficient, and limited and is b
y no means a solution to every problem, but it doesn’t pretend
to be either and instead offers a relatively easy and low
key way to communicate between
SOAP uses the same ideas as XML
RPC, but is a lot more elaborate and flexible. Thi
flexibility comes at the cost of a significant
increase in complexity, though, and it’s somewhat
dubious whether the increased functionality is worth this.
RDF vs SOAP
World Wide Web Consortium SOAP candidate recommendation
Technologies and their applications
by Osmar I