What is Java Message Service (JMS) for?

Question

I am currently evaluating JMS and I don't get what I could use it for.

Currently, I believe this would be a Usecase: I want to create a SalesInvoice PDF and print it when an SalesOrder leaves the Warehouse, so during the Delivery transaction I could send a transactional print request which just begins when the SalesOrder transaction completes successfully.

Now I found out most JMS products are standalone server.

• Why would a need a Standalone Server for Message Processing, vs. e.g. some simple inproc processing with Quartz scheduler?
• How does it interact with my application?
• Isn't it much too slow?
• What are Usecases you already implemented successfully?

Answer 1

I've used it on a number of projects. It can help with scalability, decoupling of services, high availability. Here's a description of how I used it on a project several years ago:

http://coders-log.blogspot.com/2008/12/favorite-projects-series-installment-2.html

The description explains what JMS brought to the table for this particular project, but other projects will use messaging systems for a variety of reasons.

Answer 2

Messaging is usually used to interconnect different systems and send requests/commands asynchronously. A common example is a bank client application requesting an approval for a transaction. The server is located in another bank's system. Both systems are connected in an Enterprise Service Bus. The request goes into the messaging bus, which instantly acknowledges the reception of the message. The client can go on with processing. Whenever the server system becomes available, the bus forwards the message to it. Of course there needs to be a second path, for the server to inform the client that the transaction executed successfully or failed. This again can be implemented with JMS.

Please note that the two systems need not to implement JMS. One can use JMS and the other one MSMQ. The bus will take care of the interconnection.

Answer 3

From the Javadoc:

The Java Message Service (JMS) API provides a common way for Java programs to create, send, receive and read an enterprise messaging system's messages.

In other words, and contrary to every other answer here, JMS is nothing more than an API, which wraps access to third-party Message Brokers, via 'JMS Providers' implemented by the vendor. Those Message Brokers, such as IBM MQ and dozens of others, have the features of reliability, asynchronicity, etc. that have been mentioned in other answers. JMS itself provides exactly none of them. It is to Message Brokers what JDBC is to SQL databases, or JNDI is to LDAP servers (among other things).

Answer 4

I have found a very good explanation of JMS with an example.

That is a simple chat application with JMS queues are used to communicate messages between users and messages stay in the queue if the receiver is offline.

In this example implementation they have used

• XSD to generate domain classes.
• Eclipse EE as IDE.
• JBoss as web/application server.
• HTML/JavaScript/JQuery for UI.
• Servlet as controller.
• MySQL as DB.

The JBoss configuration step for queue is explained nicely Its available at http://coder2design.com/messaging-service/

Even the downloadable code is also available there.

Answer 5

Why would a need a Standalone Server for Message Processing, vs. e.g. some simple inproc processing with Quartz scheduler?

The strength of JMS lies in the fact that you can have multiple producers and multiple consumers for the same queue, and the JMS broker manages the load.

If you have multiple producers but a single consumer, you can use other approaches as well, such as a quartz scheduler and a database table. But as soon as you have multiple consumer, the locking scheme become very hard to design; better go for already approved messaging solution. See these other answers from me for a few more details: Why choosing JMS for asynchronous solution ? and Producer/consumer system using database

The other points are just too vague to be answered.

Answer 6

JMS is an amazingly useful system, but not for every purpose.

It's essentially a high-level framework for sending messages between nodes, with options for discovery, robustness, etc.

One useful use case is when you want a client and a server to talk to one another, but without the client actually having the server's address (E.g., you may have more than one server). The client only needs to know the broker and the queue/topic name, and the server can connect as well.

JMS also adds robustness. For instance, you can configure it so that if the server dies while the client sends messages or the other way around, you can still send messages from the client or poll messages from the server. If you ever tried implementing this directly with sockets - it's a nightmare.

The scenario you describe sounds like a classic J2EE problem, why are you not using a J2EE framework? JMS is often used inside J2EE for communications, but you got all the other benefits.