Why SOAP needed?

[shai ban]

Hi Friends,
One question that is continuously popping now a days in my mind that why we need SOAP? I am not sure about what I think so I want to share my thoughts.

XML is what we want as a portable message between services over web (under web services). Now, if XML is the one that is understandable to every language then why SOAP is needed? Is it a xml CARRIER, if yes then we can send XML through other protocols also like http OR SOAP is needed for parsing the message coming? Then we can do it with any other API also?

Please share what you think.

thanks.

[Ulf Dittmer]

I think you're confusing a few concepts, so just to be clear: SOAP is XML. It is not a protocol like HTTP, it is a data format. It is also not an API. Being a standardized form of XML it has the advantage that other functionalities can be layered on top of it - useful ones like WSDL and WS-Security, and (IMO) less useful ones like most of the other WS-* specifications.

Having said that, SOAP WS have largely been replaced by REST WS, which tend to have a lower overhead of implementation. But if you need, for example, message-level security as provided by WS-Security, and in some other specialized circumstances, then it is a better choice than REST.

[shai ban]

Ulf Dittmer wrote:I think you're confusing a few concepts, so just to be clear: SOAP is XML. It is not a protocol like HTTP, it is a data format. It is also not an API. Being a standardized form of XML it has the advantage that other functionalities can be layered on top of it - useful ones like WSDL and WS-Security, and (IMO) less useful ones like most of the other WS-* specifications.

Having said that, SOAP WS have largely been replaced by REST WS, which tend to have a lower overhead of implementation. But if you need, for example, message-level security as provided by WS-Security, and in some other specialized circumstances, then it is a better choice than REST.

OK. Then who will be responsible for understanding these SOAP messages specially at non-java clients? Who will be responsible for converting SOAP messages to-fro non-java clients?

[Bear Bibeault]

SOAP has nothing at all to do with Java. XML can be consumed by just about any language.

[shai ban]

Bear Bibeault wrote:SOAP has nothing at all to do with Java. XML can be consumed by just about any language.

Is it? Then SOAP is just a specification according which XML will be formed. right.

but how the message will be created/consumed for non-java services?

[Bear Bibeault]

Do you think that Java is the only language that can consume XML?

[shai ban]

Bear Bibeault wrote:Do you think that Java is the only language that can consume XML?

No. But who is responsible for consuming soap message and transforming back to soap?

[Ulf Dittmer]

Generally you'd use a library of some kind for sending and receiving SOAP messages, so it would be the library's job to create and process the SOAP.

[surlac surlacovich]

shai ban wrote:
who is responsible for consuming soap message and transforming back to soap?

What is the difference what language used to produce executable application? At the end in the most cases it uses TCP/IP stack to read 'something' from socket and write back to it. If the app understands SOAP standard, it can consume/produce SOAP messages doesn't matter what language or platform runs it.

[shai ban]

Ulf Dittmer wrote:Generally you'd use a library of some kind for sending and receiving SOAP messages, so it would be the library's job to create and process the SOAP.

It means there is some library in every language (lets say C++) for transforming soap into C++ object and back to SOAP again. right?

[shai ban]

surlac surlacovich wrote:

shai ban wrote:
who is responsible for consuming soap message and transforming back to soap?

What is the difference what language used to produce executable application? At the end in the most cases it uses TCP/IP stack to read 'something' from socket and write back to it. If the app understands SOAP standard, it can consume/produce SOAP messages doesn't matter what language or platform runs it.

Does that mean, SOAP specification implemented by other languages also. That's the reason they are able to transform back and forth from SOAP?

[Ulf Dittmer]

It means there is some library in every language (lets say C++) for transforming soap into C++ object and back to SOAP again. right?

It doesn't necessarily need to create objects out of a SOAP message, but it does need to provide a language-specific API to SOAP functionality of some kind. Apache Axis2 is one such implementation that does it for Java and C.

In the Java world there are various standardized APIs for this that every major implementation implements, chiefly JAX-WS and SAAJ.

Does that mean, SOAP specification implemented by other languages also. That's the reason they are able to transform back and forth from SOAP?

Yes.

[shai ban]

Apache Axis2 is the SOAP implementation and that implementation is provided in almost every language. It means, these libraries, will be responsible for transforming the soap message back and forth. Am I right? So lets say, I call some object on web service then what will be the sequence for libraries. I mean first soap library will be called then something else? Hope you got it.

[Ulf Dittmer]

Please drop the habit of quoting entire posts. Quoting is for extracting specific bits of a previous posts that your reply references. Otherwise it makes no sense, and you should use the "Post reply" button instead.

Apache Axis2 is the SOAP implementation

Axis2 is a SOAP implementation - there are numerous others written in Java, but Axis2 is one of the best-known ones.

So lets say, I call some object on web service then what will be the sequence for libraries. I mean first soap library will be called then something else?

I'm not sure what you're asking, specifically. Yes, the SOAP engine accepts the incoming connection, extracts the SOAP content, processes it, and then generates and sends a SOAP response. You can probably find a more detailed architectural description on the Axis2 site if you're interested; personally, I've never been curious about that. As I see it, the important part is what happens functionally, not technically.

[surlac surlacovich]

Ulf Dittmer wrote:
there are numerous others written in Java, but Axis2 is one of the best-known ones.

