XML/HTTP Messaging: Good, Getting Better

His talk, to a packed room, gave an excellent overview of the advantages of, possible architectures for, and problems associated with using XML over HTTP for creating distributed object systems.

Orchard opened by surveying the typical infrastructure requirements of distributed object systems in today's development environments. In particular, he stressed that the infrastructure must keep a simple invocation simple, provide a consistent programming model, good performance, scalability and reliability, have support for load-balancing and fault tolerance, and very importantly, lower the bar for developer entry. (Orchard noted that this in particular is CORBA's big failing.)

Not coincidentally, these characteristics are true of HTTP--a protocol, according to Orchard, all our jobs depend on! HTTP now has a robust operational architecture, and provides a unified programming model in many environments. Reliability and scalability have received a lot of attention, and there is also the advantage of being open and standards-based.

Speed is perhaps an obvious objection to the use of HTTP, but Orchard was of the opinion that HTTP was "good enough." He later demonstrated with some sample timings that an XML/HTTP call takes about twice the amount of time as a Java RMI call (within a local network). For the extra ease, portability, and interoperability gained from using XML and HTTP, the two-times factor can be traded for economy and flexibility in development--a similar argument might be made for using Java over C++.

HTTP Extension Mechanisms

SOAP is not the only way of passing XML over HTTP. Orchard explained the various mechanisms by which HTTP can be used to transport XML:

• New HTTP verbs: an example of this is the WebDAV protocol, which adds verbs such as PROPFIND to HTTP and transports an XML payload.

• Different URLs: an XML-receiving service can simply be defined in terms of the URL, e.g., http://www.example.org/service/bookings.

• New URI schemes: new schemes such as mq://www.example.org/ could be invented (for, say, referencing an MQseries server), or perhaps soap://www.example.org/

• New HTTP headers: this is the approach taken by SOAP, where protocol-specific instructions are added as extra headers in the request and response.

• New MIME types: rather than being simple text/xml or application/xml, XML over HTTP payloads could be marked with alternative MIME types (such as application/flight-booking) to enable servers or firewalls to negotiate the service.

It's not just the HTTP elaborations that cause issues for XML/HTTP protocol design, however. One important restriction that the use of SOAP imposes is that the user cannot actually send an arbitrary XML document. SOAP requires that the root element of the document is the SOAP envelope, and things you may have in your document, such as processing instructions or doctype declarations, will just not work.

This restriction has caused Orchard to take a neutral stance on SOAP (having once been a more vocal supporter of it), as he has had problems with passing documents in the context of his work at Jamcracker. He noted the workaround of, say, using CDATA sections to escape a contained XML document, but viewed these very much as an unsatisfactory hack.

A member of the audience mentioned that multipart MIME encoding would be a good solution here, and Orchard agreed, adding that Larry Masinter and Larry Cable--two influential developers in the protocols area--favored this approach.

The Next Big Thing

Orchard was convinced that XML/HTTP messaging will dominate XML development in the next year. The current position is that the W3C is considering an XML Protocols Activity, and news is expected soon on this front. There is much more work needed to make simple protocols such as SOAP into mature infrastructures for distributed application services.

In particular, service description and discovery were highlighted as important, as were standardization of the bindings of protocol stacks into the development environment. Security is also an issue that needs addressing, though, of course, one advantage of HTTP is that there is some pre-existing security infrastructure that can be utilized.

Concluding, Orchard said that in the future of loosely-coupled services already created by the Web, XML/HTTP will play a vital role in the new distributed object infrastructure.