JMS or Java Message Service is the messaging API for Java that allows applications to send messages between each other. Essentially JMS provides a standard for Java applications to process messages (send and receive) in a way that is asynchronous, loosely coupled and reliable.
What Do We Mean By Messaging?
When we talk about messaging we mean that the software components send messages to a particular endpoint, but they may not know the final destination of the message. This is what we mean when we say that messaging allows application to be loosely coupled. So if the source application needs to send a message to the target application, the source application doesnt need to know where the target application is or even what format they require. The source application just sends a message to an endpoint. And somewhere in the middle there may be another application that acts as as middleware or a broker, to determine how to get the message to the target application.
The benefit of this is that the source application really doesnt need to know anything about the target application. This means that the target application can change or even disappear and the source application doesnt need to know or care. So this lack of dependencies between the source and target make it easier to do things like increase performance if volumes are high, or reroute the messages elsewhere is the target system changes or had problems for example. But we will discuss more about the precise details further with examples in this JMS tutorial.
Messaging Clients And Servers
In the diagram above we can see both clients and servers. In terms of messaging the clients and both the source and target for the messages, and the server is the middleware or middleman for the messages. The messaging server may not actually be a physical server, it could be a seperate standalone application on the same server that is acting as the middlware, or the server and client may be running in the same application server. For example an application server could be acting as the messaging server and passing the messages on to the applications running within it.
So we could be sending messages between servers on a network, or locally between applications running on the same server. The beauty of loosely coupled applications means that the source and target applications dont need to know whether the target is local or remote. So you may test your application against against another application running on your local PC, deploy it to a server with your application sending messages to an application running locally. But then maybe for performance reasons its decided the target application will now run on a seperate server, and in theory your client application doesnt need to change to deal with that.
What Is The JMS API?
As mentioned the JMS API is the standard for loosely coupled messaging for Java applications. It provides some standard interfaces for you to create, send, receive, and read messages. The JMS API makes it easier for an application developer to process messages between JMS clients and JMS providers such as middleware providers and application servers for example.
The JMS API also allows the source and target JMS clients to operate in an asynchronous manner, meaning that they dont both have to be available at the same time to process messages. If the source sends a message to the target but the target is down, the messages will be held until the target is available and ready to process the messages.
The JMS API an also guarantee delivery of the messages and also provide facilities to check that messages have been received. This means that the source application can send the message only once and be sure that the target client will receive it.
Each software vendor that is looking to provide an implementation of the JMS API, must adhere the JMS specification. The specification tells the vendor what facilities they must provide to meet the standard required for the JMS API (how they do it is up to them as long as they meet the standard).
Key Elements Of The JMS API
Here are the main parts of the JMS API that are important (some of these already mentioned above)
- JMS Messaging Domain
- JMS Provider
- JMS Client
- JMS Producer or Publisher
- JMS Consumer or Subscriber
- JMS Message
- JMS Queue
- JMS Topic
JMS Messaging Domain
The Messaging Domain is really a description of the type of messaging that JMS provides
Point To Point
Point to point messaging is based around a source and a target for a message, and is based around message queues. Usually there is only one target for any message. The queue will hold the messages until they are read off the queue.
Publish – Subscribe
In the publish – subscribe, or pub-sub model, there is one source for a message and one or more targets. The target clients subscribe to a topic, and once subscribed they all get a copy of the message.
JMS Providers
A JMS Provider is a system that implements the JMS specification. A JMS provider will manage the various parts if the implementation, such as the queues, topics, sessions, connectivity, configuration etc. There are many JMS Providers available so ill list a few here.
- IBM MQ – previously know as MQSeries and Websphere MQ
- Apache ActiveMQ
- RabbitMQ
- Oracle Open Message Queue (This is the reference implementation for the JMS API)
Most leading application servers will have a JMS Provider built in to provide JMS API facilities to the applications that run within them so ill list some application servers that include a JMS provider here