Java Message Service FAQ From Jguru

Java Message Service (JMS) FAQ From jGuru
Generated Sep 13, 2005 1:42:06 PM
Location: http://www.jguru.com/faq/JMS
Ownership: http://www.jguru.com/misc/user-agree.jsp#ownership.
What is JMS?
Location: http://www.jguru.com/faq/view.jsp?EID=772
Created: Nov 10, 1999 Modified: 1999-11-10 16:20:17.574
Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9)
Java Message Service (JMS) is a specification for message passing and related
operations among distributed software components. JMS vendors implement the
specification, providing the requisite API library, plus a broker, or server, that handles
message passing among clients. Programmers then implement applications that
communicate with each other by way of the vendor's JMS software.
What is message passing?

Message passing is a general term for a variety of strategies for high-level,

structured interclient communication. For example, a mobile agent framework could
provide classes and methods with which two agents (on two different computers)
send each other messages. The steps required to send and receive messages are
specific to the framework. JMS supports two common message passing strategies,
namely, point-to-point and publish/subscribe. JMS can be utilized by any (Java-
based) distributed software components; of course, the JMS middleware must be
available.
Are there other messaging frameworks that use Java technology?

Yes. Prior to JMS, Java software for various distributed computing environments, for
example, the WebLogic server, the Aglet framework for mobile agents, SoftWired's
iBus software, and many others have provided a variety of message-oriented,
interclient communication solutions for enterprise computing. In many cases, the
messaging functionality is part of a larger distributed computing framework.
Why is JMS important?

There are several reasons. First, the JMS specification includes two popular
messaging strategies: point-to-point and publish/subscribe. Many vendors are
supporting this common framework; hence, programmers will be able to implement
message-oriented operations in their distributed software that will be portable across
many messaging-oriented middleware (MOM) products.
Second, JMS supports both synchronous and asynchronous message passing. In

some scenarios, asynchronous messaging is essentially required; in others, it is
simply more convenient than synchronous message operations; and, in general,
there are scenarios for which highly structured, synchronous communication, such as
remote method invocations, is just too rigid.
A third important issue is that JMS supports an event-oriented approach to message

reception; event-driven programming is now widely recognized as a productive
programming paradigm with which many programmers are now quite familiar.
Fourth, although the JMS specification does not require a security-related API, many
JMS implementations provide extensive built-in security. Messages can be
transmitted using certificates, as well as encryption. JMS implementations free the
developer from many security burdens associated with distributed computing
because JMS applications work through the JMS server, which provides security
through administered objects. That is, beyond the application, it's possible to
establish topic- and queue-based security controls for users, groups, access lists, and
so on.
Where would I use JMS software?

JMS-based communication is a potential solution in any distributed computing

