- Tech know how online

Java message service (JMS)

The JavaMessageService (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 clients or producers and consumers. 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 with each other in a uniform manner. The JMS API supports two main messaging methods - the point-to-point method and the publish-and-subscribe method. These methods are also known 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 because 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.

JMS Clients and Providers

JMS Clients and Providers

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 principal 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 the producer, the receiver the 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 it is possible or necessary to decouple the producer and consumer in terms of time.

Publish-and-Subscribe (Pub/Sub) In this model , the producer becomes the publisher and the consumer the subscriber. The messages are assigned to topics. Many producers publish their news to a topic, while any number of consumers subscribe to the news from the topic. If there are several consumers, this is also called 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 types of clients.
  • Messages are 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 used to establish a connection by the JMS client.
  • Destination - an object that defines the source and destination of the messages. The object represents a queue for the messages.
The administered objects are entered into a JNDI (Java Naming and DirectoryInterface) by the JMS provider. This makes them available to every JMS client in a portable way, and the objects can be accessed via the JMS API.

Contexts of Communication via JMS

General JMS Model

General JMS Model

The figure illustrates the relationship between connection establishment and communication via JMS. First, aconnection is established between the JMS client and the JMS provider. The JMS standard defines the objects Connection, Session, Message Producer, and Message Consumer, which a JMS client can use to access the services of its JMS provider. The JMS provider is responsible for the appropriate implementation of the interfaces, whereby the process flow 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 queue of the provider.
  • A session is opened to control the communication, the MessageProducer is connected to the queue object.
When sending a message, the following procedure must be followed: The message generated by the JMS client is passed to the MessageProducer for storage in the queue.

When a message is received, 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.

Informationen zum Artikel
Englisch: Java message service - JMS
Updated at: 28.10.2013
#Words: 1545