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

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

"XML-RPC Programming for Web Services" XML-RPC（Extensible Markup Language - Remote Procedure Call）是一种基于XML的远程过程调用协议，允许不同的系统和语言之间进行交互和数据交换。在本书中，作者Simon St. Laurent, Joe Johnston, Edd Dumbill详细介绍了XML-RPC在Web服务中的应用和实现。 **XML-RPC简介** XML-RPC是一种轻量级的远程过程调用协议，使用XML来封装数据，HTTP或其他传输协议来传输数据。它允许不同的系统和语言之间进行交互和数据交换，实现了跨语言、跨平台的集成。 **XML-RPC的优点** XML-RPC具有许多优点，包括： * 跨语言支持：XML-RPC支持多种编程语言，包括Java, Python, Perl, Ruby等。 * 跨平台支持：XML-RPC支持多种操作系统和平台，包括Windows, Linux, Unix等。 * 轻量级：XML-RPC是一种轻量级的协议，易于实现和维护。 * 灵活性：XML-RPC允许开发者自定义数据类型和方法，实现灵活的数据交换。 **XML-RPC在Web服务中的应用** XML-RPC在Web服务中的应用非常广泛，包括： * Web服务集成：XML-RPC可以用于集成不同的Web服务，实现跨系统和跨语言的集成。 * 远程过程调用：XML-RPC可以用于远程过程调用，允许不同的系统和语言之间进行交互和数据交换。 * 数据交换：XML-RPC可以用于数据交换，实现跨系统和跨语言的数据交换。 **XML-RPC协议** XML-RPC协议包括以下几个部分： * Choreography：定义了XML-RPC的基本架构和协议。 * Data Types：定义了XML-RPC支持的数据类型，包括整数、字符串、数组等。 * Request Format：定义了XML-RPC的请求格式，包括方法名、参数和返回值。 * Response Format：定义了XML-RPC的响应格式，包括结果和错误信息。 **XML-RPC在Java中的实现** XML-RPC在Java中的实现使用了XML-RPC Java Library，提供了便捷的API和工具来实现XML-RPC客户端和服务器端的开发。 **XML-RPC的应用场景** XML-RPC的应用场景非常广泛，包括： * Web服务集成 * 远程过程调用 * 数据交换 * 企业应用集成 * 云计算 XML-RPC是一种强大且灵活的远程过程调用协议，广泛应用于Web服务、企业应用集成和云计算等领域。

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页未读，继续阅读

xinxin19881112

粉丝: 656
资源: 252

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

2001_Programming Web Services with XML-RPC

Programming Web Services with XML-RPC

programming web services with xml rpc

Programming Web Services with SOAP

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

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 中文版加英文版

最新资源