Article Discussion
Why Use SOAP?
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.
13 posts on 1 page.      
« Previous 1 Next »
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: November 2, 2007 5:37 AM by close
Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
Why Use SOAP?
March 17, 2003 2:30 AM      
Frank Sommers writes, "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."

What do you think of Frank Sommers' comments?
Posts: 1 / Nickname: joel / Registered: February 20, 2003 3:30 PM
Re: Why Use SOAP?
March 17, 2003 4:57 PM      
I agree with Frank that XML over HTTP is usually all that is required for a web service.
In my experience, I have found that it is even simpler to use a CGI Query String with a GET (or a POST) for the request and XML for the response. Although this may not fit the definition of a web service, it usually provides all the required functionality.
Posts: 6 / Nickname: berco / Registered: January 17, 2002 8:39 PM
Re: Why Use SOAP?
March 18, 2003 7:19 AM      
Not just SOAP but XML in general is becoming a hairball (in my eyes) eating up an increasingly large part of the development effort. Tim Bray, one of the authors of the original XML 1.0 spec actually think XML is too hard for programmers:

I guess it touches upon the same problems. Bray still believes in the XML approach, but having such severe problems after only 5 years makes me sceptic about number of places XML is really a good solution.
Posts: 62 / Nickname: matt / Registered: February 6, 2002 7:27 AM
Re: Why Use SOAP?
March 18, 2003 0:57 PM      
I agree. XML itself, not just SOAP, is overused. Microsoft has scuttled the most useful thing it ever invented -- the ini file -- in favor of XML (assuming they did invent it -- or did it come from the Mac? :-). In .Net, instead of simple ini files for configuration, they have XML files. So instead of this:

Use Cookies=true

You have this gibberish:

<?xml version="1.0" encoding="Windows-1252"?>
<add key="Maximized" value="false" />
<add key="Use Cookies" value="true"/>
<add key="url" value="" />

It is bad with this just these three items, but gets completely incomprehensible when there are many items. And for app settings, XML is less flexible, because for these kinds of settings, you want clarity, case-insensitivity, automatic stripping (or trimming, as it were) of strings and ability to use easily quote characters, etc.

Microsoft has also heavily pushed and hyped SOAP. So they have also probably (I haven't checked into this) made lots of wizards that make it easy for VB programmers to write simple web service clients that expect SOAP. If this is the case, I'm curious whether this puts pressure on web service providers to provide SOAP interfaces, instead of plain XML.
Posts: 62 / Nickname: matt / Registered: February 6, 2002 7:27 AM
Re: Why Use SOAP?
March 18, 2003 3:43 PM      
Oops, I forgot the envelope for that last post, it should have been inside a set of <diatribe style="bitter" type="rambling"> ... </diatribe> tags.
Posts: 1 / Nickname: jarendt / Registered: March 19, 2003 6:21 AM
Re: Why Use SOAP?
March 19, 2003 11:45 AM      
The complexity of application configuration files in .NET was less to replace ini configuration, but to replace the registry and ini configuration. I think XML suits that role since it does handle much more than app settings in ini file.

On the other hand, I wish people chose file formats by the problem at hand and not just what is in favor. I recently configured samba on my laptop to provide some fileshares under Linux on a Windows-oriented network. It was a pleasure -- no extra verbose XML files to tweak! And I was able to do it without a specialized text editors -- nano was all that was needed. :)
Posts: 135 / Nickname: fsommers / Registered: January 19, 2002 7:24 AM
Re: Why Use SOAP?
March 19, 2003 0:12 PM      
I do not have a problem with XML - in fact, I use it all the time, especially with XML schema. But most XML documents are nowadays not aimed for human consumption, but rather are targeted at editing with XML-aware tools. For instance, I'm using Intellij's XML-aware editor for my XML editing, and it's just great. Since it's schema-aware, it helps you enforce schema constraints in a document. I'd never go back to plain text or property files.

But my point in this article was not so much XML, or even SOAP. I tried to point out that most Web services out there tend to be simple: They comprise mostly of sending a simple request, and receiving a simple response. I think there are good reasons to believe that most Web services will stay simple for the foreseable future. And if you write a Web service that consists of a simple request/response pattern, would you use SOAP? Or would you just send that message exchange over HTTP? And if you did use SOAP, would you follow a document-style service, or would you model that service as a series of RPCs?

Again, I'm talking here only of simple services. If you have only one request-response exchange (e.g., I send you a city name, and you send me back a document that describes the current weather there, or I send you a company ticker symbol, and you send back a document with that company's financials, etc) -- does it make sense to define an API, create a WSDL document, etc, that consists of just that simple pattern? Or would it not be better to just write a 1-page HTML spec of how to invoke the service?

Of course, this issue goes beyond just design simplicity. That decision can have a big long-term ramification for an application: If you did use RPC-style SOAP, and did create a WSDL, and handed that WSDL to your customers, what will your customers likely do?