scenario in which you need to pass data, either synchronously or asynchronously,
among distributed software components. A distributed component can subscribe to
specific topics, or connect to specific queues, and then act accordingly when
qualifying messages arrive.
JMS can be an important tool for both e-commerce and e-business applications. Any
enterprise computing strategy that calls for middleware solutions that function as
glue and/or communication pathways among legacy applications is a potential
candidate for JMS-based distributed software components. It is straightforward to
write distributed components, for example, Enterprise JavaBeans that interface with
legacy applications. These legacy-software-managing Enterprise JavaBeans can send
legacy-related data among themselves via JMS middleware.
Comments and alternative answers
JMS
Author: Gopesh Khandelwal (http://www.jguru.com/guru/viewbio.jsp?EID=810100),
Mar 24, 2002
Could you give me some real life examples where JMS can be utilized.
Is JMS an alternative to Enterprise JavaBeans (EJB)?

No. An Enterprise JavaBean implements arbitrary server-side functionality using a

well-known component architecture. An Enterprise JavaBean is deployed within an
EJB server on an arbitrary network host. It performs services for (typically, remotely
located) distributed application components using synchronous communication,
namely, remote method invocations. JMS, in contrast, provides a general and flexible
framework for sending messages among application components, including
Enterprise JavaBeans. JMS-based communication is useful in many distributed
computing scenarios, including those that utilize Enterprise JavaBeans. In fact,
Enterprise JavaBeans can use JMS for message passing among beans.
Does JMS require the Java Naming and Directory Interface (JNDI)?
No, but... JNDI provides network-oriented look-up services for distributed objects
(among other things). It's possible to implement, as well as use, JMS software
without JNDI. In general, however, JNDI provides critical services for JMS-based
software because it's important to be able to locate (programmatically) JMS services
implemented in objects called factories.
For example, applications that communicate via JMS must set up communication
pathways that involve destinations (topic areas and queues), connections, sessions,
and so on. JNDI makes it easy for an application to locate, for example, a connection
factory for the appropriate vendor's JMS middleware, which can then provide a
connection, which can provide a session, and so on, all relative to the JMS server
that's associated with that connection factory.
What is the role of the JMS server? Why is it necessary?

The server, message broker, or whatever it is called, functions as an intermediary.

Suppose a distributed component wants to send (financial) stock information to one
or more remotely located distributed components. Rather than having to know the
exact clients to which it sends messages containing stock information, it can
establish either a message queue or a message topic area (depending on the
message-passing scheme, point-to-point or publish/subscribe) with the JMS server
and "post" the stock information with the server, which then distributes the
messages to the appropriately registered receiving clients.
Also, without this intermediary, the sending client would have the burden of
monitoring whether or not the receiving client is currently connected, whether or not
a network failure occurred during the send operation, and so on. The server plays an
important role in transparently handling many network-related issues, including
reliable message delivery, which can require transaction processing and/or persistent
message storage.
Does JMS provide load balancing, fault tolerance, scalability, and so on?
The JMS specification does not address these issues; hence, vendors are free to
implement their own support, and many vendors do provide these services.
What else is missing from JMS?!

The answer depends on your point of view. From one point of view, nothing is
missing. In terms of common distributed computing-related functionality, typically
present in larger Java application servers, JMS does not mandate functionality
related to the following:
• Administration
• Error, or system event, notification
• Load balancing, scalability
• Low-level transport protocol
• Security
What software do I need in order to add JMS message passing to my

enterprise's existing distributed applications?
The "J" in JMS stands for Java, so the first prerequisite is a Java development and
runtime environment.
The second prerequisite is Java-based distributed applications, as opposed to

C++/CORBA applications. Examples include applications developed using the
distributed computing framework that accompanies popular Java application servers
such as Gemstone/J, ObjectSpace's Voyager, the WebLogic server, and others. EJB
applications are, of course, distributed applications. Enterprise JavaBeans are often
deployed in EJB-only servers, or in EJB-capable Java application servers.
Third, if not provided by the existing distributed computing software, you must have
a JMS implementation. Note that some Java application servers include JMS; hence,
they provide virtually seamless access to JMS functionality.
Is it possible to develop distributed applications with JMS alone? Is it

necessary to have a Java application server, EJB server, and so on?
Yes. No. Minimally, a computing task can be distributed among two or more Java
applications that interoperate by sending and receiving data via JMS. Thus, the
minimal JMS-ready environment includes a Java development and/or runtime
environment plus JMS middleware.
And, of course, distributed applications can use JMS message passing directly, or
develop a higher-level, enterprise-specific framework on top of JMS.
JMS and EJB's

Author: celtech celtech (http://www.jguru.com/guru/viewbio.jsp?EID=974498), Aug
2, 2002
Is it possible to have JMS ( as a Data Access mechanism) with Java Classes and JSP's
Developing distributed application with JMS alone

Author: Sheroy Marker (http://www.jguru.com/guru/viewbio.jsp?EID=928113), Aug
14, 2002
You would need a JMS provider in the least. The JMS API is only a specification and
a provider implements the JMS interfaces.
The J2EE 1.3 server is a JMS provider.
Where can I find more information on JMS?

The JMS site at Sun is a good starting point. The vendors' page points to several
sites and many of the vendors provide whitepapers and tutorials.
What's the JMS API like?

The JMS site at Sun provides links to the specification, as well as the online javadocs
for JMS.
Where can I find a short introduction to JMS, including code segments and
example programs?
See the following introduction to Java Message Service.

Bad link
Author: Dave Tregay (http://www.jguru.com/guru/viewbio.jsp?EID=1108811), Aug
15, 2003
The introduction is no longer available at that location. Does anyone have a new link?
Does the specification require that all JMS implementations provide both
point-to-point and publish/subscribe messaging?
No. Many JMS implementations provide both, but the specification defines
compliance for each messaging style separately.
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.
What is publish/subscribe messaging?

With publish/subscribe message passing the sending application/client establishes a

named topic in the JMS broker/server and publishes messages to this queue. The
receiving clients register (specifically, subscribe) via the broker to messages by topic;
every subscriber to a topic receives each message published to that topic. There is a
one-to-many relationship between the publishing client and the subscribing clients.
Maybe my background is not fully up to date, but the...

Author: Bernhard Garmann (http://www.jguru.com/guru/viewbio.jsp?EID=9520), Jan
28, 2000
Maybe my background is not fully up to date, but the main feature of publish -
subscribe in my view is a 'push function', that is the message is pushed to a certain
'target(s)'. The advantage of this is, that the recipient need not poll but just 'sleep'.
How does JMS compare to peer-to-peer distributed computing?

The term peer-to-peer is used in a variety of ways in distributed and network
computing. One usage, at the application level, is to describe a distributed
application scenario in with each distributed component potentially interacts with
every other distributed component and maintains a network reference (access) to
each component (using any of several mechanisms to do so, for example, via
Enterprise JavaBeans and EJB servers resident on each network host, via simple
RMI-based communication among applications, and so on).
With JMS, distributed components interact with the JMS broker via destinations
(topics and queues), which then disseminates messages to the registered clients;
thus, distributed components do not have to know (and manage) each others'
network locations. As for the JMS middleware, it can use (behind the scenes) any of
several network topologies, for example, bus, ring, hierarchical, fully connected
(peer-to-peer), star (hub-and-spoke), or others, including hybrids.
Messaging systems are peer-to-peer distributed systems in the sense that, at least
potentially, every (registered) client can communicate with every other (registered)
client.
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)
What are JMS messages?

JMS messages implement the Message interface.
JMS messages include a header, properties, and the message body. Headers provide
identifying and routing information. Properties allow arbitrary ornamenting of
messages with application-specific markers or tags. Receiving clients can select, or
filter, messages based on properties.
The message body is available in five flavors:

• StreamMessage - a stream of Java primitive values
• MapMessage - a set of name-value pairs
• TextMessage - a String object
• ObjectMessage - a serialzed Java object
• BytesMessage - a stream of uninterpreted bytes
To obtain a message of the requisite type, make a request via the appropriate create
method, for example:
TextMessage message = session.createTextMessage();
Note that some vendors provide additional message types.
Explain the terms broker, provider, and implementation with respect to

JMS?
These terms are sometimes used interchangeably. Note, however, that, technically, a
JMS implementations is any implementation of the JMS API. Thus, an arbitrary
collection of application components could implement the JMS interfaces, and then
provide messaging services to its peers. The term provider is quite general and
typically would be interpreted as any implementation that provides complete JMS
functionality, with either publish/subscribe or point-to-point messaging, or both.
Technically, a JMS broker could be, perhaps, any implementation of the messaging
brokering services, omitting, for example, certain administrative capabilities.
Although the term broker is common, its usage may require a contextual
interpretation. In some cases, the entire JMS implementation/server is referred to as
a broker; in other cases, broker is used at the destination level. For example, if the
JMS server is managing the topic "Java" (among others), the "Java" topic is a broker
for all messages published to "Java" and distributed on to "Java" subscribers.
What is a JMS domain?

Created: Nov 17, 1999
There are two possible domains in JMS: (1) the publish/subscribe domain and (2) the
point-to-point domain. Not all JMS implementations provide both domans.
With the point-to-point domain, clients interact via a message queue. With the
publish/subscribe domain clients interact via a node in a content hierarchy, each
node representing a topic, or subtopic.
These two domains represent different communication strategies.
Does a JMS environment represent a client/server distributed system?

The act of serving, like beauty, is in the eye of the beholder. Any application that
provides services to another application is a server. The JMS message broker
provides both direct and indirect services:
• Managing destinations, that is, queues and the topic hierarchy

• Message brokering
• Reliable communication, configurable for both persistence and durability
• Many implementations provide clustering, load balancing, and so on
Applications that connect to and use the JMS broker are its clients.
From another point of view, any number of distributed application components can
use JMS for interclient communication. Thus, these (JMS broker) clients are actually
peers to each other, that is, with respect to the distributed applications scenario. In
this case, each peer is potentially a client to and a server for other peers.
What are administered objects?

The JMS specification does not require a security-related API and it does not address
in detail the process/mechanism for administering objects that exist within a running
JMS implementation. Thus, the administration process differs across vendors.
The JMS specification does, however, define two administered objects:
• ConnectionFactory - A client uses this object to create a connection to the

JMS server.
• Destination - A client uses this object to set up a "message rendezvous" in
the server, specifically, either a topic or a queue.
Typically, a JMS server provide destination-level security, and, of course, JMS

applications work through the JMS server. That is, beyond the application, it's
possible to establish topic- and queue-based security controls for users, groups,
access lists, and so on.
Are messages thread-safe?

If the JMS specification required a thread-safe implementation for all objects, it

would, in many situations, be a burden on programmers. The following objects
support concurrent use:
• Destination
• ConnectionFactory
• Connection
Session, on the other hand, is a single-threaded context that handles message-

passing operations. A session serves as a message factory and it processes
messages in serial order. One reason for the single-thread design is that a session is
responsible for transaction-related operations.
Sessions are single-threaded contexts because a session is where the action is. In
particular, a session is responsible for operations such as transaction handling and
asynchronous message passing. Requiring client code that's related to asynchronous
message reception to support concurrent use would have been especially
burdensome.
Note that clients can use multiple sessions to partition client operations. For
example, one client thread can drive one session and another client thread can drive
another session. Each session object serializes execution of message listeners (the
methods that handle asynchronously delivered messages). Thus, message listeners
(handlers) can share session-related resources. Client resources (critical objects)
outside the session, however, are the responsibility of the application designer, as
always.
What is a topic hierarchy?

Many publish/subscribe message systems support a tree-organized topic

arrangement, many of which predate JMS. For example, suppose the server in
question supports topic hierarchies and it is managing the topic "Dog" and the
subtopics "Kuvasz" and "Mastiff". In this case, a message published to "Kuvasz" and
a message published to "Mastiff" either would be distributed to subscribers of "Dog",
or not, depending on the characteristics of its publish/subscribe model and/or
configuration parameters. That is, subscribing to "Dog" would, in effect, constitute a
subscription to all subtopics such as "Kuvasz" and "Mastiff," if configured, for
example, with a property setting such as "includeSubtopics=true".
The JMS specification does not require support for topic hierarchies. Although topic
hierarchies can be a powerful tool, it's important to consider whether or not
portability is an issue. Topic hierarchy designs vary across JMS servers, and not all
JMS servers implement topic hierarchies.
Is it possible for a client to send multiple messages and ensure that the
entire set of messages is delivered?
The preferred method for handling interdependent messages is to produce them

within a transacted session. See Session.commit(), Session.rollback(), and
XASession.
If a session is configured as transacted, how are independent, or
nontransaction-related, messages handled?
Each client can create multiple sessions, with each session producing and/or
consuming messages. Each session is independently configurable. (Note that each
session should be closed gracefully to free server resources.)
Is it possible to use transacted sessions with other Java-technology,

transaction processing facilities, for example, JTA?
No. It is possible (if provided by the JMS implementation) to use JTA in the context of
a session, but not a transacted session. That is, you cannot use Session.commit()
and Session.rollback() in a context that's controlled by an instance of
UserTransaction.
If, for example, one or more messages, in conjunction with database operations, all
form a "logical transactional unit," it's usually best to take advantage of the
transaction support provided by the JDBC driver, possibly augmenting this transacted
(database) server operation with, javax.transaction.UserTransaction from the
Java Transaction API (JTA), if JTA is implemented by the JMS server. Note that JMS
implementations vary in their support for distributed tranaction processing. See the
javax.jms.XA... interfaces in the API documentation.
The JMS spec allows for (optional) support of the JTA....

Author: Robert Davies (http://www.jguru.com/guru/viewbio.jsp?EID=139017), Oct 5,
2000
The JMS spec allows for (optional) support of the JTA. Notably, a JMS Connection
can provide an XAResource, which controls an XASession, for the transactional
delivery or receipt of messages.
Can a client produce a message to multiple destinations, that is, to a list?

No. A client, in a single operation, cannot publish to a list of topics and it cannot send
to multiple queues. A client must establish a message-producer object for each
topic/queue and manually publish/send to each destination.
Can a client (a publisher) detect whether or not there are subscribers to a
topic?
No. The specification does not support so-called subscription notification.

Subscription notification is resource expensive and would place an unjustifiable
burdensome on the JMS server.
Are messages received in the order they were sent/published?

In general, no. JMS guarantees that messages delivered by a server to a client,

relative to a single destination and via a single session, are delivered in order. This
order may be different from the order published/sent by the producing client.
In many cases, it is unwise to structure communications so that order is important,

but in those cases in which the order must be preserved from the producer to the
consumer, the messages can be produced and consumed in a transacted session.
And, of course, if messages are published to a topic via multiple sessions, there is no
way to guarantee the ordering of message delivery because each session (potentially
driven by different threads of execution) is subject to different scheduling and
performance variances.
Does JMS support distributed transactions?

Distributed transaction services are provided via the Java Transaction API (JTA). JMS
does not mandate JTA support. See the JMS vendor's documentation for JTA-related
discussion, especially, whether or not the vendor supports JTA.
What are the ramifications of having multiple consumers in one session for
the same destination (queue or topic)?
The JMS server will provide only one instance of each message for a named
destination per session. The issue of which consumer actually receives the message
is implementation dependent. There is no reason to (ab)use a session in this
manner!

The behaviour of how multiple Topic MessageListeners...
Author: Robert Davies (http://www.jguru.com/guru/viewbio.jsp?EID=139017), Oct 5,
2000
The behaviour of how multiple Topic MessageListeners on a Session has changed

between JMS1.0.1 and JMS1.0.2.
In JMS1.0.1, only one (random) MessageListener would receive the Message. As this
was found to be severely limiting for certain applications, in JMS1.0.2 all the
MessageListeners will receive the Message.
How does message persistence affect the order of message production by a

client and delivery by the JMS server?
It's convenient to view persistent and nonpersistent messages from the same
producing client as elements of a partitioned space, even if sent to the same
destination. There is no guarantee that a consuming client will even receive a
nonpersistent message; hence, nonpersistent messages must be exempt from any
logical conditions on message order in the producing client.
A related issue is that, at best, messages are only ordered within each message-
producing session by destination.
Message priority is another related factor. In general, messages with higher priority
will arrive before messages of lower priority, within a session, but it is not possible to
depend on high-priority nonpersistent messages being delivered before low-priority
persistent messages.
Can a publishing client ensure message delivery by making a message

durable?
No. Message durability ("durableness?") is established between a subscribing client

(topic subscribers only, not queue receivers) and the JMS server on a topic-by-topic
basic, that is, per subscription. The producer has no control over this contract
between the subscriber and the JMS server. The relevant method is
TopicSession.createDurableSubscriber().
Can a publishing client ensure the order of message deliver for, say, five
messages, by manipulating the priority of each message from, say, 5 to 1?
No. Message priority is considered by the JMS server and potentially overrides the
default first-in-first-out (FIFO) message handling strategy. Priorities should be
viewed as one factor that potentially affects the order of message delivery.
The recommended way to ensure the order of message production and reception
between the publisher and the consumer is with a transacted session.
What is a message filter, or selector?

A message selector is a condition established for (attached to) a topic or queue by

the consumer. The JMS server honors a consumer's message selector and does not
deliver nonqualifying/filtered messages.
If a consumer views incoming messages as being similar to rows in a database table,

message selection is somewhat like using an SQL where clause to control the rows
selected from a table.
How does a message selector work?

As a JMS server receives messages from producing clients and evaluates which
consuming client(s) it should forward each message to, the server applies a
consumer's selector to data in the message header. Messages that do not meet the
selection criteria are not delivered to the consumer. A message selector uses SQL92
condition syntax, for example,
session.createReceiver(queue,
"DogBreed in ('Newfoundland', 'Mastiff')");
The "data" for selection criteria include certain message header fields, as well as
properties attached to messages.
Why use a message selector instead of simply filtering messages at the

consuming client level by, for example, scanning the message body based
on certain criteria?
There are at least three reasons. First, in most cases, client-side filtering is quite a
burden to implement, for example, parsing a textual message. Second, if the
message type were, say, Object, it could be burdensome for the producer to
"decorate it" with selection criteria and/or for the consumer to select messages
based on those criteria. Third, using a selector is more efficient because the JMS
server avoids having to send the filtered message to the consumer.
Can a producer filter its messages?

No! Or, yes--by not sending messages that it doesn't want to send! Message filtering
is consumer-oriented.
What is a message property?

Message producers can attach arbitrary properties to outgoing messages. This data
is stored in the message header, in essence, as virtual fields in the header. JMS
reserves the "JMSX." property name prefix for JMS-defined properties.
Producer-defined properties are set with Message.setXXXProperty() and retrieved

with Message.getXXXProperty(), where "XXX" can be Boolean, Byte, and so on.
There are many property-related methods; see the JMS vendor's documentation, as
well as the JMS API documentation, in particular, the description for Message, for
complete property handling information.
Does JMS support message acknowledgment?

Yes. With transacted sessions, acknowledgment is handled automatically by the

session's commit(). With sessions that are not transacted, there are three options
for message acknowledgment:
• DUPS_OK_ACKNOWLEDGE
• AUTO_ACKNOWLEDGE
• CLIENT_ACKNOWLEDGE
See the JMS API documentation, in particular, the description for Session, for
complete message acknowledgment information.
Does JMS support any type of future-reply mechanism, similar to what's

provided by the Aglets framework?
No. You must set up a message listener implementation for asynchronous message
consumption.
For "on-the-fly, programmatic realizations" that you need a heretofore unanticipated
message listener, you could probably design and define in advance a generic one-
size-fits-all class that implements MessageListener.
If a client registers multiple message listeners for a given session, are the
listeners processed concurrently?
No. Each session uses a single thread of execution to handle registered listeners;
thus, listeners are serviced one at a time--all listeners except for the one being
serviced are waiting.
How can a client receive multiple messages concurrently?

A client should create multiple sessions to handle each logical message-consuming

operation.
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.
When is nonpersistent message delivery a viable option?

If, for example, a suite of distributed application components includes one

component that publishes time data to its peers for intercomponent synchronization,
it's probably not critical that every peer receive every published time update. In this
case, nonpersistent messaging can reduce unnecessary computations, reduce the
overhead of the JMS server, and potentially reduce network bandwidth.
What is the once-and-only-once guarantee?

JMS guarantees that persistent messages are delivered to registered consumers once
and only once. The secondary storage-based logging scheme for persistent messages
guarantees that the message is not lost and that it is not delivered more than once.
What is the at-most-once guarantee?

JMS guarantees that nonpersistent messages are not delivered to registered

consumers more than once, but it does not guarantee that they are actually
delivered.
Is there any way to "make nonpersistent messages reliable?"

No! The reason for supporting both nonpersistent and persistent messages is to
assist the programmer in balancing the trade-offs for guaranteed, reliable delivery
and its inherent overhead for the JMS server versus the lower-overhead, no-
guarantee delivery.
If a message must be delivered reliably, use a persistent delivery mode.
What are the criteria for choosing the point-to-point messaging model over
the publish/subscribe model, and vice versa?
There are two fundamental factors:
• The point-to-point messaging model is designed for 1-to-1 messaging

between a producing client and a consuming client.
• The publish/subscribe messaging model provides two options not available
with point-to-point messaging:
o Clients can produce messages for an unknown, and/or unlimited,
number of subscribers; that is, publish/subscribe messaging supports
1-to-n messaging operations.
o Subscribing clients have the choice between durable and nondurable
connections to the JMS server.
What is a durable subscription?

When a subscribing client (via it session with the JMS server) requests a durable
subscription, the JMS server will "save" any messages intended for the subscriber
during periods when the subscriber is inactive.
What I miss in the JMS Spec is the procedure to *...

Author: Andreas Mueller (http://www.jguru.com/guru/viewbio.jsp?EID=23179), Mar
11, 2000
What I miss in the JMS Spec is the procedure to *reconnect* to a durable
subscription. That is, I create a durable subscription with createDurableSubscriber,
receive some messages and *terminate*. The next time my app is launched I will
*reconnect*. How? Using setClientID? Using createDurableSubscriber with the same
name?
The JMS specification states the following: "At the...

Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9), Mar 13, 2000
The JMS specification states the following:
"At the cost of higher overhead, a subscriber can be made durable. A durable
subscriber registers a durable subscription with a unique identity that is retained by
JMS. Subsequent subscriber objects with the same identity resume the subscription in
the state it was left by the prior subscriber. If there is no active subscriber for a
durable subscription, JMS retains the subscription's messages until they are received
by the subscription or until they expire."
Thus, to maintain an ongoing, durable subscription, you must provide an appropriate

name when creating the subscription, in addition to setting the client ID for the
connection:
tcf = (TopicConnectionFactory) c.lookup("vendor's factory string");

con = tcf.createTopicConnection();
con.setClientID("your unique client ID");
session = con.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
...
sub = session.createDurableSubscriber("YourTopic",
"YourDurableName");
...
The next time the client reconnects, it must provide the same client ID and durable
subscription name, in order to receive any accumulated messages that have been held
for the client ID/subscription name combination.
Ok, now I understand the JMS Spec. The procedure is...

Author: Andreas Mueller (http://www.jguru.com/guru/viewbio.jsp?EID=23179), Mar
17, 2000
Ok, now I understand the JMS Spec. The procedure is as follows: 1. setClientID with
a provider specific name. Under that name, several durables could be created with 2.
createDurableSubscriber. The durable is now in place, storing all msgs published on
that topic. Reconnecting is the same procedure as above. An unsubscribe from the
durable deletes the durable at server side. The point I missunderstand was the javadoc
of createDurableSubscriber. That means, one can *change* an existing durable
subscriber. That is, a createDurableSubscriber with an existing name but i.e. another
message selector or another topic etc. This operation leads to deleting and re-creating
a durable on server side. If I don't change the parameters of createDurableSubscriber,
it is always a *reconnect*.
Re: Ok, now I understand the JMS Spec. The procedure is...
Author: Tim Rickard (http://www.jguru.com/guru/viewbio.jsp?EID=454468), Jul
13, 2001
I am confused on this point myself. If I 'reconnect' with a different selector and
messages have been stored for the clientid/username pair that dont meet that
selector, are they tossed by the system.
Is there a method that allow pub to specify which subscriber to get the message?
Author: steeven lee (http://www.jguru.com/guru/viewbio.jsp?EID=572247), Dec 4,
2001
Is there a method that allow pub to specify which subscriber to get the message? In
durable mode, the subscriber has provide an unique ClientId to tell from other
subscriber. so when the server get a message that specified which ClientId should read
the message, the sever should send the message to only the ClientId other than
broadcast it out to every subscriber of the topic. an filter will do the same thing, but it
is Seted by client, not from the sender, the sender should has the ability to decide
where the message should be send.
What is the difference between durability and persistence? Both use

secondary storage to "hold" messages.
Durable versus nondurable relationships exist between a consuming client and the
JMS server, which delivers messages. Persistence versus nonpersistent delivery mode
involves a message-level relationship established between the producing client and
the JMS server, and only indirectly between the producing and consuming clients.
A producing client can choose persistent delivery mode for either messaging model,
publish/subscribe or point-to-point. "Durable delivery" is an option for clients that
subscribe to topics, not for clients that connect to a queue.
Since both durable subscriptions and persistence are...

Author: Vikram Rajan (http://www.jguru.com/guru/viewbio.jsp?EID=5140), Feb 24,
2001
Since both durable subscriptions and persistence are mechanisms of ensuring reliable
delivery of messages, are messages themselves handled in the same manner by JMS
providers? Are there any issues specific to each mechanism?
Re: Since both durable subscriptions and persistence are...

Author: Dan Stewart (http://www.jguru.com/guru/viewbio.jsp?EID=1215321),
Dec 8, 2004
It's hard to say for sure, since each provider can implement the functionality any
way they like. However, the durable subscription concept differs from message
persistence quite a bit, so I doubt they use the same mechanism.
How does a client create a topic (or a queue)?

In the section "Topic Management" the JMS specification states: "JMS does not define
facilities for creating, administering, or deleting topics." In the JMS API, however, the
QueueSession and TopicSession interfaces include createQueue() and
createTopic(), respectively.
For now, it's likely that JMS implementations will vary with respect to static versus
dynamic topic creation, as well as external topic administration and manipulation. It's
possible that some implementations will require static topic creation in advance using
external functionality, for example, a utility. Some JMS implementations include a
complete system administration tool for topic and queue management. Some
implementations will provide administrative APIs for programmatic control of
resource management. Other implementations may provide basic facilities for, say,
topic or queue creation on the fly, plus an administrative console for creation,
deletion, and other management tasks, plus security management.
For example, some environments support dynamic look-up using JNDI, plus dynamic
destination creation, if necessary:
...
try {
queue = (Queue) c.lookup(QUEUE);
}
catch (NamingException ne) {
try {
queue = session.createQueue(QUEUE);
c.bind(QUEUE, queue);
}
catch (Exception e) {
readyToSend = false;
closeConnection();
return;
}
}
...
In the previous code segment, c is a JNDI InitialContext object.
how to create dynamic Queue?

Author: prakash sowriraj (http://www.jguru.com/guru/viewbio.jsp?EID=1146230),
Feb 13, 2004
i want the jave code creates dynamic Queue
How do you implement a client that receives messages via a queue?

Client implementations vary with respect to set-up operations, depending on the JMS
implementation. The following client, ObjectReceiver, works with the WebLogic Java
application server, which supports JMS:
import javax.jms.*;
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
public class ObjectReceiver

implements MessageListener, Runnable {
public static final String SERVER_URL = "t3://localhost:7001";
public static final String JMS_FACTORY =
"javax.jms.QueueConnectionFactory";
public static final String QUEUE = "j2ee.jms.objectQueue";
private Context c;
private QueueConnectionFactory qcf;
private QueueConnection con;
private QueueSession session;
private QueueReceiver receiver;
private Queue queue;
private boolean quit = false;
private boolean readyToReceive;
public static void main(String[] args) {

if (!checkUsage(args))
System.exit(-1);
ObjectReceiver or =
(args.length == 1) ?
new ObjectReceiver(args[0]) :
new ObjectReceiver();
if (!or.isReadyToReceive()) {
System.out.println("Not ready to receive.");
System.exit(-1);
}
or.run();
or.close();
}
public ObjectReceiver() {
this(SERVER_URL);
}
public ObjectReceiver(String url) {

readyToReceive = true;
c = getInitialContextWebLogic(url);
if (c == null)
readyToReceive = false;
else
init();
}
public void init() {

if (!readyToReceive)
return;
try {
qcf = (QueueConnectionFactory) c.lookup(JMS_FACTORY);
con = qcf.createQueueConnection();
session = con.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
}
System.out.println("Can't initialize object receiving.");
closeContext();
return;
}
try {
}
try {
}
closeConnection();
return;
}
}
try {
receiver = session.createReceiver(queue);
receiver.setMessageListener(this);
con.start();
}
closeConnection();
return;
}
}
public void close() {

return;
try {
receiver.close();
closeConnection();
}
System.out.println("Can't close connections.");
}
}
private void closeConnection() {

return;
try {
session.close();
con.close();
closeContext();
}
System.out.println("Can't close connection.");
}
}
public void closeContext() {

return;
try {
c.close();
}
System.out.println("Can't close JNDI context.");
}
}
public boolean isReadyToReceive() {

return readyToReceive;
}
public void run() {

return;
synchronized (this) {
while (!quit) {
try { wait(); }
catch (InterruptedException ie) { }
}
}
}
public void onMessage(Message msg) {

return;
Runnable obj = null;
try {
if (msg instanceof ObjectMessage) {
try {
obj = (Runnable) ((ObjectMessage) msg).getObject();
}
System.out.println("Message is not an object!");
return;
}
try {
if (obj != null)
obj.run();
}
System.out.println("Can't execute the arriving object.");
}
}
else {
System.out.println("Message should be an 'ObjectMessage'.");
System.out.println(msg.toString());
}
if (msg == null || obj == null) {
quit = true;
notifyAll();
}
}
}
System.out.println("Can't receive message: " + e);
}
}
private Context getInitialContextWebLogic(String url) {

try {
Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put("weblogic.jndi.createIntermediateContexts", "true");
h.put(Context.PROVIDER_URL, url);
return new InitialContext(h);
}
System.out.println("Can't get JNDI context.");
return null;
}
}
public static boolean checkUsage(String[] args) {

if (args.length > 1) {
System.out.println("Usage: java ObjectReceiver [<server-url>]");
return false;
}
return true;
}
}
How do you implement a client that sends messages via a queue?

