June 28, 2000
XML/HTTP Messaging: Good, Getting Better
by Edd Dumbill
David Orchard of Jamcracker spoke about
XML/HTTP messaging on the final morning of XML DevCon 2000.
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
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,
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
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
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