They will likely use a tool to generate a set of Java (or C# or whatever) classes from that WSDL. And they will then compile those classes. And once they have those classes, they will hand them to their developers and say, Here, use these classes to invoke this Web services.

And their developers will go ahead and instantiate those classes, and use those objects *as if those objects were regular, local objects.* The problem is that that won't work. The reason is that those objects are *not* local - there is somewhere a network in between. And, in the words of Jim Waldo (Jini's chief designer), the fact that there is a network in between makes all the difference in your life.

When you invoke methods on those objects, those invocations will fail in unpredictable ways, because the network is not going to be reliable all the time. Messages will get lost, a call may take forever to return, etc., Of course, you can try to handle those issues as best as you can. I know that *you* will, but will your developers do the same?

I'm not saying it can't be done. What I'm saying is that it's fairly seductive to think of those WSDL-to-Java generated objects as regular, local objects. My experience is that only developers who have been beaten by the network a couple of times appreciate the difference between local and remote object invocations. Again, if you do appreciate that difference, by all means, use whatever tool you like, SOAP, XML + HTTP, etc.

But if you do have to deal with customers who may be less experienced, it is sometimes good to expose the network's frailties to them, so that they must address those failure modes explicitly in their applications. In that case, specifying a protocol via the simplest possible response-request messages makes sense, because that makes it easier to debug and monitor an application.
Posts: 1 / Nickname: mkj6 / Registered: June 12, 2003 3:07 AM
Re: Why Use SOAP?
June 12, 2003 7:17 AM      
I write many web services, never using SOAP but only XML+HTTP. Until now I have not seen any useful reason to add more complexity. Sometimes I even don't use XML, but plain old java Properties text files: XML should only be used for well-structured, object-oriented data.

I don't like buzzwords, keep it simple!
Posts: 1 / Nickname: venks / Registered: September 4, 2003 7:04 PM
Re: Why Use SOAP?
September 4, 2003 11:08 PM      
Can somebody explaing me how
" SOAP encoding simplifies serializing complex XML graphs "
just the xml is not enough ?
do u mean that in case of just XML over HTTP its the job of servlet to make sure that it maps the XML to the right object where as SOAP envelop container helps doing the same
reducing the effort of the programmer in case of complex
XML graphs ???
Posts: 2 / Nickname: thoff / Registered: January 17, 2004 2:16 AM
Re: Why Use SOAP?
February 15, 2004 0:43 PM      
I've found SOAP very complex for not much of a
win, especially if you are not using RPC.

Recently i have ammended this opinion somewhat
because attachments are useful. We can do attachments
in other ways, but having a standard protocol seems
like a good thing.
Posts: 1 / Nickname: straightly / Registered: March 20, 2004 3:04 PM
Re: Why Use SOAP?
March 20, 2004 9:27 PM      
Why SOAP? Because instead of

Using just HTTP, you could open a socket to a Web service, and submit such a document via a POST operation. A servlet on the receiving end could route the XML message, based on the message's type, to an object that processes a reservation. Finally, the servlet could send back an HTTP response, confirming a reservation. You could write a servlet that performs that functionality in fewer than 20 lines of code, not counting the processing of the XML messages.

I can, as a client, just instantiate those classes, and use those objects *as if those objects were regular, local objects.*

To sweeten the deal, as a service provider, I can also just select a java interface (Or database stored procedure, or Java static methods, or anything that can be called locally) and publish it as a web service that can be accessed by anybody who know what to do with the generated WSDL.

Wasn't this is EXACTLY the picture we want? Isn't this exactly what WSDL is trying to achieve? I must be missing something here because having "network related code and protocol related code" in my app is a bad thing to me, even IF I know how to write it.

Add to the point, what HTTP+XML can do or is doing to help addressing the network's frailties? None. However, given time, a SOAP container can and will handle these issues and hand me an informative error message which is all that I care. To this point, web servers are wonderful examples.

Network does make one's life very complicated. At the same time, our success will be measured by how well we can HIDE the complexity instead of how determined we are to expose it.

Have you tried Axis lately? It actually works!
Posts: 1 / Nickname: ajeyak / Registered: October 19, 2007 8:41 AM
Re: Why Use SOAP?
October 19, 2007 1:55 PM      
Here's my 2 cents...

If the request-response involves exchanging complex xml messages http + xml is definitely a good option. In fact, I think WSDL with http binding instead of SOAP binding works very well.

-> The interaction between client and server happens in xml that conforms to an XML Schema.

-> The client can worry about serializing/de-serializing data types to/from xml using tools built for the language used (like JAXB for Java) . The server can do the same.

-> WSDL describes the service, so all you have to do is publish the wsdl to expose your service and you are done. Clients will use the wsdl to understand how to call the service and how to learn the format of the response.

In my opinion, SOAP is better used when there are a bunch of servers that do partially complete a huge transaction. The SOAP headers, faults and processing rules will be put to good use in such scenarios...not when a single client talks directly to the server.
Posts: 1 / Nickname: closewind / Registered: September 22, 2007 0:02 AM
Re: Why Use SOAP?
November 2, 2007 5:37 AM      
Using SOAP is beacause that we must have a standard for invoking services. Standard protocol is the most important thing in Web Services. Without it,the sense of this technique will be lost.
13 posts on 1 page.
« Previous 1 Next »