Java Messaging Service – Part 1 – Understanding
In this blog article, we will see some basics about Java Message Service. Some theoretical stuff.
What is JMS?
It is a Java Message-oriented middleware (MOM) API that supports sending messaging between two or more systems.
Business scenario: Let’s say an International Organization ABC has its branches in different geo-locations. They use different Java/Pega applications to service the customers. Application A whose location is in Asia stores all the loan details, as a central repository for the entire organization. Application B which sits in Europe needs to know the updates for loan status. We can achieve this using a Web service like SOAP or REST.
Web services are bit tightly coupled – both producer and consumer needs to be available for the communication.
Let’s say in the future, Application C which sits in the USA may be interested in the same loan status update. You don’t want Application A to send the message separately to Application B and C.
These are the scenarios where JMS comes into the Picture. JMS is a MOM API that sits between producer and consumer.
Important note: The same can be achieved using Event based messaging like Kafka.
Why JMS?
JMS is asynchronous by default.
Asynchronous means the producer can produce the message and send it to MOM and then can continue its work.
Reliable
Since messages are delivered to a Middleware system/broker, we can make sure that messages can always be delivered to the consumers even if the consumer is down at the time of message creation.
What are the messaging domains in JMS?
There are two types of messaging domains in JMS.
- Point-to-point messaging domain
- Publish/Subscribe messaging domain.
Let’s see the characteristics of each messaging domain.
JMS API Programming Model
Below is the API programming model for JMS.
We don’t need to configure all the Java objects that are part of JMS API. Pega engine code takes care of the JMS API programming.
Let’s talk about some basic building blocks.
- JMS Provider and JMS Client
- Administered Objects – connection factories and destinations
- Connection and session
- Message Producers and Message Consumers
- JMS Message listeners
1. JMS Provider and JMS Client
– JMS provider is a messaging system that implements the JMS Specification. There are different Messaging providers available in the market like Apache ActiveMQ, IBM MQ, HornetQ from JBoss, OpenJMS, RabbitMQ etc. it is the middleware system between producer and consumer.
– JMS client is the message producer and consumer applications that make use of JMS provider to send and receive the messages.
2. Administered Objects
Connection factories – The client applications uses an object – Connection factory to create a connection to the provider. Establishing connection factories is the very starting point for the communication.
Note: Client here refers to both producer and consumer applications.
Once the connection factory is established, client(producer) can send messages to queue/topic or client(consumer) can receive messages from queue/topic.
Destinations
Client applications use an object – Destination which specifies the location where a message can be produced or the location where the message can be consumed. There are two types of destination – queue/topic
3. Connection and session
Note: Establishing connection and session are all hidden in the Java engine code. So we don’t need to code anything in Pega rule form for creating connection and session, but it is good to know what is happening.
– Connection specifies a virtual connection with a JMS provider. The implementation creates a connection Interface that uses connection factory objects to create a new connection
– Session is single threaded context that is used for producing and consuming messaging. Session creates the objects – Message Producers and Message consumers. The implementation creates a session Interface that uses connection object to create a new session.
4. Message Producers and Message Consumers
– Message producers are used for sending messages to the destination. The implementation creates a MessageProducer Interface that gets created by a session object
– Message consumers used for receiving messages from a destination. The implementation creates a MessageConsumer Interface that gets created by a session object.
5. JMS Message Listeners
Message listeners are used in the Message consumer applications to receive the messages. This serves as an asynchronous event handler for messages. The message listener implements Message Listener interface. Again all you need to do is create a JMS listener and Pega engine code take care of the remaining job.
In short, the steps for producing a message are below.
Step 1: The client application (message producing application) establishes a connection with the JMS provider using connection factory object
Step 2: The connection factory creates a Connection object.
Step 3: The connection object creates a session object.
Step 4: The session object creates a JMS Message producer object that is responsible to produce the JMS message. The Message producer sends the message to the destination – queue/topic
Final theory topic!
JMS Message Objects
JMS message is used by the JMS clients. JMS message is divided into three parts
1. Message Header – Predefined fields which are used by the clients and producers to identify and send messages. Predefined headers are – JMSDestination, JMSMessageID, JMSReplyTo etc.
Eg: JMSDestination refers to the queue/topic name where message gets delivered.
Visit the link for more details on the predefined Message headers – https://docs.oracle.com/cd/E19798-01/821-1841/bnces/index.html
2. Message properties – here we can set some additional custom properties with the JMS message. Mostly we use these properties to uniquely identify or select messages in the queue/topic.
3. Message Body – Currently the JMS API defines five message formats
Text message, Map message, Byte message, Stream message, Object message.
Enough of the theory.
In the next article, we will set up Active MQ in our local machine and put some messages in the queue.