Logo
  • Products
    • SecOps Studio
  • Solutions
    • Pega Stack Shifter
  • Services
    • Pega Enablement
    • Pega Modernization
  • About
  • Contact
  • Blog
Code Vault

Java Messaging Service – Part 1 – Understanding

December 10, 2024 Code Vault Curators

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.

  1. Point-to-point messaging domain
  2. 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.

  1. JMS Provider and JMS Client
  2. Administered Objects – connection factories and destinations
  3. Connection and session
  4. Message Producers and Message Consumers
  5. 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.

Java Messaging Service – Part 2 – Setup ActiveMQ
  • pega-integration
Code Vault Curators

A technical team dedicated to empowering the Pega ecosystem with in-depth knowledge, guided by Premkumar Ganesan's vision.

Post navigation

Previous
Next

Pega Courses

Pega courses can be accessed at https://myknowacademy.com

Search through the blog

Tags

activity authentication background-processing case-management data-model declarative-processing email-processing file-processing pega-core-concepts pega-integration process reporting security system-administration user-interface validation

Categories

  • Code Vault

Recent posts

  • Service REST – Usage and Configurations in Pega
  • Queue processor – Usage and Configurations
  • Data Pages Usage & Configurations in Pega
  • Requestor types in Pega
  • Case Locking Mechanism in Pega

Related Articles

Code Vault

Service REST – Usage and Configurations in Pega

December 18, 2024 Code Vault Curators

First of all, don’t think INTEGRATION is a difficult topic in PEGA. I would say Integration is much easier than creating an activity rule. Pega makes it simple for developers. All you need to do is configure the Integration rules. Pega takes care of the rest. Pega provides useful wizards and guides the developers in […]

Code Vault

Service SOAP – Usage and Configurations in Pega

December 10, 2024 Code Vault Curators

In this blog article, we will see how a Pega application can host a SOAP web service. I request you to go through another blog article on Service-REST where I already talked about services in general – Update: The Concept of SOAP services remains the same across different Pega versions. The screenshots in this blog […]

Code Vault

Connect SOAP – Usage and Configurations in Pega

December 10, 2024 Code Vault Curators

In this blog article, we will try to understand about Connect-SOAP in Pega. Update: The concept of SOAP Connector remains the same across different Pega versions. Most of the screenshots in this blog article were reused from Pega 7 version and few were updated. Use this blog article to learn the concepts and you can […]

Code Vault

Connect REST – Usage and Configurations in Pega

December 10, 2024 Code Vault Curators

In this blog article, we will try to understand about Connect-REST in Pega. Connect-REST is One of the most commonly used Connectors in Pega to integrate with external systems. Update: The concept of REST Connector remains the same across different Pega versions. Most of the screenshots in this blog article were reused from Pega 7 […]

About

MyKnowTech was born with a mission to bridge the gap between technical expertise and business needs. We are a boutique firm specializing in Pega solutions, delivering them with a personal touch. At the heart of our philosophy is a commitment to putting clients first.

Company
  • About
  • Leadership
  • Career
  • Contact
Resources
  • Blog
  • Services
  • Solutions
  • Insights

©  MyKnowTech B.V. All Rights Reserved.

  • Sitemap
  • Terms & Conditions
  • Privacy Policy