At the moment I am using RMI or hessian library to communicate between my server and clients (via a LinkedBlockingQueue). Now I read about JMS which could be used in this area too. Is this correct? If yes, would you mind to give me a simple list of advantages/disadvantages, because it seems to be a pretty complicated and ‘fullblown-enterprise’ area.
What are the benefits? And what about the performance compared to RMI+Queue? Could JMS beat RMI+Queue?
PS: I know there are similar questions, but I would like to have JMS compared to RMI+Queue.
A simplified comparison would be (not particular to JMS, more like comparison against MQ in general)…
Automatic retry
If you are a client doing a RMI to a server and for some reason RMI fails, you have to try again yourself. If you’d use JMS and you are the client, you’d just send the JMS message. When the server can not be reached, your message will be stored and then delivered when the server is up again.
Persistent queue
Since you are using a LinkedBlockingQueue, you can either have a bounded queue or an unbounded queue in-memory. The former will start to trap threads once the queue is full and will eventually fail under high load. The later would eventually throw OutOfMemoryError instead. If you’d use JMS though, it can automatically start to “persist” messages to “persistent storage”. Normally “persistent storage” is DB, which has usually much more capacity than in-memory queue. Of course, content of in-memory queue is lost when the server goes down etc., whereas in JMS you can choose durable message/persistent message that survives such event. This also allows you to have clustering, which is also very important for enterprise programs…
Abstraction
You’ll be using a standardized API (ok, you have protocols in RMI too, but if what you want is passing around messages, MQ provides much more high level abstraction than RMI+in-memory queue). Which means, you get to use future implementations of JMS.. Perhaps something that doesn’t need a DB to provide durability and persistence, more scalable than today’s implementation etc. Or maybe you can send the same message to completely different service, because of the standerization. Basically, the higher abstraction could give you flexibility, that RMI+in-memory queue doesn’t.
Some time ago, I worked with a big company that wanted to use their in-house framework to integrate our stuff. At that time we weren’t using a MQ. We asked them to use our own asynchronous protocol based on RMI. Trust me, we regretted that decision very, very much…