Java Message Service (JMS)

Definition - What does Java Message Service (JMS) mean?

Java Message Service (JMS) is an application programming interface (API) by Sun Microsystems that functions as Java message-oriented middleware. It is designed for an exchange of loosely coupled, reliable and asynchronous messages between different software application components (called clients), which are based on the Java 2 Platform, Enterprise Edition (J2EE).

JMS is a messaging standard capable of creating, sending, receiving and reading messages as requests, reports, or events consumed by the software application components, not by humans. JMS allows programs in dissimilar systems, or written in different programming languages, to coordinate with each other via messages.

Free Techopedia White Paper | The Ultimate Guide to Applying AI in Business > Download Now

Techopedia explains Java Message Service (JMS)

JMS API uses two messaging models:

Point-to-point, or Queuing, Model
JMS is loosely coupled by the virtue of an intermediary component, a queue. Thus, software components communicate indirectly. This means that message-sending software components will not require knowledge about the receiving software component. This model is characterized by:
- Only one component is receiving the message.
- The source component is not operating when the receiving component receives the message.
- The receiving component is not operating when the message is sent.
- Messages successfully processed are being acknowledged by the receiving component.
Publish-and-Subscribe Model
This model works as an anonymous bulletin board. A subscribing component may register the need to receive messages on a specified topic, but neither component (publisher or subscriber) is required to know about the other. This model is characterized by multiple components receiving the message and a timing dependency between publishing components and subscribing components as follows:
- The publisher component creates a message topic for other components to subscribe to.
- The subscriber component remains able to receive messages, unless a durable subscription is established.
- If a durable subscription is established, messages published while the subscriber is not able to receive messages will be redistributed whenever the receiving component reconnects.