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.
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)
Joined: Oct 13, 2009
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.
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.
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.
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...
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).
Joined: Oct 21, 2008
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.
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 run java and javac in a Cygwin terminal. I figured out which java it was using, then aliased javac as I have issues sharing paths between cygwin and Windows.
Ooops, I may have a problem there When I set this up I didn't have a system32/java....
Eclipse runs fine, but I prefer my CLI methods.
It's a no-brainer. We just need to take it to the next level to turn this into a win-win situation. The best practice is to get rid of the low-hanging fruit first. Ping me with an agenda so we can go flag up on this thing