In this sample chapter, Brian Cavaness and Chuck Keeton cover the following topics: the components of the JMS architecture, two JMS message models, the JMS interfaces, details of a JMS message, message selection and filtering, the JMS Point-to-Point model, the JMS Publish/Subscribe model, synchronous versus asynchronous messaging, message persistence, using transactions with JMS, and using JMS with Enterprise JavaBeans.

This sample chapter is excerpted from Special Edition Using Enterprise JavaBeans 2.0, by Chuck Cavaness and Brian Keeton.

This chapter is from the book

This chapter is from the book

Introduction to Messaging

Messaging applications, or as they are sometimes called, Message Oriented
Middleware (MOM) products, have been used for quite some time. These
messaging products help applications that normally are not connected to one
another structurally communicate with each other. In applications that
aren't using a messaging product, this communication might be performed
using sockets, RMI, or in various other ways. A few problems are associated with
communicating between applications using one of these approaches.

One of the problems is that each side involved in the communication might
have direct knowledge about one another. Each side is aware of the other with
respect to the transport protocol and other low-level details. This knowledge is
known as a tight coupling. It would be more flexible if the two sides
weren't so tightly coupled. This way, if something changed on either side,
the other side might not be affected. Another problem is that it's hard to
perform asynchronous messaging with sockets or RMI. Asynchronous
communication is where a response is not immediately expected or returned. The
alternative approaches just mentioned, such as sockets or RMI, are types of
synchronous communication.

Message-oriented middleware can help reduce the coupling and complexity of
allowing applications or components to communicate with one another
asynchronously. It's also designed to help interoperability between
applications, which is very important when building enterprise applications.

What Is Message-Oriented Middleware?

Message-oriented middleware was designed to decouple the applications or
components and allow them to communicate with one another by exchanging messages
asynchronously. These messages can be things such as event notifications,
application data, request for services, or even objects. Any type of information
that needs to be communicated from one application to another is done by passing
a message to the receiving system. As you'll see later in this chapter,
various types of messages can be passed from one application to another.

Although messages generally can be sent in either direction, certain names
are given to the application or component that is sending or receiving a
message. The component that creates or produces a message is referred to as a
producer. The application or component that receives a message is called
a consumer. It's possible for an application to be both a producer
and a consumer of messages, but for a given transfer of information, one side
must produce the message and another side must consume it. A benefit of
separating the producing and the consuming of messages is that the producer and
consumer only really need to agree on the format of the message. Each side
doesn't need to worry about how the message is transported. To make this
possible, a message is not sent directly from a producer to the consumer. As
we'll see later in this chapter, how it makes its way to the consumer
depends on which type of messaging model you choose for your application. Figure 10.1 illustrates a generic messaging scenario.

Figure 10.1 An application communicating through messaging contains a
producer and a consumer.

Java Message Service as a Message-Oriented Middleware

Although the EJB 2.0 Specification does not cover messaging, it is part of
the Java Message Service (JMS) specification and is so fundamental to the
Enterprise JavaBeans API that it would be deficient not to cover it in any
serious discussion on the subject. Because many enterprise applications will use
some level of messaging, it's a good idea to understand the concepts. You
also will need to be familiar with the Java Message Service (JMS) APIs before
understanding the new message-driven bean that has been added to the EJB 2.0
Specification.

→See "Message-Driven Beans," p. 315 for more
information on the new enterprise bean added to EJB 2.0.

Differences Among JMS Implementations

Another important fact should be pointed out. JMS is not an implementation of
a message-oriented middleware. In fact, it's really nothing more than a
specification for describing how messages should be produced and consumed in a
Java enterprise application. By itself, it provides no functionality. As with
other APIs that we have already discussed, the API or interfaces are separate
from the implementation. This gives the benefit of describing in detail what the
user view should be, while at the same time allowing vendors to implement the
details however they want. As long as the vendor adheres to the JMS
specification, a user shouldn't have to worry too much about how the
implementation is constructed. The point of hiding the implementation from the
client and exposing only the JMS APIs is to hide the details from the users that
want a higher-level API and also to ensure portability among
implementations.

If a vendor implements the JMS specification and adheres to it completely,
there is typically no problem developing portable JMS applications and switching
between vendors. As with the rest of the specifications in the Java 2Enterprise Edition (J2EE), JMS has a version number that identifies that
current release of the specification. The current JMS specification is 1.0.2. If
you write an application based on this or any newer specification, you must
ensure that the vendor whose JMS implementation you are using adheres to this
level of the specification. You can download the latest JMS specification at the
following URL:

http://java.sun.com/products/jms

Many vendors provide an implementation for the JMS specification. Some are
included along with a complete or partial implementation of the entire J2EE
suite of technologies. Table 10.1 is a list of vendors who provide a commercial
implementation of the JMS specification.

Table 10.1 Vendors Who Provide a Commercial JMS Implementation

Name

URL

JRUN Server

http://www.allaire.com

BEA Systems, Inc.

http://www.beasys.com

Fiorano Software

http://www.fiorano.com

GemStone

http://www.gemstone.com

IBM

http://www-4.ibm.com

Nirvana

http://www.pcbsys.com

Oracle

http://www.oracle.com

Orion

http://www.orionserver.com

Progress Software

http://www.progress.com

SAGA Software, Inc.

http://www.sagasoftware.com

SoftWired Inc.

http://www.softwired-inc.com

Sun (Java Message Queue)

http://www.sun.com

SpiritSoft, Inc.

http://www.spirit-soft.com

Sunopsis

http://www.sunopsis.com

SwiftMQ

http://www.swiftmq.com

Venue Software

http://www.venuesoftware.com

There are also several open-source JMS projects. Table 10.2
lists a few of them.

Table 10.2 Partial List of Open-Source JMS Projects

Name

URL

ObjectCube, Inc.

http://www.objectcube.com

OpenJMS

http://openjms.exolab.org

ObjectWeb

http://www.objectweb.org

Many other vendors endorse the JMS API. The following URL
provides a more exhaustive listing: