|
FREQUENTLY ASKED QUESTIONS
General Questions
Technical questions
- What JDK release
does the JMS API need?
- Does the JMS API provide a version of a distributed
Java event model?
- Why are there two separate JMS API domains,
point-to-point and
publish/subscribe, instead of just one?
- Why doesn't the JMS API specify a set of
JavaBeans components?
- How is the JMS API aligned with the CORBA
Notification Service?
- Why doesn't the JMS API provide end-to-end synchronous
message delivery and notification of delivery?
- Why doesn't the JMS API provide a send-to-list
mechanism?
- Why doesn't the JMS API provide subscription
notification?
- Can a message be acknowledged after its message
consumer is closed?
- What message distribution policy does the JMS API
specify when there are two or more
QueueReceivers for the same
queue at the same time?
- How does
CLIENT_ACKNOWLEDGE mode
work when there are two or more TopicSubscribers to the same topic
within a Session?
- What is the recoverability of messages for
closed consumers?
- Why can't I run the JMS API sample programs using the
J2EE 1.2.x SDK?
- According to the specification, "Getting a property
value for a name which has not been set is handled as if the the property
exists with a null value." In the case of
getStringProperty, does
this mean a null value or a null string?
- I used the
Connection.setExceptionListener(ExceptionListener) method to try to
handle connection problems, but when I stop the server, no JMSException
seems to be triggered; the onException method is not called. Is
this a bug?
-
According to Section 3.4 of the JMS Specification, a client can
effectively set only three of the message header fields. All the others are
set either by the JMS provider or by the
send or
publish method. Why do all the fields have a setter method, when
any client setting will be overridden when the message is sent or when the JMS
provider delivers it? Wouldn't it make sense to allow only getter methods for
most of the fields?
-
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?
![[new!]](/images/new.gif)
General questions
Q: What is the Java Message Service?
A:
The Java Message Service (JMS) API is an API for accessing enterprise messaging
systems.
It is part of the
Java 2 Platform,
Enterprise Edition (J2EE).
The Java Message Service makes it easy to write business applications that
asynchronously send and receive critical business data and events.
The Java Message Service defines a common enterprise messaging API that is
designed to be easily and efficiently supported by a wide range of enterprise
messaging products.
The Java Message Service supports both message queueing and publish-subscribe
styles of messaging.
Q: Is the Java Message Service another mail API?
A:
No. The term messaging is broadly defined in computing. It is used for
describing various operating system concepts; it is used to describe email and
fax systems; and with the JMS API, it is used to describe asynchronous
communication between enterprise applications.
JMS messages are asynchronous requests, reports, or events that are consumed by
enterprise applications, not humans. They contain vital information needed to
coordinate these systems. They contain precisely formatted data that describe
specific business actions. Through the exchange of these messages, each
application tracks the progress of the enterprise.
Q: Is the Java Message Service a product?
A:
No, the Java Message Service is the specification of a common API for
enterprise messaging. A JMS provider supplied by an enterprise messaging
vendor is required to use it.
Q: Where can I find the Java Message Service specification?
A:
The Java Message Service 1.0.2 specification is available at
http://java.sun.com/products/jms/docs.html.
A link to the online JMS API documentation is at the same location.
Q: Who was involved with Sun in the creation of the
specification of Java Message Service 1.0.2?
A:
A number of important industry players
initially collaborated with Sun to define the first draft of the Java Message
Service specification. In addition, many comments were received from other
companies, government and educational organizations, and others during the
three-month public review period.
Q: What is compelling about the Java Message Service?
A:
The Java Message Service is compelling for these reasons:
- It is the first enterprise messaging API that has achieved wide industry
support.
- It simplifies the development of enterprise applications by providing
standard messaging concepts and conventions that apply across a wide range of
enterprise messaging systems.
- It leverages existing, enterprise-proven messaging systems.
Q: Why should developers use the Java Message Service?
A:
The Java Message Service makes it easy to do the following:
- Write portable, message-based business applications
- Extend existing message-based applications by adding new JMS
clients that interoperate fully with their existing non-JMS clients
Q: What does a programmer need to learn to use the Java Message Service?
A:
Message-based applications are fundamentally different from remote procedure
call based applications. Once a developer understands how best to employ both
technologies, the JMS API makes writing message-based applications as easy as
learning a few additional interfaces.
Q: What is the relationship between the Java Message Service and
Enterprise JavaBeans components?
A:
Since J2EE version 1.2 was released, Enterprise JavaBeans components have been
able to use the JMS API to send enterprise messages and receive them
synchronously. The Java 2 SDK, Enterprise Edition, version 1.3, now available,
provides a new kind of enterprise bean, the message-driven bean, that
allows an enterprise application to receive messages asynchronously.
Q: What is the relationship between the Java Message Service and the Java
Naming and Directory Interface (JNDI) API?
A:
The JMS API, like the other Java Enterprise APIs, uses the JNDI API for
administration. The JMS API
defines ConnectionFactories and Destinations as administered objects that are
configured and placed in a JNDI naming context. JMS clients then look up and
use these preconfigured objects. This insures that JMS applications are easy
to deploy and administer.
Q: What is the relationship between the Java Message Service and the Java
DataBase Connectivity (JDBC) API?
A:
JMS clients may also use the JDBC API. They may use both the JMS API and the
JDBC API in the same transaction. In most cases, they will achieve this
automatically by implementing these clients as enterprise beans.
They may also use the Java Transaction API.
Q: What is the relationship between the Java Message Service, the Java
Transaction API, and the Java Transaction Service?
A:
The Java Transaction API (JTA) provides a client API for delimiting distributed
transactions and an API for accessing a resource's ability to participate in a
distributed transaction. A JMS client may use JTA to delimit distributed
transactions. A JMS provider can optionally support distributed transactions
via JTA.
The Java Transaction Service (JTS) can be used with the JMS API to form
distributed transactions that combine message sends and receives with database
updates and other JTS aware services. These services should be handled
automatically when a JMS client is run from within an application server such
as a J2EE server; however, it is also possible for JMS clients to program them
explicitly.
Q: Where can I find a JMS API discussion group?
A: You can find a JMS API discussion forum at
http://java.sun.com/j2ee/community/forums/index.html.
You must be a member of the
Java Developer
Connection to join this forum.
Q: Why is the JMS API promoted as a technology for providing
communication between components within an enterprise, but not for
business-to-business (B2B) communication between enterprises over the Internet?
What prevents its use over the Internet?
A: The main issue in providing Internet-based JMS API messaging is that
JMS API vendors would have to agree on a common (interoperable) wire format,
and the JMS specification would have to specify a router-router API.
B2B messaging is an important area with its own unique requirements. This area
is being addressed by emerging standards such as the Electronic Business XML
initiative, ebXML (see http://www.ebxml.org/), where Sun is playing an
active role. The ebXML initiative currently defines a Messaging Service (see the
ebXML Specifications
page), which supports XML messaging over the Internet. Current ebXML
specifications focus on providing point-to-point asynchronous communication
between parties over the Internet using multiple transport protocols such as
HTTP, mail, and FTP. Work is also planned in ebXML to provide publish/subscribe
XML messaging. Sun and its partners are currently defining a new Java API for
XML Messaging, JAXM (see JSR
#000067, Java APIs for XML Messaging 1.0), which supports the ebXML
Messaging Service specification. An early-access version of JAXM is available
via the Java Developer Connection at The M
Project 1.0 Early Access.
In summary, the JMS API is intended for use within an enterprise, while
XML messaging between independent enterprises over the Internet is being
supported by the ebXML initiative and the new Java APIs (including JAXM) that
support various ebXML specifications.
Technical questions
Q: What JDK release does the JMS API
need?
A: The JMS API requires JDK/JRE release 1.1.x or higher.
Q: Does the JMS API provide a version of a distributed Java event model?
A:
The JMS API can be used, in general, as a notification service; however, it does
not define a distributed version of Java Events. One alternative for
implementing distributed Java Events would be as JavaBeans components that
transparently, to the event producer and listener beans, distribute the events
via the JMS API.
Q: Why are there two separate JMS API domains, point-to-point and
publish/subscribe, instead of just one?
A: Even though there are many similarities, providing separate domains
still seems to be important. It means that vendors aren't forced to support
facilities out of their domain and that client code can be a bit more portable
because products more fully support a domain (as opposed to supporting less
defined subsets of a merged domain).
Q: Why doesn't the JMS API specify a set of JavaBeans components?
A: The JMS API is a low-level API, and like other low-level Java APIs, it
doesn't lend itself to direct representation as JavaBeans components.
Q: How is the JMS API aligned with the CORBA Notification Service?
A: The Notification Service adds filtering, delivery guarantee semantics,
durable connections, and the assembly of event networks to the CORBA Event
Service. It gets its delivery guarantee semantics from the CORBA Messaging
Service (which defines asynchronous CORBA method invocation).
Java technology is well integrated with CORBA. It provides Java IDL and COS
Naming. In addition, OMG has recently defined RMI over IIOP.
It is expected that most use of IIOP from Java will be via RMI. It is expected
that most use of COS Naming from Java will be via the JNDI API (Java Naming and
Directory Service). The JMS API is a Java specific API designed to be layered
over a wide range of existing and future Message Oriented Middleware (MOM)
systems (just as the JNDI API is layered over existing name and directory
services).
Q: 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 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.
These issues are more clearly understood when they are examined in the context
of publish/subscribe applications. In this context, synchronous delivery and/or
system acknowledgment of receipt are not an effective mechanism for
implementing reliable applications (because producers by definition are not,
and do not want to be, responsible for end-to-end message delivery).
Q: Why doesn't the JMS API provide a send-to-list mechanism?
A: Currently the JMS API provides a number of message send options;
however, messages can only be sent to one Destination at a time.
The benefit of send-to-list is slightly less work for the programmer and the
potential for the JMS provider to optimize the fact that several destinations
are being sent the same message.
The down side of a send-to-list mechanism is that the list is, in effect, a
group that is implemented and maintained by the client. This would complicate
the administration of JMS clients.
Instead of the JMS API providing a send-to-list mechanism, it is recommended
that providers support configuring destinations that represent a group. This
allows a client to reach all consumers with a single send, while insuring that
groups are properly administrable.
Q: Why doesn't the JMS API provide subscription notification? If it were
possible for a publisher to detect when subscribers for a topic existed, it
could inhibit publication on unsubscribed topics.
A: Although there may be some benefit in providing publishers with a
mechanism for inhibiting publication to unsubscribed topics, the complexity
this would add to the JMS API and the additional provider overhead it would
require are not justified by its potential benefits. Instead, JMS providers
should insure that they minimize the overhead for handling messages published
to an unsubscribed topic.
Q: Can a message be acknowledged after its message consumer
is closed?
A: Yes. Since message acknowledgment processing is performed at the
session level, message acknowledgement is still relevant after a consumer is
closed. All messages consumed by the session are acknowledged for the following
two examples:
// CLIENT_ACKNOWLEDGE session
Message msg1 = topicSubscriber1.receive();
Message msg2 = topicSubscriber2.receive();
topicSubscriber1.close();
msg2.acknowledge();
// transacted session
Message msg1 = queueReceiver.receive();
queueReceiver.close();
session.commit();
|
After the session has been closed, however, a call to the
Message.acknowledge or Session.commit method
throws an IllegalStateException. If close is called
on a transacted session before the transaction in progress is committed, the
transaction is rolled back.
Note that in order to prevent duplicate delivery of a message
from a durable subscription or queue, a message that can still be
acknowledged by a session cannot be redelivered to
another message consumer. The message can only be redelivered
to another message consumer when it can no longer be
acknowledged by the session that initially received the message.
Q: What message distribution policy does the JMS API specify when there
are two or more QueueReceivers for the same queue at the same time?
A: The JMS API does not specify a message distribution policy when two
or more QueueReceivers are registered with a destination at the
same time. JMS API semantics account for only one QueueReceiver at
any point in time. The JMS API does not prohibit multiple
QueueReceivers for a queue; it just does not define the behavior
for this case.
Q: How does CLIENT_ACKNOWLEDGE mode work when there
are two or more TopicSubscribers to the same topic within a
session?
A: From Section 6.11 of the JMS 1.0.2 Specification:
A TopicSession allows the creation of multiple
TopicSubscribers per destination, it will deliver each message for
a destination to each TopicSubscriber eligible to receive it. Each
copy of the message is treated as a completely separate message. Work done on
one copy has no affect on the other; acknowledging one does not acknowledge the
other; one message may be delivered immediately while another waits for its
consumer to process messages ahead of it.
The Message.acknowledge method is documented to acknowledge the
receipt of all messages consumed by the session.
Thus, if msgA is delivered to topic subscribers TS1
and TS2 of the same session, and TS1 synchronously
receives its copy of msgA and acknowledges it, TS2
will still be able to synchronously receive its copy of the message. However,
if TS1 receives its copy of msgA and then
TS2 receives its copy of msgA, acknowledging
receiving the message from TS2 will acknowledge both the
msgAs received by TS1 and TS2, based on
the fact that TS1's copy of msgA was received by the
session before TS2's copy of msgA was received by the
session.
Q: What is the recoverability of messages for closed consumers?
A: For messages consumed from a queue or durable subscription,
a rollback ensures that the messages are not acknowledged
and that they will be delivered to the next consumer of these
persistent entities. The JMS
specification states that messages delivered to non-durable
subscribers may be dropped. This statement means that the JMS API
does not define the recoverability of messages consumed from a non-durable
subscriber.
Q: Why can't I run the JMS API sample programs using the
J2EE 1.2.x SDK?
A: The J2EE 1.2.x Reference Implementation did not include an
implementation of the JMS API. It included only the interfaces. The JMS
Reference Implementation is available as part of J2EE 1.3 and you
can run the sample programs with the J2EE 1.3 server. See the
JMS Tutorial for information on
running simple JMS client programs with the J2EE 1.3 server.
Please see Java Message Service API
Licensees for a list of vendors that provide implementations of the JMS API.
Many of these vendors have demonstration copies of their JMS API implementations
that you can use to run the JMS API samples that you downloaded from the
website.
Q: According to the specification, "Getting a property value for a name
which has not been set is handled as if the the property exists with a null
value." In the case of getStringProperty, does this mean a null
value or a null string?
A: Either is permissible. The reason for this ambiguity is that some
MOM systems do not have the native concept of a null string, so they convert
all null-valued strings at send time to empty strings.
Q: I used the
Connection.setExceptionListener(ExceptionListener) method to try to
handle connection problems, but when I stop the server, no
JMSException seems to be triggered; the onException
method is not called. Is this a bug?
A: The JMS specification does not specify exactly what exceptions are
delivered to an ExceptionListener or when they are delivered, so
providers vary in how they handle connection problems. Check with your JMS
provider if you have questions.
Q: According to Section 3.4 of the JMS Specification, a client can
effectively set only three of the message header fields. All the others are
set either by the JMS provider or by the send or
publish method. Why do all the fields have a setter method, when
any client setting will be overridden when the message is sent or when the JMS
provider delivers it? Wouldn't it make sense to allow only getter methods for
most of the fields?
A: The specification requires setter methods mainly for consistency,
so that each message header field has both a getter and setter method. Another
reason is to allow a receiving client to change a field after a message is
received but before it is passed to some other part of an application for
processing. Although most setter methods are used very rarely, they are
provided to give programmers flexibility.
Q: 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.
 |
