MOM Player: JAVA MESSAGING SERVICE
Message Service (JMS) defines a standard API that
allows Java developers to easily build enterprise
applications. A overview of this technology
opposed to regular request/reply based communication
in traditional client/server systems, messaging
provides more flexibility and scalability
software solutions require a fast, reliable and
scalable link between broad variety of newly developed
legacy applications and data sources. Communication
in this loosely coupled environment is made possible
by a specific type of middleware called MOM. The
process of integrating an application with other
applications which are not meant for Internet is
a daunting task.
Messaging for large organizations has been via EDI
or proprietary messaging middleware products like
IBM MQ Series and TIBCO RV. Both are difficult to
configure and maintain with high overheads.
Asynchronous messaging is a proven communication
model for developing large-scale, distributed enterprise
applications. As opposed to regular request/reply
based communication in traditional client/server
systems, messaging provides more flexibility and
scalability because senders and receivers of messages
are de-coupled and are no longer required to execute
The Java Message Service (JMS) defines a standard
API that allows Java developers to easily build
enterprise applications. JMS is important in its
own right because it provides a simplified and common
way for Java clients to access message-oriented
middleware. More importantly, JMS is tightly integrated
into J2EE and is the messaging standard for Enterprise
Java Beans (EJB).
From an application design perspective, message-based
application design can be categorized into three
1. Point-to-point messaging: Point-to-point design
is a many-to-one paradigm, where many clients can
send messages to a single client. The same client
can be a sender, receiver, or both sender and receiver.
The working of this communication in JMS is based
on the concept of a "queue." Senders put
messages into a queue and receivers take messages
out. The queue has optional persistence built in
to save the messages. The working can be compared
to an e-mail. Many people can send e-mails to your
address and you retrieve them one after the other
from the mailbox. The mail server stores the e-mails
until they are retrieved.
2. Publish-subscribe messaging: Publish-subscribe
messaging is a many-to-many paradigm. It is the
design used when we want multiple applications/clients
to receive the same message or when a group of applications
want to notify each other. It is like multiple listeners
attached to a component. In a JMS message, publishers
send messages to a topic, and subscribers receive
messages sent to the topic. There can be multiple
senders and multiple receivers. The application
can again be both a sender and a receiver.
3. Request-reply messaging: Request-reply messaging
refers to the design wherein an application sends
a message and expects a reply to that message from
the receiver. This is a feature rather than a separate
design because a point-to-point or publish-subscribe
design could also be request-reply based.
doesn't explicitly support request-reply messaging,
but allows the use of a "reply to" field
in the message. A program can reply to a message
by checking this field. This response is optional
and left for the client to decide.
Another way of doing this is to create a new queue
say, 'acknowledge-queue' to which the client will
send an acknowledgement. The requester can retrieve
the acknowledgements from this queue.
What is Java Messaging Service API?
The Java Message Service is an API defined by Sun
Microsystems. The purpose of JMS is to provide a
unified Java-based API to all messaging middleware
systems. Developers that use JMS are thus able to
write client applications without too much concern
about the ultimate message middleware that the clients
are going to use. Also, the message system can be
replaced with no or few client modifications. JMS
follows a Hub and Spoke Topology. In a Hub and Spoke
architecture all the applications are connected
to a central process called a message server. The
message server handles all communication between
connected applications called clients. The message
server is responsible for routing messages correctly,
authenticating and authorizing
user access and guaranteeing the delivery of the
messages. Each application
client can be a sender, a receiver or both.
supports a point-to-point model and a publish/subscribe
model, and it defines a number of message types
that publishers and subscribers can exchange. Messages
support properties that define how they should be
treated by the message system. Subscribes can filter
messages using an SQL grammar. Clients can be transient
or durable and messages can be sent or received
in the context of a transaction.
The JMS is a client API. It only defines how a Java
client accesses the messaging capabilities of an
enterprise messaging system. Other important aspects
of a messaging system including administration and
security are not defined by JMS. Each JMS vendor
is expected to give support for administration of
the messaging system using proprietary methods and
The Concept behind JMS
Fig 2 shows the main concepts in JMS. Although publish/subscribe
and point-to-point communication models are very
different from a conceptual viewpoint, the models
have a lot in common. JMS is therefore centered
on a generic messaging model and publish/subscribe
and point- to-point models are derived (in the sense
of interface inheritance) from the generic model.
The typical steps that a JMS developer performs
when developing a client applications are:
1. Resolve a connection factory and a destination
from JNDI. A destination is either a queue or a
2. Create a connection using the connection factory.
3. Create a session with the desired properties
from the connection.
4. If the application is a supplier, create a MessageProducer;
if the application is a consumer, create a MessageConsumer
from the session.
5. Start to send or receive messages using the producer
or consumer object. A producer will use the session
to create different kinds of messages.
supports six different kinds of messages, which
are used to carry different types of payload/data.
The header of a message is the same regardless of
payload, which means filtering is same for all six
different message types. A message supports number
of properties to set priority, reliability and other
QoS properties, which will be interpreted and handled
by JMS. In order to properly support durable messages,
JMS uses the notion of a durable subscriber. This
is only necessary in the publish/subscribe model
as messages on a queue will be consumed by any queue
receiver that connects to the queue in question.
A durable subscriber is identified by a name and
the same operation is conveniently used to both
create and re-create the subscriber.
JMS, like other Java enterprise APIs, is interface-based
and consists of two parts: the client interfaces
that the application programs use and the provider
that implements the services. The provider can use
any underlying mechanism it chooses. In JDBC, for
example, applications use the client interfaces
and the driver provides implementations using anything
ranging from raw sockets to a SQLnet protocol.
The JMS implementation of point-to-point and publish-subscribe
paradigms uses these same fundamental concepts,
but has specialized classes to handle them. The
architecture consists of a common set of base interfaces
and at least two sub interfaces for each base interface-one
for the point-to-point model, the other for the
What are Administered Objects?
An administered object is an object that the application
program retrieves from the JNDI context and works
with as though it were a local object. The application
administrator uses a vendor provided tool or mechanism
to configure these objects. This is similar to the
way long-distance telephone carriers work. The phone
company can configure the administered "carrier"
object as BPL or MaxTouch for example. To the client,
the call will work the same way (until the bills
come!) and he doesn't have to buy a new telephone
set every time he changes his mobile plan.
What is the Destination Interface?
Destinations represent an abstraction of a message
delivery or endpoint. The Destination interface
is used by the provider to define the location where
messages are delivered; the provider will decide
the underlying implementation mechanism. The clients
never see the details but, this interface works
with the sub interfaces javax.jms.Queue and javax.jms.Topic,
depending on the message style. The Destination
is an administered object.
Getting connection to a Provider: The ConnectionFactory
is an abstraction used to encapsulate the specifics
of connecting to a JMS provider from an application.
The task of a ConnectionFactory is to create a provider-specific
connection to the JMS. This is similar to how the
driver manager (java.sql.DriverManager) works in
JDBC. The application programmer need only connect
with the database-specific driver which returns
a connection to the database. The ConnectionFactory
is an administered object
Client connecting to a Provider: Depending on the
messaging style chosen, the connections are created
differently from the ConnectionFactory. However,
all connections have to implement the Connection
interface and thus methods standard to all JMS connections.
A connection should be closed when the program is
done using it.
The JMS Session: One of the connection's main jobs-to
create sessions-is hidden in its implementation.
A session in JMS is single-threaded, which means
that any message sending and receiving happens in
a serial order, one after the other. For example,
if A and B sent C four messages each simultaneously,
the session ensures that C is notified one at a
time. Although notification is synchronized, it
may occur in a different thread from the one that
created the session if the program uses the MessageListener
(discussed later). Sessions can also provide a transactional
context. This context stores messages for delivery
until the transaction is committed, in which case
all the messages are considered a single atomic
unit. If the transaction is rolled back, then all
messages are destroyed and the session returns to
its initial state.
Non-Transacted Session: There are 3 types of Non-transactional
sessions AUTO_ACKNOWLEDGE (The session automatically
acknowledges a client's receipt of a message), CLIENT_ACKNOWLEDGE
(The client acknowledges a message explicitly by
invoking the acknowledge() method in the message)
and DUPS_OK_ACKNOWLEDGE (This acknowledgement mode
instructs the session to acknowledge the delivery
Sending a message: To send a message to a destination,
a client application must ask the session to create
a message producer. The message producer has to
implement the javax.jms.MessageProducer interface.
The MessageProducer is used to get and set default
values that are stored in the message when it is
sent. The producer needs to be closed once the work
MessageConsumer: Message consumers are created by
the session for clients that want to receive messages.
Message consumers are attached to a destination
and are designed to retrieve messages sent
to those destinations. Just like
other interfaces, depending on
the messaging style, the javax.jms.QueueReceiver
or javax.jms.TopicSubscriber are used.
Messages: The message consists of the header, the
properties, and the body. A message is the actual
data sent from the sender to the receiver. Again,
although the object implementation is provider-specific,
a message implements the javax.jms.Message interface.
Message Selectors and Message Filters: In an enterprise
environment, a destination may require filtering
on business rules. For example, a Bank-Teller object
listening for Bank-Account objects as messages may
be required to do something only when the account
balance is below $3,000. To support filtering, JMS
provides the concept of a selector. A selector is
a SQL92 string that is passed to the message consumer.
The client can use the selector to decide if the
message is of interest. The selector cannot reference
the contents of the message but it can access the
properties and headers. Some examples of selectors
are: amount between 300 and 3000, area code like
'333'. From the client's perspective, messages that
don't meet the selection criteria simply don't exist.
Message Persistence in JMS: Persistence is the ability
of the provider to store messages. The client can
mark a message as Persistent if it is crucial, and
the provider will store this message until it is
delivered to the recipients. A message marked as
non-persistent may be lost in the delivery process
and should only be used for non-crucial messages.
Though persistent messages are more reliable, they
take up more storage space. Non-persistent messages
are ideal for non-crucial tasks where the application
is not affected by delivery failure (such as log
Message Time-To-Live: A client can specify a time-to-live
value in milliseconds for each message it sends.
It is up to the provider to "expire" the
message or to ignore this property.
Distributed Transactions in JMS
In addition to supporting transactions in the session,
JMS provides support for distributed transactions
by using Java Transaction API (JTA). Developers
can choose between using JMS without JTA or with
JTA by using the separate classes provided with
the XA prefix (few of the classes are XAQueueConnectionFactory,
XATopicConnectionFactory, XAQueueConnection, XATopicConnection,
XAQueueSession , XATopicSession ).
JMS-based communication is a potential solution
in any distributed computing scenario that needs
to pass data, not references, either synchronously
or asynchronously, between application components.
It offers a good solution for business integration
in heterogeneous environments and for connecting
to legacy systems. For example, an enterprise computing
strategy can use JMS-based distributed software
components as a middleware solution that functions
as a bridge among legacy applications. A common
application for JMS involves interfacing Enterprise
JavaBeans with legacy applications and sending legacy-related
data between the two.
When working with JMS, we have quite a few architectural
choices and application design factors to consider.
If we are working with distributed objects, our
choices are usually narrowed down to using RMI,
RMI over IIOP, or JMS. JMS may provide advantages
over these other techniques, but when using JMS
many factors (such as performance, load balancing,
and clustering) depend on which provider and underlying
implementation you choose.
Ajay Barvey is a Senior Programmer with Plexus Technologies
and can be reached at email@example.com