JMS -Enterprise messaging systems

The Java Message Service was developed by Sun Microsystems to provide a means for Java programs to access enterprise messaging systems. Before we discuss JMS, let’stake a look at enterprise messaging systems.

Enterprise messaging systems, often known as message oriented middleware (MOM), provide a mechanism for integrating applications in a loosely coupled, flexible manner. They provide asynchronous delivery of data between applications on a store and forward basis; that is, the applications do not communicate directly with each other, but instead communicate with the MOM, which acts as an intermediary.
The MOM provides assured delivery of messages (or at least makes its best effort) and relieves application programmers from knowing the details of remote procedure calls (RPC) and networking/communications protocols.
Enterprise messaging systems, often known as message oriented middleware (MOM), provide a mechanism for integrating applications in a loosely coupled, flexible manner. They provide asynchronous delivery of data between applications on a store and forward basis; that is, the applications do not communicate directly with each other, but instead communicate with the MOM, which acts as an intermediary.
The MOM provides assured delivery of messages (or at least makes its best effort) and relieves application programmers from knowing the details of remote procedure calls (RPC) and networking/communications protocols.

The Java Message Service was developed by Sun Microsystems to provide a means for Java programs to access enterprise messaging systems. Before we discuss JMS, let’stake a look at enterprise messaging systems.

Messaging flexibility

As shown in the figure below, Application A communicates with Application B by sending a message through the MOM’s application programming interface (API).

The MOM routes the message to Application B, which may exist on a completely different computer; the MOM handles the network communications. If the network connection is not available, the MOM will store the message until the connection becomes available, and then forward it to Application B.
Another aspect of flexibility is that Application B may not even be executing when Application A sends its message. The MOM will hold the message until Application B begins execution and attempts to retrieve its messages. This also prevents Application A from blocking while it waits for Application B to receive the message.
This asynchronous communication requires applications to be designed somewhat differently than most are designed today, but it can be an extremely useful method for time-independent or parallel processing.

Loose coupling

The real power of enterprise messaging systems lies in the loose coupling of the applications. In the diagram on the previous panel, Application A sends its messages indicating a particular destination, for example “order processing.” Today, Application B provides order processing capabilities.

But, in the future, we can replace Application B with a different order-processing program, and Application A will be none the wiser. It will continue to send its messages to “order processing” and the messages will continue to be processed.

Likewise, we could replace Application A, and as long as the replacement continued to send messages for “order processing,” the order-processing program would not need to know there is a new application sending orders.

Publish and subscribe

Originally, enterprise messaging systems were developed to implement a point-to-point model (PTP) in which each message produced by an application is received by one other application. In recent years, a new model has emerged, called publish and subscribe (or pub/sub).

Pub/sub replaces the single destination in the PTP model with a content hierarchy, known as topics. Sending applications publish their messages, indicating that the message represents information about a topic in the hierarchy.

Applications wishing to receive those messages subscribe to that topic. Subscribing to a topic in the hierarchy which contains subtopics allows the subscriber to receive all messages published to the topic and its subtopics.

Multiple applications may both subscribe and publish messages to a topic, and the applications remain anonymous to each other. The MOM acts as a broker, routing the published messages for a topic to all subscribers for that topic.

This figure illustrates the publish and subscribe model.

JMS publish and subscribe model