Messaging System Types
The messaging systems which are commonly used can be broadly divided into two types as below:
- Point-To-Point
- Publish/Subscribe
We will now describe these commonly used messaging system models in detail in the following sections.
Point-To-Point
In point-to-point messaging system, illustrated in Figure 18-4, messages are routed to an individual consumer which maintains a queue of “incoming” messages. This messaging type is built on the concept of message queues, senders, and receivers. Each message is addressed to a specific queue, and the receiving clients extract messages from the queues established to hold their messages. While any number of producers can send messages to the queue, each message is guaranteed to be delivered, and consumed by one consumer. Queues retain all messages sent to them until the messages are consumed or until the messages expire. If no consumers are registered to consume the messages, the queue holds them until a consumer registers to consume them.
Figure 18-4. Point-To-Point messaging type
Publish/Subscribe
In this messaging type, illustrated in Figure 18-5, a message is delivered from a producer to any number of consumers. Messages are delivered to a topic destination, and then to all active consumers who have subscribed to this topic. In addition, any number of producers can send messages to a topic destination, and each message can be delivered to any number of subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers who have subscribed to the topic.
Publish-subscribe messaging type has the following characteristics which distinguishes from PTP. They are:
- Each message can have multiple consumers to which it can be delivered.
- A subscriber can consume messages from the topic only after the messages have been fully published by the publisher to the topic. Also, the subscriber has to be in active state for message consumption from the topic.
Figure 18-5. Publish-subscribe messaging type
Relation between Messaging and Decoupling
One of the advantages attributed with messaging integration style is decoupling as seen in previous section. Decoupling is a very high level term, which according to context can vary and can be achieved in different ways. In messaging the broker decouples the sender and receiver and it can be achieved by the following ways:
- Spatial decoupling – the systems that produce and consume messages may be deployed on different machines, networks, continents etc. That means sender(s) and receiver(s) doesn’t have to be co-located for the communication to happen.
- Temporal decoupling – a system can en-queue a message and carry on without waiting for the message consumer. That means, there is no need for other system(s) to respond immediately. Asynchronous nature of messaging is achieved by this way decoupling. The sender sends the message to the receiver and it continues. Can be used for sending-only or request-reply communication model between the sender and receiver. The reply from the receiver is delivered back as separate messages and the replied messages can be co-related with the original request.
- Logical decoupling – sender(s) need not know about the receiver(s). In this, sender(s) don’t target specific receiver(s) and that receiver(s) need not know about the sender(s), which makes it complexly decoupled. Using this model, the extra logic can be placed to the messages between the sender and receiver. The messages can be routed, filtered and transformed according to application requirement.
Java Messaging Service (JMS)
The Java Message Service was developed by Sun Microsystems to provide a means for Java programs to access enterprise messaging systems. Enterprise messaging systems, often known as Message Oriented Middleware (MOM), provide a mechanism for integrating applications in a loosely coupled, flexible manner. They provide asynchronous delivery of data between applications on a store and forward basis; that is; the applications do not communicate directly with each other, but instead communicate with the MOM, which acts as an intermediary.
JMS is a set of interfaces that define how a client accesses the facilities of an enterprise messaging product. In the past, each MOM vendor provided application access to its product through a proprietary API. JMS avoids this lock-in to proprietary API by providing a standard, portable way for Java programs to send and receive messages through a MOM product. Being standard, programs written in accordance with JMS can run on any MOM that implements this standard.
JMS Objectives
The core objectives of JMS, as stated in the specification are:
- To maximize the portability of messaging applications.
- To define a common set of messaging concepts and facilities.
- To minimize the work needed to implement a provider.
- To minimize the concepts a programmer must learn to use enterprise messaging.
- To provide client interfaces for both point-to-point and publish/subscribe messaging type.
Page Visitors: 16775
Tomcy John
Latest posts by Tomcy John (see all)
- A Guide to Continuous Improvement for Architects - February 2, 2023
- Cloud-first Architecture Strategy - January 26, 2023
- Architecture Strategy and how to create One - January 24, 2023
First of all I would like to say fantastic blog! I had a quick question which I’d like to ask if you don’t mind. I was interested to know how you center yourself and clear your head before writing. I have had difficulty clearing my mind in getting my ideas out there. I do enjoy writing but it just seems like the first 10 to 15 minutes are usually wasted just trying to figure out how to begin. Any recommendations or tips? Thank you!|