JMS in combination with JTA (Java Transaction API) and JPA (Java persistence API) can be very useful. With a simple annotation you can put several database actions + message sending/receiving in the same transaction. So if one of them fails everything gets rolled back using the same transaction mechanism.
The 'database as message queue' solution may be heavy for the task. The JMS solution is less tightly coupled in that the message sender does not need to know anything about the recipient. This could be accomplished with some additional abstraction in the 'database as message queue' as well so it is not a huge win...Also, you can use the queue in a 'publish and subscribe' way which can be handy depending on what you are trying to accomplish. It is also a nice way to further decouple your components. If all of your communication is within one system and/or having a log that is immediately available to an application is very important, your method seems good. If you are communicating between separate systems JMS is a good choice.
The key advantage is decoupling unrelated systems rather than have them share comon databases or building custom services to pass data around.
Banks are a keen example, with intraday messaging being used to pass around live data changes as they happen. It's very easy for the source system to throw a message "over the wall"; the downside is there's very little in the way of contract between these systems, and you normally see hospitalisation being implemented on the consumer's side. It's almost too loosly coupled.
Other advantages are down to the support for JMS out of the box for many application servers, etc. and all the tools around that: durability, monitoring, reporting and throttling.
Guido has the full definition. From my experience all of these are important for a good fit.
One of the uses I've seen is for order distribution in warehouses. Imagine an office supply company that has a fair number of warehouses that supply large offices with office supplies. Those orders would come into a central location and then be batched up for the correct warehouse to distribute. The warehouses don't have or want high speed connections in most cases so the orders are pushed down to them over dialup modems and this is where asynchronous comes in. The phone lines are not really that important either so half the orders may get in and this is where reliability is important.
JMS is an API used to transfer messages between two or more clients. It's specs are defined under JSR 914.
The major advantage of JMS is the decoupled nature of communicating entities - Sender need not have information about the receivers. Other advantages include the ability to integrate heterogeneous platforms, reduce system bottlenecks, increase scalability, and respond more quickly to change.
JMS are just kind of interfaces/APIs and the concrete classes must be implemented. These are already implemented by various organizations/Providers. they are called JMS providers. Example is WebSphere by IBM or FioranoMQ by Fiorano Softwares or ActiveMQ by Apache, HornetQ, OpenMQ etc. .Other terminologies used are Admin Objects(Topics,Queues,ConnectionFactories),JMS producer/Publisher, JMS client and the message itself.
So coming to your question - what is JMS good for?
I would like to give a practical example to illustrate it's importance.
Day Trading
There is this feature called LVC(Last value cache)
In Trading share prices are published by a publisher at regular intervals. Each share has an associated Topic to which it is published to. Now if you know what a Topic is then you must know messages are not saved like queues. Messages are published to the subscribers alive at the time the message was published(Exception being Durables subscribers which get all the messages published from the time it was created but then again we don't want to get too old stock prices which discard the possibility of using it). So if a client want to know a stock price he create a subscriber and then he has to wait till next stock price is published(which is again not what we want). This is where LVC comes into picture. Each LVC message has an associated key. If a messages is sent with a LVC key(for a particular stock) and then another update message with same key them the later overrides the previous one. When ever a subscriber subscribes to a topic(which has LVC enabled) the subscriber will get all the messages with distinct LVC keys. If we keep a distinct key per listed company then when client subscribes to it it will get the latest stock price and eventually all the updates.
Ofcourse this is one of the factors other that reliability,security etc which makes JMS so powerful.
a) 消息的使用者可以位于远程位置。 公开数据库进行远程访问是危险的。 您可以通过提供额外的服务来从数据库读取消息来解决此问题，但这需要更多的努力。
b) 对于数据库，消息使用者必须轮询数据库中的消息，而 JMS 在消息到达时提供回调（如 sk 提到的）
c) 负载平衡 - 如果有大量消息传入，则很容易拥有池JMS 中的消息处理器。
d) 一般来说，通过 JMS 实现比数据库路由更简单、更省力
One advantage of JMS is to enable asynchronous processing which can by done by database solution as well. However following are some other benefit of JMS over database solution
a) The consumer of the message can be in a remote location. Exposing database for remote access is dangerous. You can workaround this by providing additional service for reading messages from database, that requires more effort.
b) In the case of database the message consumer has to poll the database for messages where as JMS provides callback when a message is arrived (as sk mentioned)
c) Load balancing - if there are lot of messages coming it is easy to have pool of message processors in JMS.
d) In general implementation via JMS will be simpler and take less effort than database route
to address the original comment. what was originally described is the gist of (point-to-point) JMS. the benefits of JMS are, however:
you don't need to write the code yourself (and possibly screw up the logic so that it's not quite as persistent as you think it is). also, third-party impl might be more scalable than simple database approach.
jms handles publish/subscribe, which is a bit more complicated that the point-to-point example you gave
you are not tied to a specific implementation, and can swap it out if your needs change in the future, w/out messing w/ your java code.
The JMS implementation is "push", in the sense that you don't have to poll the queue to discover new messages, but you register a callback that gets called as soon as a new message arrives.
In my opinion JMS and other message-based systems are intended to solve problems that need:
Asynchronous communications : An application need to notify another that an event has occurred with no need to wait for a response.
Reliability. Ensure once-and-only-once message delivery. With your DB approach you have to "reinvent the wheel", specially if you have several clients reading the messages.
Loose coupling. Not all systems can communicate using a database. So JMS is pretty good to be used in heterogeneous environments with decoupled systems that can communicate over system boundaries.
JMS and messaging is really about 2 totally different things.
publish and subscribe (sending a message to as many consumers as are interested - a bit like sending an email to a mailing list, the sender does not need to know who is subscribed
high performance reliable load balancing (message queues)
The case you are talking about is the second case, where yes you can use a database table to kinda simulate a message queue.
The main difference is a JMS message queue is a high performance highly concurrent load balancer designed for huge throughput; you can send usually tens of thousands of messages per second to many concurrent consumers in many processes and threads. The reason for this is that a message queue is basically highly asynchronous - a good JMS provider will stream messages ahead of time to each consumer so that there are thousands of messages available to be processed in RAM as soon as a consumer is available. This leads to massive throughtput and very low latency.
e.g. imagine writing a web load balancer using a database table :)
When using a database table, typically one thread tends to lock the whole table so you tend to get very low throughput when trying to implement a high performance load balancer.
But like most middleware it all depends on what you need; if you've a low throughput system with only a few messages per second - feel free to use a database table as a queue. But if you need low latency and high throughput - then JMS queues are highly recommended.
发布评论
评论（11）
JMS 与 JTA（Java 事务 API）和 JPA（Java 持久性 API）结合起来会非常有用。 通过简单的注释，您可以将多个数据库操作+消息发送/接收放在同一个事务中。 因此，如果其中之一失败，所有内容都会使用相同的事务机制回滚。
JMS in combination with JTA (Java Transaction API) and JPA (Java persistence API) can be very useful. With a simple annotation you can put several database actions + message sending/receiving in the same transaction. So if one of them fails everything gets rolled back using the same transaction mechanism.
“数据库即消息队列”解决方案对于这项任务来说可能很繁重。 JMS 解决方案的耦合程度较低，因为消息发送方不需要了解有关接收方的任何信息。 这也可以通过“数据库作为消息队列”中的一些额外抽象来完成，因此这不是一个巨大的胜利...此外，您可以以“发布和订阅”方式使用队列，这可以根据需要方便地使用你正在努力实现。 这也是进一步解耦组件的好方法。 如果您的所有通信都在一个系统内，并且/或者拥有一个可供应用程序立即使用的日志非常重要，那么您的方法似乎不错。 如果您在不同的系统之间进行通信，JMS 是一个不错的选择。
The 'database as message queue' solution may be heavy for the task. The JMS solution is less tightly coupled in that the message sender does not need to know anything about the recipient. This could be accomplished with some additional abstraction in the 'database as message queue' as well so it is not a huge win...Also, you can use the queue in a 'publish and subscribe' way which can be handy depending on what you are trying to accomplish. It is also a nice way to further decouple your components. If all of your communication is within one system and/or having a log that is immediately available to an application is very important, your method seems good. If you are communicating between separate systems JMS is a good choice.
这里有一篇很好的文章，其中包含一些示例： http://www.winslam.com/ laramee/jms/index.html
There's a nice write-up with some examples here: http://www.winslam.com/laramee/jms/index.html
关键优势是解耦不相关的系统，而不是让它们共享公共数据库或构建自定义服务来传递数据。
银行就是一个典型的例子，当实时数据发生变化时，会使用日间消息传递来传递这些变化。 源系统很容易将消息“越过墙”； 缺点是这些系统之间的合同很少，而且您通常会看到住院治疗是在消费者方面实施的。 它的耦合几乎太松散了。
其他优势在于对许多应用程序服务器等的开箱即用的 JMS 支持以及与之相关的所有工具：耐用性、监控、报告和限制。
The key advantage is decoupling unrelated systems rather than have them share comon databases or building custom services to pass data around.
Banks are a keen example, with intraday messaging being used to pass around live data changes as they happen. It's very easy for the source system to throw a message "over the wall"; the downside is there's very little in the way of contract between these systems, and you normally see hospitalisation being implemented on the consumer's side. It's almost too loosly coupled.
Other advantages are down to the support for JMS out of the box for many application servers, etc. and all the tools around that: durability, monitoring, reporting and throttling.
Guido 有完整的定义。 根据我的经验，所有这些对于良好的配合都很重要。
我见过的用途之一是在仓库中分配订单。 想象一下，一家办公用品公司拥有相当数量的仓库，可以为大型办公室提供办公用品。 这些订单将进入一个中心位置，然后批量分配给正确的仓库。 在大多数情况下，仓库没有或不需要高速连接，因此订单通过拨号调制解调器推送给仓库，这就是异步的用武之地。电话线实际上也不是那么重要，因此一半的订单可能会进入并且这就是可靠性很重要的地方。
Guido has the full definition. From my experience all of these are important for a good fit.
One of the uses I've seen is for order distribution in warehouses. Imagine an office supply company that has a fair number of warehouses that supply large offices with office supplies. Those orders would come into a central location and then be batched up for the correct warehouse to distribute. The warehouses don't have or want high speed connections in most cases so the orders are pushed down to them over dialup modems and this is where asynchronous comes in. The phone lines are not really that important either so half the orders may get in and this is where reliability is important.
JMS 是用于在两个或多个客户端之间传输消息的 API。 它的规范是在 JSR 914 下定义的。
JMS 只是一种接口/API，必须实现具体的类。 这些已经由各种组织/提供商实施。 它们被称为 JMS 提供者。 示例是 IBM 的 WebSphere 或 FioranoMQ（由 Fiorano Softwares 提供）或 ActiveMQ（由 Apache、HornetQ、OpenMQ 等提供）。使用的其他术语包括管理对象（主题、队列、连接工厂）、JMS 生产者/发布者、JMS 客户端和消息本身。
那么回到你的问题 -
JMS 有什么好处？我想举一个实际的例子来说明它的重要性。
当日交易
有一个名为LVC（最后值缓存）
在交易中，股票价格由发布者定期发布。 每个共享都有一个与其发布到的关联主题。 现在，如果您知道主题是什么，那么您必须知道消息不像队列那样保存。 消息会发布给消息发布时有效的订阅者（例外是 Durables 订阅者，它们会获取从创建之日起发布的所有消息，但话又说回来，我们不希望获得太旧的股票价格，从而放弃了使用它）。 因此，如果客户想知道股票价格，他会创建一个订阅者，然后他必须等到下一个股票价格发布（这又不是我们想要的）。 这就是 LVC 发挥作用的地方。 每个 LVC 消息都有一个关联的密钥。 如果使用 LVC 密钥（针对特定股票）发送消息，然后使用相同密钥发送另一条更新消息，则后者将覆盖前一个。 当订阅者订阅某个主题（启用了 LVC）时，订阅者将获得具有不同 LVC 密钥的所有消息。 如果我们为每个上市公司保留一个不同的密钥，那么当客户订阅它时，它将获得最新的股票价格并最终获得所有更新。
当然，这是除了可靠性、安全性等之外，JMS 如此强大的因素之一。
JMS is an API used to transfer messages between two or more clients. It's specs are defined under JSR 914.
JMS are just kind of interfaces/APIs and the concrete classes must be implemented. These are already implemented by various organizations/Providers. they are called JMS providers. Example is WebSphere by IBM or FioranoMQ by Fiorano Softwares or ActiveMQ by Apache, HornetQ, OpenMQ etc. .Other terminologies used are Admin Objects(Topics,Queues,ConnectionFactories),JMS producer/Publisher, JMS client and the message itself.
So coming to your question -
what is JMS good for?I would like to give a practical example to illustrate it's importance.
Day Trading
There is this feature called LVC(Last value cache)
In Trading share prices are published by a publisher at regular intervals. Each share has an associated Topic to which it is published to. Now if you know what a Topic is then you must know messages are not saved like queues. Messages are published to the subscribers alive at the time the message was published(Exception being Durables subscribers which get all the messages published from the time it was created but then again we don't want to get too old stock prices which discard the possibility of using it). So if a client want to know a stock price he create a subscriber and then he has to wait till next stock price is published(which is again not what we want). This is where LVC comes into picture. Each LVC message has an associated key. If a messages is sent with a LVC key(for a particular stock) and then another update message with same key them the later overrides the previous one. When ever a subscriber subscribes to a topic(which has LVC enabled) the subscriber will get all the messages with distinct LVC keys. If we keep a distinct key per listed company then when client subscribes to it it will get the latest stock price and eventually all the updates.
Ofcourse this is one of the factors other that reliability,security etc which makes JMS so powerful.
JMS 的优点之一是支持异步处理，这也可以通过数据库解决方案来完成。 然而，以下是 JMS 相对于数据库解决方案的一些其他优势：
a) 消息的使用者可以位于远程位置。 公开数据库进行远程访问是危险的。 您可以通过提供额外的服务来从数据库读取消息来解决此问题，但这需要更多的努力。
b) 对于数据库，消息使用者必须轮询数据库中的消息，而 JMS 在消息到达时提供回调（如 sk 提到的）
c) 负载平衡 - 如果有大量消息传入，则很容易拥有池JMS 中的消息处理器。
d) 一般来说，通过 JMS 实现比数据库路由更简单、更省力
One advantage of JMS is to enable asynchronous processing which can by done by database solution as well. However following are some other benefit of JMS over database solution
a) The consumer of the message can be in a remote location. Exposing database for remote access is dangerous. You can workaround this by providing additional service for reading messages from database, that requires more effort.
b) In the case of database the message consumer has to poll the database for messages where as JMS provides callback when a message is arrived (as sk mentioned)
c) Load balancing - if there are lot of messages coming it is easy to have pool of message processors in JMS.
d) In general implementation via JMS will be simpler and take less effort than database route
解决原始评论。 最初描述的是（点对点）JMS 的要点。 然而，JMS 的好处是：
您不需要自己编写代码（并且可能会搞砸逻辑，使其不像您想象的那么持久）。 此外，第三方 impl 可能比简单的数据库方法更具可扩展性。
jms 处理发布/订阅，这比您给出的点对点示例要复杂一些
to address the original comment. what was originally described is the gist of (point-to-point) JMS. the benefits of JMS are, however:
you don't need to write the code yourself (and possibly screw up the logic so that it's not quite as persistent as you think it is). also, third-party impl might be more scalable than simple database approach.
jms handles publish/subscribe, which is a bit more complicated that the point-to-point example you gave
you are not tied to a specific implementation, and can swap it out if your needs change in the future, w/out messing w/ your java code.
JMS 实现是“推送”的，即您不必轮询队列来发现新消息，而是注册一个回调，一旦新消息到达，该回调就会被调用。
The JMS implementation is "push", in the sense that you don't have to poll the queue to discover new messages, but you register a callback that gets called as soon as a new message arrives.
在我看来，JMS 和其他基于消息的系统旨在解决需要以下功能的问题：
In my opinion JMS and other message-based systems are intended to solve problems that need:
JMS 和消息传递实际上是两个完全不同的事情。
查看更多信息 < a href="http://activemq.apache.org/how-does-a-queue-compare-to-a-topic.html" rel="noreferrer">队列与主题的比较
你所说的情况是第二种情况，是的，你可以使用数据库表来模拟消息队列，
主要区别是JMS消息队列是一种高性能高并发负载均衡器，设计用于通常可以发送的巨大吞吐量；每秒向许多进程和线程中的许多并发消费者发送数万条消息，原因是消息队列基本上是高度异步的 - 优秀的 JMS 提供者会提前将消息流式传输给每个消费者，以便一旦有数千条消息可以在 RAM 中处理消费者可用。 这会带来巨大的吞吐量和非常低的延迟。
例如，想象一下使用数据库表编写一个 Web 负载均衡器:)
当使用数据库表时，通常一个线程倾向于锁定整个表，因此在尝试实现高性能负载均衡器时，您往往会获得非常低的吞吐量。
但与大多数中间件一样，这一切都取决于您的需求； 如果您的系统吞吐量较低，每秒只有几条消息，请随意使用数据库表作为队列。 但如果您需要低延迟和高吞吐量 - 那么强烈建议使用 JMS 队列。
JMS and messaging is really about 2 totally different things.
See more info on how a queue compares to a topic
The case you are talking about is the second case, where yes you can use a database table to kinda simulate a message queue.
The main difference is a JMS message queue is a high performance highly concurrent load balancer designed for huge throughput; you can send usually tens of thousands of messages per second to many concurrent consumers in many processes and threads. The reason for this is that a message queue is basically highly asynchronous - a good JMS provider will stream messages ahead of time to each consumer so that there are thousands of messages available to be processed in RAM as soon as a consumer is available. This leads to massive throughtput and very low latency.
e.g. imagine writing a web load balancer using a database table :)
When using a database table, typically one thread tends to lock the whole table so you tend to get very low throughput when trying to implement a high performance load balancer.
But like most middleware it all depends on what you need; if you've a low throughput system with only a few messages per second - feel free to use a database table as a queue. But if you need low latency and high throughput - then JMS queues are highly recommended.