Sponsored Link •
During my day job, I recently developed a Web service client that accesses four different Web service providers. Each service provider is a leader in its field, and its customers rely on the provider for mission-critical data. I estimate that each provider must process tens of thousands of Web service transactions every hour. Each firm implemented its Web service without SOAP, using the architecture depicted in Figure 1. When I asked their architects whether they would eventually support SOAP-based access to their data, they did not at first understand the reason for my inquiry. From their viewpoint, their firms must provide highly reliable, high-throughput data access, and HTTP + XML is all they need to fulfill those requirements. They considered SOAP an unnecessary addition to a system that already worked well.
Intrigued by their resistance to SOAP, I conducted an informal survey of a few, large enterprise IT shops. They were all working on XML-based data access solutions in business-to-business interactions. But, to my surprise, many of them transmitted XML documents via HTTP, without any trace of SOAP encoding. Several IT managers I spoke with commented: If HTTP + XML works so well, why use SOAP?
In my experience, a SOAPless solution works for most simple Web services. And many Web services are simple. If you look at the publicly available Web services list on XMethods, or search a UDDI registry, you will find that most Web services currently provide but a handful of basic functions—retrieving a stock price, obtaining a dictionary word definition, performing a math function, or reserving an airline ticket. All those activities are modeled as simple query-response message exchanges. HTTP was designed as an effortless protocol to handle just such query- response patterns, which is largely the reason for its popularity. Simple Web services can piggyback on HTTP's mature infrastructure and popularity by directly sending business-specific XML messages via HTTP operations without an intermediary protocol.
Of course, there are many Web services that rely on SOAP. The RPC-style SOAP usage seems more popular, but lately some Web services started to define document-style SOAP messages. One reason for that trend may be the need to interoperate between various SOAP implementations: When the SOAP message carries a simple XML document, you don't rely on a specific SOAP implementation's way of encoding that message. But document-style SOAP also meshes with the request/response message nature of many Web services.
You need SOAP when you design your Web service not as a series of message exchanges, but as a Web-accessible API. SOAP, and its various implementations, automate much of the marshalling and unmarshalling of method parameters and return values when invoking that API.
There can be no one "best" way to design a Web service. My take is that simple Web services should be kept simple. I don't see many reasons to build an API consisting of a single method, with that method consuming one parameter and returning a minor value. An API makes sense when interaction with a service is more intricate—for instance, if you must offer alternate ways of obtaining information from a service. In that case, an API affords a richer interface to that Web service. A well-designed API is also easier for programmers to understand than a bunch of XML message exchanges.
But even in the case of a complex service, you would first have to define your parameter and return value XML structures. You may find that you can often define a complex Web service without reference to any specific invocation style, such as socket-based message exchanges (HTTP + XML) or through SOAP. If you design your service with that flexibility in mind, you can start out using simple HTTP, and switch to a SOAP-based implementation as the need arises. You may find that your Web service's clients will be happy with HTTP for quite a while.
One advantage of keeping your Web services simple is that, instead of spending time debugging them, you get to spend more time hanging around the water cooler, chatting about technologies and protocols that, surely, are the wave of the future. Will SOAP be the wave of the future when it comes to Web services? Or will developers eschew its use in favor of simple HTTP-based XML messaging protocols? Let us know what you think on the Artima forums!
Come back Monday, April 14, for the next installment of Frank Sommer's Web Services column. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
How do you feel about using SOAP versus plain old XML document transfer for Web services? Discuss this article in the News & Ideas Forum topic, Why Use SOAP?
Frank Sommers is founder and CEO of Autospaces, a company dedicated to
bringing Web services and Jini to the automotive sales and finance
industries. He also writes Javaworld's Web
Jiniology columns, and serves as chief editor of ClusterComputing.org, the
Newsletter of the IEEE Task Force on Cluster Computing. Frank is Artima.com's
Web Services columnist.
The W3C's definition of a Web service:
The SOAP specifications:
The SOAP Primer:
More information on service choreography languages:
XMethods lists web services publicly available on the internet: