This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
Limitations of XML-RPC
This particular set came to be the chosen list as a result of the persistence and effort
of the author, who regularly solicited feedback as he developed the document.
In the area of service description and discovery, the most popular effort towards
interoperability derives from an interface developed as part of the PHP toolkit, upon
which the Meerkat XML-RPC service described earlier was built.
This discovery interface provides access to information about the methods a server
provides. It lists the procedure names, as well as calling-syntax details and documen-
tation (when available). The original designer chose names for the routines that
started with the sequence
system so as to avoid collision with other procedure names.
As with the proposed standard regarding error codes, this is only a suggestion to ser-
vice designers, but one that has caught on in at least one of the Perl toolkits. The
three main methods are:
Provides a list (array) of local procedure/method names as string-type values.
For a given method name (which is passed as a parameter to the call), this
returns any help text (or documentation) for the method.
Returns an array of arrays, listing the known signatures for the method given as
an argument. Recall from earlier that the signature is defined as the promised
return value’s type followed by the types of any arguments. A method/proce-
dure can be called in more than one way, which is what the purpose of defining
signatures is meant to distinguish.
Some toolkits provide more than this, while some toolkits provide no predefined
methods at all. It is still necessary for client developers to have some knowledge of
the servers they are dealing with. They can also try sending requests for these meth-
ods and see what happens.
Choosing XML-RPC over SOAP
The single biggest advantage XML-RPC has over SOAP is the size of the specifica-
tion, or more accurately, the compactness of it. XML-RPC can be implemented
much more simply than SOAP. As more and more applications are being targeted
towards embedded platforms and other targets, memory or processing overhead (or
both) may be at a premium.
Even when memory or other such resources aren’t an issue, the fact remains that
XML-RPC is a much simpler protocol than SOAP. As such, it introduces less com-
plexity into a software system than SOAP would. Many applications need the func
tionality and scope that SOAP offers. In cases where it isn’t needed, however, there is
no reason to introduce extra overhead.