Manage your expenses via Email, SMS, iPhone, Twitter, Voice (Call and say your expense), IM (Yahoo, AIM, MSN), or Web.
SOAP over JMS: No Such Thing
Comments(12)
Subbu Allamaraju makes an excellent point: there is no such thing as SOAP over JMS. It simply doesn’t make sense.
JMS is a set of APIs. It is not a transport or a protocol. You can implement JMS on any kind of transport; I could use messenger pigeons or smoke signals as the transport for a JMS system.
So let’s stop saying SOAP over JMS. It’s very misleading – the majority of people, particularly those a vendor has spoken to, assume it’s possible to have something that listens to any JMS system and picks messages off the wire. I’ve heard smart people ask for “a generic monitoring system for SOAP messages over JMS”. There’s no standard wire, so you really can’t do that.
JMS specifies the two ends (publishing and subscribing APIs), but not the middle. A transport specifies the middle. That’s what you need to send SOAP over.
I see your point, but consider it to be a limiting view.
By your same reasoning, I could say that only Direct socket level communications is the transport. Or, perhaps only TCP/IP is the transport. Or, perhaps only modulated rf energy is the transport.
You are right in thinking that it doesn’t matter how the transport is implemented. You are only limited in your assumption that one level of abstraction is somehow better than another.
Soap over is an abstraction over an abstraction over an abstraction….
In fact, all of computing, I would even say the whole point of computing, is abstraction.
Otherwise, without abstraction we need to go back to the original discussion of whether a bit being manipulated on a computer is a 1 and a 0 or is actually +2V to 5V and 0V to .8V volts on a TTL logic circuit.
So, from an applications perspective, an API into JMS is no less of an abstracted transport than any other way of getting the message from point to point without having to carry it by hand.
Brent, I’m afraid this has nothing to do with abstraction. Take a look at the wikipedia page defining protocol and API:
http://en.wikipedia.org/wiki/Protocol_%28computing%29
http://en.wikipedia.org/wiki/Application_programming_interface
HTTP is a protocol. TCP is a protocol. IP is a protocol. UDP is a protocol. SMTP is a protocol (look for the P at the end, it stands for protocol).
JMS is an API. There’s nothing to go “over”. It defines the ends, not the middle.
So you can have SOAP over TCP, SOAP over SMTP, but not SOAP over JMS.
I completely understand and agree with your point that JMS is not a protocol, nor is RV, nor is RVCMQ nor are many many other means of getting a message from one application to another (transport).
But let’s not confuse transport with protocol. Protocol is a specific implementation of a set of rules and techniques for good communications across physical devices. Transport uses Protocol. Protocols even use other protocols to facilitate transport. In fact Protocols using underlying protocols is exactly what is stated in the W3C SOAP specification.
To be overly simplistic….APIs expose transport and their implementation uses protocols.
Can JMS be implemented over HTTP? Absolutely! Can JMS be implemented over SMTP? Absolutely! Can JMS be implemented over raw ICMP? I think so….but it could get ugly. (joke)
Oh and http://en.wikipedia.org/wiki/SOAP is interesting.
The W3C org specification is authoritative
A good place to start for anyone who would like a link: http://www.w3.org/TR/2003/REC-soap12-part1-20030624/
So, since SOAP is in and of itself a “Protocol” (an XML protocol that is designed to be used with other underlying protocols) you could easily implment JMS over SOAP. Which is a different animal alltogether and realy not the point of this conversation.
Back to abstraction:
http://en.wikipedia.org/wiki/Abstraction
http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29
http://en.wikipedia.org/wiki/Abstraction_%28sociology%29
The concept of transport is an abstraction, and it is an abstraction that can be highly nested. Just like Protocol is an abstration, and it is an abstraction that can be highly nested.
So, since all things in life should be a learning process, I now go back and reassess my original statement. You are not being limiting in your view. You are actually being pedantically correct. (I mean that in a nice way).
It is my belief however that the problem (like most) comes from applying the wrong terms to the problems at hand.
I also disagree to some extent with the W3C specification. I believe they should reconsider their use of the term “protocol” when discussing how the XML-SOAP message is “transported” from sender to reciever. In truth that “Protocol” could include printing it out, sending it via the US Postal Service, and running it through OCR on the other side. It is my personal belief that they should define it as XML over Transport and then specify the XML and leave the transport definition to the implementation.
The true requirement of people who want to do “SOAP” over “JMS” is not that they want to argue about “What is a transport?” or “What is a protocol?” or even “What is SOAP?”.
They have two end points and an xml message that they want to get from one end point to the other. They want that message to look like the xml used in SOAP (Borrow from the best) . They do not want the well known limitations (yes I know there are benefits too) that are implied by using raw HTTP as a “transport” protocol. They want a way to send the message using all the nice neat benifits of the JMS API “transport” (yes I know there are problems too) and let the API abstract the worry about exacly what underlying protocol is used to enable the “transport” of the message. So yes they do want to send “SOAP” actually “SOAP formatted xml in accordance with the W3C Standard” messages using the JMS API.
Full Circle? Perhaps….
By the way, I’ve read most of your blog. I’ve enjoyed it. Thanks!
Well said Brent ! You have grasped the point and have given the just reply Good mate.
Awesome comments from both Parand and Brent.
Well said Brent.
End of day, clients want to send a XML message, from one point to another and they want message delivery guarantee and JMS specification provides that (read pub-sub). For confused people ‘SOAP using JMS’ may work.
http://www.w3.org/Submission/SOAPJMS/
I’m puzzled. As far as I know, the only thing you can do with a SOAP message with JMS is to put a SOAP-encoded message on a queue via JMS. Is that what we are calling “SOAP over JMS”? If so, I think that is indeed very misleading … leaving out the need for a message queue is kind of important IMO.
Do we mean something else by “SOAP over JMS” ?
I would be actually bold enough to say that JMS is both an API and an “abstract protocol”. Think about different types of messages like Object, Text, Map. They define an abstract structure for the exchanges thus limiting what can be send and accepted on the endpoints. Still, that abstract message type like all other abstract structures requires muscles to cover the skeleton and build the body and that is exactly how I would see SOAP formatted message in this context
I see your point but still in some cases I see JMS like an abstract protocol (like Mariusz indicated) that allows me to process the message in a very different way, that being asynchronously.
W3C released back in June the “SOAP over Java Message Service 1.0″ spec candidate. It might be a lack of a better name the reason why SOAP over JMS is used often. I think the problem might be if we don’t want to called SOAP over JMS then how to call it?
“SOAP over RMI in the middle using JMS API at both ends to achieve asynchronous processing” hmmm. it won’t fly.
I agree that JMS can not be defined as a pure transport protocol, nor a pure communication protocol so it is a bit of both maybe or maybe not, it is really up for debate.
The most important part for me is that it enables asynchronous SOAP post that is needed in some cases over the synchronous SOAP over HTTP so if HTTP give us the synchronous aspect of transport and JMS gives the opposite asynchronous then I see a reason to called SOAP over JMS when in reality the “middle” part is not mentioned.
Bea (now Oracle) goes as far as describe JMS as a transport protocol due of its asynchronous nature maybe again for lack of a better term.
There is a nice diagram that shows conceptually what soap over jms is :
http://www.ibm.com/developerworks/websphere/library/tutorials/0903_adams/
Its got a nice description of soap over jms internals.