Programming Web Services with Perl

This is the Title of the Book, eMatter Edition

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Limitations of XML-RPC

|

51

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:

system.listMethods

Provides a list (array) of local procedure/method names as string-type values.

system.methodHelp

For a given method name (which is passed as a parameter to the call), this

returns any help text (or documentation) for the method.

system.methodSignature

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.