Implementing Store and Forward pattern Using WSO2 ESB/JMS MessageStores with fault handling

WSO2 ESB can be used for implementing Store and Forward messaging patterns using message stores and Processors.

The store and forward messaging pattern is used by clients to send the messages to a WSO2 ESB proxy service. Proxy service will be storing the messages in a message store. Lately Message Processor will fetch those messages and send it to the back end. This main objective of this sort of a design is to make sure the client doesn't loose any messages in the event of failure of back end services.

This entire operation can be depicted in this diagram.

Let me explain the operation in full detail.

1. Initially client sends a message to the Proxy service of WSO2 ESB.
2. Proxy service stores the message in to persistent/in-memory Message store. Before the message being inserted to storage, ESB's message store serializes the messages by using store mediator.
3. Message Processor will act either as sampling processor or forwarding processor. This diagram depicts of a message forwarding processor where the processor won't pop the message from queue until the message delivered successfully. Message store can just pass the message back to the endpoint or before sending to the back end it can perform some operations on the message.
4. Eventually the message will be send to back end server.

In this blog post I will be using ActiveMQ (as JMS store ) and Message Forwarding Processor( as message processor). 

Implementing Store and Forward messaging patterns using WSO2 ESB

Download and install the ActiveMQ from here.

Create a Proxy Service in WSO2 ESB. You can go through the ESB samples on how to create proxy services.

  


In this proxy service, I have defined only the essential components to explain the Store and Forward messaging pattern. Here "inSequence" receives the incoming message and performs following tasks.

1. Logs the incoming message
2. Sends the message to back-end service,
3. Sends back the HTTP STATUS code 202 to client message. 

In addition Proxy service has a faultSequence too. I will get back to it later.

Next we have to define a message store and corresponding properties to that store. Here we have selected ActiveMQ persistent message store.

Once we have sorted out the message store, next we have to define a way to pop or peek messages from the queue. So next we have to define the message processor properties like the message processing class, polling interval etc ...


Now we are almost done except one thing. We haven't mentioned any where to store the incoming message :) . So I have to add a small bit of code in to Proxy's inSequence. we can add the message storing tag in between FORCE_SC_ACCEPTED and OUT_ONLY properties. 

We are recommending this order for a purpose. Lets consider that the JMSMessageStore crashed due to some reason. On that scenario, when proxy service tries to write the message in to store, will return with an exception. Thus triggering the fault sequence. We can pack the error message in to a payload factory and we can send it to the client. Therefore by preserving this order, we make sure that we send 202 HTTP STAUTS message to client only if the storage is succesful.

Now we can look in to complete ESB synapse configuration.