This content has been marked as final. Show 3 replies
JMS doesn't give you an edge over the legacy MQ capabilities. The root of the JMS existence goes deep inside the portablity issue in the software industry. Application written to the MQ can only be run on MQ environment but the application written using JMS can be run on any JMS supported platform. JMS has got widespread acceptance in the software industries and most of the heavy weights in the messaging domain now supports JMS in their messaging product.
The only thing we can achieve using JMS is portability - Write Once Run Anywhere paradigm of traditional java language.
I hope this helps.
Why to use JMS when I have other messaging technologies like MQ etc.?Your question is ill-formed. JMS is not a messaging technology. It is an API for messaging technologies. If you have MQ you can use JMS as the API. If you have some other messaging technology you can still use JMS as the API. Your application code barely needs to change at all if you decide to switch from one messaging technology to another. That's what JMS is for.
kiran wrote:Of course there are no such things. Asynchronous messaging can be implemented in several ways.
what is the thing that we can achieve only with JMS?
[for example: This can only be done by none other than JMS ... anything like that?]
However if you decide to invent your own way (let's say by using a database table as a queue) then you would have to build in all of those architectural features like guaranteed delivery on your own. And you could do that, or at least you might be able to do it. If you chose e-mail as your messaging tool, for example, then you would have to work pretty hard, but you still might be able to do it. And I wouldn't be surprised to find that .Net has a similar set of classes -- they of course would not be JMS but they would perform the same function.