如何使用 Glassfish 的 JMS Broker 来“代理”发送到互联网上的 JMS 代理的消息？
我正在开发一个在我的本地 Glassfish3 安装上运行的 Java EE 6 企业应用程序。我的一个 EJB 需要将消息发送到位于 Internet 上某处的远程 JMS 代理。
不幸的是，互联网连接相当不可靠，所以我的想法是首先将消息发送到本地 Glassfish 自己的 JMS Broker。然后，我的本地代理会将消息转发到远程代理。如果互联网连接不可用，本地代理将简单地等待，直到连接恢复。
我的假设是否正确？如果是这样，我将非常感谢一些如何开始的想法。
I am working on a Java EE 6 Enterprise Application that runs on my local Glassfish3 installation. One of my EJBs needs to send messages to a remote JMS Broker which is located somewhere on the Internet.
Unfortunately, the Internet connection is rather unreliable, so my idea is to first send the messages to the local Glassfish's own JMS Broker. My local broker would then forward the messages to the remote broker. Should the internet connection be unavailable, the local broker would simply wait until the connection came back up.
Am I correct in assuming this will work? If so, I would highly appreciate some ideas how to get started.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这种方法对于这种情况（当远程端点并不总是可用时）完全有效，并且被称为“存储并转发”消息传递。事实上，许多应用程序服务器都支持这种开箱即用的功能，例如 WebLogic 和他的 存储转发服务：
对于 Open MQ（GlassFish 的 JMS 实现），我知道存储和转发消息传递包含在功能计划中（请参阅此演示文稿从 2007 年起）。但我很难找到确切的状态（像 this one 并没有真正澄清情况）。可以肯定的是，GlassFish v3 使用 Open MQ 4.4 并且 Open MQ 4.4 有 JMS 桥（这是存储和转发所必需的），您可以将其用于经纪人之间的通信。请参阅这篇最近的博客文章了解如何配置它（找不到打开 MQ 4.4！！）。就我个人而言，我会在开发邮件列表上发布一条消息。
现在，如果这不是很清楚，或者如果您没有得到满意的答案，那么总是可以编写一个自定义应用程序来使用消息并将它们转发到不同的代理，而且并不那么复杂。基本上，存储和转发消息传递意味着为应用程序使用“本地”持久队列，并使用 MDB 来使用消息并将它们发送到远程 JMS 目标（在单个事务中）。这需要一些进一步的测试，但作为 JMS 客户端，处理转发的 MDB 应该能够透明地重新连接到远程目标。
This approach is perfectly valid for this situation (when the remote endpoint is not always available) and is known as "store-and-forward" messaging. In fact, many application servers support this out of the box, for example WebLogic and his Store and Forward service:
In the case of Open MQ (GlassFish's JMS implementation), I known that Store and Forward messaging was on the features plans (see this presentation from 2007). But I have some difficulties to find an exact status on this (messages like this one don't really clarify the situation). What is sure is that GlassFish v3 uses Open MQ 4.4 and Open MQ 4.4 has JMS bridge (which is required for store and forward) and you may be able to use it for broker to broker communication. See this recent blog post on how to configure it (couldn't find the documentation of Open MQ 4.4!!). Personally, I'd post a message on the dev mailing list.
Now, if this isn't really clear, or if you don't get a satisfying answer, it's always possible to write a custom application to consume messages and forward them to a different broker and it is not that complicated. Basically, store and forward messaging means using a "local" persistent queue for the application and using a MDB to consume the messages and send them to the remote JMS destination (in a single transaction). This would require some further testing but, as a JMS client, the MDB that handles the forwarding should be able to reconnect transparently to the remote destination.
当客户端（生产者或消费者）不可靠时，JMS 非常适合，但如果代理本身不可靠，您就会遇到麻烦。
您可以尝试使用“登台”代理的重新交付参数（超时、重试次数等）。但是，您仍然需要一个充当转发器的虚拟 MDB：声明代理尝试将数据传送到尝试连接外部代理的虚拟 MDB。如果不能，事务将失败并且消息保留在登台代理中。然后，声明代理将稍后尝试将消息重新传送到虚拟 MDB。
如果 MDB 无法将消息转发到“外部”代理，“登台”代理的重新传递功能可以帮助管理连接问题。但请注意，在某个时间点，消息可能会进入“暂存”代理的死消息队列 (DMQ)，甚至会被丢弃，具体取决于其配置方式。
但这对我来说仍然听起来有点奇怪......
JMS is well suited when the clients (producer or consumer) are not reliable, but in the case the broker itself is not reliable you are in trouble.
You could try to play with the redelivery parameters (timeout, # of retry, etc) of the "staging" broker. You however still need a dummy MDB that act as a forwarer: the stating broker attempts to deliver to the dummy MDB which tries to connect the the external broker. If it can't the transaction fails and the message remains in the staging broker. The stating broker will then try to redeliver the message to the dummy MDB later on.
The redelivery capabilities of the "staging" broker could then help to manage connectivity issues in case the MDB can't forward the message to the "external" brokers. Beware nevertheless that at a point in time the message may go the dead message queue (DMQ) of the "staging" broker or even be discarded depending depending on how it's configured.
But this still sounds a bit strange to me...