Message Queues

Asynchronous vs. Synchronous Messaging

Asynchronous messaging refers to a communication pattern where a sender and a receiver do not need to be active or available at the same time. In contrast, synchronous messaging requires both the sender and receiver to be available at the same time for a communication to take place.

The use of message queues in asynchronous messaging can provide several benefits over synchronous communication:

  1. Scalability: Asynchronous messaging allows for communication between loosely coupled systems, which can be scaled independently, leading to better overall system scalability.
  2. Resilience: By decoupling systems, message queues provide a buffer between the sender and receiver, allowing the receiver to process messages at its own pace. This can improve system resilience, as it reduces the risk of cascading failures.
  3. Improved performance: Asynchronous messaging allows for non-blocking communication, enabling the sender to continue processing requests while waiting for a response. This can lead to improved system performance and responsiveness.
  4. Increased flexibility: Message queues allow for the creation of flexible and dynamic communication patterns, where messages can be routed to multiple recipients, transformed, and processed in parallel.

Overall, the use of asynchronous messaging and message queues can provide greater flexibility, scalability, and resilience compared to synchronous messaging.

GLU Message Queue Connectors

GLU.Ware supports integration to both ActiveMQ (Produce and Consume) and Rabbit Message Queues (Produce). Often useful for Asynchronous offloading of a task in a flow, MQ’s can help to speed up transaction round-trip times.


The Client DevOps team will be responsible for the MQ setup and configuration as for any other End-Point that the GLU.Engine Connects to as such configuration of the MQ’s is not covered here.


Based on the setup of the MQ Broker, the GLU Connector can be configured to support the appropriate Protocol e.g. TCP or AMQP.


The GLU.Engine will contain all the libraries to facilitate the connections. So as an example for RabbitMQ all the client components are in the GLU.Engine no additional software is required.

Publish/Subscribe Integration Pattern

ActiveMQ and RabbitMQ are two popular message brokers that support the Microservice Publish/Subscribe integration pattern using topics for consumption by subscribers. GLU plans to expand its support for Pub/Sub pattern topics by adding compatibility with additional messaging systems such as Amazon SQS, IBM MQ, RocketMQ, Google Pub/Sub, Apache Pulsar, and Apache Kafka. Please log any requirements for GLU.Ware to priorise support for any of these via the GLU.Support desk.


The Publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorise published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.

This pattern is commonly used in messaging systems as part of larger message-oriented middleware systems. Many messaging systems, including Java Message Service (JMS), support both the Pub/Sub and message queue models.


In the Publish-subscribe model, subscribers typically receive only a subset of the total messages published. The process of selecting messages for reception and processing is called filtering. In a topic-based system, messages are published to “topics” or named logical channels. Subscribers in a topic-based system will receive all messages published to the topics to which they subscribe. The publisher is responsible for defining the topics to which subscribers can subscribe.

RabbitMQ

RabbitMQ can be configured to either produce a RabbitMQ transaction on a Queue or consume from a RabbitMQ Queue. If a consumer is to be used then this will need to have a connector set up which has OUTBOUND/INBOUND set to BOTH.

Both consumer and producers can be configured so that the settings for the rabbitMQ can be adjusted from the application.yml file.

Connector Setup

Set Protocol to RABBIT_QUEUE. In the Connector Environment Settings panel, set the Username and Password for access to the RabbitMQ:

Producer

When RabbitMQ is set up in a Connector, it will send transactions of the RabbitMQ as a producer.

Using application.yml file

To have the configuration setup so it is possible to configure the RabbitMQ from the application.yml file, you will need to tick the “Use Queue Holder” checkbox:

When this is ticked the default queue holder value needs to be setup. This value will be the initial value which is held in the application.yml file and used for the GLU.Engine interactions with RabbitMQ.


The parameters in the default queue string should use “&amp ;” separator values.

When not using application.yml

To have the configuration setup so it is not possible to configure the RabbitMQ from the application.yml file, you will need to untick the “Use Queue Holder” button.


When this is unticked the Queue field should contain the rabbitMQ queue which the transaction will go to. The Options field should contain the string of characters which define the settings for the transaction going to RabbitMQ.


The parameters in the default queue string should use “&amp ;” separator values.

Consumer

When RabbitMQ is set up as a connector it will receive the incoming transactions.


When the GLU.Engine is run then then this API will listen on the Queue from RabbitMQ and if there is transactions in the Queue it will pull them in and start the orchestration process.

Using the application.yml file

To have the configuration setup so it is possible to configure the RabbitMQ from the application.yml file, you will need to tick the “Use Queue Holder” button.


When this is ticked the default queue holder value needs to be setup. This value will be the initial value which is held in the application.yml file and used for the integrations interactions with RabbitMQ.


The parameters in the default queue string should use “&amp ;” separator values.

When not using application.yml

To have the configuration setup so it is not possible to configure the RabbitMQ from the application.yml file, you will need to untick the “Use Queue Holder” button.


When this is unticked the Queue field should contain the rabbitMQ queue which the transaction will go to . The options field should contain the string of characters which define the settings for the transaction going to RabbitMQ.


The parameters in the default queue string should use “&amp ;” separator values:

Was this article helpful?

Related Articles

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