Java message service (JMS)
The Java Message Service (JMS) defines an open standard for a uniform Java interface with regard to Message Oriented Middleware (also MOM or message-oriented middleware). In the sense of MOM, a message service implementation with its possibly further functions such as security functions, load balancing or tools for administration is also referred to as a JMS provider.
The users of this service are generally called client or also producer and consumer. Producer and consumer do not communicate directly with each other but via the provider. The sending client is always asynchronous in relation to the provider, while the receiving client can act both asynchronously and synchronously. In any case, it is advantageous that the JMS can thus connect different platforms in a uniform manner. The JMS API supports two main messaging methods - the point-to-point method and the publish-subscribe method. These methods are also referred to as messaging domains. JMS was developed by Sun Microsystems and is part of the Java Enterprise Edition (JEE).
The JMS specification is very extensive. To some extent, this is due to the fact that at the time this specification was written, the structure of MOM systems was very inconsistent, having existed for a considerable time before. The current specification is available in full at the link below.
The figure shows the provider with its clients - a producer, which generates and sends the message - and - a consumer, which receives the message and acts accordingly - in a basic principle arrangement.
JMS supports the following message models:
Point-to-Point (PTP) Here the message - which has exactly one receiver - is sent to a queue. The sender is called producer, the receiver is called consumer. Both are completely independent of each other in terms of time. The queue is used to store persistent messages that can either be read by the consumer or become invalid depending on a time limit. This model is mainly used where a temporal decoupling of producer and consumer is possible or necessary.
Publish-Subscribe (Pub/Sub) In this model , the producer becomes the publisher and the consumer the subscriber. The messages are assigned to so-called topics. Many producers publish their messages to a topic, while any number of consumers subscribe to the messages from the topic. With several consumers one speaks also of multicast. This model is used in systems where messages have to be distributed in real time, for example RSS feeds or stock exchange services.
A JMS application can now use one of these message models or also combinations of these so-called message domains. In any case, the architecture of a JMS application is composed of the following elements:
- JMS clients refer to the Java programs that send and receive messages.
- Non-JMS clients( legacy clients) use the API of the message system but not JMS. A message system usually supports both forms of clients.
- Messages refer to the messages that enable the exchange of information between clients.
- JMS providers define a message system that implements JMS in addition to administrative functions.
- JMS objects are referred to as administrative objects. These are administered by the JMS provider and provide connection information to JMS clients.
JMS now takes into account that JMS providers may differ significantly in terms of their configuration or even technology. These characteristics are also referred to as proprietary, and the goal is portability of JMS clients and deployed JMS provider. This is ensured by the administrative objects created by the JMS provider, of which there are two different types:
- ConnectionFactory - an object for establishing a connection by the JMS client.
- Destination - an object that defines the source and destination of messages. The object represents a queue for the messages.
The administered objects are entered into a JNDI (Java Naming and Directory Interface) by the JMS provider. This makes them available to any JMS client in a portable way, and the objects can be accessed via the JMS API.
Context of communication via JMS
The figure illustrates the relationship between connection establishment and communication via JMS. First, a connection is established between the JMS client and the JMS provider. For this purpose, the JMS standard defines the objects Connection, Session, Message-Producer and MessageConsumer, via which a JMS client can reach the services of its JMS provider. The appropriate implementation of the interfaces is the task of the JMS provider, whereby the process can vary depending on the message model selected.
To establish a connection and communicate, a JMS client must generate the following steps:
- Request the administrative objects (ConnectionFactory and Destination) via the name service (JNDI).
- ConnectionFactory is responsible for the connection, Destination implements the provider's queue.
- A session is opened to control the communication, MessageProducer is connected to the queue object.
When sending a message, the following sequence must be followed: The message generated by the JMS client is passed to the MessageProducer for storage in the queue.
When receiving a message, a distinction must be made between: Asynchronous reception: for this purpose, the JMS client installs a MessageListener that informs it when a message is available for it at the JMS provider, and synchronous reception: the JMS client waits until the MessageConsumer has received a message for it, which can lead to the JMS client being blocked.
JMS is not multithreaded but with limitations the design of JMS supports multiple users. For example, the JMS objects Destination, ConectionFactory and Connection support so-called concurrent uses.