Synchronous Message Processing – Request-Response Pattern; Handle Failed Request Asynchronously-Hybrid Design pattern.

This is mainly a synchronous design pattern. But sometimes, some messages can’t be posted to the destination in real time due to connection failure or other reason. So we need to process those messages asynchronously. This design pattern is partly synchronous and partly asynchronous. So you can call this a hybrid design pattern.  Those   failed messages needs to be stored temporarily in a message queue or database for retry.  ESB main process will send an intermediate status code to the requester application in such case. A separate ESB process will listen to the queue and try to post it to the destination. Requester application needs to provide a call back web service.

Happy path will be always synchronous. Only few messages that could not be posted will be processed asynchronously.

Messages should be published to the queue to post in   near real-time. As faster message processing is the foremost important in synchronous design pattern, preferably we should use messages queue instead of database. If messages are stored in a database we should write a batch process which will try periodically to post those messages. Also we can use database to persist the messages if we need fine grain control.

For synchronous main process,   every process component like duplicate checking, auditing, error handling is applicable.

For the second process which work asynchronously, we may not need to have duplicate check. But we should have other common sub-processes like audit and error handling. We may store the enriched and transformed messages or we may store original messages sent from source application. But in this case again we need to do message enrichment and transformation, which may not be required and may be avoided.

We need to have two distinct processes to implement this design pattern.

          Main Process-Invoke Provider and send failed messages to the queue.

 Requester will invoke the Integration process web service and wait for response.

1. The main integration process will validate the request and if messages are ok, enrich and transform the messages and invoke provider service.
2. The process  will send the response in real time to the requester
3. The process will send the messages, which could not be posted, to the message queue.

         Process 2-Process from queue

1. This process 2 can be scheduled process or a queue listener process
2. Process 2 will get requester messages from the queue or database
3. Process 2 will invoke provider web service to pass the messages
4. Process 2 will pass the response to requester by call  back web service
5. In case messages could not be delivered; the messages will be placed in the error queue or it can keep on retrying the messages. In case messages are stored in the database, message flag can be updated for successful delivery of the messages of delivery failure.
6. This process will try repeatedly to push the failed messages to the target application.

Use Case

 Use this pattern, when requester wants to pass messages to the provider preferably in real time. However, it requires integration layer to push failed messages to the destination asynchronously. A call back web service should be provided by requester to send acknowledgement to the requester.