*
The moose likes EJB and other Java EE Technologies and the fly likes Why JMS? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Why JMS?" Watch "Why JMS?" New topic
Author

Why JMS?

harsh anajwala
Greenhorn

Joined: Oct 13, 2009
Posts: 16
I have a doubt regarding JMS.
In my Application which is divided in four components,I want to send messages between Components.Now it seems that I could use JMS for this with say ActiveMQ as a JMS Provider.

My question is that this simple task can also be provided by Client/Server TCP communication using Socket programming and underneath JMS does the same thing.Then Why should I go for JMS?
JMS might hit the performance of the application.
And normal Socket Programming would be high in performance(Response Time,Memory Consumption) than JMS.

So is there any concrete reason to choose JMS?
Just to mention ,my application is normal Java application not a web application.It is not using EJB.

Thanks in advance.
Chinna Eranna
Ranch Hand

Joined: Dec 08, 2009
Posts: 174

There are lot of features you get for free. if you use JMS.

http://java.sun.com/products/jms/faq.html#what_is_jms

http://www.allapplabs.com/interview_questions/jms_interview_questions.htm#q3


- Chinna
Chinna Eranna
Ranch Hand

Joined: Dec 08, 2009
Posts: 174

This topic is debatable..

All depends on what non-functional requirements you have.. like performance, memory.

Using JMS will add extra load on to system.

Still with a basic Synchronous messaging.. you will have features to send different types of messages (like, Streams, texts, java objects, map, etc).

With socket programming, you will have to manually indicate, where is the message starts, where it ends.. and so on.. (Obviously this will have high performance)
harsh anajwala
Greenhorn

Joined: Oct 13, 2009
Posts: 16
Ok..currently communication is taking place using pipe files in unix.
In socket programming we can send/receive object like JMS so no need to mention start/end of the message.
In future we may want to use other features of JMS also...This could be a valid reason to use JMS in my case...

but truly it's very debatable topic.
I wish some more participation.

Thanks.

Chinna Eranna
Ranch Hand

Joined: Dec 08, 2009
Posts: 174

harsh anajwala wrote:
In socket programming we can send/receive object like JMS so no need to mention start/end of the message.


I agree..
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41034
    
  43
My question is that this simple task can also be provided by Client/Server TCP communication using Socket programming and underneath JMS does the same thing. ... JMS might hit the performance of the application.

This is a bit like saying: Why should I use a higher-level language like Java when all it does can be done in Assembler as well? Using something pre-made will get you to the finish line much faster than writing it on your own, since basic JMS is a rather easy-to-use API.

Will using JMS to send a message eat up more CPU cycles than doing the same using a socket? Certainly. But unless you've proven that -given the number of messages you need to handle- JMS causes a performance issue that can't be solved by simply running it on a faster server, it's premature to make technology decisions based on performance.


Ping & DNS - my free Android networking tools app
Jack Numen
Ranch Hand

Joined: Nov 09, 2011
Posts: 42

Hi,
I have the same confusion in using JMS for my chat application.
Since my socket program creates a new thread for every user and binds this thread to a port.
Internally the user can be identified using the port number to which he is bound.

The problem is this approach limits the scalability of the Chat Application.
Can anyone suggest another strategy where the entire chat application can be run on a single port without any overheads.


Thanks and Regards,
Jack Numen.
ntumba lobo
Ranch Hand

Joined: Oct 21, 2008
Posts: 180
Harsh, you're saying you want to send messages between your components.

It is true that technically this can be achieved with TCP connections but the main reason why you would go for JMS is to have guaranteed delivery.
That way you are sure that when a component A sends a message to component B, component B will get it eventually.
This is not the case with TCP connection (synchronous), if you have network issue while compo A sends a message to compo B the message will be lost.

So guaranteed develivery is the main reason to go for JMS

Also scalability is another factor in favor of JMS, I could tell more if you're interested...


SCJP 5 , SCWCD 5, SCEA 5
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
ntumba lobo wrote:It is true that technically this can be achieved with TCP connections but the main reason why you would go for JMS is to have guaranteed delivery.

TCP is actually a guaranteed protocol. Is something doesn't work you WILL get an error message. That's different from IP (which is not guaranteed).
ntumba lobo
Ranch Hand

Joined: Oct 21, 2008
Posts: 180
Sure for TCP but the avantage of JMS is that in case of network failure it will not throw an error, it will keep trying silently until the delivery is successful.
With TCP your code has to handle the error and you have to add logic to resend the message, it is completely transparent with JMS.
john lazeraski
Ranch Hand

Joined: Nov 14, 2011
Posts: 76
We were using JMS for async communications a while back. However, other than the guaranteed message delivery mechanism which is nice, we switched to using REST between the tiers for a couple reasons. First, we couldn't find an easier way to send complex objects across JMS nicely. Perhaps there is a good way. However, REST implemented via java, jersey (JAX-RS) handles incoming requests async already, so we didn't need that feature of JMS. Better yet, with REST we could use the same object model, via the JAXB transformation of objects to xml or json and vice versa. Because we already had a rest API, in our case it was very simple to copy/paste some classes, modify and have it running between tiers in minutes. Even better, in our case, the back tier which we were sending data to was a sort of "agent" that could be located anywhere and would basically be passed some data that would then talk to another API translating the data our front tier sent to it, into the endpoint format needed. Because of using REST, we now have a complete document that explains how you can consume the xml/json REST data we send, and write an endpoint in any language/platform that can handle rest. So we're no longer bound to just Java for those endpoint developers that wish to use Ruby, Python, php, whatever. Scaling is very easy..everything is stateless, so we simply add another server and load balance requests to the cluster.

The only issue we have is having the front server "find" the back servers and load balancing between them. The main issue is configuring it for local dev, qa, staging and production servers, which all have their own different ips, some in different geo-locations with different networks.



 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why JMS?
 
Similar Threads
APIs/Strategy to be used in developing web-based chat Application using Servlets.
Chat Application Architecture?
Which JMS provider?
Connecting 2 Computers
HSQLDB in production?