Introduced in the Enterprise JavaBean 2.0 specification, the message-driven
bean is a type of Enterprise JavaBean that uses asynchronous communication.
Message-driven beans are based on the Java Message Service (JMS) architecture
and require an understanding of JMS prior to writing message-driven bean
applications. This chapter focuses on Java Message Services, beginning with a
brief review of messaging concepts. Specifically, this chapter provides

an introduction to JMS

a review of the JMS architecture and messaging domain

the JMS programming API

JMS and its relation to EJBs

Broadly speaking, messaging is the exchange of information between two
separate and independent entities distributed over a network such as a local
area network (LAN), a wide area network (WAN), or a wireless network. Messaging
entities can be either humans or applications. E-mail is an example of a
messaging system that allows human-to-human exchange of messages, while the
messaging middleware enables two or more client applications to communicate by
sending and receiving messages in a distributed environment without any human
intervention.

With messaging middleware, clients use the peer-to-peer communication model,
according to which clients can either produce or consume messages. There's
no distinction between consumer and producer. In fact, a client may be a
producer, a consumer, or both simultaneously. Producer clients produce messages;
consumer clients consume the messages as shown in Figure 12-1.

Messaging Oriented Middleware (MOM) messaging systems have been around since
the 1970s (including IBM's MQSeries, Microsoft's MSMQ, and
Tibco's Rendezvous), and businesses have used them extensively, from
exchanging messages between incompatible systems to managing B2B
(business-to-business) exchanges processes with global partners.

Introduction to Java Message Service

JMS, like JDBC and JNDI, isn't a product, but rather a Java specification
for messaging middleware from Sun and its partners. JMS defines an enterprise
messaging Java API that makes it easy to write business applications that can
exchange business data and events asynchronously and reliably in a vendor-agnostic
manner. The messaging server vendors provide the service provider interface
that supports the standard JMS API (see Figure
12-2). JMS is required in the J2EE 1.3 specification and is supported by
several different vendor-generated enterprise messaging products.

The JMS specification was written by Sun Microsystems and its partners, many
who already had proprietary messaging middleware, resulting in the combination
of "best of the breed" features from existing proprietary messaging
middleware. One objective of JMS is to minimize the learning curve for writing
messaging applications and to maximize the portability of messaging
applications. As a result, JMS applications are easier to write and highly
portable and support both the P2P and pub/sub messaging models.

Prior to JMS, programmers had to go through a steep learning curve to learn
the complex proprietary APIs of the specific messaging serverthis made
writing messaging applications difficult and resulted in minimal portability.
Additionally, messaging servers from different vendors weren't
interoperable in most cases, and businesses weren't happy with vendor
lock-in and high cost of the product and support. Adoption of JMS in businesses
is being driven by the following:

wide industry supportBecause it's easy to implement the
JMS specification in existing messaging servers, JMS is the first enterprise
messaging API that has garnered wide industry support and, as a result, has
become the messaging standard.

interoperabilityJMS leverages the existing messaging systems
and is widely supported in many messaging products. For example, a client
application using MQSeries as the JMS provider can communicate with another
client application using the Rendezvous JMS provider. JMS clients can
interoperate fully with non-JMS clients, an important consideration for
businesses having proprietary applications.