I've heard that Apache CXF provides both JAX-WS and JAX-RS implementations. Why not to just use CXF instead?

shai ban wrote:I call some object on web service then what will be the sequence for libraries. I mean first soap library will be called then something else?

Axis2 will receive SOAP message via HTTP (or other ways), parse the xml (SAAJ), check if it has definition of requested endpoint and operation, instantiate service instance (Java object) and call a method.

[surlac surlacovich]

Ulf Dittmer wrote:
Axis2 is a SOAP implementation - there are numerous others written in Java, but Axis2 is one of the best-known ones.

Ulf, so why Axis2 is the best one, if it only supports JAX-WS? Apache CXF has support for both WS and RS.

[Ulf Dittmer]

so why Axis2 is the best one, if it only supports JAX-WS?

I didn't say it was. But I don't see any particular advantage in having one library implement both SOAP and REST, so if I wanted to compare frameworks, that wouldn't count as a plus in my book.

[surlac surlacovich]

So JAX-RS support is not a big feature by your means, is it? Then I believe Axis2 has something that you 'count' as a plus (despite RS). Could you please tell us about it?
Because some of application servers just hosts both Axis2 and CXF. Why?

[surlac surlacovich]

Ulf Dittmer, any comments on this? Still very interested.

[Jaikiran Pai]

surlac surlacovich wrote:So JAX-RS support is not a big feature by your means, is it?

I don't see how you concluded that that's what Ulf meant when he said:

Ulf Dittmer wrote:But I don't see any particular advantage in having one library implement both SOAP and REST, so if I wanted to compare frameworks, that wouldn't count as a plus in my book.

IMO, what Ulf meant was that if you are comparing libraries, then the fact that a certain library supports SOAP as well as REST isn't a factor when a certain other library supports only REST (for example).

[surlac surlacovich]

Jaikiran Pai wrote: the fact that a certain library supports SOAP as well as REST isn't a factor when a certain other library supports only REST (for example).

Why not? Small example based on some experience working with both. Our application server has both Axis2 and CXF, it uses Axis2 for SOAP and CXF for REST by default. When we were forced to implement some mechanism to intercept messages and convert some part of it to Java objects (for specific messages; SOAP->Object; JSON->Object), we had to write Handler for Axis2 and Interceptor for CXF as a separate components - it would be really helpful to just have one. That's why I'm interested what experience did you have to claim that additional support of one more protocol isn't the factor to prefer more universal library.

[surlac surlacovich]

So what experience did you have to claim that additional support of one more protocol isn't the factor to prefer more universal library?

[Ulf Dittmer]

Jaikiran interpreted correctly what I said.

So what experience did you have to claim that additional support of one more protocol isn't the factor to prefer more universal library?

I don't really understand this question. The underlying logic seems to be "if it does more, it's better" - I'd rather pick the best of each and combine them. There's no difficulty in running my JAX-RS library of choice and my JAX-WS library of choice within the same web app, if I wanted to do that.
The use case about writing one filter class for both kinds of WS sounds rare to me, and even where it does happen, not important enough to me to be a deciding factor for or against a particular WS implementation. I'm also guessing that it should be possibly to implement the interfaces of the JAX-RS interceptor and the JAX-WS handler within the same class, and factor out the common logic into its own method - and thus end up with an implementation-agnostic solution with not much more work.

[surlac surlacovich]

Ulf Dittmer wrote:The underlying logic seems to be "if it does more, it's better" - I'd rather pick the best of each and combine them.

Why not? You should be confident about implementation because each type of web-service framework (WS, RS) is covered by corresponding standard (JSR-224, JSR-311), so the minimal requirements will be satisfied anyway. You are talking about something additional to the standard, which makes a difference for you. I'm not aware of it right now, thus I'm really interested to know what makes that difference.

Ulf Dittmer wrote:I'm also guessing that it should be possibly to implement the interfaces of the JAX-RS interceptor and the JAX-WS handler within the same class, and factor out the common logic into its own method - and thus end up with an implementation-agnostic solution with not much more work.

Axis2 deploys Handlers as mar-files (module archive), and interceptors as a plain jar-files, which are loaded by different classloaders from 2 different directories. So I guess it is possible to factor out and make one class, but it will involve non-trivial configuration/modification of frameworks.

[Ulf Dittmer]

I'm talking about pragmatic factors like pre-existing knowledge of certain libraries. There are also other discriminating factors like features and performance that one would take into account when comparing frameworks.

[surlac surlacovich]

Ulf Dittmer wrote:I'm talking about pragmatic factors like pre-existing knowledge of certain libraries.

That's one is really subjective.

Ulf Dittmer wrote:There are also other discriminating factors like features and performance that one would take into account when comparing frameworks.

Thanks for the answer, that's makes more sense for me, so I digged I little bit deeper and I've found the answer here and here. So it's basically comparison of the frameworks.

[Ulf Dittmer]

That's one is really subjective.

Yes, and I didn't claim otherwise. Feature comparisons (like the ones you linked to) are only part of the decision. For a comprehensive comparison, every applicable difference -of whatever nature it may be- needs to be weighted by its importance for the particular environment. That's why there rarely is a universally "best" implementation of anything, whether for WS, or DB, or web app framework, etc.