This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
Chapter 3: Introduction to XML-RPC
Method signatures aren’t a part of the XML-RPC specification. They are imple-
mented at the server level in many of the toolkits offered for application develop-
ment. Signatures are most often used by the server to determine if it can actually
send the input data to the appropriate procedure without generating a fatal excep-
tion or error. Most languages have some sort of exception-handling facility (such as
eval and die functions), but some don’t. These languages can encounter prob-
lems if passed a string when expecting an integer, for example. Depending on the
language and how the software was written, the result of these problems can range
from just returning errors to stack-buffer overflows.
A method’s signature is defined as the sequence of the return parameter’s type, fol-
lowed by the types of all input parameters. For example, using the messages from
Example 3-4 and Example 3-8 as the input and response of the same method, that
method’s signature would be:
(int, struct, string)
Note that the first input parameter is the struct, and that nothing in the signature
indicates (or mandates) any of the underlying structure in that parameter.
This is one reason why the return values from methods must always be single values.
There would be no way to discern the earlier signature from one that indicates a sin-
gle input of
string, with an output of int followed by struct. In order to fully sup-
port languages such as Java or C++ that allow multiple interfaces to methods
(sometimes called overloaded methods), it is necessary to distinguish between the dif-
ferent calling signatures. If an XML-RPC server is exposing routines from a library
written in C, this isn’t an issue. But Java, C++, and many other languages (including
Perl) can have more than one way to call a given routine.
How a server manages method signatures and how (or even if) it imparts that infor-
mation to client applications is entirely up to the developers of the server toolkits and
developers of the servers themselves.
Example Client: Meerkat
Before moving to Chapter 4 and diving straight into the different Perl toolkits for
XML-RPC, let’s look at a simple example of a client
to give you a feel for the phases
in the XML-RPC request/response lifecycle. The example is fairly rudimentary, so
that it can be done without using any of the available toolkits. But even so, it’s com-
plex enough that it also serves as an incentive for you to read Chapter 4, which
shows how much the toolkits can simplify an application.
* Illustrating server development will be left for the introduction of toolkits in Chapter 4 because such code
would be long and unwieldy if written from scratch.

Get Programming Web Services with Perl now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.