3.3 Limitations of XML-RPC

As flexible and powerful as XML-RPC is, it does suffer from a number of very significant limitations. None of these limitations prevent it from being usable, and there are some very useful systems built with XML-RPC. In some cases the use of XML-RPC is a supplementary feature, while in others it is a basic aspect of the system. However, understanding the limitations of the protocol make it easier to avoid pitfalls or traps when designing applications to use it.

3.3.1 Status of the Specification

Probably the most limiting aspect of XML-RPC is within the specification itself. No, this doesn't mean that the protocol is the source of the limitation. Rather, the specification as it stands is frozen. Because there is no version specification within the base definitions, the author of the protocol has thus far chosen to not implement any changes or extensions to the specification. This is primarily out of a concern for maintaining a strict sense of compatibility at the wire level between implementations .

The definition of XML-RPC is intentionally simple and clear. The specification at http://www.xmlrpc.com is the single and definitive source for evaluating a claimant to the stamp of XML-RPC compatibility.

Some toolkits (in various languages) have strayed off of the path in small steps, primarily in terms of being more flexible at the transport level. The most common example of this is when a toolkit chooses to allow HTTP 1.1 chunked transfer encoding. When this style of content-transmission is used, it isn't always necessary to provide a Content-Length header. This method is often used with streaming content models such as multimedia types, but it can also be used in cases in which an application wants (or needs) to start the transmission of data before the complete length of the response is known.

If an application or toolkit does something like this, it still bears the responsibility of being completely compatible with even the strictest servers and clients . Otherwise , it can't refer to itself as being an implementation of XML-RPC.

As an example, at least two of the Perl XML-RPC toolkits ( XMLRPC::Lite and RPC::XML , both detailed in Chapter 4) can compress messages with the popular GNU Zip compression algorithm. These toolkits do this only after confirming that the recipient of the message can correctly understand the compressed content. They confirm using standard HTTP headers beyond those used directly by the XML-RPC specification. Thus, both implementations maintain compatibility with other toolkits and applications.

Among the most- requested additional features is a type that is functionally equivalent to C's void or Perl's undef . While it is true that these aren't types in the strictest sense of the word, they are often used to denote that a function has no return value or express a value that is demonstrably different than the boolean false .

As it stands, there is no way to express a remote procedure that doesn't return some sort of value. Every procedure call is expected to return something, even if the value is immediately discarded. Proponents of a <nil/> or <null/> type argue that having such an option would not only make more syntactic sense than returning a throw-away integer or boolean, it would also be several bytes shorter.

Another common request is for more flexibility in the HTTP coupling that the specification exhibits. In particular, because the specification calls out explicitly to the Content-Length header and the POST HTTP verb, the alternatives offered by HTTP 1.1 (and in some cases available as extensions to HTTP 1.0) can't be easily applied to XML-RPC conversations. It is difficult to take advantage of optimizations such as persistent or asynchronous connections, or streaming transfer methods . In addition to this, there are those in favor of completely decoupling XML-RPC from HTTP to allow for lighter-weight transports, such as TCP, or attachment to newer technologies such as BEEP (the Blocks Extensible Exchange Protocol).

The specification-level limitations are difficult, but XML-RPC remains useful in its present form. You can work around the shortcomings by adjusting interfaces and using Base64 to send data that doesn't otherwise fit the available model.

3.3.2 XML-RPC and Interoperability

The XML-RPC specification itself doesn't provide any degree of well-defined interoperability between clients and servers from different implementations. There are some efforts on the parts of individuals and development teams , but all of these are left up to voluntary compliance. Interoperability, were it to be formalized , would need to cover at least two areas: the nature and structure of error or diagnostic messages and the way in which services and capabilities are discovered and shared.

Thus far, very little has been done in the XML-RPC community about consistency in error and diagnostic codes and messages. The numeric codes are actually more important from the vantage point of standardization because depending on exact text message isn't only unreliable, it fails to take into account issues of internationalization. The participants of an XML-RPC mailing list undertook such an effort at standardization, and the current state of that project may be read at the URL:

http://xmlrpc-epi. sourceforge .net/ specs /rfc.fault_codes.php

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 documentation (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 service 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/procedure 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 methods and see what happens.

3.3.3 Choosing XML-RPC over SOAP

The single biggest advantage XML-RPC has over SOAP is the size of the specification, 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 complexity 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.