What is Java Message Service (JMS) for?_问答_开发者

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开发者_Python百科 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?

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.

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.

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.

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.

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.

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.

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

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