Answers:
JMS（ActiveMQ是JMS代理实现）可以用作允许异步请求处理的机制。您可能希望这样做，因为请求需要很长时间才能完成，或者因为实际的请求可能涉及多个方面。使用它的另一个原因是允许多个客户端（可能以不同的语言编写）通过JMS访问信息。ActiveMQ是一个很好的示例，因为您可以使用STOMP协议来允许从C＃/ Java / Ruby客户端进行访问。
一个真实的示例是用于为特定客户下订单的Web应用程序的示例。作为下订单（并将其存储在数据库中）的一部分，您可能希望执行许多其他任务：
为此，您的应用程序代码会将消息发布到包含订单ID的JMS队列中。您的应用程序中侦听队列的一部分可以通过获取orderId来响应该事件，在数据库中查找订单，然后将该订单提交给另一第三方系统。应用程序的另一部分可能负责获取orderId并向客户发送确认电子邮件。
始终使用它们来异步处理长时间运行的操作。网络用户不希望等待超过5秒来处理请求。如果运行的时间更长，则一种设计是将请求提交到队列，然后立即发送回URL，供用户检查以查看作业何时完成。
发布/订阅是将发送者与许多接收者解耦的另一种好方法。这是一种灵活的体系结构，因为订户可以根据需要来来去去。
我对JMS有很多惊人的用途：
网络聊天交流，以提供客户服务。
在后端调试日志。所有应用服务器都在各个级别广播调试消息。然后可以启动JMS客户端以监视调试消息。当然，我可以使用syslog之类的东西，但这给了我各种各样的方式来根据上下文信息（例如，按应用服务器名称，API调用，日志级别，用户ID，消息类型等对信息进行过滤）。我还为输出着色。
调试日志记录到文件。与上述相同，仅使用过滤器提取特定的片段，并将其记录到文件中以进行常规记录。
警报。同样，与上面的日志记录类似的设置，监视特定错误并通过各种方式（电子邮件，短信，IM，低吼弹出窗口等）提醒人们。
动态配置和控制软件集群。每个应用程序服务器将广播“配置我”消息，然后广播配置守护程序，该守护程序将以包含各种配置信息的消息进行响应。以后，如果所有应用服务器都需要立即更改其配置，则可以通过config守护程序来完成。
和通常的-排队交易延迟活动，例如账单，订单处理，供应，电子邮件生成...
您希望保证异步传递消息的任何地方都非常好。
分布式（a）同步计算。
一个真实的示例可能是整个应用程序范围的通知框架，该框架在应用程序使用过程中的各个时间点将邮件发送给利益相关者。因此，应用程序将Producer通过创建Message对象，将其放在特定对象上Queue并向前移动来充当。
将有一组Consumers会订阅相关的Queue，并会小心处理Message发送过来的内容。请注意，在此交易过程中，Producers与如何Message处理给定逻辑分离。
消息传递框架（ActiveMQ等）充当主干，Message通过提供来促进此类交易MessageBroker。
我用它来发送不同基金管理系统之间的日内交易。如果您想详细了解什么是出色的技术消息传递，我可以为您推荐“ Enterprise Integration Patterns ” 一书。有一些用于请求/回复和发布/订阅之类的JMS示例。
消息传递是集成的绝佳工具。
我们使用它来启动异步处理，我们不想中断或与现有事务冲突。
例如，假设您有一个昂贵且非常重要的逻辑，例如“购买东西”，那么购买东西的重要部分就是“通知东西商店”。我们使通知调用异步进行，以便通知调用中涉及的任何逻辑/处理都不会阻塞或与购买业务逻辑争用资源。最终结果，购买完成，用户满意，我们得到了收益，并且由于保证了队列的交付，因此商店一旦开业或队列中有新商品，便会得到通知。
我将其用于我的学术项目，该项目是类似于Amazon的在线零售网站。JMS用于处理以下功能：
我们还有多个已实现的远程客户端连接到主服务器。如果连接可用，他们将使用访问主数据库，或者如果不使用自己的数据库。为了处理数据一致性，我们实现了2PC机制。为此，我们使用JMS在这些系统之间交换消息，即一个充当协调者的人将通过在队列上发送消息来启动该过程，而另一个将通过在队列中再次发送消息来做出相应的响应。正如其他人已经提到的，这类似于发布/订阅模型。
与ActiveMQ结合使用的Apache Camel是执行企业集成模式的好方法