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?
A:
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?
A:
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.
A:
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?
A:
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?
A:
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
How
is a java object message delivered to
a non-java Client?
A:
It
is according to the specification that the
message sent should be received in the same
format. A non-java client cannot receive
a message in the form of java object. The
provider in between handles the conversion
of the data type and the message is transferred
to the other end.
What is MDB and What is the special feature
of that?
A:
MDB
is Message driven bean, which very much
resembles the Stateless session bean. The
incoming and out going messages can be handled
by the Message driven bean. The ability
to communicate asynchronously is the special
feature about the Message driven bean.
There
are two kinds of Messaging.
Synchronous Messaging: Synchronous messaging
involves a client that waits for the server
to respond to a message.
Asynchronous Messaging: 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
are the core JMS-related objects required
for each JMS-enabled application?
A:
:
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)
.
