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

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.

Answer 2

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 3

JMS is a message-oriented middleware.

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

It depends on what other components you may have. I guess. But I don't know anything about Quartz

• How does it interact with my application?

You send messages to the broker.

• Isn't it much too slow?

Compare to what ?

• What are Usecases you already implemented successfully?

I've used JMS to implement a SIP application server, to communicate between the various components.

Answer 4

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 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

What ist Java Message Service (JMS) for

JMS is a messaging standard that allows Java EE applications to create, send, receive, and consume messages in a loosely coupled, reliable, and asynchronous way. I'd suggest to read the Java Message Service API Overview for more details.

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

Sure, in your case, Quartz is an option. But what if the invoice system is a remote system? What if you don't want to wait for the answer? What if the remote system is down when you want to communicate with it? What if the network is not always available? This is where JMS comes in. JMS allows to send a message guaranteed to be delivered and to consume it in a transactional way (sending or consuming a message can be part of a global transaction).

How does it interact with my application?

JMS supports two communication modes: point-to-point and publish/subscribe (if this answers the question).

Isn't it much too slow?

The MOMs I've been working with were blazing fast.

What are Usecases you already implemented successfully?

Used in system such as a reservation application, a banking back-office (processing market data), or more simply to send emails.

See also

• EJB Message-Driven Beans