Skip to main content

Java Messaging Service

Message-Oriented-Middleware provide a common reliable way for programs to create, send, receive and read messages in any distributed Enterprise System. MOM ensures fast, reliable asynchronous electronic communication, guaranteed message delivery, receipt notification and transaction control.

The Java Message Service (JMS) provides a standard Java-based interface to the message services of a MOM of some other provider.

Messaging systems are classified into different models that determine which client receives a message. The most common messaging models are:
Publish-Subscribe Messaging
Point-To-Point Messaging
Request-Reply Messaging

Not all MOM providers support all these models.

Publish-Subscribe Messaging

When multiple applications need to receive the same messages, Publish-Subscribe Messaging is used. The central concept in a Publish-Subscribe messaging system is the Topic. Multiple Publishers may send messages to a Topic, and all Subscribers to that Topic receive all the messages sent to that Topic. This model, as shown in Figure 1, is extremely useful when a group of applications want to notify each other of a particular occurrence.

The point to note in Publish-Subscribe Messaging is that, there may be multiple Senders and multiple Receivers.

Point-To-Point Messaging

When one process needs to send a message to another process, Point-To-Point Messaging can be used. However, this may or may not be a one-way relationship. The client to a Messaging system may only send messages, only receive messages, or send and receive messages. At the same time, another client can also send and/or receive messages. In the simplest case, one client is the Sender of the message and the other client is the Receiver of the message.

There are two basic types of Point-to-Point Messaging systems. The first one involves a client that directly sends a message to another client. The second and more common implementation is based on the concept of a Message Queue. Such a system is shown in Figure 2.

The point to note in Point-to-Point messaging is that, even though there may be multiple Senders of messages, there is only a single Receiver for the messages.


Request-Reply Messaging
When an application sends a message and expects to receive a message in return, Request-Reply Messaging can be used. This is the standard synchronous object-messaging format. This messaging model is often defined as a subset of one of the other two models. JMS does not explicitly support Request-Reply Messaging, though it allows it in the context of the other methods.

The Java Message Service (JMS) Architecture
Figure 3 shows the JMS Architecture. As shown in Figure 3, JMS Service Providers implement the JMS interface on top of their messaging services. JMS defines Queues and Topics, but it does not require the provider to implement both. JMS thus tries to maximize portability of the solution with as many features as possible.


The primary features of JMS are as follows:
· Connection Factories are used in JMS to create connections to a specific JMS provider.

· In JMS, both Publish-Subscribe Messaging and Point-To-Point are implemented and defined by separate interfaces so that a Provider does not have to support both.

· JMS defines the concept of a Topic or a Queue as the target for a Message. Topics are used for Publish-Subscribe Messaging. Queues are used for Point-to-Point Messaging.

· The Providers’ code is defined by interfaces in JMS, freeing the implementation from the limitations of subclassing.

· JMS provides support for distributed transactions.

The Java Message Service API
Both Publish-Subscribe Messaging and Point-To-Point Messaging inherit from a common set of abstract interfaces asshown in the below table

JMS Parent

Publish-Subscribe Domain

Point-To-Point Domain

DestinationTopicQueue
ConnectionFactoryTopicConnectionFactoryQueueConnectionFactory
ConnectionTopicConnectionQueueConnection
SessionTopicSessionQueueSession
MessageProducerTopicPublisherQueueSender
MessageConsumerTopicSubscriberQueueReceiver, QueueBrowser

Table 1: Relationship of Point-To-Point and Publish-Subscribe interfaces

Comments

Popular posts from this blog

Asynchronous Vs. Synchronous Communications

Synchronous (One thread):   1 thread -> |<---A---->||<----B---------->||<------C----->| Synchronous (multi-threaded):   thread A -> |<---A---->| \ thread B ------------> ->|<----B---------->| \ thread C ----------------------------------> ->|<------C----->|

WebSphere MQ Interview Questions

What is MQ and what does it do? Ans. MQ stands for MESSAGE QUEUEING. WebSphere MQ allows application programs to use message queuing to participate in message-driven processing. Application programs can communicate across different platforms by using the appropriate message queuing software products. What is Message driven process? Ans . When messages arrive on a queue, they can automatically start an application using triggering. If necessary, the applications can be stopped when the message (or messages) have been processed. What are advantages of the MQ? Ans. 1. Integration. 2. Asynchrony 3. Assured Delivery 4. Scalability. How does it support the Integration? Ans. Because the MQ is independent of the Operating System you use i.e. it may be Windows, Solaris,AIX.It is independent of the protocol (i.e. TCP/IP, LU6.2, SNA, NetBIOS, UDP).It is not required that both the sender and receiver should be running on the same platform What is Asynchrony? Ans. With messag...

Advantages & Disadvantages of Synchronous / Asynchronous Communications?

  Asynchronous Communication Advantages: Requests need not be targeted to specific server. Service need not be available when request is made. No blocking, so resources could be freed.  Could use connectionless protocol Disadvantages: Response times are unpredictable. Error handling usually more complex.  Usually requires connection-oriented protocol.  Harder to design apps Synchronous Communication Advantages: Easy to program Outcome is known immediately  Error recovery easier (usually)  Better real-time response (usually) Disadvantages: Service must be up and ready. Requestor blocks, held resources are “tied up”.  Usually requires connection-oriented protocol