Table of contents
What is JMS?
The Java Messaging Service (JMS), which is part of the Java Community Process [JSR-914], was designed by Sun Microsystems and several other organizations. As per the design's final draft, we had a common set of APIs that can be used as a standard industry-wide. Each company can implement JMS in its way, but the APIs will be the same.
Communication between enterprise applications is the main purpose of messaging.
This Message-oriented middleware is designed to handle messages using the JMS specification. This makes it possible to create a reliable and robust messaging service for your applications.
How does JMS differ from existing Mail APIs? What are the benefits of JMS?
Mail and Messaging share similarities in that they facilitate asynchronous communication between senders and recipients.
Java Mail allows you to send emails, send emails with attachments, read emails, etc.
Java Mail provides asynchronous communication between two clients through email messaging.
Java Mail is the right choice if you are only concerned with e-mails. This includes sending and receiving emails.
JMS stands for Java Messaging Service, which allows applications to exchange messages.
In enterprise applications, JMS facilitates synchronous and asynchronous communication between application components. For example. Using an ATM to make a banking transaction.
In terms of JMS, it offers much more. JMS is better suited to interacting with applications that aren't e-mail clients.
JMS offers full programmatic control over delivery options and quality of service for high-performance messaging.
What are the different models of message distribution in JMS?
Point-to-Point (Queue destination):
The communication will be 1:1 or Many:1. Messages will be produced and sent to the Queue configured in one of the JMS providers [e.g. ActiveMQ, Weblogic's JMS].
Consumers who are registered to the queue will consume messages.
Messages are produced by many producers and sent to the queue, where one consumer consumes them.
Message delivery is guaranteed. If a consumer goes down, messages will remain in the queue and will be available for consumption once the consumer has been restored.
It is the responsibility of providers to ensure that only one consumer consumes the message in a P2P system.
Async fire and forget: App A can send the message and forget about it, continuing its task without listening or waiting for a response/reply. App B will consume it and process it in its way.
Synchronous request/response messaging: App A can send the message and listen to another queue (e.g., reply queue) once the consumer App B consumes the message. App B will put an acknowledgment message or reply on App A/producer's queue, which App A will consume and process.
Publish/Subscribe (Topic destination):
In many-to-many and one-to-many communication, one producer or several producers can send a message to the destination referred to as TOPIC and all active subscribers/consumers will be able to read it.
Since Topic does not store or hold messages until consumers are active, message delivery cannot be guaranteed.
- If the consumer is registered as a durable consumer, the message will be delivered when the durable consumer is operational.
This is a push model, meaning that messages are broadcasted to the Topic and the JMS provider will send them to all subscribers who are subscribed to the Topic.
A Java messaging system involves the following components in general
Producers [Client]: JMS application that uses JMS APIs to connect to JMS Servers to send messages
Consumers or Subscribers [Client]: JMS application that uses JMS APIs to connect to JMS Servers to consume or read messages.
Providers: A middleware or a software product that hosts JMS Server and contains destination to messages to sit. A message destination can be a queue or topic based on messaging model.
- We need to create administered objects like connection factory, queue or topic needs to be created inside provider software and name them so producers and consumers can use these names to look up and connect to message destination using JNDI.
How did applications communicate before JMS? Why did JMS come about?
Every application that needs to communicate with other applications requires RMI calls if they are on the same network. This would make the application tightly coupled, which means that App A needs to know the APIs exposed by App B.
- One disadvantage of tight coupling is that if there are any changes made to the design or API, then the consuming App will also need to make the necessary changes.
JMS (Java Message Service) is a specification that helps with communication between applications and provides a set of standard APIs for developers to use.
This allows for better communication and eliminates obstacles(tight coupling) while developing applications.
Any provider that follows the standards outlined in the JMS specifications can offer their versions of JMS, such as WebSphereAQ, Weblogic JMS Server, or ActiveMQ.
The JMS APIs are all that developers need to keep in mind when developing applications.
- The JMS provider takes care of everything else after JMS. It's almost like a black box. Just follow some rules and call APIs.