Friday, May 27, 2011

An Alternative Method to the Request-Reply Pattern for Message-Driven Application Configuration

On a recent ActiveMQ forum discussion, I presented an alternative to a common problem that I've seen more and more people running into.

I've seem some companies using JMS - Java Message Service to provide application configuration based on the client profile. So, basically when the application starts, it connects to a JMS broker and then request its information. The application then receives all information necessary like settings, connections URLs, what destinations to read from and send to, etc.

That's a very smart way to dynamically provide that kind of information and be able to make changes on the fly if necessary.

You can transparently add and remove new features on the backend systems, change destinations, change server URLs, without performing any major update on the client side.

What I also have noticed is that most of the people uses the JMS request-reply mechanism to achieve that which is a good way to do it but can cause some side effects and problems during the client-broker communication once the client application will be waiting for a response from the another application through the JMS broker.

So, one alternative way to do that without the request-reply mechanism in place is employing the traditional point-to-point messaging model.

Using point-to-point messaging techniques you can load the necessary configuration message to an ordinary queue and the client applications can read the necessary information from there.

The client can instead of consume the message from the configuration queue, just browse the queue, which means that the client reads the message but doesn't remove it, so other client applications can benefit from the same configuration message as well.

You also have the ability to load multiple configuration messages to the configuration queue with different message headers where the clients could use the JMS message selector capability to get the right message.

When you need to update the configuration message you can consume that message administratively (simply connect a JMS client and consume the message would be the most simple way to do that) and then load the most updated information where the client applications can start reading from.

You can also take a different approach and create a queue for each client application profile you have but that may not be the best way to do it if you have a large installation base as it will certainly consume more resources on the broker.

Lastly, you can implement something really creative if you implement a Camel route to provide the client application configuration but I'll cover that on another post.

In summary, the idea here is to avoid the risk of the replier application not being able to respond in a timely fashion (it maybe be busy or offline) or consuming too many resources on the JMS broker with the request-reply pattern.

Setting Up Local Environment for Developing Oracle Intelligent Bots Custom Components

Oh the joy of having a local development environment is priceless. For most cloud based solutions the story repeats itself being hard to tr...