|
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.
Page Numbers : 1
2
3
4
5
6
Have a Question ?
post your questions here. It
will be answered as soon as possible.
Check
Java Interview
Questions for more Java Interview Questions with answers
Check
Structs Interview
Questions for more Structs Interview Questions with answers
Check
Servlet Interview
Questions for more Servlet Interview Questions with answers
|