atr<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"><HTML> | |
<HEAD> | |
<TITLE> | |
Architecture | |
</TITLE> | |
</HEAD> | |
<BODY BGCOLOR="#ffffff"> | |
<P> | |
The Java Message Service (JMS) API provides a common way for Java programs to create, | |
send, receive and read an enterprise messaging system's messages. | |
<H3>JMS Applications</H3> | |
<P>A JMS application is composed of the following parts:</P> | |
<UL> | |
<LI>JMS Provider - a messaging system that implements the JMS API | |
in addition to the other administrative and control functionality required | |
of a full-featured messaging product</LI> | |
<LI>JMS Clients - the Java language programs that send and receive | |
messages</LI> | |
<LI>Messages - objects that are used to communicate information between the | |
clients of an application</LI> | |
<LI>Administered Objects - provider-specific objects that clients look up | |
and use to interact portably with a JMS provider</LI> | |
<LI>Non-JMS Clients - clients that use a message system's native | |
client API instead of the JMS API. If the application predated the | |
availability of the JMS API, it is likely that it will include both JMS | |
clients and non-JMS clients.</LI> | |
</UL> | |
<H3>Administration</H3> | |
<P>JMS providers differ significantly in their implementations of | |
underlying messaging technology. There are also major | |
differences in how a JMS provider's system is installed and administered.</P> | |
<P>For JMS clients to be portable, they must be isolated from these | |
proprietary aspects of a provider. This is done by defining JMS administered | |
objects that are created and customized by a provider's administrator and | |
later used by clients. The client uses them through JMS interfaces that are | |
portable. The administrator creates them using provider-specific facilities.</P> | |
<P>There are two types of JMS administered objects:</P> | |
<UL> | |
<LI>ConnectionFactory - the object a client uses to create a | |
connection with a JMS provider</LI> | |
<LI>Destination - the object a client uses to specify the | |
destination of messages it is sending and the source of messages | |
it receives</LI> | |
</UL> | |
<P>Administered objects are placed in a Java Naming and Directory | |
Interface<SUP><FONT SIZE="-2">TM</FONT></SUP> (JNDI) namespace by an | |
administrator. | |
A JMS client typically notes in its documentation the JMS administered objects | |
it requires and how the JNDI names of these objects should be provided to it.</P> | |
<H3>Two Messaging Styles</H3> | |
<P>The JMS specification defines two styles of messaging: the point-to-point | |
(PTP) or the publish-and-subscribe (Pub/Sub). These styles can be combined in a | |
single application, or a given application can use just one of these styles.</P> | |
<P>The JMS API defines these two styles because they represent two of the | |
dominant approaches to messaging currently in use. While the domains have many | |
similarities, they also have some differences. JMS provides a unified programming | |
interface to allow the client programmer to easily send and receive message using | |
either domain, but the client programmer must also be aware of the differences | |
between the domains. The key differences relate to how message persistence is | |
handled, and the meaning of certain message attributes. </P> | |
<H3>JMS Interfaces</H3> | |
When programming an application client, the programmer may either program using | |
the domain specific interfaces, or may use the common interfaces. The key interfaces | |
are listed in the table below. The preferred model is to use the common interfaces. | |
The advantage to using the common interfaces is that both point-to-point and | |
pub/sub tasks can be combined in one session, allowing transactions to operate | |
over both domains. | |
<P>In earlier versions of JMS, there were separate class hierarchies for | |
the pub/sub and point-to-point programming models that had to be used. | |
These class hierarchies are retained to support backward compatibility with | |
earlier versions of the JMS API, but client developers are encouraged to use | |
the common interfaces. | |
<P> | |
<TABLE BORDER CELLPADDING="3" CELLSPACING="0"> | |
<CAPTION> | |
<B>Relationship of PTP and Pub/Sub interfaces<B> | |
</CAPTION> | |
<TR> | |
<TH ALIGN="LEFT">JMS Common</TH> | |
<TH ALIGN="LEFT">PTP Domain</TH> | |
<TH ALIGN="LEFT">Pub/Sub Domain</TH> | |
</TR> | |
<TR> | |
<TD>ConnectionFactory</TD> | |
<TD>QueueConnectionFactory</TD> | |
<TD>TopicConnectionFactory</TD> | |
</TR> | |
<TR> | |
<TD>Connection</TD> | |
<TD>QueueConnection</TD> | |
<TD>TopicConnection</TD> | |
</TR> | |
<TR> | |
<TD>Destination</TD> | |
<TD>Queue</TD> | |
<TD>Topic</TD> | |
</TR> | |
<TR> | |
<TD>Session</TD> | |
<TD>QueueSession</TD> | |
<TD>TopicSession</TD> | |
</TR> | |
<TR> | |
<TD>MessageProducer</TD> | |
<TD>QueueSender</TD> | |
<TD>TopicPublisher</TD> | |
</TR> | |
<TR> | |
<TD>MessageConsumer</TD> | |
<TD>QueueReceiver</TD> | |
<TD>TopicSubscriber</TD> | |
</TR> | |
</TABLE> | |
<P>The following provides a brief definition of these JMS concepts. See the PTP | |
and Pub/Sub chapters of the JMS specification for more information.</P> | |
<UL> | |
<LI>ConnectionFactory - an administered object used by a client to create a | |
Connection</LI> | |
<LI>Connection - an active connection to a JMS provider</LI> | |
<LI>Destination - an administered object that encapsulates the identity of a | |
message destination</LI> | |
<LI>Session - a single-threaded context for sending and receiving messages</LI> | |
<LI>MessageProducer - an object created by a Session that is used for sending | |
messages to a destination</LI> | |
<LI>MessageConsumer - an object created by a Session that is used for receiving | |
messages sent to a destination</LI> | |
</UL> | |
<P>The term <EM>consume</EM> is used in this document to mean the receipt of a | |
message by a JMS client; that is, a JMS provider has received a message and has | |
given it to its client. Since the JMS API supports both synchronous and asynchronous | |
receipt of messages, the term <EM>consume</EM> is used when there is no need to | |
make a distinction between them.</P> | |
<P>The term <EM>produce</EM> is used as the most general term for sending a | |
message. It means giving a message to a JMS provider for delivery to a | |
destination.</P> | |
<H3>Developing a JMS Application</H3> | |
<P>Broadly speaking, a JMS application is one or more JMS clients that exchange | |
messages. The application may also involve non-JMS clients; however, these | |
clients use the JMS provider's native API in place of the JMS API.</P> | |
<P>A JMS application can be architected and deployed as a unit. In many cases, | |
JMS clients are added incrementally to an existing application.</P> | |
<P>The message definitions used by an application may originate with JMS, or they | |
may have been defined by the non-JMS part of the application.</P> | |
<H3>Developing a JMS Client</H3> | |
<P>A typical JMS client executes the following setup procedure:</P> | |
<UL> | |
<LI>Use JNDI to find a ConnectionFactory object</LI> | |
<LI>Use JNDI to find one or more Destination objects</LI> | |
<LI>Use the ConnectionFactory to create a JMS Connection. At this point, | |
message delivery is inhibited</LI> | |
<LI>Use the Connection to create one or more JMS Sessions</LI> | |
<LI>Use a Session and the Destinations to create the MessageProducers and | |
MessageConsumers needed</LI> | |
<LI>Start message delivery for the Connection. Messages will be delivered to | |
MessageConsumers</LI> | |
</UL> | |
<P>At this point a client has the basic setup needed to produce and consume | |
messages.</P> | |
<H3>Package Specification</H3> | |
<BLOCKQUOTE> | |
<A HREF="http://java.sun.com/products/jms/docs.html">Java Message Service | |
Specification - Version 1.1 </A> | |
</BLOCKQUOTE> | |
<H3>Related Documentation</H3> | |
<BLOCKQUOTE> | |
<A HREF="http://java.sun.com/products/jms/tutorial/index.html">Java Message | |
Service Tutorial</A> | |
</BLOCKQUOTE> | |
</BODY> | |
</HTML> |