What Is the JMS API?
The JMS is a Java Application Programming Interface (API),
which allows software applications, components, and objects to
create, send, receive, and read messages. Sun Microsystems is a
JMS vendor that markets an iPlanet product, but Sun designed and
developed JMS specifications in collaboration with JMS vendors,
not by itself. Sun also provides developers with reference
implementations to test and apply specifications to your
projects. In this book, I will use the JMS API Reference
Implementation bundled with the Java 2 Platform Enterprise
Edition (J2EE) version 1.3 or later to test sample applications
instead of commercial JMS products. If you need more information
about JMS products, refer to Appendix C, "Java Message Service
(JMS) API Vendors." The JMS API enables communication that:
-
Is loosely coupled
-
Is asynchronous, which means that a JMS server delivers a
message to the client, but the client does not have to read
immediately
-
Is reliable, which means that a JMS server ensures that a
message is delivered once and only once
Point-to-Point and Publish-and-Subscribe Messaging
As mentioned in the previous chapter, there are two major
messaging types: point-to-point (p2p or PTP) and
publish-and-subscribe (pub/sub). They are the fundamentals of
MOM and are supported by JMS specifications. (JMS vendors are
not required to support both types of messaging, although many
of them do.)
Recall that in p2p messaging, the domain (or destination) is
called a queue (see Figure 5.2). The
sender sends the message to the queue, and the receiver
(recipient) takes (or reads) the message from the queue whenever
it is ready. Although this seems like peer-to-peer, there can be
two or more senders for the same queue.
Figure 5.2
The p2p messaging service.
This queue is stored in the messaging server or in a
relational database if data persistence is required. JMS does
not ban using direct messaging, but it uses a queue for p2p
messaging.
A human resource application that sends a message to the
accounting application about annual salary increases for workers
in a factory plant in Wisconsin is an example of p2p
messaging.
In the pub/sub messaging type, a messaging domain
(destination) is called a topic, a sender is called a publisher,
and a receiver is called a subscriber (see Figure 5.3).
Publishers send the message to a topic. Subscribers receive all
of the messages sent to that topic as long as they subscribe to
the topic. In this model, there are one or more publishers and
receivers. If one publisher sends a message to the topic, all
subscribers receive a copy of the same message. You might need
to use this messaging model to notify a group of applications
using the same message. An example of the pub/sub messaging
model is when a production application sends a message to a
NewProduct topic, and subscribers to the NewProduct
topic, such as a sales application and a marketing application,
receive this message.
This model supports multiple senders and receivers, and
applications do not need to act together. Senders called
publishers send (publish) their messages at different times,
independently from other senders to the topic. Receivers called
subscribers also read (subscribe) the messages from the topic,
independently from other receivers.
Figure 5.3
The pub/sub messaging service.
The JMS API and the J2EE Platform
Sun first released the JMS API in 1998. Its main purpose was
to allow Java applications to work with MOM-based products.
Because it was found very useful, many MOM vendors adopted and
implemented the JMS API. In version 1.2 of the J2EE platform,
vendors were not required to implement the JMS API. It was an
add-on product, and vendors had to provide a JMS API interface.
With version 1.3 of the J2EE platform, the JMS API is an
integrated part of the platform. J2EE certified vendors,
including Sun Microsystem's own application server product,
"iPlanet," must support the JMS API. The JMS API in the J2EE
platform version 1.3 has some valuable features:
-
Enterprise JavaBeans (EJBs) or an enterprise Web component
can create, send, and synchronously receive a message.
-
Message-driven beans, which are new enterprise beans included
with version 1.3 of the J2EE platform, allow asynchronous
messaging.
-
Messages that are sent and received can participate in Java
Transaction API (JTA) transactions.
Additionally, EJB container architecture provides support for
distributed transactions and allows for the concurrent
consumption of messages.
The JMS API makes developing enterprise applications easier
for developers and allows loosely coupled, synchronous and
asynchronous, reliable communications and interactions between
J2EE components and other applications capable of messaging. You
can develop enterprise applications with new message-driven
beans for specific business events in addition to the existing
business events.
Another technology, the J2EE Connector, exists within the
J2EE platform version 1.3, and it provides tight integration
between Java enterprise applications and enterprise information
systems (EIS). The JMS API is different from connector
technology because it provides loosely coupled interaction
between J2EE applications and database servers or information
application servers (IAS).
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
