With some industrial experience on Message broker related SOA integrations, thought of discussing about Enterprise messaging. Let’s start with the basics and later in the coming post let’s discuss how we can have a high available messaging architecture.
Messaging
One mechanism which distributed applications can communicate is via message passing. Before we move ahead let’s check what “message” means. A message is a structured piece of information sent from one agent to another over a communication channel. Message will have an identifier within it and it will tell the receiver the purpose or type of the message. We can use different protocols and network standards such as HTTP, SSL, TCP/IP to do message parsing between applications. However when we talked about enterprise messaging with message brokers, we talk about transmission control protocol. Another important fundamental concept we should know in messaging is the message handling methods. Namely Asynchronous and Synchronous. So let’s discuss it.
Asynchronous vs. Synchronous message handling
One critical thing we need to consider when planning message parsing or processing is to know whether it needs to be Asynchronous or not. First let’s see the difference between the two types.
- Synchronous Messages:
Synchronous messaging involves a client that waits for the server to respond to a message. Messages are able to flow in both directions, to and from. Essentially it means that synchronous messaging is a two way communication. i.e. Sender sends a message to receiver and receiver receives this message and gives reply to the sender. Sender will not send another message until it gets a reply from receiver.
- Asynchronous Messages: Asynchronous messaging involves a client that does not wait for a message from the server. An event is used to trigger a message from a server. So even if the client is down, the messaging will complete successfully. Asynchronous Messaging means that, it is a one way communication and the flow of communication is one way only.
Depending on your business process need you can choose one of the above methods in your communication channel. Now let’s discuss about the message broker which handles all these message flows between different applications.
Message Broker
A message broker is a middleware program that translates messages from the formal messaging protocol of the publisher to the formal messaging protocol of the receiver. Message broker decouples the publisher and consumer systems. The beauty of the message broker is that it can receive messages from a publisher and it can transmit it to multiple subscribers. In addition there are key advantages on using a message broker in the middle of a message communication. They are as follows:
- Ability to store messages when the consumer is not available to consume the messages
- Guarantee message delivery between two parties
- Act as a load controller in the middle of an application to ensure the consumer is not overloaded with requests. All the requests will come to the message broker and it will store them until consumer, reads them one by one with the highest rate it can consume.
Now we know what is the message broker and the importance of it. Next we will look in to the two main subscription models in messaging.
Queues and Topics
As the message handling model, message subscription model also need to be selected based on the business process requirement. Let’s see what we need to consider when selecting the model.
| Queue |
Topic |
| Point-to-point model. |
Publish/subscribe model. |
| Only one consumer gets the message. |
Multiple clients subscribe to the message. |
| Messages have to be delivered in the order sent. |
There is no guarantee messages have to be delivered in the order sent. |
| A JMS queue only guarantees that each message is processed only once. |
There is no guarantees that each message is processed only once. As this can be sensed from the model. |
| The Queue knows who the consumer or the JMS client is. The destination is known. |
The Topic, have multiple subscribers and there is a chance that the topic does not know all the subscribers. The destination is unknown. |
| The JMS client (the consumer) does not have to be active or connected to the queue all the time to receive or read the message. |
The subscriber / JMS client needs to the active when the messages are produced by the producer, unless the subscription was a durable subscription. |
| Every message successfully processed is acknowledged by the consumer. |
Every message successfully processed is not acknowledged by the consumer/subscriber. |
Next let’s investigate on how message broker can exist in enterprise SOA.
Messaging Topologies
- External Broker:
Fully fledge message broker solution. Message broker is an external server. Activemq, Sonicmq, Mulemq are some examples for those external brokers. From those we can achieve clustering, fault tolerance, scalability
Now we have discussed all the aspects related to message broker and enterprise messaging. In the next post we will discuss on how we can setup an External Broker Architecture with high availability and fault tolerance.
References
- http://peoplesofttutorial.com/difference-between-synchronous-and-asynchronous-messaging/
- Java Distributed Computing by Jim Farley
- ENTERPRISE MESSAGING WITH JMS by Mark Richards
- http://www.ebizq.net/topics/eai/features/1590.html
- JD Edwards EnterpriseOne Transaction Server Reference Guide
Read More
