Sponsored Link •
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.