11.1 Messaging in J2EE
Most discussions of messaging in the J2EE
world focus on JMS, the Java Message Service API, which is a core
component of the J2EE standard. JMS provides access to heavy-duty
messaging software. A JMS-enabled application can take advantage of a
range of services, such as delivery guarantees, quality of service
contracts, and an easy-to-use Java interface.
The patterns in this chapter apply to JMS applications, but many of
them can be used alongside another message transport mechanism:
trusty old Internet email. Email has gotten relatively short shrift
in most texts on enterprise software development, and
we're hard pressed to see why; it's
easy to use, and the infrastructure is nearly ubiquitous.
There's even a handy J2EE API, JavaMail, designed
for dealing with it. We look at most of the patterns in this chapter
through the lenses of both JMS and JavaMail. Of course, JavaMail and
JMS are hardly equivalent, and we'll point out some
of the differences in the next few pages.
11.1.1 Asynchronous Messaging Versus Web Services
This chapter doesn't cover message-oriented web
services, partially because messaging is such a broad subject. If you
think about it, most of what an application does can be cast in terms
of messaging: method calls, for instance, are messages from one class
to another, with immediate receipt and confirmation of delivery.
For our purposes, there's one major difference
between asynchronous messaging and web
services: web services are synchronous. When you're
remotely accessing an EJB session bean or other Remote Procedure Call
interface, it's expected that the service
you're looking for will be available and online, and
a web service is the same way. Web services use XML messages that
conform to the SOAP specification, but they deliver the message
immediately or not at all. The SOAP protocol doesn't
mandate a delivery mechanism, but web services do.
(HTTP梩hat's where the
"web" part comes from.) These
messages, like method calls, are synchronous: they happen
immediately, and both sides of the exchange must coordinate with each
other.
In this chapter, we're focusing on asynchronous
messaging: communication between multiple systems in something other
than real time. In an asynchronous exchange, the sender dispatches
the message and goes on with other work. The recipient may receive
the message milliseconds, minutes, hours, or days later, depending on
the transport mechanism, system design, network conditions, and so
forth (sunspots have been known to play a role here).
Even though the core web services concept is synchronous, that
doesn't mean web services can't be
deployed in support of an asynchronous application: you just need to
write a little more code. Once you've done that, the
underlying principles and patterns start to look a lot like the ones
in this chapter.
|