1. Home
  2. GLU.Guide
  3. Integration Builder
  4. Synchronous vs Asynchronous Messages

Synchronous vs Asynchronous Messages

Synch vs Asynch Messsageing in GLU

Suppose your GLU.Engine needs to call an HTTP service but this service is slow to respond and you do not want your GLU.Engine to be blocked, waiting for the response. You want your GLU.Engine to do other important computation while the slow response is happening. In such a case you can set your message to be Asynchronous so your GLU.Engine can do other stuff while the slow service is processing requests.

When doing messaging there are a few aspects to keep in mind. First of all, a GLU.Engine can initiate an outbound message exchange in the Orchestration as either:

‘Request’ only or ‘Request Reply’

Request only is when the caller sends a message but do not expect any reply. This is also known as fire and forget or event message.

The Request-Reply is when the caller sends a message and then waits for a reply. This is like the HTTP protocol that we use every day when we surf the web. We send a request to fetch a web page and wait until the reply message comes with the web content.

In GLU a message is labeled with a Message Exchange Pattern that labels whether it’s a request only or a request-reply message. By default messages are treated as request/reply i.e. synchronous, in order to treat a message as a request only, one can flag the message as asynchronous using the ‘Asynch’ checkbox in the ‘Endpoint Manager Panel’.

Synchronous Transactions

A synchronous exchange is defined as the caller sends a message and waits until it’s complete before continuing.

You can also do synchronous Request only. In this case the GLU.Engine sends a message for which a reply is not expected. However, the GLU.Engine still waits until the message is processed by the receiving system which would typically return an ACK/NACK message to complete the transaction.

Asynchronous Transactions

On the other hand, the asynchronous version is where the GLU.Engine sends a message to a receiving Endpoint with then returns immediately back to the GLU.Engine with an ACK/NACK response, this message, however, is processed in another thread within the GLU.Engine, the asynchronous thread. This enables the GLU.Engine to continue doing other work and at the same time, while the asynchronous thread is processing the message.

As opposed to the synchronous Request Only the Async counterpart will not wait for the processing of the message to complete. In this case, the GLU.Engine can immediately continue doing other work while the message is being routed and processed in by the Receiving System. This is the ultimate ‘fire and forget’ flavour.

Asynchronous transactions do not implement any kind of persistence or recovery, if the GLU.Engine terminates while messages are yet to be processed. If you need persistence, reliability or distributed SEDA, some form of queueing mechanism will need to be used like ActiveMQ or RabbitMQ

SEDA

To provide enhanced asynchronous transactions GLU provides the ability to deliver asynchronous transactions through the SEDA method.

SEDA – Staged event-driven architecture (https://en.wikipedia.org/wiki/Staged_event-driven_architecture)

The SEDA component provides asynchronous SEDA behaviour, so that messages are exchanged on a BlockingQueue and consumers are invoked in a separate thread from the producer.

Concurrent Consumers – Sets the default number of concurrent threads processing exchanges (Default value = 1)

Size – Sets the default maximum capacity of the SEDA queue (i.e., the number of messages it can hold) (Default value = 1000)

Was this article helpful?

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Need Support?

Can't find the answer you're looking for?
Contact Support
Fill the form and we’ll contact you shortly

    I agree with

    cookies
    We uses cookies to make your experience on this website better. Learn more
    Accept cookies