jms interview questions and answers.Contains frequently asked interview questions on jms for freshers and experienced.
Java Messaging Service(JMS) is a standard for an asynchronous messaging in java.With the help of JMS, we can send and receive messages from client and server asynchronously.Do not confuse JMS with any kind of SMS service. You can simply refer JMS as an asynchronous API.
JMS is asynchronous in nature. Thus not all the pieces need to be up all the time for the application to function as a whole. Even if the receiver is down the MOM will store the messages on it's behalf and will send them once it comes back up. Thus at least a part of application can still function as there is no blocking.
Synchronous messaging refers to messaging technique where client wait for the response in correspondence to the request meaning client can expect instant response from the server. For example, when we make any API call, we instantly get the response of either failure or success. Asynchronous messaging refers to message technique where response is not guaranteed instantly for a given request.
There are basically 2 different messaging models - queue and topic. Queue refers to point to point messaging and Topic refers to public to subscribe model commonly called as pub-sub model.
Queue refers to point to point messaging and Topic refers to public to subscribe model commonly called as pub-sub model.In case of queue model, there will be a single producer and consumer.Once, a message id produced by a producer, only one consumer in the life time of the message can can actually consume the mesage and once this message is consumed, the message is destroyed. But in case of topic or pub-sub domain, a single message can be consumed by many consumers.For example, sending a single message to multiple recipients.
JMS provider is an implementation of the JMS interface for a Message Oriented Middleware (MOM).Actually, JMS provider has multiple roles.Major role involves in securing the messages.It also handles Data Conversion and Client triggering.
The different components of JMS are JMS provider, JMS client, Messages, Administered objects and Native clients.
Connection factory and destination
An implementation of the JMS interface for a Message Oriented Middleware (MOM). Providers are implemented as either a Java JMS implementation or an adapter to a non-Java MOM.
An application or process that produces and/or receives messages.
A JMS client that creates and sends messages.
A JMS client that receives messages.
Durable subscription allows the subscriber to receive messages from producer even if the subscriber is inactive or has lost the connection with the subscriber. Similarly, a non-durable subscriber is a message consumer that only receives messages that are published while the subscriber is active.
Bytes Message stores data in bytes. Thus the message is one contiguous stream of bytes. While the Stream Message maintains a boundary between the different data types stored because it also stores the type information along with the value of the primitive being stored. Bytes Message allows data to be read using any type. Thus even if your payload contains a long value, you can invoke a method to read a short and it will return you something. It will not give you a semantically correct data but the call will succeed in reading the first two bytes of data. This is strictly prohibited in the Stream Message. It maintains the type information of the data being stored and enforces strict conversion rules on the data being read.
TextMessage contains instance of java.lang.String as it's payload. Thus it is very useful for exchanging textual data. It can also be used for exchanging complex character data such as an XML document.
ObjectMessage contains a Serializable java object as it's payload. Thus it allows exchange of Java objects between applications. This in itself mandates that both the applications be Java applications. The consumer of the message must typecast the object received to it's appropriate type. Thus the consumer should before hand know the actual type of the object sent by the sender. Wrong type casting would result in ClassCastException. Moreover the class definition of the object set in the payload should be available on both the machine, the sender as well as the consumer. If the class definition is not available in the consumer machine, an attempt to type cast would result in ClassNotFoundException. Some of the MOMs might support dynamic loading of the desired class over the network, but the JMS specification does not mandate this behavior and would be a value added service if provided by your vendor. And relying on any such vendor specific functionality would hamper the portability of your application. Most of the time the class need to be put in the classpath of both, the sender and the consumer, manually by the developer.
JMS has no inherent support for email operations.
JMS and RPC(Remote Procedure Call) are both related to request–response message-passing system but both have different mechanism of message passing.RPC passes message in an asynchronous way whereas JMS is an asynchronous messaging.
MOM stands for Message Oriented Middleware and it acts as a broker in between the subscriber and consumer.So, all the messages shared between the subscriber and producer first hits the broker and actually the subscriber and producer listens to this broker. The MOM also adds an extra level of security in JMS. for example activeMQ,rabbitMQ
The messages are always converted to some universal format such as JSON or XML and then only the raw messages is transferred from subscriber to producer.
Toward the end of delivery, the message conceptually passes through the following stages: message with JMS provider and message in application processing. Message with JMS provider In this stage, the message stays with the JMS provider just before the provider delivers it to the application. Consider a catastrophic situation where the JMS provider fails. What happens to the messages that the provider has not yet delivered to the client? Will the messages be lost? The messages' fate depends not upon the transaction options outlined earlier, but rather upon the delivery mode. There are two delivery modes: nonpersistent and persistent. Messages with nonpersistent delivery modes are potentially lost if the JMS provider fails. Messages with persistent delivery modes are logged and stored to a stable storage. The JMS provider saves these messages to a stable storage, such as a database or a file system, and eventually delivers them to the application for processing.
To implement client acknowledgement mode, when you create the receiver's session, specify false as createSession()'s first argument and Session.CLIENT_ACKNOWLEDGE as its second argument. Specifying false creates a nontransacted session. In client mode, invoking the Message class's acknowledge() method explicitly acknowledges the message. In fact, using the acknowledge() method makes sense when only using the client mode.
Is this page helpful to you? Please give us your feedback below. We would love to hear your thoughts on these articles, it will help us improve further our learning process.