implementation. The following client, ObjectSender, works with the WebLogic Java
application server, which supports JMS:
import javax.jms.*;
import java.io.Serializable;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
public class ObjectSender extends Thread {

public static final String SERVER_URL = "t3://localhost:7001";
public static final String JMS_FACTORY =
"javax.jms.QueueConnectionFactory";
public static final String QUEUE = "j2ee.jms.objectQueue";
private Context c;
private QueueConnectionFactory qcf;
private QueueConnection con;
private QueueSession session;
private QueueSender sender;
private Queue queue;
private ObjectMessage msg;
private boolean readyToSend;

System.exit(-1);
ObjectSender os =
(args.length == 1) ?
new ObjectSender(args[0]) :
new ObjectSender();
if (!os.isReadyToSend()) {
System.out.println("Not ready to send messages.");
System.exit(-1);
}
os.sendObject(new Cat());
os.sendObject(new Dog());
os.sendObject(null);
os.close();
}
public ObjectSender() {
this(SERVER_URL);
}
public ObjectSender(String url) {

readyToSend = true;
c = getInitialContextWebLogic(url);
if (c == null)
else
init();
}

if (!readyToSend)
return;
try {
qcf = (QueueConnectionFactory) c.lookup(JMS_FACTORY);
con = qcf.createQueueConnection();
}
System.out.println("Can't initialize time sending.");
closeContext();
return;
}
try {
}
try {
}
closeConnection();
return;
}
}
try {
sender = session.createSender(queue);
msg = session.createObjectMessage();
con.start();
}
closeConnection();
return;
}
}

if (!readyToSend)
return;
try {
sender.close();
closeConnection();
}
System.out.println("Can't close ObjectSender instance.");
}
}

if (!readyToSend)
return;
try {
session.close();
con.close();
closeContext();
}
}
}
private void closeContext() {

if (!readyToSend)
return;
try {
c.close();
}
System.out.println("Can't close JNDI context.");
}
}
public void sendObject(Serializable obj) {

if (!readyToSend)
return;
try {
msg.setObject(obj);
sender.send(msg);
}
System.out.println("Can't send message: " + e);
}
}
public boolean isReadyToSend() {

return readyToSend;
}
private Context getInitialContextWebLogic(String url) {

try {
Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, url);
h.put("weblogic.jndi.createIntermediateContexts", "true");
return new InitialContext(h);
}
System.out.println("Can't get JNDI context.");
return null;
}
}

if (args.length > 1) {
System.out.println("Usage: java ObjectSender [<server-url>]");
return false;
}
return true;
}
}
Clarification required
Author: Johnson Samuel (http://www.jguru.com/guru/viewbio.jsp?EID=561793), Nov
26, 2001
Exception in thread "main" javax.naming.CommunicationException. Root exception
is weblogic.socket.UnrecoverableConnectException: [Login failed: 'Incompatible
version:Incompatible versions - this server:6.1.0.0 client:5.1.0] this is the error i am
getting clarification regarding this is appreciated
RMI de-serialization Error

Author: Rachel Elkin (http://www.jguru.com/guru/viewbio.jsp?EID=872791), May 9,
2002
Hi. When I run this sample against Weblogic 5.1, I get an error with the RMI
invocation: weblogic.rmi.ServerError: A RemoteException occurred in the server
method [java.io.InvalidClassException:
weblogic.jms.common.JMSConnectionRemote_WLStub;
java.lang.NoSuchMethodException: createDurableConnectionConsumer]] It appears
not to like the createDurableConnectionConsumer on
weblogic.jms.common.JMSConnectionRemote_WLStub for some reason. Any ideas?
Thanks! -Rachel
How do you implement a client that subscribes to a topic?

implementation. The following client, TimeSubscriberSonicMQ, works with the
SonicMQ JMS server:
import javax.jms.*;
public class TimeSubscriberSonicMQ

implements MessageListener, Runnable {
public static final String SERVER_URL = "localhost:2506";
public static final String TOPIC = "j2ee.jms.timeTopic";
public static final String USER_ID = "subuser";
public static final String PASSWORD = "password";
public static final String SHUTDOWN_MSG = "Publishing Terminated...";
private String url;

private TopicConnectionFactory tcf;
private TopicConnection con;
private TopicSession session;
private TopicSubscriber subscriber;
private Topic topic;
private String statusMessage = "";
private boolean readyToSubscribe;

System.exit(-1);
TimeSubscriberSonicMQ ts = new TimeSubscriberSonicMQ(args[0]);
if (!ts.isReadyToSubscribe()) {
System.out.println("Not ready to subscribe.");
System.exit(-1);
}
ts.run();
ts.close();
}
public TimeSubscriberSonicMQ() {
this(SERVER_URL);
}
public TimeSubscriberSonicMQ(String url) {

readyToSubscribe = true;
this.url = url;
init();
}

if (!readyToSubscribe)
return;
try {
tcf = new progress.message.jclient.TopicConnectionFactory(url,
"");
con = tcf.createTopicConnection(USER_ID, PASSWORD);
}
readyToSubscribe = false;
setStatusMessage("Can't initialize time subscribing.");
System.out.println(getStatusMessage());
return;
}
try {
topic = session.createTopic(TOPIC);
}
closeConnection();
return;
}
try {
subscriber = session.createSubscriber(topic);
subscriber.setMessageListener(this);
con.start();
}
closeConnection();
return;
}
}

return;
try {
subscriber.close();
closeConnection();
}
setStatusMessage("Can't close TimeSubscriberSonicMQ instance.");
}
}

return;
try {
session.close();
con.close();
}
setStatusMessage("Can't close connection.");
}
}
public boolean isReadyToSubscribe() {

return readyToSubscribe;
}
public String getStatusMessage() {

return statusMessage;
}
private void setStatusMessage(String msg) {

statusMessage = msg;
}
public void run() {

return;
while (!quit) {
try { wait(); }
}
}
}

return;
try {
String msgText;
if (msg instanceof TextMessage) {
msgText = ((TextMessage) msg).getText();
}
else {
msgText = msg.toString();
}
System.out.println("The time is: " + msgText);
if (msgText.equalsIgnoreCase(SHUTDOWN_MSG)) {
quit = true;
notifyAll();
}
}
}
setStatusMessage("Can't receive message: " + e);
}
}

if (args.length != 1) {
System.out.println("Usage: java TimeSubscriberSonicMQ <server-
url>");
return false;
}
return true;
}
}
How do you implement a client that publishes to a topic?

implementation. The following client, TimePublisherSonicMQ, works with the
SonicMQ JMS server:
import java.util.Date;
import javax.jms.*;
public class TimePublisherSonicMQ extends Thread {

public static final String SERVER_URL = "localhost:2506";
public static final String TOPIC = "j2ee.jms.timeTopic";
public static final String USER_ID = "pubuser";
public static final String PASSWORD = "password";
public static final int REPORTING_DURATION = 30000; // milliseconds
public static final int REPORTING_INTERVAL = 5000; // milliseconds
private String url;

private TopicConnectionFactory tcf;
private TopicConnection con;
private TopicSession session;
private TopicPublisher publisher;
private Topic topic;
private TextMessage message;
private int interval = REPORTING_INTERVAL;
private boolean quit;
private boolean readyToPublish;
//
// main() is for testing only. It starts time publishing, waits
// for a short period of time, and then stops time publishing.
//

System.exit(-1);
TimePublisherSonicMQ tp = new TimePublisherSonicMQ(args[0],
REPORTING_INTERVAL);
if (!tp.isReadyToPublish()) {
System.out.println("Not ready to publish.");
System.exit(-1);
}
tp.startPublishing();
try { Thread.sleep(REPORTING_DURATION); }
catch (Exception e) {}
tp.stopPublishing();
tp.close();
}
public TimePublisherSonicMQ() {
this(SERVER_URL, REPORTING_INTERVAL);
}
public TimePublisherSonicMQ(String url) {

this(url, REPORTING_INTERVAL);
}
public TimePublisherSonicMQ(String url, int interval) {

readyToPublish = true;
this.url = url;
this.interval = interval;
init();
}

if (!readyToPublish)
return;
try {
tcf = new progress.message.jclient.TopicConnectionFactory(url,
"");
con = tcf.createTopicConnection(USER_ID, PASSWORD);
}
readyToPublish = false;
System.out.println("Can't initialize time publishing.");
return;
}
try {
topic = session.createTopic(TOPIC);
}
closeConnection();
return;
}
try {
publisher = session.createPublisher(topic);
message = session.createTextMessage();
con.start();
}
closeConnection();
return;
}
}

return;
try {
publisher.close();
closeConnection();
}
System.out.println("Can't close TimePublisherSonicMQ instance.");
}
}

return;
try {
session.close();
con.close();
}
}
}
public boolean isReadyToPublish() {

return readyToPublish;
}
public void startPublishing() {

return;
start();
}
synchronized public void run() {
return;
quit = false;
while (!quit) {
try {
message.setText(new Date().toString());
publisher.publish(message);
}
System.out.println("Can't publish times.");
}
try {
wait(interval);
}
catch (InterruptedException e) {
}
}
}
public void sendMessageToSubscribers(String msg) {

return;
try {
message.setText(msg);
publisher.publish(message);
}
System.out.println("Can't send message: " + e);
}
}
synchronized public void stopPublishing() {

return;
quit = true;
notifyAll();
}
synchronized public void setInterval(int interval) {

this.interval = interval;
}

if (args.length != 1) {
System.out.println("Usage: java TimePublisherSonicMQ <server-
url>");
return false;
}
return true;
}
}
How does a client accommodate asynchronous message notifications from

the JMS server?
To receive messages asynchronously, a client must:
• Implement javax.jms.MessageListener:
• public interface MessageListener {
• void onMessage(Message message);
• }
• Register the message handler using setMessageListener():
• ...
• subscriber = session.createSubscriber(topic);
• SubscriberMessageThread smt = new SubscriberMessageThread(this);
• subscriber.setMessageListener(smt);
• con.start(); // start connection
• smt.start();
• ...
The use of a listener for method notifications is similar to using listeners for event
notification with graphical AWT clients. Note, however, that every AWT application
has a screen-updater thread running in the background that keeps the application
alive when main() completes its thread of execution. Certainly, JMS clients vary
enormously in function but, in general, some thread of execution must be
responsible for managing the wait cycle associated with potential onMessage()
invocations.
Again, clients vary in many ways, but one strategy is to design either a general-
purpose class to handle this task, which can be specialized for each message-
receiving scenario, or build this functionality into the client itself (the client
implements MessageListener). In the first case, you could design a simple class that
extends Thread and implements MessageListener, for example, MessageThread:
public class MessageThread extends Thread

