Java Message Service
1
Preface
What Is the Java Message Service?
When Java™ was first introduced, most of the IT industry focused on its graphical user
interface characteristics and the competitive advantage it offered in terms of distribution
and platform independence. Today, the focus has broadened considerably: Java has been
recognized as an excellent platform for creating enterprise solutions, specifically for
developing distributed server-side applications. This shift has much to do with Java's
emerging role as a universal language for producing implementation-independent
abstractions for common enterprise technologies. The JDBC™ API is the first and most
familiar example. JDBC provides a vendor-independent Java interface for accessing SQL
relational databases. This abstraction has been so successful that it's difficult to find a
relational database vendor that doesn't support JDBC. Java abstractions for enterprise
technologies have expanded considerably to include JNDI (Java Naming and Directory
Interface™) for abstracting directory services, JMX (Java Management Extensions) for
abstracting access to computer devices on a network, and JMS™ (Java Message Service)
for abstracting access to different Message-Oriented Middleware products.
JMS has quickly become a de facto industry standard. In its second version, most
enterprise messaging vendors now support the JMS specification, making for a large
selection of JMS providers to choose from.
The Java Message Service is a Java API implemented by enterprise messaging vendors to
provide Java applications with a common and elegant programming model that is portable
across messaging systems. Enterprise messaging systems are used to send notification of
events and data between software applications. There are two common programming
models supported by the JMS API: publish-and-subscribe and point-to-point. Each model
provides benefits and either or both may be implemented by JMS providers.
JMS and enterprise messaging systems provide Java developers with an asynchronous
messaging system that allows systems to interact without requiring them to be tightly
coupled. Messages can be delivered to systems that are not currently running and
processed when it's convenient. The decoupled, asynchronous characteristics of enterprise
messaging make JMS an extremely powerful and critical enterprise API. JMS is used by
Java developers in Enterprise Application Integration, Business-to-Business (B2B)
projects, and distributed computing in general.
As JMS quickly moves into the forefront as one of the most important J2EE technologies,
understanding how JMS works and when to use it will become the hallmark of the most
successful distributed computing professionals. Choosing to read this book to learn about
JMS may be one of the smartest career moves you ever make.
Who Should Read This Book?
This book explains and demonstrates the fundamentals of the Java Message Service. This
book provides a straightforward, no-nonsense explanation of the underlying technology,
Java classes and interfaces, programming models, and various implemenations of the JMS
specification.
Java Message Service
2
Although this book focuses on the fundamentals, it's no "dummy's" book. While the JMS
API is easy to learn, the API abstracts fairly complex enterprise technology. Before
reading this book, you should be fluent with the Java language and have some practical
experience developing business solutions. Experience with messaging systems is not
required, but you must have a working knowledge of the Java language. If you are
unfamiliar with the Java language, we recommend that you pick up a copy of Learning
Java™ by Patrick Neimeyer and Jonathan Knudsen (O'Reilly). If you need a stronger
background in distributed computing, we recommend Java™ Distributed Computing by
Jim Farley (O'Reilly).
Organization
Here's how the book is structured. The first chapter explains messaging systems,
centralized and distributed architectures, and how and why JMS is important. Chapter 2
through Chapter 5 go into detail about developing JMS clients using the two messaging
models, publish-and-subscribe and point-to-point. Chapter 6 and Chapter 7 should be
considered "advanced topics," covering deployment and administration of messaging
systems. Chapter 8 is an overview of the Java™ 2, Enterprise Edition (J2EE) with regard
to JMS, including coverage of the new message-driven bean in Enterprise JavaBeans 2.0.
Finally, Chapter 9 provides a summary of several JMS vendors and their products.
Chapter 1
Defines enterprise messaging and common architectures used by messaging vendors.
JMS is defined and explained, as are its two programming models, publish-and-
subscribe and point-to-point.
Chapter 2
Walks the reader through the development of a simple publish-and-subscribe JMS
client.
Chapter 3
Provides a detailed examination of the JMS message, the most important part of the
JMS API.
Chapter 4
Examines the publish-and-subscribe programming model through the development
of a B2B JMS application.
Chapter 5
Examines the point-to-point programming models through the enhancement of the
B2B JMS application developed in Chapter 4.
Java Message Service
3
Chapter 6
Provides an in-depth explanation of advanced topics, including guaranteed
messaging, transactions, acknowledgments, and failures.
Chapter 7
Provides an in-depth examination of features and issues that should be considered
when choosing vendors and deploying JMS applications.
Chapter 8
Provides an overview of the Java™ 2, Enterprise Edition (J2EE) with regard to JMS,
and also includes coverage of the new JMS-based bean in Enterprise JavaBeans 2.0.
Chapter 9
Provides a summary of several JMS vendors and their products, including: IBM's
MQSeries, Progress' SonicMQ, Fiorano's FioranoMQ, Softwired's iBus, Sun's JMQ,
BEA's WebLogic, and Exolab's OpenJMS.
Appendix A
Provides a quick reference to the classes and interfaces defined in the JMS package.
Appendix B
Provides detailed information about message headers.
Appendix C
Provides detailed information about message properties.
Appendix D
Provides detailed information about message selectors.
Software and Versions
This book covers the Java Message Service Version 1.0.2. It uses Java language features
from the Java 1.1 platform. Because the focus of this book is to develop vendor-
independent JMS clients and applications, we have stayed away from proprietary
extensions and vendor-dependent idioms. Any JMS-compliant provider can be used with
this book; you should be familiar with that provider's specific installation, deployment, and
runtime management procedures to work with the examples. To find out the details of
installing and running JMS clients for a specific JMS provider, consult your JMS vendor's
documentation; these details aren't covered by the JMS specification.
Java Message Service
4
Examples developed in this book are available through the book's catalog page at
http://www.oreilly.com/catalog/javmesser/examples. The examples are organized by
chapter. Special source code modified for specific vendors is also provided. These vendor-
specific examples include a readme.txt file that points to documentation for downloading
and installing the JMS provider, as well as specific instructions on setting up the provider
for each example.
Conventions
Italic is used for filenames, pathnames, hostnames, domain names, URLs, email addresses,
and new terms where they are defined.
Constant width is used for code examples and fragments, class, variable, and method
names, Java keywords used within the text, SQL commands, table names, column names,
and XML elements and tags.
Constant width bold is used for emphasis in some code examples.
Constant width italic is used to indicate text that is replaceable.
The term "JMS provider" is used to refer to a vendor that implements the JMS API to
provide connectivity to their enterprise messaging service. The term "JMS client" refers to
Java components or applications that use the JMS API and a JMS provider to send and
receive messages. "JMS application" refers to any combination of JMS clients that work
together to provide a software solution.
Comments and Questions
We have tested and verified the information in this book to the best of our ability, but you
may find that features have changed (or even that we have made mistakes!). Please let us
know about any errors you find, as well as your suggestions for future editions, by writing
to:
O'Reilly & Associates, Inc.
101 Morris Street
Sebastopol, CA 95472
(800) 998-9938 (in the United States or Canada)
(707) 829-0515 (international or local)
(707) 829-0104 (fax)
We have a web page for this book, where we list errata, examples, or any additional
information. You can access this page at:
http://www.oreilly.com/catalog/javmesser/
To comment or ask technical questions about this book, send email to:
bookquestions@oreilly.com
Java Message Service
5
For more information about our books, conferences, software, Resource Centers, and the
O'Reilly Network, see our web site at:
http://www.oreilly.com
Richard Monson-Haefel maintains a web site for the discussion of JMS and related
distributed computing technologies (http://www.jMiddleware.com). jMiddleware.com
provides news about this book as well as code tips, articles, and an extensive list of links to
JMS resources.
David Chappell hosts a similar site, the SonicMQ Developers Exchange, which can be
found at http://www.sonicmq.com/developers/.
Acknowledgments
While there are only two names on the cover of this book, the credit for its development
and delivery is shared by many individuals. Michael Loukides, our editor, was pivotal to
the success of this book. Without his experience, craft, and guidance, this book would not
have been possible.
Many expert technical reviewers helped ensure that the material was technically accurate
and true to the spirit of the Java Message Service. Of special note are Joseph Fialli, Anne
Thomas Manes, and Chris Kasso of Sun Microsystems, Andrew Neumann and Giovanni
Boschi of Progress, Thomas Haas of Softwired, Mikhail Rizkin of International Systems
Group, and Jim Alateras of ExoLab. The contributions of these technical experts are
critical to the technical and conceptual accuracy of this book. They brought a combination
of industry and real-world experience to bear, and helped to make this the best book on
JMS published today.
Thanks also to Mark Hapner of Sun Microsystems, the primary architect of Java 2,
Enterprise Edition, who answered several of our most complex questions. Thanks to all the
participants in the JMS-INTEREST mailing list hosted by Sun Microsystems for their
interesting and informative postings.
Java Message Service
6
Chapter 1. Understanding the Messaging Paradigm
Computers and people can communicate by using messaging systems to exchange
messages over electronic networks. The most ubiquitous messaging system today is email,
which facilitates communication among people. While email is an important human-to-
human messaging system, this book is not about email. Instead, this book is concerned
with messaging systems that allow different software applications to communicate with
each other. These application-to-application messaging systems, when used in business
systems, are generically referred to as enterprise messaging systems, or Message-Oriented
Middleware (MOM).
Enterprise messaging systems allow two or more applications to exchange information in
the form of messages. A message, in this case, is a self-contained package of business data
and network routing headers. The business data contained in a message can be anything -
depending on the business scenario - and usually contains information about some
business transaction. In enterprise messaging systems, messages inform an application of
some event or occurrence in another system.
Using Message-Oriented Middleware, messages are transmitted from one application to
another across a network. MOM products ensure that messages are properly distributed
among applications. In addition, MOMs usually provide fault tolerance, load balancing,
scalability, and transactional support for enterprises that need to reliably exchange large
quantities of messages.
MOM vendors use different message formats and network protocols for exchanging
messages, but the basic semantics are the same. An API is used to create a message, give it
a payload (application data), assign it routing information, and then send the message. The
same API is used to receive messages produced by other applications.
In all modern enterprise messaging systems, applications exchange messages through
virtual channels called destinations. When a message is sent, it's addressed to a destination,
not a specific application. Any application that subscribes or registers an interest in that
destination may receive that message. In this way, the applications that receive messages
and those that send messages are decoupled. Senders and receivers are not bound to each
other in any way and may send and receive messages as they see fit.
All MOM vendors provide application developers with an API for sending and receiving
messages. While a MOM vendor implements its own networking protocols, routing, and
administration facilities, the basic semantics of the developer API provided by different
MOMs are the same. This similarity in APIs makes the Java Message Service possible.
The Java Message Service (JMS) is a vendor-agnostic Java API that can be used with
many different MOM vendors. JMS is analogous to JDBC in that application developers
reuse the same API to access many different systems. If a vendor provides a compliant
service provider for JMS, then the JMS API can be used to send and receive messages to
that vendor. For example, you can use the same JMS API to send messages using Progress'
SonicMQ as you do IBM's MQSeries. It is the purpose of this book to explain how
enterprise messaging systems work and in particular how the Java Message Service is used
Java Message Service
7
with these systems. This book focuses on JMS 1.0.2, the most recent version of the
specification, which was introduced in November 1999.
The rest of this chapter explores enterprise messaging and JMS in more detail, so that you
have a solid foundation with which to learn about the JMS API and messaging concepts in
the rest of this book. We assume that you are already familiar with the Java programming
language - other than that, everything is explained.
1.1 Enterprise Messaging
Enterprise messaging is not a new concept. Messaging products such as IBM MQSeries,
Microsoft MSMQ, TIBCO Rendevous, Open Horizon Ambrosia, and Modulus InterAgent
have been in existence for many years. Newer messaging products such as Progress
SonicMQ, Softwired iBus, and FioranoMQ have been built from the ground up, based on
the need for doing reliable Business-to-Business communications over the Internet.
A key concept of enterprise messaging is messages are delivered asynchronously from one
system to others over a network. To deliver a message asynchronously means the sender is
not required to wait for the message to be received or handled by the recipient; it is free to
send the message and continue processing. Asynchronous messages are treated as
autonomous units - each message is self-contained and carries all of the data and state
needed by the business logic that processes it.
In asynchronous messaging, applications use a simple API to construct a message, then
hand it off to the Message-Oriented Middleware for delivery to one or more intended
recipients (Figure 1.1). A message is a package of business data that is sent from one
application to another over the network. The message should be self-describing in that it
should contain all the necessary context to allow the recipients to carry out their work
independently.
Figure 1.1. Message-Oriented Middleware
Message-Oriented Middleware architectures of today vary in their implementation. The
spectrum ranges from a centralized architecture that depends on a message server to
perform routing, to a decentralized architecture that distributes the "server" processing out
to the client machines. A varied array of protocols including TCP/IP, HTTP, SSL, and IP
multicast are employed at the network transport layer. Some messaging products use a
hybrid of both approaches, depending on the usage model.
Java Message Service
8
Before we discuss the different architectures, it is important to explain what we mean by
the term client. Messaging systems are composed of messaging clients and some kind of
MOM. The clients send messages to the MOM, which then distributes those messages to
other clients. The client is a business application or component that is using the messaging
API (in our case JMS).
1.1.1 Centralized Architectures
Enterprise messaging systems that use a centralized architecture rely on a message server.
A message server, also called a message router or broker, is responsible for delivering
messages from one messaging client to other messaging clients. The message server
decouples a sending client from other receiving clients. Clients only see the messaging
server, not other clients, which allows clients to be added and removed without impacting
the system as a whole.
Typically, a centralized architecture uses a hub-and-spoke topology. In a simple case, there
is a centralized message server and all clients connect to it. As shown in Figure 1.2, the
hub-and-spoke architecture lends itself to a minimal amount of network connections while
still allowing any part of the system to communicate with any other part of the system.
Figure 1.2. Centralized hub-and-spoke architecture
In practice, the centralized message server may be a cluster of distributed servers operating
as a logical unit.
1.1.2 Decentralized Architectures
All decentralized architectures currently use IP multicast at the network level. A
messaging system based on multicasting has no centralized server. Some of the server
functionality (persistence, transactions, security) is embedded as a local part of the client,
while message routing is delegated to the network layer by using the IP multicast protocol.
Java Message Service
9
IP multicast allows applications to join one or more IP multicast groups; each group uses
an IP network address that will redistribute any messages it receives to all members in its
group. In this way, applications can send messages to an IP multicast address and expect
the network layer to redistribute the messages appropriately (see Figure 1.3). Unlike a
centralized architecture, a distributed architecture doesn't require a server for the purposes
of routing messages - the network handles routing automatically. However, other server-
like functionality is still required to be included with each client, such as message
persistence and message delivery semantics like once-and-only-once delivery.
Figure 1.3. Decentralized IP multicast architecture
1.1.3 Hybrid Architectures
A decentralized architecture usually implies that an IP multicast protocol is being used. A
centralized architecture usually implies that the TCP/IP protocol is the basis for
communication between the various components. A messaging vendor's architecture may
also combine the two approaches. Clients may connect to a daemon process using TCP/IP,
which in turn communicate with other daemon processes using IP multicast groups.
1.1.4 Centralized Architecture as a Model
Both ends of the decentralized and centralized architecture spectrum have their place in
enterprise messaging. The advantages and disadvantages of distributed versus centralized
architectures are discussed in more detail in Chapter 7. In the meantime we need a
common model for discussing other aspects of enterprise messaging. In order to simplify
discussions, this book uses a centralized architecture as a logical view of enterprise
messaging. This is for convenience only and is not an endorsement of centralized over
decentralized architectures. The term "message server" is frequently used in this book to
refer to the underlying architecture that is responsible for routing and distributing
messages. In centralized architectures, the message server is a middleware server or cluster
of servers. In decentralized architectures, the server refers to the local server-like facilities
of the client.
1.2 The Java Message Service (JMS)
The Java Message Service (JMS) is an API for enterprise messaging created by Sun
Microsystems. JMS is not a messaging system itself; it's an abstraction of the interfaces
and classes needed by messaging clients when communicating with messaging systems. In
the same way that JDBC abstracts access to relational databases and JNDI abstracts access
Java Message Service
10
to naming and directory services, JMS abstracts access to MOMs. Using JMS, a messaging
application's messaging clients are portable across MOM products.
The creation of JMS was an industry effort. JavaSoft took the lead on the spec and worked
very closely with the messaging vendors throughout the process. The initial objective was
to provide a Java API for connectivity to MOM systems. However, this changed to the
wider objective of supporting messaging as a first-class Java distributed computing
paradigm equally with Remote Procedure Call (RPC) based systems like CORBA and
Enterprise JavaBeans:
There were a number of MOM vendors that participated in the creation of
JMS. It was an industry effort rather than a Sun effort. Sun was the spec
lead and did shepherd the work but it would not have been successful
without the direct involvement of the messaging vendors. Although our
original objective was to provide a Java API for connectivity to MOM
systems, this changed over the course of the work to a broader objective of
supporting messaging as a first class Java distributed computing paradigm
on equal footing with RPC.
- Mark Hapner, JMS spec lead, Sun Microsystems
The result is a best-of-breed, robust specification that includes a rich set of message
delivery semantics, combined with a simple yet flexible API for incorporating messaging
into applications. The intent was that in addition to new vendors, existing messaging
vendors would support the JMS API.
1.2.1 JMS Messaging Models: Publish-and-Subscribe and Point-to-Point
JMS provides for two types of messaging models, publish-and-subscribe and point-to-
point queuing. The JMS specification refers to these as messaging domains. In JMS
terminology, publish-and-subscribe and point-to-point are frequently shortened to pub/sub
and p2p (or PTP), respectively. This book uses both the long and short forms throughout.
In the simplest sense, publish-and-subscribe is intended for a one-to-many broadcast of
messages, while point-to-point is intended for one-to-one delivery of messages (see Figure
1.4).
Figure 1.4. JMS messaging domains
Không có nhận xét nào:
Đăng nhận xét