Advantages/disadvantages of XML-RPC - Angelfire

stizzahaddockSoftware and s/w Development

Dec 14, 2013 (3 years and 5 months ago)

83 views

XML
-
based RPC


By Bas Rutten

Eindhoven University of Technology

April 2003


What this paper is about


The previous lecture covered the topic of
middleware,
software that is used to “glue together”
a collection of heterogeneous and distributed applications.

There are several approaches to
implementing
a middleware application, and one of these approaches uses RPCs, or
Remote
Procedure Calls.
RPC
is
“a
protocol

that o
ne program can use to request a service from a
program located in another computer in a network without having to understand network
details
….

Like a regular or local procedure call, an RPC is
a synchronous
operation requiring
the requesting program to be
suspended until the results of the remote procedure are returned


[SearchWebServices]
. 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
-
RPC
and SOAP and com
pare them,
both to each other and to other middleware solutions.

The basics


Both XML
-
RPC and SOAP work in a
relatively simple

way: they

make use of the standard
Hyper
Text Transfer Protocol (HTTP), more specifically they make use of this protocol’s
Post
me
thod
(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
sired
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
-
RPC and

SOAP have been implemented in
a number
of applications and a number of languages, like PERL, Java, C, C++ et
c.


As an example, consider the following request to call the procedure
getDifference, which
returns the difference between two floating point numbers.


<methodCall>



<
methodName>math.getdifference
</methodname>


<params>




<param>





<value><float>9
<
/float></value>



</param>



<param>




<value><float>4</float></value>



</param>


</params>

</methodCall>


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
r.
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


<methodResponse>


<params>



<param>




<value><float>5</float></value>



</param>


</params
>

</methodResponse>


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
ext and
often
contain
ing many repeated
patterns
, tend to compress very well.
Of course, this compression
does
decrease the speed of
XML
-
RPC.

Advantages/disadvantages
of XML
-
RPC


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
ot
her middleware approaches like
CORBA or (D)Com.
In theory, XML
-
RPC is easy
enough tha
t somebody with knowledge o
f HTML should be able to pick
up

the basics

in a matter of minutes.



There are a wide number of (often free) libraries available that allow you to easily use
XML
-
based RPC in your applications.

Furthermore, XML
-
RPC is
stable
, whi
ch
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
called a
disadvantage,
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
-
bas
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
im
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] :



XML
-
RPC doesn’t support function overloading, and the exact types of all parameters
must be known in advance.



XML
-
RPC
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).



XML
-
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.



XML
-
RPC doesn’t work well with more c
omplex data types, like JPEGs,
XML (that
is: parameters of type “XML”
), or used
-
defined data types.



XML
-
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
problem.


There are, however, some other problems regarding the XML
-
RPC specification, which is
inconsistent regarding a number of things, like the handling of strings.

Enter Soap


SOAP (Simple
Object Access Protoc
ol) is an RPC
-
variant that is in many ways similar to
XML
-
RPC, but it offers a number of refinements and improvements, like user
-
defined data
types, polymorphism/overloading,
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.

SOAP
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
th
an
and
is
even more verbose than XML
-
RPC code. An additional
disadvantage (albeit a temporary one) is the fact the SOAP is still “under construction” (while
XML
-
RPC is stable) which means that applications that use SOAP may need to be updated
more often.

A
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.


One
part
icularly interesting difference between SOAP and XM
L
-
RDF is the fact that SOAP
uses named variables, whereas XML
-
RDF
uses unnamed parameters and
distinguishes
between
them

based on their position. The SOAP
-
approach is more flexible, but it also makes
the parser
that is
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)
than
that
it actually helps.
Therefore, XML
-
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.

Conclusion


XML
-
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
distributed systems.

SOAP uses the same ideas as XML
-
RPC, but is a lot more elaborate and flexible. Thi
s
flexibility comes at the cost of a significant
increase in complexity, though, and it’s somewhat
dubious whether the increased functionality is worth this.


References



[Mime
-
RPC]



Mime
-
RPC homepage

http://www.mime
-
rpc.com/xmlrpc.html


[Rhodes]


`

XML
-
RDF vs SOAP





by
Kate Rhodes

http://weblog.masukomi.org/writings/xml
-
rpc_vs_soap.htm


[SearchWebServices]

SearchWebServices sit
e


http://searchwebservices.techtarget.com


[W3C]




World Wide Web Consortium SOAP candidate recommendation





http://www.w3.org/TR/SOAP/


[Zaiane]



Web

Technologies and their applications





by Osmar I
.

Zaïane






http://www.cs.ualberta.ca/~zaiane/courses/cmput499/slides/Lect

15/sld001.htm