Java Message System

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 which 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) that 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?

When best to use JMS depends on the use case but usually, it will fall into at least one of these use cases.

1. The first use case is this: 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.
2. Secondly. 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.

Terminology

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, these have a payload which contains 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.

Further Reading

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:

• What are JAX-RS annotations? A deep dive looking at the annotations most commonly used when developing REST endpoints.
• What is the @Context annotation used for? A deep dive into the many uses of the @Context annotation.

What Next?

If you are new to Java EE it can be overwhelming to get your head around all the APIs the form the enterprise eco-system. That is why I wrote and recorded the video training course Learning Java Enterprise Edition. It is a two-hour course that introduces you to all the most important Java EE APIs. With plenty of demonstrations, code examples, and practice tasks on how to program with Enterprise Java, you will up to speak and well on your way to being a Java EE developer.

Advance Your Knowledge

If you want to learn more, there are courses that dive deeper into each of the APIs. There is a course about the JAX-RS API in you advance your knowledge by learning how to construct RESTful endpoints. There is a course on the WebSocket API where you can learn how to develop a chat application and there is a course about JSON where you learn how to master the JSON-Processing API course. There are many courses on the horizon, so why not jump in now and give your Java EE career a kick.