phpBeans Compared to XML-RPC, SOAP, and REST

By Lux

December 8, 2004

The goal of this comparison is to have you gain a better understanding of the goals and the purpose of phpBeans. My intention is not to criticize any of the other specifications, but to use them to illustrate how and where phpBeans fits in, and what problems it solves best.

The first thing to understand when comparing phpBeans against XML-RPC, SOAP, REST, or any other stateless RPC protocol is the intended use of each specification.

The commonality of purpose shared between phpBeans, XML-RPC, SOAP, and REST is to be able to execute a method of an object residing on a remote server and to receive a response. But this is where the commonality ends. For phpBeans, this intention is limited to the scope of n-tier development. For the others, the opposite is true.

This difference results in a shift in priorities for each specification, and consequently a shift in how the specification solves the problems it addresses. To illustrate these differences, I've broken them down by topics below.

Maintaining State

phpBeans uses a single TCP/IP connection for an entire client/server session, whereas the others offer a stateless execution model, where each request to the server is an independent connection. This allows XML-RPC, SOAP, and REST to potentially change the underlying communication layer (ie. SOAP over HTTP over TCP/IP, or SOAP over SMTP over TCP/IP), whereas phpBeans is restricted to phpBeans over TCP/IP.

This means that XML-RPC, SOAP, and REST apply to a wider variety of situations than phpBeans. It also means that the phpBeans protocol is faster than any of them.

Verbosity

phpBeans values shorter message sizes (or a compromise between succinctness and readability, leaning towards succinctness), whereas XML-RPC, SOAP, and REST value readability foremost (to varying degrees).

For example, the following is an encoded string in the phpBeans protocol format:

s:6:"string";

While the following is the equivalent string in SOAP:

<SOAP-ENC:String>string</SOAP-ENC:String>

The SOAP encoding, in this case, adds five times the amount of wrapper data that phpBeans does. The reason is because SOAP uses an XML-formatted encoding, and XML is quite a verbose markup language by nature.

To further illustrate the difference in message sizes, I've prepared a few tables that list the encoded message length of different variables in a number of specifications.

String Encoding

This table compares phpBeans against XML-RPC and SOAP. REST and phpBeans are nearly identical in size in terms of client requests, and REST doesn't specify a strict encoding format for responses (although it generally uses an XML-based response format), making it difficult to compare.

Array Encoding

This table compares phpBeans against XML-RPC, SOAP, and CORBA. CORBA is an older binary protocol that SOAP's creators sought to replace, and represents another more terse encoding format for a more varied comparison.

Security

Authentication

phpBeans implements its own authentication layer as part of the specification itself, whereas XML-RPC, SOAP, and REST generally rely on the underlying protocol for authentication. There are some efforts to add authentication extensions to the XML-RPC and SOAP protocols, but none of them are very widely implemented or supported across implementations.

Encryption

All four protocols are able to work over a Secure Socket Layer (SSL).

Ease of Use

Both SOAP (Simple Object Access Protocol) and phpBeans try to make client-side programming as transparent as possible, providing sufficient remote object reflection information (Web Services Description Language, or WSDL, in the case of SOAP, and the objectInfo method defined in the phpBeans Server API specification) as to be able to produce a local object that immitates the remote object. XML-RPC and REST have more limited capabilities in this regard, and so many client libraries are unable to provide this same level of abstraction.

The benefit of this transparency is that it makes remote object programming nearly identical to local object programming, which substantially reduces the learning curve involved in learning to use a given technology.

The phpBeans Server API also makes it very straight-forward to write server-side objects, called beans. The ease of server-side development in SOAP, XML-RPC, and REST varies from implementation to implementation.

Object Persistence

The phpBeans Server API specification defines standard methods for server-side objects to save and restore their state at any time, making object persistence a very simple task.

Object persistence is beyond the scope of either the SOAP, XML-RPC, or REST specifications.

Conclusion

As you can see, phpBeans has clear advantages over each of the compared specifications, in terms of speed and ease-of-use, for the purposes of n-tier application development. For communicating with third-party servers, SOAP or the others are clear winners.

Hopefully this gives you a better basis for your own comparisons and for making a decision about your upcoming software projects.

More News

Return to Top