JMS with Ballerina lang: Part 2
Understanding JMS Concepts
This article series focuses on using JMS in conjunction with Ballerina language. In the previous article, we received a brief introduction on why Ballerina language is a great fit to be used with JMS. In this specific piece, our focus is on delving into the key concepts of JMS.
JMS API
JMS provides two API versions for interfacing with available JMS providers:
Classic API
Introduced in JMS v1.1, the Classic API includes several key components designed to manage messaging effectively:
- ConnectionFactory : an administered object used to create a JMS connection
- Connection : an active connection to a JMS provider
- Session : a single-threaded context for sending and receiving messages
- MessageProducer : an object used for sending messages
- MessageConsumer : an object used for receiving messages
- Destination : an object used to specify the target of messages it produces and the source of messages it consumes. A Destination can be either a queue or a topic.
Simplified API
The Simplified JMS API, launched with JMS v2.0, streamlines the process by integrating multiple functionalities into fewer components:
- ConnectionFactory : an administered object used to create a JMS connection
- JMSContext : an active connection to a JMS provider and a single-threaded context for sending and receiving messages
- JMSProducer : an object used for sending messages
- JMSConsumer : an object used for receiving messages
To enhance the developer experience and ensure flexibility when using JMS providers that are compatible with both JMS v1.1 and JMS v2.0, Ballerina JMS connector adheres to JMS v1.1 specification.
JMS Implementation
Java Message Service (JMS) is defined purely as an API specification. This specification outlines how Java applications should communicate with message-oriented middleware but does not dictate the underlying implementation. To connect your application to a specific JMS provider, you must integrate a JMS implementation library. This library serves as a runtime dependency that contains the provider-specific client implementation tailored to the relevant JMS API.
Eg: Apache ActiveMQ requires `activemq-client` library
At runtime, the application locates the JMS implementation through the Java Naming and Directory Interface (JNDI). Using the configuration settings of the initial context factory, JNDI constructs the javax.naming.InitialContext resource. The InitialContext is then used to dynamically identify the JMS connection factory object provided by the implementation. In the JMS context, JNDI acts as a bridge between the application and the JMS implementation library.
Messaging models
A messaging model defines how messages are produced, delivered, and consumed within a messaging system. It dictates the interaction patterns between the message producers and consumers and ensures that messages are routed correctly to their destinations.
JMS supports two primary messaging models:
- Point-to-Point (PTP) model
In the point-to-point model, messages are sent to a specific queue. Each message in the queue is received and processed by exactly one consumer. This model is suitable for scenarios where each message must be processed by a single consumer, ensuring that no two consumers receive the same message.
2. Publish/Subscribe (Pub/Sub) model
In the publish/subscribe model, messages are sent to a topic. Multiple consumers can subscribe to the topic and receive the messages broadcasted to it. This model is ideal for scenarios where messages should be delivered to multiple consumers, such as broadcasting events or notifications.
In this article, we briefly discussed the JMS API and the messaging models available in JMS. In the next article, we will dive deeper into writing the first JMS-based application using Ballerina lang.
References
- Java Message Service, 2nd Edition (https://www.oreilly.com/library/view/java-message-service/9780596802264/)
Previous: JMS with Ballerina lang: Part 1
