Asynchronous Design Pattern

In this message exchange pattern, messages from source application are processed asynchronously.

Source application send the messages to the integration process. Integration process commit the messages in a database of integration layer and send the response back (HTTP OK) to the source application. Another integration process will pickup the messages from the database and send the message eventually to the target application.

The response message to the source application is normally HTTP 200 OK for success response or HTTP 500 for failure (or any other error code)   It is the responsibility of integration layer to send the messages to the target application.

We can implement this pattern with two processes.

First Process

1. Source application will invoke the integration process
2. The process validates the messages and after successful validation commit the messages in the database.
3. If validation is unsuccessful, it sends HTTP error code to the source application.
4. Send HTTP OK /HTTP Error according to the successful commit or failure.

Second Process

1. This is batch process which is scheduled or it can be a listener process which will poll the database.
2. This process will pick up messages from the database and then validate, enrich and transform the messages and invoke provider web service.
3. This process will delete the record from the database after successful processing.

  Use Case

    Use this pattern when messages delivery from source to target takes significant amount of time.  Also for cloud to cloud communication, sometimes connection failure occurs vary frequently. In that situation it is better to choose asynchronous design pattern. Also when middle-ware needs to have lots of complicated business logic for messages enrichment and transformation, you may choose this design pattern.