JMS Interview Questions And Answers _ 6

[ganeshbala]

JMS Interview Questions And Answers

What are the three components of a Message ?
A1:
A jms message has three components
1. A header
2. Properties (Optional)
3. A body (Optional)

A2:
A JMS message consists of three parts:
Message header - For message identification. For example, the header is used to determine if a given message is appropriate for a "subscriber"
Properties - For application-specific, provider-specific, and optional header fields
Body - Holds the content of the message. Several formats are supported, including TextMessage, which wrap a simple String, that wrap arbitrary Java objects (which must be serializable). Other formats are supported as well.

What is the difference between queue and topic?

A1:
A connection is created between the client and the server from a connection factory. Connections can be shared by several threads. The user credentials are supplied at this level. It is probably common for a client application to share access to a single connection to the server (unless different security credentials are required for different destinations). A session is created from a connection. The session may only be used by one thread at one time. The user credentials are inherited from the parent connection.
It is probably common for each MessageProducer (TopicPublisher or QueueSender) or MessageConsumer (TopicSubscriber or QueueReceiver) to have their own session due to the threading restriction. You can look at it like a tree. At the top you have a connection factory, beneath this you have your connections and then beneath the connections you have sessions. The leaves of the tree are the JMS actors (MessageProducers and MessageConsumers).

A2:
Both work on 2 different comminication models. Queue is point-to-point and topic is publish-subscriber.

A3:
In queues, one message can be consumed by only one client. But in the topics, one message can be consumed by many clients. Both are separate domains in MOM.
Queue represent Point-To-Point domain and Topic represent Pub/Sub domain

A4:
A point-to-point (PTP) product or application is built around the concept of message queues, senders, and receivers. Each message is addressed to a specific queue, and receiving clients extract messages from the queue(s) established to hold their messages. Queues retain all messages sent to them until the messages are consumed or until the messages expire.
In a publish/subscribe (pub/sub) product or application, clients address messages to a topic. Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a topic's multiple publishers to its multiple subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers.

What are the types of messaging?
There are two kinds of Messaging. Synchronous messaging involves a client that waits for the server to respond to a message. Asynchronous messaging involves a client that does not wait for a message from the server. An event is used to trigger a message from a server.

What is the difference between Point to Point and Publish/Subscribe
Point-to-point (P2P)
In point-to-point, messages are sent via queues. Messages are put onto the queues by the message producers (the clients). The message consumer is responsible for pulling the message from the queue. Point-to-point is typically used when a given message must be processed (received) only once by a given consumer. In this way, there is only one consumer of the given message.
Publish-and-subscribe (pub/sub)
In publish-and-subscribe, messages are sent through topics. Messages are published to topics by the message producers. The messages may be received by any consumers that subscribe to the given topic. In this way, a message may be received, or processed, by multiple consumers.

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 insure 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 core JMS-related objects required for each JMS-enabled application?
Each JMS-enabled client must establish the following:
* A connection object provided by the JMS server (the message broker)
* Within a connection, one or more sessions, which provide a context for message sending and receiving
* Within a session, either a queue or topic object representing the destination (the message staging area) within the message broker
* Within a session, the appropriate sender or publisher or receiver or subscriber object (depending on whether the client is a message producer or consumer and uses a point-to-point or publish/subscribe strategy, respectively). Within a session, a message object (to send or to receive)

How does the Application server handle the JMS Connection?
1. App server creates the server session and stores them in a pool.
2. Connection consumer uses the server session to put messages in the session of the JMS.
3. Server session is the one that spawns the JMS session.
4. Applications written by Application programmers creates the message listener.

What is Stream Message ?
Stream messages are a group of java primitives. It contains some convenient methods for reading the data. However Stream Message prevents reading a long value as short. This is so because the Stream Message also writes the type information along with the value of the primitive type and enforces a set of strict conversion rules which actually prevents reading of one primitive type as another.