How can the MQ Light API help my applications?

The MQ Light API is designed to allow applications to exchange discrete pieces of information in the form of messages. The MQ Light API removes much of the complexity of TCP/IP networking, and provides a higher level set of abstractions with which to build your applications.

Common uses for messaging include:

  • Worker offload – A web application needs to carry out some processing work, but it also needs to be responsive to the user. The MQ Light API utilizes several back-end worker applications that can do the processing, enabling the web application to send a work request to a worker application. If there is more than one worker application, the MQ Light API can share out the work among them. And if the load increases, you can simply add in worker applications without having to make changes to the web application, or to the MQ Light API.
  • Batch processing – A variant of the worker offload, but where the work is deliberately queued for processing at a later time, perhaps when off-peak, less expensive computing resources are available.
  • Event Notification – Where an application publishes data to a group of applications. For example, publishing stock price updates to a set of trading applications. By acting as a ‘man in the middle’, messaging allows the updates to be simply sent to the messaging service which then manages the storage and distribution of the messages to each interested application.

MQ Light API: Concepts

MQ Light API concepts

  • Messages – All data is carried in the form of messages. Messages can include:
    • The message payload, or the data to carry between applications. This can be string data (such as text, JSON, or XML), binary data, or nothing (empty).
    • Name-value properties. For example, color=blue or size=medium. A message can have zero or more properties associated with it.
    • Attributes that are interpreted by the MQ Light messaging service. For example, a topic name. The MQ Light API can use these attributes to affect how the message is to be processed.
  • Topics – Applications send messages to a topic. A topic is a string that identifies a location in the topic space that messages will be routed to, and indirectly govern which applications will receive a copy of the message. They can just be a name, for example, ImageProcessingService, or can be arranged in a hierarchical format using the ‘/’ character to separate levels of hierarchy, for example, ibm/services/imageProcessing. Hierarchies of topics can be used when you have applications that want to receive messages based on a pattern that matches multiple topics. For more information, see Wildcards.
  • Destinations – Applications receive messages from destinations. Destinations are associated with a topic, or set of topics, using a pattern. Destinations store a copy of each message sent to a topic that matches the destination’s pattern, until it is consumed by an application. Zero, one, or many destinations can be associated with any given topic. If a message is sent to a topic without a destination, it will not be delivered to any application.

    Destinations are automatically created and removed from the messaging service as a result of an application using the API’s provided by the messaging service. Destinations are always created with a time-to-live value, which is reset each time an application uses the destination. The MQ Light API will remove a destination, along with any messages it is holding, if it remains unused for a period of time which exceeds its time-to-live value.
  • Sharing – Applications can either exclusively use a destination, meaning that they will receive all its messages, or they can share a destination, meaning that messages arriving at the destination will be shared amongst the applications sharing the destination.
    When more than one application is consuming messages from a destination, the messages are shared out so that each message is delivered to only one application. Whether a destination is shared or not is controlled by the parameters supplied to the API call that causes the destination to be created.


The MQ Light API will create each instance of the client with its own destination, and each destination will receive a copy of the message published to topic1. The following diagram demonstrates the behavior of running multiple copies of the code at the same time:MQ Light API: Delivery To Both Clients

Messages sent to topic1 will be shared amongst all the clients that have subscribed to topic1, and used the share name of share1. The following diagram illustrates this behavior:

Join The Discussion

Your email address will not be published.