Question

I’m reading this section of Java EE tutorial.
http://download.oracle.com/javaee/6/tutorial/doc/bncfu.html#bncfy

And have a question: If I have a JMS client (not Server) that produces messages and sends them to a destination queue that is on the server, does this producer.setDeliveryMode(DeliveryMode.PERSISTENT); still applies?

I mean does JMS client support any mechanism to persist messages or that is only comes with the provider/sever software?

Thanks

Answer 1

Since JMS is just a specification, there is nothing that would prevent an implementation from providing some level of message persistence at the client. However, in practice all implementations (that I am aware of anyway) delegate that to the broker.

Keep in mind that messaging was originally designed to have a broker at every node in the same way that every node also had a TCP/IP, LU6.2 or other transport stack. In that sense messaging was strictly supposed to be a transport, not a central service like a database. The intention was to provide a local service that insulated the application from unavailability of the network and also from the myriad of synchronous transport protocols that were available. In this model, the broker was always local and the only network communication was between two brokers.

Over the years, messaging added a client capability but this is more about licensing costs than architecture. The messaging client connection re-introduced a dependency on synchronous network connectivity that the transport had originally been intended to shield the application from. We have now come full circle as your question illustrates – a requirement for a local queuing to shield the application from unavailability of the network. Except now the application requiring a local persistence for messages is in fact the (supposedly) asynchronous messaging application.

We could of course build a local mini-broker to queue messages before they get to the central broker. But before we go making the client code much more complex (and inviting an infinite recursion of backing our async messaging with yet more async messaging) I would recommend taking a second look at the original messaging architecture – put the broker local to the applications which require that level of persistence.

One approach to this is to treat service provider apps differently than service consumer apps. It is the service providers who require deep, persistent message stores and, because they are often transactional, cannot be allowed to fail over to a different instance of the broker (in this case “different” as recognized by the XA resource manager).

On the other hand, simple request/reply apps can continue to anonymously connect over the network to a lightweight tier of brokers with no permanent queues on them. These apps issue a request message outside of syncpoint and wait for the reply on a dynamic queue. If they fail over, they can just reissue the request and the reply will come to the new node. These are ideal candidates for networked, client-based messaging since they have no affinity to a particular broker. As long as there is a network hop between client and server apps, there is no need to make sure that clients fail over with servers, etc. Service providers have local brokers and service consumers have two (or more) lightweight central brokers to connect to.

Of course, this does not meet every async messaging requirement but it does provide a solution that provides highest reliability for systems of record and still conserves license costs by allowing service requestors to share centralized brokers.