Java Message System Introduction
Java Message System Introduction
Messaging services are a great way to decouple systems and keep those same systems scalable. Here is how such middleware fits into the world of enterprise Java.
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
In this article, I will talk about Message Orientated Middleware (MOM) and how it is implemented in Enterprise Java by JMS. Also, I will discuss the typical use cases that suit the use of JMS and different terminology used to talk about messaging solutions such as Publisher/Sender, Destination/Topic/Queue, and Subscriber/Receiver. I will introduce the two types of message topology: point-to-point and publish/subscribe.
Data Access Layer
In the typical architecture of a Java EE application, the data access layer has technologies that communicate with data stores such as Java Persistence API (JPA), Java Connector Architecture (JCA), which connects your application to enterprise information systems (EIS); and Java Message Service (JMS).
What Is JMS Used for?
JMS is used for passing messages in a loosely-coupled, asynchronous, scalable, and secure manner among distributed applications. Applications send and receive messages via the Message-Orientated Middleware using what are known as destinations.
Asynchronous means that the sender and receiver of the message do not need to interact with the message queue at the same time. So the receiver can pick up the message at some time after the message was sent.
Loosely coupled because the senders know nothing about the receivers and the receivers know nothing about the senders.
Scalable means that different parts of the system can grow at different rates, and in response to application load. So for example, if a sudden burst of activity on the site results in a dramatic increase in messages being sent across the messaging middleware the messages can be queued while the receiver responds or auto scales. This provides robustness in the system which would otherwise have difficulty in handling the sudden load and the application would start behaving badly or just stop working altogether.
When to Use JMS?
Using JMS depends on the use case, but usually, it will fall into at least one of these use cases.
- The application should be able to send a message without requiring an immediate response to that message. Perhaps the response to the message is optional and the application can continue its proper function without the response, or perhaps it’s a purely one-way communication.
- The sender does not need to depend on the receiver’s interface so the receiver can be easily replaced. This comes down to a need for parts of the application to be decoupled.
The application should continue to run when the receiver is down. The receiver can be broken and the application will continue its normal operation. This allows for robustness.
There is some useful terminology to know when talking about JMS that helps us communicate our intent.
A destination is where the messages are sent and is referred to as either a queue or topic. This is normally defined in JMS as a String value. Destinations should be given names that denote their function.
The JMS system has publishers or senders. This is where the message originates, and subscribers or receivers which are where the message terminates. The terminology used here depends on the topology of the messaging system which can be either point-to-point or publish/subscribe.
There are messages, which have a payload that contain useful information that the receiver will extract and process. The message type can be text, binary, stream, an object, or a map of properties.
Point-To-Point Message Topology
In a point-to-point set-up, the origin of the message is referred to as the sender and the destination is referred to as a queue. Here messages are sent to a single destination and only one instance of the message is received by the receiver. If the receiver is down, messages are held in the queue until the receiver is up and running again.
Publish/Subscribe Message Topology
In a publish/subscribe set-up, the origin of the messages is referred to as publisher and the destination is referred to as a topic. Here many subscribers can subscribe to a topic and each subscriber receives an instance of the message. So one message is sent to many waiting subscribers. If a subscriber is down it will not receive the message when it is up and running again.
How about learning a little about the following Java EE technologies:
- Context and Dependency Injection (CDI)
- Enterprise Java Beans (EJB)
- JSP, JSP and Expression Language
- RESTful webservices
- Java Persistence API
JAX-RS for RESTful Webservices
I have recently posted a mini-series of blogs taking a look at JAX-RS. They discuss:
- How to manage bean validation failure,
- Work with consumers and producers, and
- How to create JAX-RS resource entities.
There are two deep dive series on JAX-RS topics:
Published at DZone with permission of Alex Theedom , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.