XML-RPC：简化网络程序调用的技术

需积分: 10 188 浏览量更新于2024-07-27 收藏 672KB PDF 举报

"Programming Web Services with XML-RPC" 是一本由 Simon St. Laurent、Joe Johnston 和 Edd Dumbill 合著的书籍，由 O'Reilly 出版，首次出版于2001年。该书深入介绍了如何使用XML-RPC进行网络服务编程，旨在简化不同程序之间的简单但强大的连接。 XML-RPC（XML远程过程调用）是一种技术，它通过HTTP协议和XML数据格式提供了一种新的方法来创建不同类型的程序之间的交互。它提供关键的抽象层，使得无需为每个应用程序创建新的标准就能轻松连接不同的计算系统。由于XML-RPC基于广泛可用的HTTP和XML技术，因此其实施成本较低。它专注于解决特定问题——跨网络进行过程调用，这使得它在各种系统中易于学习和实现。本书首先介绍了XML-RPC的基本概念，包括它能做什么，以及在哪些场景下表现优秀。作者还提到了使用XML-RPC可能遇到的一些挑战，帮助读者理解技术的应用环境。接下来，书中详细讲解了XML-RPC协议，包括协议的工作流程、数据类型、请求和响应格式。还特别提到了“nil”值的概念，以及XML-RPC的DTD（文档类型定义），这些都是理解XML-RPC通信机制的关键。在第三章中，作者聚焦于Java平台上的XML-RPC客户端和服务器通信。讨论了为何选择XML-RPC用于Java开发，详细解释了Java库的使用，如何构建XML-RPC客户端和服务器，以及创建XML-RPC处理程序的方法。此外，通过三个实用示例进一步巩固了理论知识，并探讨了跨平台的对等通信可能性。这本书是为那些想要了解和实现XML-RPC技术的开发者准备的，无论是在内部网络整合系统还是对外提供服务和信息，都能从中受益。它提供了一个清晰的学习路径，帮助读者快速掌握XML-RPC的核心概念和技术，以构建高效且灵活的网络服务。

Programming Web Services with XML-RPC

- 16 -

Chapter 2. The XML-RPC Protocol

This chapter describes the XML-RPC protocol -- that is, the sequence and structure of

requests and responses required to invoke computations on a remote machine using XML

and HTTP. It also covers XML-RPC's data types, a subset of those commonly found in

programming languages. If you plan to use an available XML-RPC library to create XML-RPC

clients and servers, you don't need to understand all the details of the XML-RPC protocol.

However, when you need to debug your service, you'll find it quite helpful to know about the

protocol details. This chapter also provides the information you need to implement your own

XML-RPC library, should there not be a library for your particular environment.

This chapter, and the rest of the book for that matter, assume that you have a basic

understanding of both XML and HTTP. This knowledge is critical to your ability to understand

XML-RPC. If you don't know much about XML or HTTP, or if you just want to refresh your

memory about the basics, you should check out

HTUAppendix AUTH and HTUAppendix BUTH.

