JMS between Enterprise applications

Question

Hi

We have a project where we want to link 2 enterprise systems together using JMS. In a nutshell, system 1 sends a message to the queue. Systems2 picks up that message, does a whole load of processing in the background for about 30mintues and then sends a message back to the queue for System1 to pick up.

Can we get away with 1 queue or do we need 2? If we have 2 queues then, System1 writes to queue1, System2 picks up. When system2 is ready, it writes to queue2 and System1 picks it up.

Which approach would be the best? If anyone knows of any limitations to these approaches, or any better solutions, then please do share

Thanks Damien

Answer 1

You can employ selectors on a queue, but I would advise keeping it simple and using 2 queues as you described. I prefer to domain message types into separate queues and I think you'll find that the easiest to manage too.

A queue is largely just a logical name for a bucket of messages and little if any further overhead than all messages in a single queue.

Answer 2

If this is a dedicated peer-to-peer interface and neither of these applications acts like a server, then you could get away with a single queue. However this model does not support the client-server pattern. On the other hand, the client-server pattern supports a peer-to-peer interface as well as client-server interface and it is no harder to implement so why not use it?

Specifically, a server listens on a well-known queue. Any app wanting to drive that service sends a message to the well-known queue. The message contains the address of a Reply-To destination and the server sends the reply to that destination. In this way a server application can process requests from many relatively anonymous (or authenticated if so desired) clients anywhere on the network.

This approach also supports the client and server queue not being on the same message engine. It supports accessing the queues in FIFO mode which should be more performant. It handles the classic asynch messaging case of fast producer, slow consumer better than a single queue. It supports dynamic reply-to destinations. It allows the applications to be relocated independent of each other. And if what you have is truly a peer-to-peer with no elements of the client-server pattern then this architecture supports that too.