implements MessageListener {
private String statusMessage = "";

public MessageThread() {
super();
}
public void run() {

while (!quit) {
try { wait(); }
}
}
}
public void shutdown() {

notifyQuit();
}

}
public String getStatusMessage() {

return statusMessage;
}
private void setStatusMessage(String msg) {

statusMessage = msg;
}
private void notifyQuit() {

quit = true;
notifyAll();
}
}
}
Note that onMessage() is empty. Hence, for each message-receiving scenario, you
could specialize this class providing the appropriate functionality for onMessage.
(See, for example, the reference to SubscriberMessageThread in the previous code
segment from the JMS client that registers the message handler.)
Note that some JMS implementations provide convenience functionality for handling
the wait process, for example, ThreadHelper.WAIT_UNTIL_EXIT.suspend(), in
iBus//MessageServer.
JMS
Author: giordano bruno (http://www.jguru.com/guru/viewbio.jsp?EID=1223061), Jan
24, 2005
what is this
SubscriberMessageThread smt = new SubscriberMessageThread(this);
Is this a javax beast or user written or what?
Do we really need to create a thread?

the EJB examples dont
Re: JMS
Author: l h (http://www.jguru.com/guru/viewbio.jsp?EID=1251056), Jun 30, 2005
Looks like that's an error. Check this link out.... this example works.... I tried it out.
http://www.oracle.com/technology/sample_code/tech/java/jms/unidomain/AsyncClient.java.html
Does JMS directly support XML?
No. The JMS specification defines five message types:
• StreamMessage - a stream of Java primitive values

• MapMessage - a set of name-value pairs
• TextMessage - a String object
• ObjectMessage - a serialzed Java object
• BytesMessage - a stream of uninterpreted bytes
You can pass XML data in the body of a text message, and, of course, you can do
just about anything with an object message. Optionally, some vendors plan to
support other message types. Given the rapid growth and widespread use of XML,
it's likely that several vendors will offer direct XML support.
At this time, the following vendors/products provide some form of direct support for
XML:
• Progress/SonicMQ - SonicMQ provides an XML message type, plus dynamic

parsing of XML messages upon delivery.
Another one.
Author: Tom Barnes (http://www.jguru.com/guru/viewbio.jsp?EID=569489), Dec 2,
2001
WebLogic 6.0+ JMS also has some XML support.
Which JMS vendors fully support JNDI look-up operations for connection
factories and destinations?
At this time, the following vendors/products provide some form of direct support for
JNDI look-up operations via their JMS server:
• SoftWired's iBus//MessageServer - Over-the-network access to connection

factories and destinations, plus convenience methods
• The WebLogic server - Full JNDI support via the WebLogic server, plus
convenience objects, plus delegation to LDAP providers, and so on.
IBM's MQSeries products provide an implementation of...

Author: Neil Kolban (http://www.jguru.com/guru/viewbio.jsp?EID=89126), Jun 30,
2000
IBM's MQSeries products provide an implementation of JMS that utilizes JNDI. This
includes a powerful administration application (written entirely in Java) to define the
ConnectionFactory and Destination objects. Currently, both LDAP and
FileSystem JNDI repositories can be employed.
TIBCO Enterprise for JMS

Author: Stefan Zoerner (http://www.jguru.com/guru/viewbio.jsp?EID=74946), Nov 6,
2001
TIB/JMS provides its own implmementation of JNDI.
See www.tibco.com for details.
Why is JNDI important anyway?

JMS clients must set up the proper network-capable objects, for example, connection
factories, in order to obtain access to other server-resident objects, for example,
connections and topics. The latter objects are, of course, fundamental to JMS-based
interclient communication.
With some JMS implementations, a client obtains a connection factory directly using
local instantiation (new AVendorConnectionFactory()). This approach requires
access to server-oriented classes. In some environments, it's preferable not to
distribute the vendor's classes (typically, housed in JAR files) to network hosts
executing JMS clients.
JNDI facilitates server-side administration of JMS-related functionality and service-

oriented access to JMS functionality for clients. In general, JNDI offers another level
of (network) indirection between each client and various servers, which can be
important for reducing version-related incompatibilities for frequently upgraded
software.
Is it possible for a consumer to look ahead at incoming messages? Is there

anything for messages similar to the C library's getc() and ungetc() for
character streams?
With point-to-point messaging, QueueBrowser supports look-ahead or primitive

browsing operations without removing the message from the queue. QueueBrowser
makes messages in the queue available via an Enumeration object. Note that the
exact behavior, in terms of capturing the queue's current contents, will vary across
JMS implementations.
For publish/subscribe messaging, the consumer can exercise limited control over the
message queue with the Session.CLIENT_ACKNOWLEDGE acknowledgment mode:
...
topicCon.createTopicSession(false, CLIENT_ACKNOWLEDGE);
...
In particular, messages remain available for re-processing until there is a client

acknowledgment of a message; at this point the acknowledged message and all
"older" messages become unavailable.
How does a consumer acknowledge a message from a producer?

The easiest way is to allow the framework to do it--automatic acknowledgment:
...
topicCon.createTopicSession(false, AUTO_ACKNOWLEDGE);
...
With client acknowledgment, a client can allow messages to accumulate until some
arbitrary application condition:
...
topicCon.createTopicSession(false, CLIENT_ACKNOWLEDGE);
...
When a client acknowledges a message, the acknowledged message and all "older"
messages become unavailable for future processing.
Is it possible to turn off message acknowledgment if it is not important for a

particular communication scenario?
Sort of. In this situation, in general, you can improve throughput by setting the
acknowledgment mode to permit duplicates, that is, by allowing the JMS server to
avoid the overhead of the once-and-only-once guarantee:
...
topicCon.createTopicSession(false, DUPS_OK_ACKNOWLEDGE);
...
Also.
2001
BEA WebLogic JMS 6.0+ provides two approaches here: a non-reliable multicast
pub/sub mode where there is no acknowledge involved, and a proprietary
acknowledge mode "NO_ACKNOWLEDGE".
If your goal is to improve performance, you can also get a near equivalent
performance boost by defering client acknowledges until the consumer has processed
a number of messages (ack every 50 for instance).
Is it possible to do RMI-like, request-reply communication with JMS?

No and yes. JMS provides no analog to structured, remote method invocation, that
is, with strong data typing of arguments packaged succinctly in a single method call,
and with a type-checked return value.
On the other hand, for quick-and-dirty synchronous communication from a client that
normally plays the role of a consumer with respect to some topic, the consumer
client can use QueueRequestor or TopicRequestor to send a message via a
temporary queue/topic and wait for a reply. Communication is message-oriented;
thus, it is somewhat unstructured, or at least, differently structured, compared to a
method invocation.
Should the producing client store data in a message's header or its body?
Created: Dec 1, 1999
Decisions regarding where to store data should be based on the following guidelines:
• The primary purpose of the header is to identify and route messages.

• JMS does not provide a consuming client with access to the message body
until the message is consumed. (QueueBrowser does not provide static
snapshots.)
• It's more likely that "large quantities of data" will be handled more efficiently
in message bodies than in the message header as property values.
If consuming clients will be using the data to filter the messages they receive from
the JMS server, this data should be small and stored as a message property. In this
case, any inefficiencies related to "top-heavy" headers, data conversions to and from
strings, and so on will more than likely be offset by the savings in not having to
delivery a significant percentage of the messages to a consuming client(s),
depending on the message selecting criteria.
If messages potentially transport a large amount of data, and consuming clients are
interested in only certain data-laden messages, it makes sense to put the data in the
message and a coordinating, or identifying, property name and value in the header,
in order to maximize the message selection/filtering capabilities that are available
with JMS.
How does a client application create a transaction object?
Created: Dec 14, 1999 Modified: 2000-08-03 22:25:31.928
How you gain access to UserTransaction objects varies depending on the type of
client. Enterprise JavaBeans provides two types of transaction management:
• Container-managed transactions. As the name implies, the EJB container

makes the decisions (based on the deployment descriptor's trans-attribute
setting) regarding how to bundle operations into transactions and then works
with the transaction manager, which manages the transaction processing.
• Bean-managed transactions. In this case, a session bean obtains the
UserTransaction object via the EJBContext using the
getUserTransaction() method.
JMS clients can bundle several messages in a transaction simply by using a

transactional session--a UserTransaction object is not required. To create a
transactional session, use either QueueConnection.createQueueSession() or
TopicConnection.createTopicSession() with true as the first argument. (Some
JMS implementations support JTA, so that it's also possible to obtain a
UserTransaction object from the JMS server.)
In other environments, for example, a web server that supports servlets and/or
JavaServer Pages (JSP), a JMS server, and others, you obtain a UserTransaction
object via JNDI. Of course, for a servlet to obtain a UserTransaction object, there
must be a JTS-capable server to deliver the object.
Typically, the server provides the JNDI look-up name either directly or via a system
or server property. For example, with the WebLogic server, you would use a code
segment similar to the following:
...
Context c = new InitialContext();
UserTransaction ut = (UserTransaction)
c.lookup("javax.jts.UserTransaction");
ut.begin();
// perform multiple operations...
ut.commit()
...
With J2EE implementations, you obtain the UserTransaction object with a code
segment similar to the following:
...
c.lookup("java:comp/UserTransaction");
ut.begin();
ut.commit()
...
If the environment provides the UserTransaction object via a system property, you
would use a code segment similar to the following:
...
String transName = System.getProperty("jta.UserTransaction");
UserTransaction ut = (UserTransaction) c.lookup(transName);
ut.begin();
ut.commit()
...
JNDI remote look-up names and property names vary, of course, across
servers/environment.
WebLogic does it differently

Author: Alex Chaffee (http://www.jguru.com/guru/viewbio.jsp?EID=3), Feb 14, 2003
In WebLogic 6.1, the JNDI name of the UserTransaction is either
javax.transaction.UserTransaction
or
weblogic.transaction.UserTransaction
I have found that the standard (?) JNDI name "java:comp.UserTransaction" or
"java:comp/UserTransaction" does not always work.
WebSphere 5.0
Author: Christoph Ernst (http://www.jguru.com/guru/viewbio.jsp?EID=1106402),
Aug 6, 2003
In WebSphere 5.0 the JNDI-Lookup works like
ctx.lookup("jta/usertransaction");
See e.g. http://www-
3.ibm.com/software/webservers/appserv/doc/v30/ae/web/doc/ent_beans/atswpgec.htm
Re: WebSphere 5.0

Author: Ralf Taugerbeck (http://www.jguru.com/guru/viewbio.jsp?EID=1119711), Oct 6, 2003
The link above is a bit outdated (from WAS 3.0 documentation). Check the current Infocenter for detai
support in WAS 5.0:
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.base.doc/info/a
The lookup "jta/usertransaction" is still supported for J2EE apps with a spec level of 1.2 or lower. But
1.3 or later "java:comp/UserTransaction" is demanded.
Re[2]: WebSphere 5.0
Author: William Koscho
(http://www.jguru.com/guru/viewbio.jsp?EID=1148721), Feb 24, 2004
I am familiar with looking up the JNDI reference, but I am having trouble
defining the UserTransaction in Websphere. Can someone help me to set it up?
How do I create a javax.transaction.UserTransaction object and map it to
"java:comp/UserTransaction"? I am using WSAD 5.1 - any help is appreciated.
Thanks, Bill

Author: Donato Marrazzo
(http://www.jguru.com/guru/viewbio.jsp?EID=1179813), Jun 18, 2004
You don't need set up nothing. java:comp/UserTransaction is implicitly

defined, just use it!
From J2EE 1.3 specs: "The J2EE platform must provide an object
implementing the javax.transaction.UserTransaction interface to all web
components. The platform must publish the UserTransaction object in the
Java™ Naming and Directory Interface (JNDI) name space available to
web components under the name java:comp/UserTransaction."

Author: himanshu Sharma
(http://www.jguru.com/guru/viewbio.jsp?EID=1241678), Apr 29, 2005
We have a set of interface programs that use Open Adaptor framework
for interfacing with external apps using MQ Series, JMS & Databases .
The interface programs run in seperate JVMs and most of the time
access at least two resources such as MQ and Database tables. Therefore
it is neccesary to provide a two phase commit to preserve transacttion
integrity across interface boundaries. In order to meet this requirement
we need to understand how we can use WAS 5.1.1 (JTS impl) for XA
compliant Datasources and JMS queues.
I also feel that accessing WAS (Transaction Manager or UserTransaction

object advertised over JNDI) is prohibited for client applications
(seperate JVMs) other than the web apps.
using java:comp/UserTransaction
Author: Radhakrishnan Nariangadu
(http://www.jguru.com/guru/viewbio.jsp?EID=752623), Aug 4, 2005
Can I use the J2EE JNDI lookup even within a EJB container?
I'm developing a Hibernate based DB component that will provide a uniform
transactional interface anywhere,ie, J2EE container or normal JVM. Therefore within
a Bean managed Session bean, rather than obtaining UserTransaction from the
EJBContext will everything work smoothly if I obtain the UserTransaction using the
JNDI lookup?
I'm planning to switch to a non-managed configuration based on whether I can create

an InitialContext. This will allow the same code to be unit tested in eclipse without
having to run it within a App server.
...thanks in advance
What are the ramifications of mixing JTA and non-JTA transactions where
the same resources are involved?
It depends on the context/resource. In general, you shouldn't create this type of

heterogeneous transaction scenario, especially when working through a Java
application server that shares objects such as database connections. In any situation
where the possibility arises for both, design the application to use JTA transactions so
that all transactions fall under the control of the transaction manager.
If mixed transactions are necessary (for whatever reason), the application should
manipulate the transactions in serial order, that is, start and finish the JTA
transaction before creating the non-JTA transaction (or vice versa). If, for example, a
JMS client creates a transaction via a UserTransaction and this transaction uses a
database resource via the transaction manager, there could be problems if the same
application directly accesses the database using a shared database connection.
One of the advantages of using a J2EE-compliant environment is the resource

coordination provided by the J2EE implementation via its JTS implementation. If, say,
a servlet, accesses multiple resources, for example, via multiple enterprise beans,
the J2EE implementation is responsible for ensuring that all related resource usage
participates in the global, distributed transaction.
Can different threads manipulate the same transaction?

If thread t1 executes UserTransaction.begin() and thread t2 executes

UserTransaction.commit(), UserTransaction.rollback(), or any other
UserTransaction service, the behavior depends on the (EJB, JMS, or whatever)
server's transaction support as well as the transaction manager implementation.
You likely can.

2001
In general, this is possible, but the application must call suspend() on the first thread
and then call resume() on the second thread to move the transaction there. These calls
are found on javax.transaction.TransactionManager. The ability for the second thread
to call commit() is in question though, some transaction managers may require that
the transaction be moved back to the original thread before it can be called.
JTA, J2EE 1.3 specification

Author: Sean Sullivan (http://www.jguru.com/guru/viewbio.jsp?EID=203382), Jun
15, 2003
Sun's J2EE 1.3 specification discusses this topic.
J2EE.4.2.3 Transactions and Threads
There are many subtle and complex interactions between the use of
transactional
resources and threads. To ensure correct operation, web components
should obey
the following guidelines, and the web container must support at least
these usages.
• JTA transactions should be started and completed in the thread in

which the
service method is called. Additional threads that are created for any
purpose,
should not attempt to start JTA transactions.
• Transactional resources may be acquired and released by a thread

other than
the service method thread, but should not be shared between threads.
• Transactional resource objects (for example, JDBC Connection

objects)
should not be stored in static fields. Such objects can only be
associated with
one transaction at a time. Storing them in static fields would make
it easy to
erroneously share them between threads in different transactions.
• Web components implementing SingleThreadModel may store

transactional
resource objects in class instance fields. The web container ensures
that requests
to a SingleThreadModel servlet are serialized and thus only one
thread
and one transaction will be able to use the object at a time.
• In web components not implementing SingleThreadModel, transactional

resource
objects should not be stored in class instance fields, and should be
acquired
and released within the same invocation of the service method.
• Enterprise beans may be invoked from any thread used by a web

component.
Transaction context propagation requirements are described above and
in the
EJB specification.
Is an EJB, JMS, or general-purpose Java application server a transaction

manager?
It depends on the server implementation. The JTA and JTS specifications define
client-, application-, and transaction manager-level operations. There is nothing to
prevent a Java application server from implementing, JMS, EJB, and JTS functionality.
On the other hand, it could (if available) obtain transaction manager services
indirectly from another server.
Is it possible for server-side applications, for example, a JMS application, to

play the role of a resource in a distributed transaction?
Under certain conditions, yes. In this particular case, the JMS server would have to
implement the appropriate resource-related interfaces in javax.transaction.xa so
that the JTS transaction manager can enlist the JMS server as an intermediary,
playing the role of a resource manager with respect to the JMS application.
Can a JMS client obtain a JTA UserTransaction object?

The JMS specification does not require that JMS implementations support distributed
transactions. If a JMS implementation supports distributed transactions, it's likely
that it will do so through the JTA API, providing a JTA UserTransaction object via
JNDI.
Is there a mailing list for discussion of the JMS API?

Created: Jan 29, 2000 Modified: 2000-02-01 06:33:15.981
Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7)
Sun manages the JMS-INTEREST list. You can signup and read the archives at
http://archives.java.sun.com/archives/jms-interest.html.
The JMS API describes the ConnectionFactory and TopicConnectionFactory.
These are also described as "administered'. In order to build an application
using JMS, what do I start first and how? Specifically, what parameters are
required to get a connectionFactory running?
Created: Mar 6, 2000 Modified: 2000-03-06 08:56:49.488
Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) Question
originally posed by m gottshall (http://www.jguru.com/guru/viewbio.jsp?EID=8652
In addition to TopicConnectionFactory, the JMS API also includes

QueueConnectionFactory, which provides connections for queued, or point-to-point
(P2P), communications. Although support is growing, not all JMS providers
implement P2P messaging at this time.
An application receives certain JMS-related objects from a JMS factory that are
administered in the sense that these resources are controlled by the JMS server's
security subsystem. The security subsystem varies from vendor to vendor and is not
part of the JMS specification from Sun Microsystems. Most JMS middleware vendors
provide a graphical console for administering these resources.
Applications (distributed application components) typically communicate via one or

more destinations (topics and/or queues); these destinations are placed under the
control of the security subsystem. Thus, for application components to produce or
consume messages via these destinations, they (1) must be on the access list for the
named destinations, (2) hold the appropriate user ID and password at the connection
(or some other) level, or (3) satisfy other vendor-specific access criteria.
For intranet- or extranet-distributed applications, these security steps are often

necessary; for experimenting with JMS, these steps are a minor inconvenience.
Some JMS servers, however, automatically create destinations with guest access
privileges, so that the security subsystem is virtually seamless. Applications can
"turn on" a higher level of security at a later stage in the development cycle. Even
for JMS servers that require direct participation with respect to the security
subsystem, the process is often as simple as providing user ID and password
arguments when invoking a factory method. For example, with the JMS middleware
from Progress Software, the following steps (1) obtain a connection factory, and (2)
create a connection, and (3) start a session:
try {
qcf = new progress.message.jclient.QueueConnectionFactory(url, "");
con = qcf.createQueueConnection(userId, password);
}
catch (Exception e) { /* handle exception */ }
In order to set up a JMS-capable application, that is, in order to access JMS services
within a distributed application, you must:
• Obtain the appropriate connection factory

• Obtain the appropriate connection from the factory
• Obtain a session object from the connection
• Obtain a queue/topic from the session
• Obtain a consumer or producer object
• In the case of a consumer connection, register a message listener (if the
client wants to receive messages asynchronously)
• Activate the connection
• When the application is finished, close the connection
This process involves several steps, but the resulting messaging capabilities are
extensive. Also, this process is "routine" and amazing similar for each application, so
it's pretty easy to write a convenience class that performs these step, and that is
configurable for different topics and/or queues.
Of the steps listed previously for enabling JMS services in an application, the first
step varies somewhat across vendors. Some vendors provide connection factories via
object instantiation, as in the previous example. In this case, you must know the
class name for the connection factory. Other vendors deliver the connection factory
via a JNDI look-up operation, in which case you must know the appropriate look-up
symbol, for example, "topicConnectionFactory". These minor details are explained
in the vendor's documentation.
The JMS FAQ includes several complete example programs that demonstrate how to
set up JMS services in an application, as well as how to employ those services. In
addition, most vendors provide demonstration programs as part of their software
distribution.
Does the JMS specification require compatibility between JMS

implementations, or will all parties involved have to use the same vendor?
originally posed by Michael Prescott
(http://www.jguru.com/guru/viewbio.jsp?EID=25013
The JMS specification, like many specifications, is an attempt to specify a software

system with both core and optional functionality. As with many specifications, there
are design and implementation issues that are unclear, or not fully specified.
Sometimes, specifications are unclear in certain areas by accident; sometimes,
ambiguities are inevitable, simply because the technology is new and it is virtually
impossible to fully anticipate every issue. Over time, feedback from the developers
who implement the specification helps clarify certain issues and the specification is
then revised.
Vendors who provide JMS implementations must implement the core functionality;
implementing optional functionality is, of course, optional. Another issue is vendor-
specific functionality beyond the optional functionality described by the specification.
Developers who use JMS implementations expect optional functionality to be missing
in some implementations. In contrast, vendor-specific functionality is not likely to
appear, in any other implementation (at least not as compatible, extended
functionality). Sometimes, vendor-specific functionality provides a truly needed
service for the vendor's customers; sometimes, it simply inhibits portable software
development.
A developer should expect each JMS implementation to be highly source-code
compatible with respect to the core functionality. That is, with minor changes to
various configuration-related code areas, an enterprise should be able to switch JMS
implementations half way through the development process, assuming that they
strive to write portable code. Of course, the user cannot expect runtime compatibility
among JMS implementations, because the specification does not address low-level
transport details, as well as other implementation issues.
The JMS specification, for example, does not address the overall JMS server
administration process. (The specification does outline so-called administered
objects.) Thus, each vendor's configuration and administration interface will vary, for
example, lightweight text-oriented, command-line tools versus graphical
administration consoles with elaborate resource monitoring charts. Even with these
variances, however, the developer should still be able to deliver applications with JMS
functionality that is approximately 95 percent portable.
Choosing a JMS vendor is not unlike choosing a relational database vendor, because
all parties in the enterprise must weigh the importance of the vendors' extensions, as
well as the robustness and portability of the core functionality. Although the JMS
specification has been around for a relatively short period (in terms of specification
and standards metrics), there are already several very stable JMS implementations,
with several more under development. (Compare this stability to, for example,
Swing.)
One issue that organizations should consider is whether or not a JMS implementation
is truly enterprise-capable and is compatible (as much as possible) with other
frameworks, for example, Enterprise JavaBeans (EJB). Furthermore, does the JMS
implementation make its administered objects available via standard services now
common in the Java arena, such as the Java Naming and Directory Interface (JNDI)?
See the JMS corner of the Java universe for a list of JMS vendors. See the Taco
framework for an example of JMS-related software that is striving to be 100 percent
portable.
In the above answer, the fact that transport-level...

Author: Robert Prince (http://www.jguru.com/guru/viewbio.jsp?EID=86891), Nov 6,
2000
In the above answer, the fact that transport-level compatibility is not ensured is
mentioned. Does that mean that it is definitely not possible to mix and match different
implementations of JMS? Here's an example: Application 1 uses WebLogic's JMS. It
wishes to connect to application 2, a JMS application backed by MQSeries. So, can
app1 connect directly to one of app2's queues? What are the implications?
As far as I know, the JMS specification doesn´t...

Author: Mario Prados (http://www.jguru.com/guru/viewbio.jsp?EID=238319), Nov 6,
2000
As far as I know, the JMS specification doesn´t guarantee or ask for JMS providers to
support compatibility between different MOM vendors. Imagine the hypothetical
"compatibility matrix", since every MOM uses such different protocols to support
JMS. The only way to acomplish that is implementing (I have done such work)
gateways between JMS domains.
JMS implementations runtime compatibility.

Author: Igor Gorbunov (http://www.jguru.com/guru/viewbio.jsp?EID=817578), Mar
29, 2002
Just wanted to mention one more thing: JMS specification tries its best to assure that
the Message objects, received from one JMS implementation, can be published to
other vendor's JMS implementation without any explicit changes/translations.
Is there an interface to Microsoft's MSMQ server from/to JMS and is there

an interface from/to IBM's MQSeries?
Author: Benoit Xhenseval (http://www.jguru.com/guru/viewbio.jsp?EID=3363)
Question originally posed by John Thorhauer
Responding about MQSeries, the JMS implementation is provided by IBM under the
MA88 Support pack available at http://www-
4.ibm.com/software/ts/mqseries/txppacs/ma88.html and it's free!
Fiorano (www.fiorano.com) sells a product called the...

Author: Sean Sullivan (http://www.jguru.com/guru/viewbio.jsp?EID=203382), Sep
12, 2000
Fiorano (www.fiorano.com) sells a product called the "FioranoMQ - Bridge" that
allows you to use the JMS API to send and receive messages over MSMQ and IBM
MQSeries.
How can JMS be used from EJB 1.1?

Author: Jason Vanguard (http://www.jguru.com/guru/viewbio.jsp?EID=27748)
Question originally posed by Jon Finanger
The same as any client would use JMS. At this point there is no integration, but it is
planned for a future release of the EJB spec.
Could you please expand: Can a bean be a JMS subscriber...

Author: Benoit Xhenseval (http://www.jguru.com/guru/viewbio.jsp?EID=3363), Apr
18, 2000
Could you please expand: Can a bean be a JMS subscriber and "sit" there in memory
waiting for a JMS event? How could we guarantee that this bean stays active in
memory?
EJB 1.1 specification doesn't allow an enterprise bean...

Author: Alessandro Alinone (http://www.jguru.com/guru/viewbio.jsp?EID=14810),
Apr 27, 2000
EJB 1.1 specification doesn't allow an enterprise bean to receive messages
asynchronously. You can only pull messages through the receive() method. The
asynchronous delivery will be made possible by EJB 2.0 specification. Here is a quote
from JMS 1.0.2 specification (sec. 1.4.3 on page 18): "The current EJB specification
defines beans that are invoked synchronously via method calls from EJB clients. A
future release of EJB will add a form of asynchronous bean that is invoked when a
JMS client sends it a message."
Is there any reason why a message can't be sent to an applet via JMS?
Created: Apr 5, 2000 Modified: 2000-04-05 06:27:25.621
Author: Benoit Xhenseval (http://www.jguru.com/guru/viewbio.jsp?EID=3363)
Question originally posed by Andrea O. K. Wright
No. It all boils down to the standard applet limitations and your chosen
implementation of JMS.
• An applet can connect only to the server it came from.

• An applet could be on the wrong side of several firewalls, so if your JMS
implementation requires specific ports to be open, you might be facing some
problems.
To get around the firewall issue, nothing could stop you from implementing a simple
JMS client using HTTP stream (i.e. keep the connection open) to communicate with a
servlet that would register on your async backbone. Soon, some commercial JMS
implementation could implement it.
Currently, you can do it with the JMS implementation on top of MQSeries.
No. There's no particular reason why you can't do...

Author: karan oberai (http://www.jguru.com/guru/viewbio.jsp?EID=2836), Oct 17,
2000
No. There's no particular reason why you can't do that, but you would have to work
around it a little bit.
There are many ways you can implement the above:

• Use a applet-servlet model using socket connections.
• Use RMI or CORBA.
• Right now, JMS doesn't support HTTP tunneling, so you would have to use a
URL connection via a servlet which talks to an applet on the other side.
Is it possible to communicate between different EJBs and between EJB and

servlets through JMS? If so, how? Are there links to related references?
Your help will be appreciated.
Author: karan oberai (http://www.jguru.com/guru/viewbio.jsp?EID=2836) Question
originally posed by Sakeb Ali (http://www.jguru.com/guru/viewbio.jsp?EID=32453
Communication between EJBs and servlets is very much possible. In fact, one of the
advantages of JMS is that it can be used to link very different applications running on
different environments or separate JVMs. What you need to have is a message
producer and consumer each at both levels, i.e., at your EJB side as well as on your
servlets. So, for your servlet to communicate with EJB it would have to send a
request via a message producer (to a named destination like a queue or topic),
which would be read by the EJB's message consumer on the other end, and vice
versa.
In a publish/subscribe model, how do you go about having one class be a

listener for more than one topic? It seems logical to just create a
TopicSubscriber for each topic you want to listen to. If so, should each
TopicSubscriber be created under the same session or different sessions? Is
there some rule of thumb to follow or does it not make a difference?
originally posed by Michael Juster
Any time that multiple destinations are involved, for example, subscriptions to
multiple topics, the preferred approach (in my opinion) is to design a separate class
(either inner or conventional, depending on the circumstances) that functions as a
message listener for each topic, and then manage each topic in its own session. It's
possible, of course, to create multiple TopicSubscriber instances, one per topic,
each registered with a common message listener and associated with the same
session. In most situations, the latter approach does not scale well and can lead to
readability and maintenance problems.
Also, note that sessions are single-threaded contexts. That is, a session uses a single
thread of execution for all registered message listeners. Hence, managing multiple
topics and listeners within the same session (in effect) attenuates the asynchronous
message-handling operations. Suppose that multiple messages arrive at
approximately the same time (for example, one per topic for several topics). In this
case, all messages except one must wait while the session handles one message
notification (executes the registered listener). In this scenario concurrency can be
improved by designing listeners with dedicated execution threads. Of course, if there
are dependencies among the message-handling operations, for example, common
data, the application must accommodate these critical-region issues.
Also, unexpected delays in processing messages, due to serialized message

notifications, can have unintended effects for an application. Thus, in many cases,
handling each topic subscription in a separate session, simplifies application logic.
Is there a way for a consumer in JMS to automatically send an

acknowledgement message to a producer (not only to the server) to notify
the reception of a message?
originally posed by Giuseppe Tanzi
There is no portable, automatic mechanism for a consumer to acknowledge message

receipt with the producer. Providing such a mechanism is actually quite difficult
because of factors such as time-outs, etc.
The only reliable way to handle producer-consumer communications in which the

producer requires acknowledgment is through an application-specific request-reply
scenario.
One general strategy is for the messaging-producing client to provide "destination-

based contact information" in the message header so that the message-consuming
client can use this information to publish/send a reply. JMS provides general-purpose
functionality for request-reply operations. See the following in the JMS API
documentation: the TopicRequestor and QueueRequestor convenience classes, plus
Message, in particular, the convenience methods associated with the JMSReplyTo and
JMSCorrelationID message header fields.
The SonicMQ Programming Guide, available from the Progress/SonicMQ website,

discusses this issue. The SonicMQ software distribution provides request-reply
examples as well.
Has JMS replaced Java Message Queue? More importantly, which technology
should a developer be using?
Created: May 7, 2000 Modified: 2000-05-07 14:26:24.506
originally posed by CHARLES TAM
JMQ does not replace JMS; JMQ is an implementation of the JMS specification. JMQ is
now sold as Sun Microsystems software. JMQ is only one of several JMS
implementations. Enterprises shouldn't "jump to JMQ" before considering alternative
JMS implementations.
I am quite new in JMS and would like to try it out. Can you please suggest
any complementary software?
originally posed by CHARLES TAM
See the Vendors' page at the JMS site at Sun.
free JMS
Author: JP Bonn (http://www.jguru.com/guru/viewbio.jsp?EID=937269), Jul 3, 2002
Look at JBoss also - http://www.jboss.org The JBossMQ is a free, open source JMS
impelmentation.
Are there any JNDI tutorials?

Author: John Mitchell (http://www.jguru.com/guru/viewbio.jsp?EID=4)
Yes, check out The JNDI Tutorial online and/or buy a copy of it here.
What books cover JNDI (Java Naming and Directory Interface)?

Check out The JNDI Tutorial. It's also available on the web.
For other books that are relevant to JNDI, check out Are ther any books that provide
decent JNDI coverage?.
OK, so EJB doesn't support user-created threads. So how do I perform tasks

asynchronously?
Author: Robert Castaneda (http://www.jguru.com/guru/viewbio.jsp?EID=4362)
Question originally posed by Venkateswaran Muthuswamy
If your EJB does not need to know about the results of the aynch calls, then you can
use JMS to send an asynch. message to another part of the system.
Another alternative is to place the multithreaded code inside a CORBA or RMI server
and call this from your EJB. Always keep site of the big picture, RMI and CORBA are
part of J2EE and can be used as part of a 'J2EE' solution.
There are some things that these technologies can do that EJB at this present time
cannot.
You can perform tasks asynchronously in two different...

Author: Prasad Thammineni (http://www.jguru.com/guru/viewbio.jsp?EID=36479),
Jun 14, 2000
You can perform tasks asynchronously in two different ways. 1. Using client-side
threads - less complex. Kick off separate threads for each EJB access. At a later time
join the threads on the client-side. 2. Using JMS - more complex. Define EJB
methods with an additional parameter to indicate whether it is a asynchronous call or
not. If called asynchronously, the EJB method would post a JMS message to a queue
and return immediately without doing any work. The JMS queue monitor would pick
up the message and call the EJB by setting the asynchronous parameter to false. The
EJB executes the method and returns the results. The queue monitor posts the results
to an output queue being monitored by the client. Both JavaPro and Java Report had
published articles on this topic recently.
Does the J2EE reference implementation support the JMS?

Created: Jun 21, 2000 Modified: 2000-07-11 22:37:14.122
Author: Andrea Pompili (http://www.jguru.com/guru/viewbio.jsp?EID=51802)
Question originally posed by Richard Landon
The current release of J2EE (1.2.1) support EJB 1.1 specification so it doesn't
implements JMS over EJB.
This kind of EJB appears only in the EJB 2.0 specifications (available at
http://java.sun.com/products/ejb/docs.html).
At this time only BEA and Silverstream support this specification. Probably in the
future more Vendors will follow this new specification, so wait...
The current release of J2EE reference implementation...

Author: Prasad Thammineni (http://www.jguru.com/guru/viewbio.jsp?EID=36479),
Jun 22, 2000
The current release of J2EE reference implementation supports the JMS API only and
does not come with a reference implementation of JMS. Thus, you can write EJB and
non-EJB components to run in the J2EE reference implementation which access a
3rd-party JMS server using the JMS API.
Orion supports JMS now, as well.

Author: Joseph Ottinger (http://www.jguru.com/guru/viewbio.jsp?EID=37791), Jul 6,
2000
Orion supports JMS now, as well.
JRun 3.0 also has started supporting the JMS featu...

Author: Anoop Sehdev (http://www.jguru.com/guru/viewbio.jsp?EID=208040), Sep
17, 2000
JRun 3.0 also has started supporting the JMS feature.
How do you bind a queue to a context for subsequent applications to look

up? If queues are created in the context of a session, how can they be used
by another session?
Author: Andreas Mueller (http://www.jguru.com/guru/viewbio.jsp?EID=23179)
Question originally posed by Kim Limbrick
A client cannot create a queue, except temporary queues. If your question refers to
the createQueue() method of a QueueSession, the JMS 1.0.2 specification states,
that this method is not to create the physical queue instance but only the destination
object, which is the address of the queue. Creating physical queues is an
administration task not to be performed by a client. This is well separated in JMS.
Consider two processes A and B. A wants to send a message to B's queue

and A wants B to reply to A's message. For example, A sends to queue
'Consumer' that B creates, and B sends the reply to A's 'Producer' queue.
How would the clients implement this scenario?
Question originally posed by Subri Shastry
First,client 'B' cannot create a queue 'Consumer'. This is an administration task,

performed by administration tools. If the queue exists, 'B' can look up the queue and
can create a QueueReceiver to receive incoming messages. If the JMSReplyTo
header of a message contains a destination object (a TemporaryQueue), 'B' can send
a message to it (via a QueueSender created for this destination). To implement this
request/reply pattern, client 'A' can use a QueueRequestor helper class, which is part
of JMS.
In a system where one client sends a message to one specific peer out of
thousands, is it appropriate to use a single queue and have the peers find
their messages using selectors?
Question originally posed by Henrik Hermansson
This is one possibility, but very slow, I think. Every message has to pass every
receiver to check if the specific message selector does match. Also, not every vendor
supports multiple receivers on a single queue. I would suggest, use publish/subscribe
and map your selection criteria to topics or, if your vendor supports this, to topic
hierarchies. But your sender client has to perform some pre-selection to publish to
the right topic.
why pub/sub for ptp problem domain?

Author: Jason Dillon (http://www.jguru.com/guru/viewbio.jsp?EID=23800), Mar 18,
2002
This seems a bit backwards... the problem domain looks like ptp, but you suggest
pub/sub as the solution.
Does this mean that you suggest setting up a sub-topic for each client(out of
thousands) and only listen on that one sub-topic?
Or do you mean to setup a smaller number of topics and then use message selectors
on the client to further limit the message delivery?
Is there a way to have mutiple instances of the consumer running on

different server instances read from the same queue and ensure that each
message is processed by one and only one of the consumers. I'd like to do
this to spread the load over the various machines.
Created: Jul 3, 2000 Modified: 2000-07-03 10:47:59.446
JMS specifically does not define how messages delivered to a queue are load
balanced across multiple consumers. It does not define an optional mechanism for
doing this. The reason it does not is that this involves complicated APIs that are quite
hard to define in a vendor neutral form. The EJB 2.0 message-driven bean facility
addresses this need by making the J2EE server responsible for integrating JMS, and
if the container provides some form of clustering/load balancing, then the container
handles this complexity. JMS vendors may provide some form of load balancing, but
if they do, it is completely outside the JMS specification. (Original answer from Mark
Hapner, Sun Microsystems)
Clarification
2001
While the JMS spec does not spec out load balancing, it does spec out that the same
message must not be delivered twice unless using the DUPS_OK_ACKNOWLEGE
mode. You can get an even better guarantee from JMS vendors that support user
transactions. You are right in thinking that queues make for a nice load-balancing
solution, the caveat is that the JMS vendor makes some effort not to favor any
particular consumer.
Are there any open-source JMS implementations?
Created: Aug 1, 2000 Modified: 2000-08-06 12:01:00.093
Author: Robert Castaneda (http://www.jguru.com/guru/viewbio.jsp?EID=4362)
Question originally posed by y yc
Open Source JMS implementations include:
spyderMQ, which is part of the jBoss project - http://www.jboss.org/
and
OpenJMS, which is sposored by intalio - http://www.openjms.org/
open source JMS API

Author: kunal khanna (http://www.jguru.com/guru/viewbio.jsp?EID=403594), Apr
16, 2001
The following JMS API implementations are available as open source:
objectCube.com OpenJMS.exolab.org ObjectWeb.org/joram/
open source JMS implementation

Author: Dmitry Jirov (http://www.jguru.com/guru/viewbio.jsp?EID=448170), Jul 1,
2001
Open3 JMS implementation - http://www.open3.org
Re: open source JMS implementation

Author: Benjamin Ranck
(http://www.jguru.com/guru/viewbio.jsp?EID=1242079), May 2, 2005
the above link is spam.
www.swiftmq.com
Author: Mark Smith (http://www.jguru.com/guru/viewbio.jsp?EID=491756), Sep 6,
2001
www.swiftmq.com - It's open source, fast, relialbe, and mature.
Re: www.swiftmq.com
Author: Jason Dillon (http://www.jguru.com/guru/viewbio.jsp?EID=23800), Mar
18, 2002
SwiftMQ is not an open source JMS impl. It also appears that since v3.0 it is not
even free anymore.
Re[2]: www.swiftmq.com
Author: Mark Smith (http://www.jguru.com/guru/viewbio.jsp?EID=491756),
Mar 19, 2002
Yes, you are correct. They have changed their licensing unfortunately. Here is
a link of some open-source JMS vendors:
http://www.ejbnow.com/jms_links_page.html
When there is an asynchronous listener on a JMS queue, a new thread is

spawned to handle each new message being passed to the queue. If the
message processing takes time, and a large number of messages are
queued in a short time, this could cause quite a few threads to be spawned
very quickly. Are there any mechanisms inherent in JMS (the specification,
or in specific vendor implementations) to manage a thread pool of message
processors? Would a developer need to do some sort of synchronous listen-
>local thread pool to firmly control the threading in this scenario?
Author: Kishan A (http://www.jguru.com/guru/viewbio.jsp?EID=66106) Question
originally posed by Paul Danckaert
No, a new thread is not spawned to handle each new message being passed to the
queue. A session can handle only one message at a time, i.e, it is a single thread of
execution. While one message is being processed, all the other messages need to
wait. To have messages delivered concurrently, you need to have multiple sessions.
See Sections 4.4.16 and 4.4.17 of the JMS 1.0.2 specification.
There is an advanced feature of JMS for concurrent processing of a subscription's

message. This is an optional feature that is expected to be supported only by
sophisticated JMS providers.
See Section 8.2 of the specification for a detailed explanation of what it means.
Sounds like you want consumer pools.

2001
These can be provided by Message Driven Beans (MDBs)hosted on an app server.
And ServerSessionPools (the "advanced feature" mentioned above). Since
ServerSessionPools are less universal, and are not as capable as MDBs, I recommend
MDBs. BEA WebLogic supports both.
Where can I find the API documentation for Java Messaging Service (JMS)?
The JMS API documentation is available from Sun's J2EE API documentation page.
How should I take care of issues like security while implementing a

QueueConnectionFactory and other administered objects in JMS?
originally posed by saima rizvi
JMS does not define a security API. JMS implementations provide vendor-specific
security facilities, typically, through a text-oriented console or a graphical
browser/console.
For this reason, (distributed) JMS clients should use a topic and queue design within
their application components that facilitates the factoring of and provision of security
at several levels--whatever matches the needs of the application components. In this
way, an administrator can set the security characteristics of various topics and
queues to allow the proper level of accessibility by user and by application
functionality.
Is there a way of setting up JMS for secure communications? Essentially, I

want to be able to restrict topics to authorized users only.
originally posed by Norm MacDonald
JMS implementations typically provide a text-based console and/or graphical browser

for setting the security for each topic and queue, including access lists. JMS clients
can read and process a user ID and password dynamically, providing the ID and
password as arguments to API methods that create client-side topic and queue
objects, thereby restricting access for the server-side topics and queues to
authorized users.
I am a little confused about the differences, advantages, and disadvantages

of using JavaMail, JMS, and James Apache. Could someone please help me
by clarifying these to decide which is the best solution to implement?
originally posed by Armando Noval
The JavaMail API is a mail user agent (MUA) for creating programs for a user to
get/send email messages, using standard mail protocols.
James (and others) is a mail server / mail transfer agent (MTA). It is responsible for
the actual sending and delivery of mail messages, as well as queueing messages
when something is down, holding them for the user to receive, etc.
The Java Message Service (JMS) is a Java API for interclient messaging. JMS provides
a general-purpose facility for sending messages among distributed application
components. It does not provide email functionality.
How can I integrate JMS third-party software with EJB application servers
(both J2SDKEE 1.2.1 and, for example, the WebLogic server)? And, how can
I run the client application? A sample program would be useful?
Created: Sep 8, 2000 Modified: 2000-09-11 07:40:17.597
Author: Ron Kurr (http://www.jguru.com/guru/viewbio.jsp?EID=132270) Question
originally posed by Chandra Shekar
If you want everything to participate within the same transaction, you can't. For
example, if you are in an EJB that has a transaction context started and you place
something on a non-Weblogic JMS queue and the transaction ends up rolling back,
the message you placed on the JMS queue will still remain.
WebLogic 6.0+ supports this via MDB standard.

2001
BEA WebLogic JMS 6.0+ can drive an MDB (message driven bean) asynchronously
in combination with a transaction.
This is a useful design pattern that has been around for a while. BEA Tuxedo (a C
app-server) has for years had a similar capability with its /Q queueing system in
combo with its "TMQFORWARD" process.
Note that there is no standard that allows one vendor to drive another vendor's MDB
transactionally, so BEA has provided a proprietary interface to allow for this.
SonicMQ JMS is currently implementing this interface, but of course BEA JMS has
been able to do this since MDBs came out (about a year now)...
Re: WebLogic 6.0+ supports this via MDB standard.

Author: J C (http://www.jguru.com/guru/viewbio.jsp?EID=756527), Feb 13, 2002
A MDB can only listern to queue/topic on the EJB container, right? If not, how can
MDB listern to queue/topic on external JMS provider? I guess that this
mechanisms is not in the JMS standard. Right?
Re[2]: WebLogic 6.0+ supports this via MDB standard.

Author: Tom Barnes (http://www.jguru.com/guru/viewbio.jsp?EID=569489),
Feb 13, 2002
Ah, I checked, you are correct. To drive a WL MDB with a another vendor's
JMS implementation at all requires filling fields in the WL specific descriptor
for destination JNDI name, connection factory JNDI name, and provider URL.
http://developer.bea.com/docs/jmsmdb.jsp

Author: Jeff Rhines
(http://www.jguru.com/guru/viewbio.jsp?EID=449109), Mar 25, 2002
Unfortunately, that link is now 404ed. Anyone have a copy of it, or know
where it moved to?
Author: Tom Barnes (http://www.jguru.com/guru/viewbio.jsp?EID=569489),
Mar 25, 2002
You can get to it on the bea "dev2dev" site, under "resource library" then
"white papers". Specifically,
http://dev2dev.bea.com/resourcelibrary/whitepapers.jsp?highlight=whitepapers

Author: hernan cuellar
(http://www.jguru.com/guru/viewbio.jsp?EID=851756), Apr 23, 2002
Unfortunately, that file doesn't exist in ftp, too. Anyone have a copy
of it, or know where it moved to?
What are my options for leveraging JMS in a C++ environment?

originally posed by Christopher Green
If you have a messaging system that can be accessed by both Java and C++, you
might consider storing your messages in the form of XML. XML is platform and
language independent and might get you where you want to go. I'm not doing C++
right now, so I can't point you to a JMS implementation that also has a C++
interface.
Fiorano's JMS implementation, FioranoMQ, has a C++...

Author: Jason Rimmer (http://www.jguru.com/guru/viewbio.jsp?EID=240417), Oct
30, 2000
Fiorano's JMS implementation, FioranoMQ, has a C++ access library.
Progress' JMS implementation, SonicMQ, has a C access library.
The SpiritWAVE JMS implementation from SpiritSoft also...

Author: Christoph Sawicki (http://www.jguru.com/guru/viewbio.jsp?EID=339101),
Feb 26, 2001
The SpiritWAVE JMS implementation from SpiritSoft also supports C++ and COM,
but with additional packages called SpiritC++ and SpiritCOM.
Also look at Codemesh

Author: Nick Minutello (http://www.jguru.com/guru/viewbio.jsp?EID=222214), Jun
18, 2001
Codemesh have a greatly simplified Java<->C++ solution. Under the hood, it is JNI,
but you are spared all the frustration of learning the pitfalls of JNI.
BTW, I havent used this so I dont have experience with it.
http://www.codemesh.com/en/index.html
Talarian's middleware
Author: John Reid (http://www.jguru.com/guru/viewbio.jsp?EID=241194), Oct 4,
2001
Talarian offers high performance, scalable publish/subscribe and queueing
middleware that Java, JMS, C and C++ clients can use interoperably. See
http://www.talarian.com/
WebLogic Has A Number Of Integration Options

2001
C++ can access BEA WebLogic directly via IIOP, and through its bridge to BEA's
Tuxedo middle-ware (Tux includes a non-JMS queueing implementation - it predates
JMS by about 10 years.), and from MS through COM support. Also, some integration
tasks can be done through Webservices/SOAP. BEA also sells a higher level
integration product "WebLogic Integrator".
IBM MQSeries
Author: Michael Lanzetta (http://www.jguru.com/guru/viewbio.jsp?EID=1017593),
Oct 25, 2002
MQSeries from IBM also has C++ & Java bindings, as well as bindings for many
other languages. I haven't used any of the others, but I've used MQSeries for this
exact purpose and it worked well.
Pricing is really the issue. Does anyone know of any free solutions for this problem
(besides vanilla JNI)?
I am using JMS to communicate between EJBs and client (GUI) classes in

my application. I have the following problem. When I publish a message to
my EJB component (a stateless session bean) directly from my client (an
applet), it's working fine. But, when I invoke another EJB (a stateful session
bean) from my client and use the stateful bean to communicate with the
stateless bean, it's waiting in a loop and it eventually times out. Can
someone explain this behavior?
originally posed by Suresh Chettoor
Suresh, I think we'll need a few more details before you can be helped. How is JMS
being used here? Are you using queues or pub-sub? What type of payload are in your
messages? Have you looked to verify that you don't have some sort of deadlock
situation causing your thread to wait forever? How is the communication between the
EJBs being done? Is it via JMS or a direct EJB call?
I have a stateless session bean which is used as a...

Author: Suresh Chettoor (http://www.jguru.com/guru/viewbio.jsp?EID=134382), Sep
11, 2000
I have a stateless session bean which is used as a service to serve different

applications. It uses JMS pub/sub to communicate with different applications. The
applications are stateful session beans. The service EJB component uses a handler
(typically, a MessageListener class) to listen to and publish messages
(ObjectMessage). The application uses a pub/sub pair to publish and subscribe to the
same topics that the service listens to.
The communication framework is functioning well if I use a servlet/JSP as my

application. So, I don't think there is a deadlock situation here. But, if I try the same
approach with an stateless EJB as my application, it just keeps on waiting after
publishing the message. The onMessage() method of the MessageListener object is
not invoked at all.
The payload is quite high in my system, and I don't know whether it is the culprit. The
EJBs are communicating through JMS (no look-up involved). In fact, these
components don't even know with whom they are communicating. The application
component just publishes the message through a topic and waits for the response.
There are service components registered to listen these topics, which on receiving
these messages, sends out a response, which the application receives using a
receive() method.
Applet and JMS

Author: Sanjit Singh (http://www.jguru.com/guru/viewbio.jsp?EID=533804), Nov
12, 2001
Hi,
I am rather new to the JMS technology and know only the basics as of now. I was
wondering whether it is a problem to incorporate Applets to receive messages
from the application server using the pub/sub model, and to display the message
or not?
I have an applet in my JSP page and I want to display the message that it receives
from an EJB. How & where is the JNDI naming lookup handled?
I would be grateful if you could help me out and also tell me how the above may
be achieved (basic architecture).
Regards, Sanjit
Are there links (complete with code) to Java publish/subscribe examples?

Also, are there tutorials?
originally posed by David Schab
Sun has some example programs that you might want to look at.
Can an EJB send asynchronous notifications to its clients?

Author: Alex Chaffee (http://www.jguru.com/guru/viewbio.jsp?EID=3) Question
originally posed by Paul Chuang
[. e.g. the client displays alarm status of devices. If I use EJB to periodically check
the database for alarm status change, how to program the EJB to forward notification
to clients when the status is changed? ]
Asynchronous notification is a known hole in the first versions of the EJB spec. The
recommended solution to this is to use JMS, which is becoming available in J2EE-
compliant servers.
The other option, of course, is to use client-side threads and polling. This is not an
ideal solution, but it's workable for many scenarios.
See also OK, so EJB doesn't support user-created threads. So how do I perform tasks
asynchronously? .
Is it better to have one topic and use properties to filter subscribers'

interests or should you set up multiple topics? Is there a performance issue
with having multiple topics versus multiple filters?
Created: Oct 5, 2000 Modified: 2000-10-06 06:51:21.477
Author: Robert Davies (http://www.jguru.com/guru/viewbio.jsp?EID=139017)
Question originally posed by niah bryant
The general answer is that it would be best to use a bit of both. There will always be
an overhead on the broker for the creation of a Topic, but if variations are small,
(for example, less than 200), throughput should be significantly better. This is
because of the overhead incurred in applying the selector to each message, as
opposed to routing a message to a particular client.
This contradicts the following:

Author: Yaniv Shaya (http://www.jguru.com/guru/viewbio.jsp?EID=427872), May
24, 2001
From: http://www.fiorano.com/developer/faq_miscellaneous.htm Should multiple
destinations be used for messages filtering ? Destination are a heavy weight JMS
resources and creation of new destination should be avoided unless necessary. It is a
good JMS programming practice to use MessageSelectors for filtering messages
instead of sending data on separate topics/queues. For special clients, which require a
message to be selected based on a large number of selector conditions, then it might
be a better idea to filter messages based on topics as well as selectors.
What is the best way to implement the subscribe side in the pub/sub
connection?
1. Should I never close the line and receive the messages

asynchronously?
2. Should I close the line and use a durable subscription?
If option 2 is the best way, I have a question: What is the best way to close
the connection? Is there a method that tells me when to close the line?
Author: Robert Davies (http://www.jguru.com/guru/viewbio.jsp?EID=139017)
Question originally posed by Nir Alon
If you want to guarantee that all messages are received by a subscriber, then use a
durable subscriber. If you explicitly close the connection, or there is a network
failure, all unacknowledged messages will be re-delivered the next time you
subscribe.
The publisher and subscriber are completely asynchronus, so it is not possible to

determine if a publisher has finished using JMS. However, you could always set a
property on the last message published to indicate the end of transmission--though
this is application specific.
This varies from vendor to vendor.

2001
For non-durable subscriptions, WebLogic 6.0+ JMS guarantees that all messages sent
while the subscription exists will be received, whether the subscription is synchronous
or asynchronous. One popular vendor on the other hand, may drop such messages
under certain conditions. This is legal according to the JMS 1.0.2 spec, but not
intuitive. It is best to test this out for yourself.
Using JMS we want to transfer files from server A to server B. Is there any
limit to the size to a file that can be transfered using JMS? Is it possible, for
example, to transfer 50- or 60-MB files.
Author: Rajiv Kanaujia (http://www.jguru.com/guru/viewbio.jsp?EID=226198)
Question originally posed by Ramesh Parthasarthy
Theoretically, there are no limits to the size of JMS message. Message size limitations
can be imposed by a JMS service provider.
Message size limitation

Author: chinna n (http://www.jguru.com/guru/viewbio.jsp?EID=891328), May 24,
2002
Though there is no theoretical limit, the suggested maximum file size is around 1
MB(one mega byte)at least as per one of the IBM's article. It may be able to handle
bigger size files with much less queue size(max queue messages), but it may raise
performance/memory issues.
Which type of message is most suitable for file(xml) transfer ?

Author: Tim Poh (http://www.jguru.com/guru/viewbio.jsp?EID=1012409), Oct 15,
2002
On the same note of size limitation. Which subInterfaces of the javax.jms.Message I-
face is most suitable to transfer content of an xml file ? TextMessage, StreamMessage
etc., and why ?
Are there load tests available for JMS?

Question originally posed by paul knowles
You may find some through JMS vendors or Business Analyst groups. Try visiting
some of the JMS provider sites.
Are there any JMS implementations that utilize email under the covers for
interclient communication?
Author: Mario Prados (http://www.jguru.com/guru/viewbio.jsp?EID=238319)
Question originally posed by John Zukowski PREMIUM
I'm not 100% sure, but I could say that probably nobody will be implementing JMS
using e-mail as the underlying transport. If you take a look at Sun's JMS web page,
you'll see the list of JMS implementors. All of them are MOMs (IBM, Fiorano, TIBCO,
Allaire, etc.); thus, you can expect all of them will put JMS interfaces on top of their
respective products.
Yes, all the major vendors are not using email as their...
Author: Mark Pollack (http://www.jguru.com/guru/viewbio.jsp?EID=231174), Oct
30, 2000
Yes, all the major vendors are not using email as their underlying transport. However,
e-mail and JMS/MOM will come together to some extent when message driven beans
(EJB 2.0 spec) become more popular.
Progress' JMS implementation, SonicMQ, has an add-on...

Author: Jason Rimmer (http://www.jguru.com/guru/viewbio.jsp?EID=240417), Oct
30, 2000
Progress' JMS implementation, SonicMQ, has an add-on that enables utilization of
email protocols (SMTP, POP, and IMAP) for JMS client/server communication. It's
currently in its first Beta and is available at Progress' Developer's Exchange
(registration required).
What's MOM?
Author: neal ravindran (http://www.jguru.com/guru/viewbio.jsp?EID=17737)
Middleware is usually something that sits between a client and a server. Or, in
simpler terms, between a requestor and a requestee. A request can be considered as
a message. Different software components in a distributed computing network need
to pass messages between themselves, asynchronously. MOM, or Message Oriented
Middleware is software that sits between two such communicating software
components. MOM products facilitate this message-passing by using a technique
called queueing. Messages are stored in queues until the client which requested it
can "read" it in a FIFO fashion, or on a priority basis. The queueing technique thus
eliminates complex connection overhead, and also helps the communicating software
components work independent of time (or asynchronously). IBM's MQSeries and MS
MSMQ are examples of MOMs.
What is the relationship between types of the sent JMS messages and types
of the received JMS messages? Can they be different types?
Question originally posed by Luis Rivera
Theoretically, if you have a single JMS provider, there should be no difference in the
message type (for both send and receive). If you have multiple JMS providers, and
they are talking to each other through a bridge, then there is a possibility that the
message types may differ. The bridge vendor should document these issues.
However, the entire message should be an instance of a class implementing

javax.jms.BytesMessage, javax.jms.MapMessage, javax.jms.ObjectMessage,
javax.jms.StreamMessage, or javax.jms.TextMessage. Since each of these
message types extends the javax.jms.Message interface, they must be of type
javax.jms.Message. If there is a custom message, it too should implement
javax.jms.Message interface, or any of the five standard message types.
What encryption options are there for sending messages through JMS?
Encryption is not handled by the JMS specification. It is left to the JMS provider to
implement and provide encryption and decryption of messages. These days, Progress
Software’s SonicMQ is a leading JMS provider and they have a robust encryption
mechanism called Quality of Protection. They also provide an SSL-related feature,
which also has build in encryption. Check out their documentation to see what they
do…
Is it possible to acknowledge individual messages on a queue without

affecting previously received, but as yet unacknowledged, messages?
Author: David Ben-Yaacov (http://www.jguru.com/guru/viewbio.jsp?EID=18017)
Question originally posed by Gordon Tyler
If you acknowledge a message, all previously received messages will also be

acknowledged. From the javax.jms.Message Javadoc, the acknowledge method will
"Acknowledge this and all previous messages received."
So the answer to your question is no, if what you meant by "affecting" is not-yet
acknowledged.
I suggest an alternative. You should look at javax.jms.QueueBrowser to review

queued messages. QueueBrowser has getEnumeration, which "Gets an enumeration
for browsing the current queue messages in the order they would be received".
Use user transactions.

2001
User transactions (as opposed to transacted sessions) address this issue nicely, and
give the added benefit of allowing JMS operations and a non-JMS operations to
combine into a single unit of work.
I want to use JMS for transfering data between two applications that are
not on the same host. Where can I find JMS providers (that is, JMS
implementations) for HTTP exchange, for file exchange, for socket
exchange?
Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7) Question
originally posed by jeanbaptiste_g jeanbaptiste_g
Check out SonicMQ. It supports different protocols like TCP/IP, HTTP, and SMTP, can
send XML messages, and supports multi-domain routing.
I want to use JMS for transfering data between two applications that are
not on the same host. Where can I find JMS providers (that is, JMS
implementations) for HTTP exchange, for file exchange, for socket
exchange?
Question originally posed by jeanbaptiste_g jeanbaptiste_g
Go to http://www.java.sun.com/products/jms/endorsements.html for listed JMS

provider. I have worked with Progress Software's SonicMQ and they have stuff you
need. Their developer edition is easily downloadable and good samples. Also, check
their FTP Bridge for file exchange.
Will a message published in a TopicSession using a TopicConnection be

received by a different TopicSession (in another JVM) via the
MessageListener if used? Or, is asynchronous message handling only
capable in the same JMS Session?
Author: Chris Dupuy (http://www.jguru.com/guru/viewbio.jsp?EID=40966) Question
originally posed by Dean Sheppard
The Session is a way of interacting with the JMS router, and providing transactional
support. It does not affect the delivery of messages on topics. You can use a session
to post a message to a topic, and still retrieve that message from a MessageListener
that is also registered with a session on the same topic regardless of JVM or location.
That is one of the benifits of JMS, it allwows distributed message processing, with a
variety of delivery options.
Is it possible to browse a topic? Or, is browsing only available on queues?
Author: Chris Dupuy (http://www.jguru.com/guru/viewbio.jsp?EID=40966) Question
originally posed by Dean Sheppard
The JMS specification does not define a way of browsing a topic, but it is really quite
simple: just subscribe to the topic using a non-transaction, non-durable subscriber.
You get the messages that are posted to the topic, but you do not affect delivery to
other subscribers. In a Queue there is a defined way of browsing, because looking at
or retriving messages from a queue could affect delivery to other clients.
Can I send persistent messages to a queue? The JMS 1.0.2 specification

says that the default message delivery mode is persistent. But when I send
messages using default mode I see messages are nonpersistent. Why is
that?
Author: Nick Minutello (http://www.jguru.com/guru/viewbio.jsp?EID=222214)
Question originally posed by Unknown User
You can indeed send persistent messages to a queue; however, whether it is

successfully persisted depends on how well the vendor followed the spec.
depends on the vendor

Author: Kiran Reddy (http://www.jguru.com/guru/viewbio.jsp?EID=553543), Nov
20, 2001
If you are using weblogic ...by default it has persistent. It should be same with others.
But make sure that you have a backing dbstore/file store .
Regarding a QueueBrowser, is it possible to associate a MessageSelector to

it?
Author: Nicholas Whitehead (http://www.jguru.com/guru/viewbio.jsp?EID=1260)
Question originally posed by Dean Sheppard
You create a queue browser using one of two API calls:
1. public QueueBrowser createBrowser(Queue queue)

This call will return a browser for all messages.
2. public QueueBrowser createBrowser(Queue queue, java.lang.String
messageSelector)
In this call, the messageSelector parameter allows you to associate a
message selector with the forthcoming browser.
However, there is no way (in the JMS spec) to associate a message selector with an
existing browser.
So there is no way to dynamically change the associated...

Author: Dean Sheppard (http://www.jguru.com/guru/viewbio.jsp?EID=14227), Feb 1,
2001
So there is no way to dynamically change the associated selector on a queue then.
QueueBrowser message selector

Author: warrell HARRIES (http://www.jguru.com/guru/viewbio.jsp?EID=318121),
Dec 21, 2001
Alas, whenever I set a MessageSelector for a QueueBrowser I get an invalid selector
exception even though the String works fine when I create a receive queue with it.
Anyone know why? It has held me up for a couple of hours but it doesn't affect my
app that much.....
How do I communicate between two clients that are on different machines

on a network using JMS? I want to use a standalone application for
communicating between the machine and I want to pass the message using
JMS.
Created: Feb 5, 2001 Modified: 2001-02-07 06:50:09.603
Question originally posed by satish nimje
You can make two JMS client applications, say AppA and AppB. Make AppA listen to
topic ‘forA’. Make AppB listen to topic ‘forB’.
If AppA sends a message to topic ‘forB’, AppB will receive it. If AppB sends a
message to topic ‘forA’, AppA will receive it.
For sample code etc, try downloading SonicMQ (as a JMS server) and go through the
samples.
The discussion here suggests a solution that uses ...

Author: Jef Newsom (http://www.jguru.com/guru/viewbio.jsp?EID=129583), Feb 20,
2001
The discussion here suggests a solution that uses pub/sub when the point-to-point
approach is probably more appropriate, considering that the 'requirements' were 'How
do I communicate between two clients that are on different machines on a network
using JMS? I want to use a standalone application for communicating between the
machine and I want to pass the message using JMS.' One-to-one messaging
relationships are best modeled with a queue. I would need to clarify 'stand-alone' and
'network' before being certain, but the question seems to suggest that Rajiv wants the
clients to communicate directly with each other, which is different than pub/sub.
Adding applets to the picture??

Author: E Babin (http://www.jguru.com/guru/viewbio.jsp?EID=825685), Jun 3,
2002
Slight variation to the problem proposed. Using applets (i know... client
requirement !!!) I need to both publish and subscribe to two diffrent topics. Think
of messaging applet where the "Controller" (one to many) would want to publish
the same messages to multiple listeners. And the listeners would want to publish
messages to one Controller (many to one). From what I've read, the JMS
publish/subscribe techniques would work well with this requirement. My thought
would be using JMS Topics, that is Controller writing to one Topic (with multiple
client subscribers). And Client subscibers writing to one topic (with one
Subscriber (Controller). I've worked throught several of the articles on how to do
this with a servlet in the middle, but I'm having trouble wrapping my head around
how to do the subscribe part of the picture... Would my Applet periodically
connect to the servlet and pull off the "queued" messages... What would be the
"speed" overhead from this approach. I know I could also go the "session-bean"
route, but I thought a JMS solution might be more efficient? This applet has the
requirement of having "near-realtime" turnaround.... That is if a new "message"
comes in, the system needs to notifify all of the listening clients? Thanks in
advace for thoughts... Eric...
Is there any relationship between javax.jms.Message and

javax.mail.Message?
Question originally posed by Ganesh Prasad
There is no direct relationship between javax.mail.Message and

javax.jms.Message. If your requirement is to map (correlate) them, here is what
you can do:
1. From JMS domain to JavaMail domain (a javax.jms.Message is received):

1. A JMS topic/queue can be associated with one or many e-mail id(s).
2. The JMS Message Header can be mapped to ‘custom’ JavaMail Message
Header.
3. The JMS Message Body can be associated with the JavaMail Message
body.
4. A JavaMail client application should be able to process these ‘custom’
headers and the content of the message body.
2. From JavaMail domain to JMS domain (a javax.mail.Message is received):
1. An e-mail id can be associated with one or more JMS topics/queues.
2. The JavaMail Message Header can be mapped to ‘custom’ JMS Message
Header.
3. The JavaMail Message Body can be associated with the JMS Message
body.
4. The JMS client application should be able to process these ‘custom’
headers and the content of the message body.
In a simple application that I tried, I removed the ‘custom’ header scenario and just
forwarded the contents of the message (text message), which worked without any
problems.
Try using SonicMQ bridges, which already has something like that.
Where can get JMS whitepapers?

Author: Jef Newsom (http://www.jguru.com/guru/viewbio.jsp?EID=129583)
Question originally posed by vasireddy kiran kumar
The authoritative whitepapers would be found at Sun JMS Docs

You might also check out TheServerSide's resource page as it sometimes contains
articles/whitepapers related to JMS.
Is there a way to to send a message.acknowledge() for each and every

message. The message.acknowledge() removes all the messages that have
been received by a QueueReceiver. But I need to acknowledge only the
messages that I want to, the remaining messages that have been received
by the receiver earlier has to stay in the JMSMessage table provided by the
JMS specification for persisting messages. I read many of the documents
that I found on web, but still not found out a way to acknowledge separate
messages?, is it possible?
Author: Doug Erickson (http://www.jguru.com/guru/viewbio.jsp?EID=1718)
Question originally posed by Stephen Bhadran
If you want to control message acknowledgment on a per-message basis, you

shouldn't consume another message until you've acknowledged the current one. It's
impossible to acknowledge a message without acknowledging all previously
consumed messages. For example, if you receive messages A, B, and then C, there's
no way to acknowledge C without acknowledging A and B as well.
Reconsider what you are trying to achieve. Other design alternatives include
message selectors or a dead message queue.
If you don't want to acknowledge earlier messages because they are not relevant to
you, don't consume them; use a message selector to get only the messages you care
about. If you're using queues, it is important to have another receiver to consume
these messages, or eventually the queue will back up.
If you don't want to acknowledge a message because processing failed, but you don't
want to stop processing subsequent messages, requeue the bad message in a "dead
letter" queue for manual intervention, acknowledge it, and move on to the next.
message.acknowledge() does not seem to be working correctly

Author: Amit Biswas (http://www.jguru.com/guru/viewbio.jsp?EID=1247087), Jun 3,
2005
We got a scenario where our process needs to send a message.acknowledge() on a
per-message basis. In order to do this, we are subscribing to the topic and dump these
messages in a blocking queue. A separate thread runs on this queue to process each
message individually and once succeeded, sends a message.acknowledge() to JMS.
But to our surprise, we found that, "next time" we ran our process, we see some old
JMS messages, that we received in previous run, are retrieved from JMS again. My
question is that isn't message.acknowledge() is not safe to use? Or are there any other
option we can persue.. Thanks in advance..
Is there a standard JMS way that works with all JMS providers to notify a
producer that there are new consumers subscribed? I found a way with my
SpiritWave provider to do that--I just wait for SubscribtionEvent, but I think
this will not work if I change to another JMS provider.
Question originally posed by Christoph Sawicki
No, there's not a standard way to do this at the JMS level.
Typically, a pub/sub system is designed specifically to decouple publishers from

subscribers, so that your publishers don't have any knowledge of the subscribers. If
your producers really need to know specifics about consumers, pub/sub might not be
the right model.
In practice, however, sometimes it's nice to know at least if anyone is out there
listening, so that you can save the overhead of message production. To be portable, I
think you'd have to implement your own mechanism to do this at the application
level.
I would like to know what is the format of a JMS message. If I should create
a JMS message without using javax.jms classes, how should I create this
message?
I'm using JMQ 2.0 to receive a JMS message, but suppose whoever sends
me a message can't use Java. So how should he write the message?
Question originally posed by Aesse Italia Aesse Italia
The JMS specification doesn't dictate a message format or interprocess

communication protocol for clients. These issues are left up to the vendors to
implement as they choose, and typically, vendors use a proprietary protocol and
format.
As a consequence, in order to use a vendor's message system, you have to use its
client software. In the case of JMQ, the client is available only in Java. There's no
way to connect to JMQ from another environment and send and receive messages.
JMS defines the interface that the vendor should present to your Java application.
The value here is that if you don't like, for example, JMQ, you can replace it with
another product that does support the functionality you need, without re-writing your
app.
Is it possible to send email messages using JMS?

Created: Apr 18, 2001
originally posed by sujatha ravi
JMS has no inherent support for email operations. Consider the JavaMail API.
SonicMQ links JMS and mail

Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7), Apr 19,
2001
See Are there any JMS implementations that utilize email under the covers for
interclient communication? for an answer.
Is JMS the right thing for simple asynchronous message passing? I want to
build a peer-to-peer network, where each node has only 2-5 connections.
They should be able to forward asynchronous messages. I assume that
installing a JMS provider on each single node would be too much for it,
because of the few connections. On the other hand, RMI is too simple,
especially because the asynchronism has to be implemented by threads.
Would it be a bad idea to install a JMS provider on each machine? Does
there exist a better way for message passing?
originally posed by Benedikt Voigt
Answer by Jerry Smith Re: Is JMS the right thing for simple asynchronous message
passing? Yes, JMS is a common solution. It is not necessary to have a participating
JMS server on each node. For this scenario, a single JMS server could provide the
message handling for all participating nodes. The JMS server could be located on one
of the nodes, or on a neutral network host/node.
Also consider using Jini event service, RIO events (above Jini) or JavaGroups
Author: anthony warden (http://www.jguru.com/guru/viewbio.jsp?EID=274895), Sep
11, 2002
See http://jini.org and http://www.javagroups.com/javagroupsnew/docs/index.html
The questions was about p2p - so having a central / single / non distributed JMS
server may not accord with the design philosophy stated.
How
Author: Arthur Chan (http://www.jguru.com/guru/viewbio.jsp?EID=1036721), Dec
11, 2002
Jerry, you said, "For this scenario, a single JMS server could provide the message
handling for all participating nodes. The JMS server could be located on one of the
nodes, or on a neutral network host/node."
May I ask how do you do this? Would you please be so kind to send me some sample
code of using JMS for p2p messaging? Many thnx.
Are there any JMS implementations that are optimized for mobile devices
such as Palm? (The only product I know is iBus//mobile from Softwired.)
originally posed by Sandro Dindo
At this time, I'm aware of no other implementations for mobile devices.

Mobile JMS Implementation

Author: Alex Kritikos (http://www.jguru.com/guru/viewbio.jsp?EID=457116), Jul 18,
2001
Check out Nirvana by my-channels, with the ability to run the server & client on
mobile devices such as the Compaq IPAQ
JMS for mobile devices

Author: James Knox (http://www.jguru.com/guru/viewbio.jsp?EID=575341), Dec 6,
2001
IBM has a product called MQ Everyplace which is designed for mobile devices
running Java. I've been using it for a couple of months and it looks pretty good. MQe
has a proprietary Java API, not JMS.
AshnaMQ for Mobile Messaging

Author: Rob Glance (http://www.jguru.com/guru/viewbio.jsp?EID=851615), Apr 23,
2002
AshnaMQ 2.0 Enterprise Edition comes with JMS implementation for Mobile
Devices of various configurations.
More info at http://www.ashnasoft.com
regards,
Rob Glance
Customer Support Engineer
Ashnasoft Corp
JMS/JNDI-Implementation for J2ME

Author: Frank Schlinkheider
(http://www.jguru.com/guru/viewbio.jsp?EID=1178040), Jun 11, 2004
Hello, see under http://www.jtom.de. There is a small JMS and JNDI-Implementation
for J2ME-Devices. You can use it for CLDC and CDC or PersonalJava to connect to
jboss etc. Regards Frank
How do you pass a file from a message producer to a consumer using JMS?
originally posed by krishna kumar
Answer by Josh Rayls

I believe the best way to do this would be to use an ObjectMessage. Simply store
your File object in the Message.
ObjectMessage msg = queue_session.createObjectMessage();

msg.setObject(your_file_object);
Upon consumption, just call the msg.getObject() method to return your File object.
Answer by Alessandro A. Garbagnati
Josh,
I'm not sure that passing the File object will work. The problem is that the File object
is just an "abstract representation of file and directory pathnames" (as stated by the
JDK documentation), and it does not contain the file itself. What if the file is not
located on the same system?
Your solution it's ok, just do not use java.io.File;
Answer by kunal khanna
I just used fileInput stream to read a file into a byte array,transmitted the array to a
queue. The consumer reads this byte array and writes it to another file. It runs very
well...
File message....with weblogic

Author: Kiran Reddy (http://www.jguru.com/guru/viewbio.jsp?EID=553543), Nov
20, 2001
I tried it with File Reader.I converted it to string and added it . This works fine. If
interested you may use this code... make sure you change the appriprite things to suit
you local setup. /* * $Author$ $Date$ * $Revision$ $RCSfile$ * Property of Equant
*/ package com.equant.csi.client; import java.io.*; import java.util.*; import
javax.transaction.*; import javax.naming.*; import javax.jms.*; /** * This program
shows how to establish a connection and send messages to the * JMS topic. The
classes in this package operate on the same topic. Run * the classes together with
OrderMDBean to observe message being sent and received. This * class is used to
send messages to * the topic. * * @author KiranReddy, OrderSystemsDevelopment
group */ public class OrderClient { /** * Defines the JNDI context factory. */ public
final static String JNDI_FACTORY="weblogic.jndi.WLInitialContextFactory"; /** *
Defines the JMS connection factory. */ public final static String
JMS_FACTORY="KiranConfFactory"; /** * Defines the topic. */ public final static
String TOPIC="kiranTopic"; protected TopicConnectionFactory tconFactory;
protected TopicConnection tcon; protected TopicSession tsession; protected
TopicPublisher tpublisher; protected Topic topic; protected TextMessage msg; /** *
Creates all the necessary objects for sending * messages to a JMS Topic. * * @param
ctx JNDI initial context * @param topicName name of topic * @exception
NamingExcpetion if problem occurred with the JNDI context interface * @exception
JMSException if JMS fails to initialize due to internal error * */ public void
init(Context ctx, String topicName) throws NamingException, JMSException
{ tconFactory = (TopicConnectionFactory) ctx.lookup(JMS_FACTORY); tcon =
tconFactory.createTopicConnection(); tsession = tcon.createTopicSession(false,
Session.AUTO_ACKNOWLEDGE); topic = (Topic) ctx.lookup(topicName);
tpublisher = tsession.createPublisher(topic); msg = tsession.createTextMessage();
tcon.start(); } /** * reads a message from the file . * * @params filename message to
be sent * @exception IOException if JMS fails to read message * */ public String
readTry() throws Exception { FileReader fr = new FileReader("OrderClient.java");
BufferedReader br=new BufferedReader(fr); String s=""; String kir="";
while((s=br.readLine()) != null) { kir=kir+""+s; } System.out.println(" Total String is
"+kir); return kir; } /** * Sends a message to a JMS topic. * * @params message
message to be sent * @exception JMSException if JMS fails to send message due to
internal error * */ public void send(String message) throws JMSException
{ msg.setText(message); tpublisher.publish(msg); } /** * Closes JMS objects. * *
@exception JMSException if JMS fails to close objects due to internal error */ public
void close() throws JMSException { tpublisher.close(); tsession.close();
tcon.close(); } /** * main() method. * * @param args WebLogic Server URL *
@exception Exception if operation fails */ public static void main(String[] args)
throws Exception { if (args.length != 1) { System.out.println("Usage: java
com.equant.csi.client.OrderClient WebLogicURL"); return; } InitialContext ic =
getInitialContext(args[0]); OrderClient ts = new OrderClient(); ts.init(ic, TOPIC);
readAndSend(ts); ts.close(); } /** * Prompts, reads, and sends a message. * *
@param ts OrderClient * @exception IOException if problem occurs during
read/write operation * @exception JMSException if JMS fails due to internal error */
protected static void readAndSend(OrderClient ts) throws IOException,
JMSException { //BufferedReader msgStream = new BufferedReader (new
InputStreamReader(System.in)); String line=null; //do { System.out.print("Enter
message (\"quit\" to quit): "); try { line =ts.readTry(); } catch(Exception e)
{ System.out.println("error while calling ts.readTry()"+e); } //line =
msgStream.readLine(); if (line != null && line.trim().length() != 0) { ts.send(line);
System.out.println("JMS Message Sent: "+line+"\n"); } // } while (line != null && !
line.equalsIgnoreCase("quit")); } /** * Get initial JNDI context. * * @params url
Weblogic URL. * @exception NamingException if problem occurs with JNDI
context interface */ protected static InitialContext getInitialContext(String url) throws
NamingException { Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
env.put(Context.PROVIDER_URL, url);
env.put("weblogic.jndi.createIntermediateContexts", "true"); return new
InitialContext(env); } }
Where can I learn (more) about CORBA (Common Object Request Broker
Architecture)?
Created: May 30, 2001
Check out the jGuru CORBA FAQ.
Where can I learn (more) about Java's EJB (Enterprise JavaBeans)?

Check out the jGuru EJB FAQ.
Where can I learn (more) about using JNDI (Java Naming and Directory
Interface)?
Check out the jGuru JNDI FAQ.
Where can I learn (more) about Java networking capabilities?

Check out the jGuru Networking FAQ.
Where can I learn (more) about Java's support for developing multi-
threaded programs?
Check out the jGuru Threads FAQ.
Where can I learn (more) about Java's support for transaction processing?
Check out the jGuru Transactions FAQ.
Where can I learn (more) about JCA (Java Connector Architecture)?

Check out the Sun's Java Connector Architecture homepage.
Does Tomcat support JMS (Java Messaging Service)?

Created: Sep 18, 2001
Author: Christopher Schultz (http://www.jguru.com/guru/viewbio.jsp?EID=138382)
Question originally posed by soma shekar
Alessandro A. Garbagnati writes:

Tomcat is just a servlet container, not an EJB container nor an application server, so
it does not contains any JMS basic support.
However, there's nothing stopping you from using another JMS provider (like
OpenJMS from within Tomcat.
-chris
JBossMQ
Author: Colin Bennett (http://www.jguru.com/guru/viewbio.jsp?EID=500093), Sep
19, 2001
I have used the open-source JBoss JMS server (JBossMQ) with Tomcat and it works
wonderfully. Easy to set up, sticks with the specs, powerful, fast, and open source.
Re: JBossMQ
Author: Frank Shen (http://www.jguru.com/guru/viewbio.jsp?EID=504656), Sep
26, 2001
I need to send a batch job request from the client to the server. This batch job will
run for hours. I don't want the client browser to be hanged. Is it a good situation to
use JMS. If so, can I cut off the network connection after the request has been
submitted? How do I do that?
Re[2]: JBossMQ
Author: Steve Lawton
(http://www.jguru.com/guru/viewbio.jsp?EID=1060438), May 13, 2004
JMS... err Batch job.. The information on the clients machine, should be
captured as a file. (presume you have said waiting file) The send on your
admin side for the client should have an action to send this file. Your servlet
should accept the single request of a file, and download it as one to the server,
(it wont stop the server). Or use JMS to send the file as one. If they have to be
recieved one at a time, then you have to wait.
Re[2]: JBossMQ
Author: Guido Medina (http://www.jguru.com/guru/viewbio.jsp?EID=1212409),
Nov 22, 2004
You dont need to use JMS to do that, less keep it simple, I already did that for a
different process (Oracle Batch Processes for the Dominican Republic Social
Security System), put a process manager in the context and using any data
structure (HashMap, Map, List, etc) control your Threads, you can have multi-
threading in the context and it works just perfect, my app also has an monitor for
the running process which you can kill (for DB was a statement.cancel() to do a
rollback) and with the data structure you avoid process duplication in case you
need it. Kind regards, Guido.
Re[3]: JBossMQ
Author: v konda (http://www.jguru.com/guru/viewbio.jsp?EID=1213241),
Nov 26, 2004
I need this functionality too. I was using OpenJMS but would like to avoid
if possible. What is a Process manager and how do you configure it in
Tomcat? Thanks.
Is it possible to integrate TIBCO system with EJB or, generally, with J2EE?
Is this done through the JMS-TIBCO connector? Is it possible to deploy EJB
directly on TIBCO?
Author: Jon Dart (http://www.jguru.com/guru/viewbio.jsp?EID=996845) Question
originally posed by Francesco Marchioni
TIBCO has a product called TIBCO Adapter for EJB that facilitates communication
between EJBs and services that use TIBCO's Rendezvous messaging system.
TIBCO also has a full-featured JMS implementation that can gateway JMS messsages
into and out of TIBCO Rendezvous.
You cannot deploy EJB directly on TIBCO, since TIBCO isn't a deployment platform
for EJBs.
anthony warden has also added the link to the TIBCO Enterprise for JMS, that
provides a standardized interface for enabling communications between J2EE-
compliant applications, Enterprise Java Beans, and application servers.
The integration with JBoss and weblogic is documented in the help files.

Java Message Service FAQ From Jguru

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Java Message Service FAQ From Jguru

Загружено:

Авторское право:

Доступные форматы

Java Message Service (JMS) FAQ From jGuru

Generated Sep 13, 2005 1:42:06 PM

What is message passing?

Message passing is a general term for a variety of strategies for high-level,

Are there other messaging frameworks that use Java technology?

Why is JMS important?

Second, JMS supports both synchronous and asynchronous message passing. In

A third important issue is that JMS supports an event-oriented approach to message

Where would I use JMS software?

JMS-based communication is a potential solution in any distributed computing

Comments and alternative answers

Is JMS an alternative to Enterprise JavaBeans (EJB)?

No. An Enterprise JavaBean implements arbitrary server-side functionality using a

What is the role of the JMS server? Why is it necessary?

The server, message broker, or whatever it is called, functions as an intermediary.

What else is missing from JMS?!

What software do I need in order to add JMS message passing to my

The second prerequisite is Java-based distributed applications, as opposed to

Is it possible to develop distributed applications with JMS alone? Is it

Comments and alternative answers

JMS and EJB's

Developing distributed application with JMS alone

The J2EE 1.3 server is a JMS provider.

Where can I find more information on JMS?

What's the JMS API like?

See the following introduction to Java Message Service.

Comments and alternative answers

What is point-to-point messaging?

With point-to-point message passing the sending application/client establishes a

What is publish/subscribe messaging?

With publish/subscribe message passing the sending application/client establishes a

Comments and alternative answers

Maybe my background is not fully up to date, but the...

How does JMS compare to peer-to-peer distributed computing?

Each JMS-enabled client must establish the following:

• A connection object provided by the JMS server (the message broker)

What are JMS messages?

JMS messages implement the Message interface.

The message body is available in five flavors:

TextMessage message = session.createTextMessage();

Note that some vendors provide additional message types.

Explain the terms broker, provider, and implementation with respect to

What is a JMS domain?

These two domains represent different communication strategies.

Does a JMS environment represent a client/server distributed system?

• Managing destinations, that is, queues and the topic hierarchy

What are administered objects?

The JMS specification does, however, define two administered objects:

• ConnectionFactory - A client uses this object to create a connection to the

Typically, a JMS server provide destination-level security, and, of course, JMS

Are messages thread-safe?

If the JMS specification required a thread-safe implementation for all objects, it

Session, on the other hand, is a single-threaded context that handles message-

What is a topic hierarchy?

Many publish/subscribe message systems support a tree-organized topic

The preferred method for handling interdependent messages is to produce them

Is it possible to use transacted sessions with other Java-technology,

Comments and alternative answers

The JMS spec allows for (optional) support of the JTA....

Can a client produce a message to multiple destinations, that is, to a list?

No. The specification does not support so-called subscription notification.

Are messages received in the order they were sent/published?