The current chapter explains the XML-RPC specification (found online at

HTUhttp://www.xmlrpc.com/specUTH), which is the first point of reference for the technology. In

addition, the chapter draws upon current practice to recommend guidelines for

implementation and use, and to highlight areas for future specialization or extension of the

technology.

2.1 Choreography

An XML-RPC call is conducted between two parties: the client (the calling process) and the

server (the called process). A server is made available at a particular URL (for example,

http://example.org:8080/rpcserv/).

[1]

UTHP

To use the procedures available on that server, the

following steps are necessary:

[1]

That is, an HTTP server responding on port 8080, on the machine whose name is example.org.

1. The client program makes a procedure call using the XML-RPC client, specifying a

method name, parameters, and a target server.

2. The XML-RPC client takes the method name and parameters and then packages

them as XML. Then the client issues an HTTP

TPOSTT request containing the request

information to the target server.

3. An HTTP server on the target server receives the

TPOSTT request and passes the XML

content to an XML-RPC listener.

4. The XML-RPC listener parses the XML to get the method name and parameters and

then calls the appropriate method, passing it the parameters.

5. The method returns a response to the XML-RPC process and the XML-RPC process

packages the response as XML.

6. The web server returns that XML as the response to the HTTP

TPOSTT request.

7. The XML-RPC client parses the XML to extract the return value and then passes the

return value back to the client program.

8. The client program continues processing with the return value.

There is nothing to stop a process from being both a server and a client, making and

receiving XML-RPC requests. It is important, however, to recognize that in any single XML-

RPC request, there are always the two roles of client and server.

The use of HTTP means that XML-RPC requests must be both synchronous and stateless.

2.1.1 Synchronous

Programming Web Services with XML-RPC

- 17 -

An XML-RPC request is always followed by exactly one XML-RPC response; the response is

synchronous with the request. This happens because the response must occur on the same

HTTP connection as the request.

Furthermore, the client process blocks (waits) until it receives a response from the server.

This step has consequences for program design: your code should be written in such a way

that the potential blocking of a response for some time will not affect its operation, or else

your program should restrict itself to calling remote methods that execute in "reasonable" time.

"Reasonable" may vary, according to the needs of your program. Methods that are called

frequently in time-sensitive environments may be unreasonable if they take more than a

fraction of a second; methods that are called occasionally to return large volumes of

information may be perfectly reasonable even if they take a few minutes to return the full

collection of information requested.

It is possible to implement an asynchronous system, where the response to a request is

delivered at some point subsequent to the time of request. However, this implementation

would require both processes to be XML-RPC client and server enabled and to contain a

significant amount of code for handling such asynchronous responses. Systems that require

asynchronous responses can build such systems on the synchronous foundation of XML-

RPC using multiple request-response cycles. One simple way forward would be to have the

server process return a unique identifier and the calling process implement a special XML-

RPC method that allows the transmission of results corresponding with the request. If the

transactions are conducted over the Internet, this also means that both processes must be

accessible through any firewall that might be in place.

In general, synchronous requests are capable of fulfilling many processes' requirements, and

the overhead of creating an asynchronous system is probably prohibitive in most cases.

2.1.2 Stateless

HTTP is an inherently stateless technology. This means that no context is preserved from one

request to the next. XML-RPC inherits this feature. So, if your client program invokes one

method on the server and invokes it again, XML-RPC itself has no way to treat them as

anything other than two isolated, unconnected incidents. This avoids the sometimes massive

overhead involved in maintaining state across multiple systems.

But there are good reasons why you might want to preserve state. For instance, one request

might create a certain object inside the server, and subsequent requests modify that object.

Users of HTTP have gotten around its statelessness by storing state server-side and using

identifiers held in cookies, or in the URL of the page itself, to indicate to the server a

continuation of a session of requests. Although this is often necessary for projects like web-

based shopping carts, the program-to-program communication of XML-RPC doesn't need this

infrastructure for the simple processes it supports.

Although XML-RPC itself provides no support for preservation of state, you can implement a

stateful system on top of XML-RPC. For instance, you could make the first argument of all

your procedure calls be a session identifier. The procedures would need to have some kind of

state management system, perhaps a database, in the background. They could then keep

track of which calls came from where and perhaps use the history of previous calls to

determine responses to current calls.

2.2 Data Types

XML-RPC calls closely model function calls in programming languages. An invocation of a

remote method is accompanied by data in the form of parameters, and the response to that

method contains data as a return value. Although a request may contain multiple parameters,

the response must contain exactly one return value.

Programming Web Services with XML-RPC

- 18 -

To represent these values, XML-RPC defines an XML representation for program data. It

does this for several basic data types, such as integers and strings, and for compound data

structures, such as arrays.

Any data item in an XML-RPC request or response is contained within a

T<value>T T...T

T</value>T element.

2.2.1 Simple Data Types

XML-RPC defines a set of simple data types, from which other, more complex, data

structures can be built. These types are common to most programming languages.

2.2.1.1 Integers

XML-RPC has exactly one data type for integers. It is capable of representing a 32-bit signed

integer: any integer between -2,147,483,648 (-2

) and 2,147,483,647 (2P

31-

1). It has two

interchangeable representations:

or:

(Note that the

T4T in Ti4T is derived from the length of the integer: four octets, 32 bits.)

XML-RPC implementations must recognize both of these representations as input data. No

recommendation is given as to which form they should use when generating output data,

however. Because XML-RPC is strict about its limitations to 32-bit signed integers, it makes

no difference which form is used: if larger integers (or bignums, arbitrarily large integers) are

ever incorporated into the specification, another element name must be found anyway.

The character string representing the integer may contain no whitespace or other characters;

that is, between

T<int>T and T</int>T there may only occur the characters T-T, T+T, and the

numerals

T0T through T9T. (A positive integer may optionally have the plus sign, T+T, as a prefix.)

Here are some integers encoded to the XML-RPC specification:

2.2.1.2 Floating-point numbers

The XML-RPC specification expresses the range of the floating-point data type as "double-

precision floating point." Conventionally,

[2]

UTHP

this refers to the use of 64 bits for the

representation of the number, giving an effective range of ± ~10

-323.3

to ~10P

308.3

. It has the

following representation in XML-RPC:

[2]

The most common standard for defining floating-point numbers is IEEE 754, which defines single-

precision (32 bits) and double-precision (64 bits) representations for floating-point numbers. A good

overview of IEEE 754 floating-point numbers may be found at

HTUhttp://www.research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.htmlUTH.

As a consequence of its element name, the XML-RPC floating-point type is referred to as a

double.

Although many computing platforms support abbreviated notations for floating-point numbers,

XML-RPC restricts itself to one representation only. A double may be represented by a

T+T or T-T,

followed by digits and a decimal point, after which only further digits are permitted. Here are

some double-precision floating-point numbers encoded to the XML-RPC specification:

Programming Web Services with XML-RPC

- 19 -

There are several caveats to using floating-point numbers in XML-RPC:

• You should be aware of rounding errors that occur with the use of floating-point

numbers (due to the imprecise notation used inside computers). These errors can

occur within your own programs or within the remote server.

• The decimal notation used may lead you to expect that arbitrarily precise (or large)

decimals may be used in XML-RPC. This is not the case, and you should restrict

yourself to what may be represented using an IEEE 754 double-precision integer.

• The special floating-point values not-a-number ("NaN"), infinity, and indeterminate

have no representation in XML-RPC and may not be sent or received. This has

consequences if your methods are performing floating-point operations and yield one

of these values. These cases may be best handled using fault codes (see later in this

chapter).

2.2.1.3 Boolean values

XML-RPC defines a type used to encode Boolean logical values. The type has a range of two

permissible values:

T1T or T0T. The value 1 corresponds to the Boolean value true, and to the

Boolean value false. The type is indicated by the element boolean:

Here are all the possible representations of Boolean values in XML-RPC:

2.2.1.4 Strings

String values within XML-RPC may use one of two alternative representations. In the first

form, the string type is assumed to be the default for any value enclosed in the

T<value> ...

</value>

T element. Thus, the string "Hello, World!" is legally represented as:

<value>Hello, World!</value>

Additionally, an explicitly typed representation of strings is available:

<value><string>Hello, World!</string></value>

XML-RPC implementations must understand both representations.

Whitespace is significant within strings. Furthermore, any XML character is permissible within

a string. If you wish to include characters special to XML, such as

T&T and T<T, in a string value,

you must use their predefined entity references (e.g.,

T&T (for T&T) and T<T (for T<T)).

The XML-RPC specification clearly says that the string type is restricted to ASCII strings. This

strategy works well with many programming environments that can only handle ASCII strings;

however, it can become a substantial problem in cases when string content includes

characters outside the ASCII set. Not even the accented characters of Latin-1 sets are

available.

In theory, if every XML-RPC processor you use conforms to the XML 1.0 specification, the

use of Unicode, ISO-8859-1, or other non-ASCII character sets will cause you no problem.

However, the reality is somewhat different. Not every implementation of XML-RPC is built on

top of a conformant XML 1.0 parser, for example, so you may find that character encoding

issues arise. It is safe to assume that ASCII strings will always be passed unmolested, but

you ought to conduct tests on the platforms of your choice to determine whether it is possible

to use Unicode or another non-ASCII character encoding. You may encounter similar

problems if you use XML character references, which are not explicitly supported by the XML-

RPC specification.

Programming Web Services with XML-RPC

- 20 -

Here are some valid representations of XML-RPC strings:

<value>Tom & Jerry</value>

<value><string>"Twelve apples please," she said.</string></value>

Programs that process XML-RPC calls see the first string as

TTom & JerryT and the fourth Tas

3 < 5

T because they use the XML encoding for the special characters T&T and T<T.

When we examine a complete XML-RPC request later in the chapter, we will see that the

specification's default position is to omit any declaration of character encoding. As per the

XML 1.0 specification, this means that processors should assume that the incoming message

is encoded in UTF-8. Because ASCII is a subset of UTF-8, this should work perfectly well for

messages that conform to the XML-RPC's requirement of ASCII text.

2.2.1.5 Date-times

Dates and times are encoded in XML-RPC using the

TdateTime.iso8601T element type.

This type permits the absolute specification of a combined date and time, according to the

ISO 8601 standard.

[3]

UTHP

To be more precise, XML-RPC uses a profile of ISO 8601 dates

because ISO 8601 allows many different representations. A date-time is represented in XML-

RPC as follows:

[3]

The standard is available at

HTUhttp://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26780&ICS1

=1&ICS2=140&ICS3=30UTH. You can also find an easy-to-read introduction to ISO 8601 dates at

HTUhttp://www.hut.fi/u/jkorpela/iso8601.htmlUTH.

<value><dateTime.iso8601>CCYYMMDDTHH:MM:SS</dateTime.iso8601>

Some example date-times will make this clearer:

The above time means "thirty-minutes after midnight on the twenty-third of February, 1903"

(using the 24-hour clock).

This time means "thirty-minutes and twenty-five seconds after midday on the thirty-first of

December, 2000."

Conventionally, with ISO 8601 date-times, a time zone indicator follows the time part of the

date-time string. However, date-times in XML-RPC are represented without any time zone

information. The specification says that server owners should indicate their time zone by

means of documentation. Unfortunately, this is not a satisfactory situation of which the client

has no prior knowledge. For this reason, we recommend that GMT (Greenwich Mean Time)

be used within XML-RPC applications when possible. Because most programming languages

commonly have functions that translate from GMT into the local time zone, this should

simplify interoperability between systems in different time zones.

2.2.1.6 Binary

Certain characters are forbidden in XML (as explained in

HTUAppendix AUTH). XML prohibits any

character with an ordinal value lower than that of the space character (32), commonly called

control characters. How, then, can data items, such as binary files, that may contain these

characters be transported in an XML-RPC request? The solution is to use an ASCII-based

encoding of the binary object. XML-RPC uses base-64 encoding, commonly found in Internet

applications (email clients, for example, often use base-64 to encode attachments).

The

T<base64> ... </base64>T element is used to enclose a binary object. Here's an

example encoding of the string "Hello, World!":

<value><base64>SGVsbG8sIFdvcmxkIQ==</base64></value>

剩余125页未读，继续阅读

keg2007

粉丝: 0
资源: 2

XML-RPC：简化网络程序调用的技术

2001_Programming Web Services with XML-RPC

programming web services with xml rpc

使用XML-RPC编程Web服务指南

Programming Web Services with SOAP

Programming_Web_Services_with_Perl

Python Network Programming Cookbook, 2nd Edition - 2017

Web Services with SOAP.

Python Network Programming Cookbook, 2nd Edition

ROS Robot Programming 中文版加英文版

web service

最新资源