XML-RPC | XML, Web Services, and the Data Revolution


Team-Fly

	XML, Web Services, and the Data Revolution By Frank P. Coyle
	Table of Contents

	Chapter 4. SOAP

XML-RPC, which does remote procedure calls over the Internet, is a great example of out-of-the-box thinking. In confronting the communication problem of how a program on machine A can get some code on machine B to run, XML-RPC ignores the difficulty entirely and delegates the transport to HTTP, focusing instead on the details of what to say, not how to get the message there.

Early work on XML-RPC was done by Dave Winer of UserLand Software. Winer had been working on one of the classic problems of distributed computing: how to get software running on different platforms to communicate. Shortly after XML came out in 1998, Winer demonstrated cross-platform communication by placing XML remote procedure commands in the body of an HTTP POST request. Because XML-RPC depends on HTTP to move data from one server to another, it only needs to define an XML vocabulary that specifies the name of some piece of code to execute remotely and any parameters the code might need.

Aren't Procedures Pass ?

If you're from Object-land, you may wonder why we're not talking object methods instead of procedures. Isn't the term "procedure" rather antiquated, harking back to the days of procedural languages, structured programming, and data flow diagrams? There's actually a two-part answer here. First, RPC is a term that has been in use since before folks starting thinking objects and object-orientation, and XML-RPC carries forward in that tradition. Second, XML-RPC makes no assumptions about the kind of entity that will interpret the request for code execution. XML-RPC elements simply define a vocabulary to communicate information about a piece of code to be executed on some remote server. When a server receives an XML-RPC message packaged in an HTTP POST request, the XML is used to trigger a remote procedure and the result is sent back to the originator as XML.

As for data flow diagrams, they're back. Because data is free to move about the Web unencumbered by code, data flow has now returned as an important technique for modeling the flow of data across networks. One important aspect of SOAP is its ability to specify message paths and intermediaries for handling SOAP messages. Data flow is an excellent design technique to model these interactions.

Data Typing

In keeping with the spirit of Web reuse, XML-RPC uses XML Schema data types to specify the parameter types of the procedure call. Data types include scalars, numbers , strings, and dates, as well as complex record and list structures. Table 4.1 lists the possible scalar data types for XML-RPC parameters and return values.

ZwiftBooks and XML-RPC

To understand how a company might make use of XML-RPC, let's look at how ZwiftBooks Inc. might use it to allow other computer systems to query the ZwiftBooks server about the availability and delivery time of a badly needed book. The basic idea is that the user supplies an ISBN and a zip code and ZwiftBooks returns the guaranteed delivery time.

Figure 4.7 illustrates the use of XML-RPC over HTTP to trigger the execution of a procedure called getGuaranteedDeliveryTime based on ISBN number and zip code. As can be seen in the diagram, a well- formed XML document is getting a free ride over the Internet in the payload of the request that would normally contain the data from a Web form. To make this work, the server must be in on the deal, notice that XML is arriving, and be able to process the XML-RPC elements in order to execute whatever procedure is specified in the methodCall element.

Figure 4.7. An XML-RPC request from a ZwiftBooks server showing the request, the response, and an XML-RPC fault if the server does not understand the request.

graphics/04fig07.jpg

Table 4.1. Scalar Parameter Types for XML-RPC

Tag	Type	Example
`<i4>` or `<int>`	four-byte signed integer	-7247
`<boolean>`	0 (false) or 1 (true)	1
`<string>`	ASCII string	XML for all
`<double>`	double precision signed floating-point number	-72.47
`<dateTime.iso8601>`	date/time	20010524T20:08:45
`<base64>`	base64-encoded binary	7WegYR24048

There are several items of interest in this example. The XML-RPC specification places a number of minimal requirements on the XML, including the following:

The XML payload must be well-formed XML and contain a single methodCall structure.
The methodCall element must contain a methodName sub-item consisting of a string that names the method to be called.
If parameters are required, the methodCall element must contain a params sub-item that contains individual param elements, each of which contains a single value .

XML-RPC Responses

The job of the server is to process the XML-RPC request for the execution of some piece of code and return a value to the client. According to the rules of XML-RPC, a server must return either the result of the procedure execution or a fault element.

Figure 4.7 also illustrates the return value of an XML-RPC packaged in the data area of an HTTP reply. Again, as far as HTTP is concerned , it's just data.

XML-RPC specifies that the response to a procedure call must be a single XML structure, a methodResponse , which can contain either the return value packaged in a single params element or a fault element which contains information about why the fault occurred. Figure 4.7 also illustrates returning a fault element as the payload of an HTTP response. As we'll see with SOAP, the specification for describing failure is an important aspect of XML-based protocols.


Team-Fly

Top