JMS Interview Questions and Answers

Q. What is Message Oriented Middleware? What is JMS?
A.  Message Oriented Middleware (MOM) is generally defined as a software infrastructure that asynchronously communicates with other disparate systems (e.g. Mainframe system, C++ System, etc) through the production and consumption of messages. A message may be a request, a report, or an event sent from one part of an enterprise application to another.

Q. How does JMS differ from RPC(Remote Procedure Call)?
A. 

Remote Procedure Call (e.g. RMI)

Java Messaging Service (JMS)

Remote Procedure Call (RPC) technologies like RMI attempt to mimic the behavior of system that runs in one process. When a remote procedure is invoked the caller is blocked until the procedure completes and returns control to the caller. This is a synchronous model where process is performed sequentially ensuring that tasks are completed in a predefined order. The synchronized nature of RPC tightly couples the client (the software making the call) to the server (the software servicing the call). The client can not proceed (i.e. its blocked) until the server responds. The tightly coupled nature of RPC creates highly interdependent systems where a failure on one system has an immediate impact on other systems.

With the use of Message Oriented Middleware (MOM), problems with the availability of subsystems are less of an issue. A fundamental concept of MOM is that communications between components is intended to be asynchronous in nature. Code that is written to connect the pieces together assumes that there is a one-way message that requires no immediate response. In other words, there is no blocking. Once a message is sent, the sender can move on to other tasks; it doesn't have to wait for a response. This is the major difference between RPC and asynchronous messaging and is critical to understanding the advantages offered by MOM systems. In an asynchronous messaging system each subsystem (Customer, Account, etc) is decoupled from the other systems. They communicate through the messaging server (aka a broker), so that a failure in one does not impact the operation of the others.

Q. Why use JMS?
A. Message Oriented Middleware (MOM) systems like Websphere MQ (formerly known as MQSeries), webMethods broker, SonicMQ, etc are proprietary systems. Java Message Service (JMS) is a Java API that allows applications to create, send, receive, and read messages in a standard way.  Like JDBC API is used to access database drivers in a standard way.

This is another example of the adapter design pattern. Designed by Sun and several partner companies, the JMS API defines a common set of interfaces and associated semantics that allow programs written in the Java programming language to communicate with other messaging implementations provided by MOM libraries. The JMS API minimizes the set of concepts a programmer must learn to use messaging products but provides enough features to support sophisticated messaging applications.

Many companies have spent decades developing their legacy systems. So, XML can be used in a non-proprietary way to move data from legacy systems to distributed systems like JEE over the wire-using MOM implementation and JMS interface.

Q. What are the components of the JMS architecture?
A.

Message producers: A component that is responsible for creating a message. E.g. QueueSender, and TopicPublisher. An application can have several message producers. Each producer might be responsible for creating different types of messages and sending them to different destinations (i.e. Topic or Queue). A message producer will send messages to a destination regardless of whether or not a consumer is there to consume it.

Message consumers: A component which resides on the receiving end of a messaging application. Its responsibility is to listen for messages on a destination (i.e. Topic or Queue) . E.g. QueueReceiver, TopicSubscriber, MessageDrivenBean (MDB). A MDB is simply a JMS message consumer. A client cannot access a MDB directly as you would do with Session or Entity beans. You can only interface with a MDB by sending a JMS message to a destination (i.e. Topic or Queue) on which the MDB is listening.

Message destinations: A component which a client uses to specify the target of messages it sends/receives. E.g. Topic (publish/Subscribe domain) and Queue (Point-to-Point domain). Message destinations typically live on a MOM, which is remote to the clients. Message destinations are administered objects that need to be configured.

JMS messages: A message is a component that contains the information (aka payload) that must be communicated to another application or component. E.g. TextMessage (XML file), ObjectMessage (serialized object) etc.



JMS Administered objects: JMS administered objects are objects containing configuration information that are set up during application deployment or configuration and later used by JMS clients. They make it practical to administer the JMS API in the enterprise. These administered objects are initialized when the application server starts. When a producer or a consumer needs to get a connection to receive or send a JMS message, then you need to locate the configured administered objects QueueConnectionFactory or TopicConnectionFactory. Message destinations are administered objects that need to be configured as well. These administered objects hide provider-specific details from JMS clients.

JNDI naming service: For a producer and consumer to be able to use the administered objects to send and receive messages, they must know how to locate things such as the destination and connection factories.

Example To publish a message to a topic: (Note: exception handling etc are omitted for brevity)

 String factoryJndiName = "WSMQTopicConnectionFactory";
 String destinationJndiName = "wsmq/topic/ProductManagerTopic";

 //JNDI lookup of administered ConnectionFactory object
 Context iniCtx = new InitialContext();
 TopicConnectionFactory topicCF = (TopicConnectionFactory) iniCtx.lookup(factoryJndiName);

 //JNDI lookup of administered destination (i.e. Topic)
 Topic topicDestination = (Topic) iniCtx.lookup(destinationJndiName);

 //get a connection from the TopicConnectionFactory
 TopicConnection publishConnection = topicCF.createTopicConnection(); 
 
 //get a session from the connection. Session should be accessed by only one thread.
 TopicSession publishSession =   
                 publishConnection.createTopicSession(false,TopicSession.AUTO_ACKNOWLEDGE);
 
 //create a publisher from the session
 TopicPublisher publisher = publishSession.createPublisher(reqDestination);

 //create a JMS message to send
 TextMessage message = publishSession.createTextMessage();
 message.setText("JMS test message");

 //send the message
 publisher.publish(message, DeliveryMode.NON_PERSISTENT, 4, 0);

To consume a message

String factoryJndiName = "WSMQTopicConnectionFactory";
String destinationJndiName = "wsmq/topic/ProductManagerTopic";

//JNDI lookup of administered ConnectionFactory object
Context iniCtx = new InitialContext();
TopicConnectionFactory topicCF = (TopicConnectionFactory) iniCtx.lookup(factoryJndiName);

//JNDI lookup of administered destination (i.e. Topic)
Topic topicDestination = (Topic) iniCtx.lookup(destinationJndiName);

//get a connection from the TopicConnectionFactory
TopicConnection subscribeConnection = topicCF.createTopicConnection(); 
 
//get a session from the connection
TopicSession subscribeSession = 
                  subscribeConnection.createTopicSession(false,TopicSession.AUTO_ACKNOWLEDGE);
 
//create a subscriber from the session
TopicSubscriber subscriber = subscribeSession.createsubscriber(reqDestination);

//look for messages every 1 second
while (true) {
    Message response = subscriber.receive();

    if (response != null && response instanceof TextMessage) {
         System.out.println (((TextMessage) response).getText());
    } 

    Thread.sleep(1000);
}

If you use JEE container with a Message Driven Bean (MDB) or Spring Container with a message listener, the container will provide the infrastructure for receiving messages, and invokes the onMessage(Message message) to process the message.

public void onMessage(Message message) {

    String text = null;
    if (message instanceof TextMessage) {
       text = ((TextMessage)message).getText();
    }

    log.info(text);
}

Q. What is a message broker?
A. A message broker acts as a server in a MOM. A message broker performs the following operations on a message it receives:

• Processes message header information.
• Performs security checks and encryption/decryption of a received message.
• Handles errors and exceptions.
• Routes message header and the payload (aka message body).
• Invokes a method with the payload contained in the incoming message (e.g. calling onMessage(..) method on a Message Driven Bean (MDB)).
• Transforms the message to some other format. For example XML payload can be converted to other formats like HTML etc with XSLT.