Queue Centric Workflow Pattern

In queue centric workflow, one technique of loose coupling focuses on asynchronous delivery of commands that are sent via an interface to the back end service for the purpose of processing. The good thing of queue centric workflow is that it lets the updates to continue with the help of web tier without letting the web server to slow down. These are specifically useful for maintaining updates which are more time consuming.

This kind of pattern is mainly used with respect to the requests for updates by a user. Firstly its taken care by the user code which is generated displaying a message that the work has to be completed in the response of the update request. That message will then be attached to the queue. The messages flows only in one specific direction, right from web tier, to the queue and directly in service tier. Also, queue centric workflow pattern does not state if or how the user has been notified of the progress made.

How it works?

There are many applications where the web tier has to call on numerous different back-end services to finish a task. If a service layer functions unreliably, it can spoil the entire user experience and may also affect the application’s expandability. In this kind of situation, the answer is to convey non-synchronously where a web tier can transmit a command to perform a certain task. These commands are sent via messages on top of a queue.

Here in certain cases, the application uses web tier to post any message in the queue and the recipient then eliminates the messages from the queue and then processes the commands. By this process the web tier and the service tier are combined loosely. This will make it possible for the receiver as well as the sender to run at different plans.

The receiver has to follow a certain procedure to process the messages that are in the queue:

1. Firstly he has to get the following message from the queue.
2. Next he has to process the message.
3. Then he will have to delete or remove the message that is in the queue.
4. The procedure of the removal of the message from the queue and the deletion are split up so that we can make sure that the message is at least once been processed.

Figure displays the web tier adding messages to the queue and the service tier removing and processing the messages.

Invisibility Window

This states that every queue service offers an invisible window which are meant for the messages in queue. Whenever a message is removed from a queue, that message has been stored in a hidden queue. As soon as the message has completed processing, it has to be evacuated by the service. If there is an error while processing the message, that previously hidden message becomes accessible again and can be processed later in the queue.

Whenever there is any invisible window, there will be one exact copy of the message that is in process. Sometimes the invisible window shutdown before even the message has completed being processed. Its the responsibility of the application code to handle it correctly.

Queue Centric Workflow Pattern is very much constructive in dealing with the challenges mentioned below:

1. It gives assurity that the application will process the messages at least once across the tiers.
2. It guarantees a consistent and responsive user experience in the user tier even if there are third-party services that are accessing at the time of processing.
3. All the applications are disconnected across the tiers.

Impact of Queue Centric Workflow Pattern:

1. Reliability
2. User Experience
3. Availability, and
4. Scalability