Summary
SOAP (Simple Object Access Protocol) has become synonymous with XML-
based Web services. However, many real-world response-request-type Web
services don't use SOAP; instead, they pass XML messages directly over HTTP.
This article discusses these two Web service design approaches.

There is an old joke in the distributed computing community: Agents are the wave of
the future—and have been for 30 years. It's just that the future hasn't caught
up with agents yet.

In a few years, will we joke similarly about SOAP? When reminiscing with
colleagues around the water cooler about past technologies that did not, after all,
become the wave of the future, will we ask, "Remember SOAP?"

Let me point out that I'm not for or against SOAP: I don't
believe in being for or against a technology. But I do believe in using the right tools
for a job. SOAP is rapidly becoming the generally accepted protocol for XML-
based system-to-system communication. Because several important Web services
infrastructures rely on SOAP for XML message transfer, many developers have
adopted SOAP as an essential Web service tool.

But is SOAP necessary to build XML-based Web services?

The W3C's Web Services Architecture working group doesn't mandate using
SOAP for a Web service. According to the W3C's definition (See Resources):

A Web service is a software system identified by a URI, whose public interfaces
and bindings are defined and described using XML. Its definition can be discovered
by other software systems. These systems may then interact with the Web service
in a manner prescribed by its definition, using XML-based messages conveyed by
Internet protocols.

You don't need SOAP to build a system that satisfies that definition: The Web
Services Description Language (WSDL) defines and describes a Web service with
XML; UDDI (Universal Description, Discovery, and Integration) facilitates service
discovery; and XML messages are easily sent between services via HTTP or
some other Web protocol.

For many Web services, you need only a combination of XML, HTTP, and an
application-specific message protocol. To be sure, SOAP has its uses. But, in my
opinion, SOAP's role is overstated in the early stages of a Web service's
development. Using SOAP for the wrong tasks can easily hijack a Web service
development project, because SOAP introduces a large set of problems that are
orthogonal to the challenges of building a Web service. SOAP-related issues tend
to consume the majority of the development effort.

The most common purpose of Web services today is to exchange XML data. For
instance, more than 200 Web services listed on XMethods (See Resources) share that purpose. The classic examples of a
stock quote service, weather service, or postal code lookup service are all about
sending an XML query message, and receiving an XML reply. That pattern
dominates more complex Web services as well: the UDDI registry service or the
Liberty Alliance single sign-on and identity federation Web services are all defined in
terms of XML-based query-response message exchanges.

At best, SOAP introduces a level of indirection to such XML message exchanges
by embedding an XML message in a SOAP envelope. Since the SOAP
envelope can carry metadata about the original XML message, such as processing
instructions, the envelope can aid a Web service in processing that message. At
worst, SOAP makes it difficult, if not impossible, to verify the validity of an XML
message traversing between two Web services.