plugins/org.eclipse.net4j.jms.api/src/javax/jms/package.html - cdo/cdo - Git at Google

 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>
	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>