views:

500

answers:

2

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.

A: 

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

ewernli
+1  A: 

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:

The SAF service enables WebLogic Server to deliver messages reliably between applications that are distributed across WebLogic Server instances. For example, with the SAF service, an application that runs on or connects to a local WebLogic Server instance can reliably send messages to an endpoint that resides on a remote server. If the destination is not available at the moment the messages are sent, either because of network problems or system failures, then the messages are saved on a local server instance, and are forwarded to the remote endpoint once it becomes available.

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.

Pascal Thivent