JMS Interview Questions
What is point-to-point messaging?
With point-to-point message passing the sending application/client establishes a named message queue in the JMS broker/server and sends messages to this queue. The
receiving client registers with the broker to receive messages posted to this queue. There is a one-to-one relationship between the sending and receiving clients.
Can two different JMS services talk to each other?
For instance, if A and B are two different JMS providers, can Provider A send messages directly to Provider B? If not, then can a subscriber to Provider A act as a
publisher to Provider B?
The answers are no to the first question and yes to the second. The JMS specification does not require that one JMS provider be able to send messages directly to
another provider. However, the specification does require that a JMS client must be able to accept a message created by a different JMS provider, so a message received
by a subscriber to Provider A can then be published to Provider B. One caveat is that the publisher to Provider B is not required to handle a JMSReplyTo header that
refers to a destination that is specific to Provider A.
What is the advantage of persistent message delivery compared to nonpersistent delivery?
If the JMS server experiences a failure, for example, a power outage, any message that it is holding in primary storage potentially could be lost. With persistent
storage, the JMS server logs every message to secondary storage. (The logging occurs on the front end, that is, as part of handling the send operation from the message
producing client.) The logged message is removed from secondary storage only after it has been successfully delivered to all consuming clients .
Give an example of using the publish/subscribe model ?
JMS can be used to broadcast shutdown messages to clients connected to the Weblogic server on a module wise basis. If an application has six modules, each module
behaves like a subscriber to a named topic on the server.
Why doesn’t the JMS API provide end-to-end synchronous message delivery and notification of delivery?
Some messaging systems provide synchronous delivery to destinations as a mechanism for implementing reliable applications. Some systems provide clients with various
forms of delivery notification so that the clients can detect dropped or ignored messages. This is not the model defined by the JMS API.
JMS API messaging provides guaranteed delivery via the once-and-only-once delivery semantics of PERSISTENT messages. In addition, message consumers can ensure reliable
processing of messages by using either CLIENT_ACKNOWLEDGE mode or transacted sessions. This achieves reliable delivery with minimum synchronization and is the
enterprise messaging model most vendors and developers prefer.
The JMS API does not define a schema of systems messages (such as delivery notifications). If an application requires acknowledgment of message receipt, it can define
an application-level acknowledgment message.
What are the various message types supported by JMS?
Stream Messages ? Group of Java Primitives
Map Messages ? Name Value Pairs. Name being a string& Value being a java primitive
Text Messages ? String messages (since being widely used a separate messaging Type has been supported)
Object Messages ? Group of serialize able java object
Bytes Message ? Stream of uninterrupted bytes