![]() ![]() ![]() ![]() ![]() ![]() ![]() |
These sections briefly review the different Java Message Service (JMS) concepts and features, and describe how they work with other application objects and WebLogic Server.
It is assumed the reader is familiar with Java programming and JMS 1.1 concepts and features.
WebLogic JMS is an enterprise-class messaging system that is tightly integrated into the WebLogic Server platform. It fully supports the JMS Specification and also provides numerous WebLogic JMS Extensions that go above and beyond the standard JMS APIs.
An enterprise messaging system enables applications to communicate with one another through the exchange of messages. A message is a request, report, and/or event that contains information needed to coordinate communication between different applications. A message provides a level of abstraction, allowing you to separate the details about the destination system from the application code.
The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems. Specifically, JMS:
The following figure illustrates WebLogic JMS messaging.
As illustrated in the figure, WebLogic JMS accepts messages from producer applications and delivers them to consumer applications.
WebLogic Server is compliant with the following Java specifications.
WebLogic Server is compliant with the Sun Microsystems J2EE 1.4 specification.
WebLogic Server is fully compliant with the JMS 1.1 Specification and can be used in production.
The following figure illustrates the WebLogic JMS architecture.
The major components of the WebLogic JMS Server architecture, as illustrated in Figure 2-2, include:
weblogic-jmsmd.xsd
schema.
JMS supports two messaging models: point-to-point (PTP) and publish/subscribe (pub/sub). The messaging models are very similar, except for the following differences:
Each model is implemented with classes that extend common base classes. For example, the PTP class javax.jms.Queue and the pub/sub class javax.jms.Topic both extend the class javax.jms.Destination.
Each message model is described in detail in the following sections.
Note: | The terms producer and consumer are used as generic descriptions of applications that send and receive messages, respectively, in either messaging model. For each specific messaging model, however, unique terms specific to that model are used when referring to producers and consumers. |
The point-to-point (PTP) messaging model enables one application to send a message to another. PTP messaging applications send and receive messages using named queues. A queue sender (producer) sends a message to a specific queue. A queue receiver (consumer) receives messages from a specific queue.
The following figure illustrates PTP messaging.
Multiple queue senders and queue receivers can be associated with a single queue, but an individual message can be delivered to only one queue receiver.
If multiple queue receivers are listening for messages on a queue, WebLogic JMS determines which one will receive the next message on a first come, first serve basis. If no queue receivers are listening on the queue, messages remain in the queue until a queue receiver attaches to the queue.
The publish/subscribe (pub/sub) messaging model enables an application to send a message to multiple applications. Pub/sub messaging applications send and receive messages by subscribing to a topic. A topic publisher (producer) sends messages to a specific topic. A topic subscriber (consumer) retrieves messages from a specific topic.
The following figure illustrates pub/sub messaging.
Unlike with the PTP messaging model, the pub/sub messaging model allows multiple topic subscribers to receive the same message. JMS retains the message until all topic subscribers have received it.
The Pub/Sub messaging model supports durable subscribers, allowing you to assign a name to a topic subscriber and associate it with a user or application. For more information about durable subscribers, see Setting Up Durable Subscriptions.
As per the “Message Delivery Mode” section of the JMS Specification, messages can be specified as persistent or non-persistent:
For information about using the system-wide, WebLogic Persistent Store, see Using the WebLogic Persistent Store.
WebLogic JMS is tightly integrated into the WebLogic Server platform, allowing you to build highly-secure J2EE applications that can be easily monitored and administered through the WebLogic Server console. In addition to fully supporting XA transactions, WebLogic JMS also features high availability through its clustering and service migration features, while also providing seamless interoperability with other versions of WebLogic Server and third-party messaging providers.
For a detailed listing of these value-added features, see “ WebLogic Server Value-Added JMS Features” in Configuring and Managing WebLogic JMS.
In addition to the standard JMS APIs specified by the JMS Specification, WebLogic Server provides numerous weblogic.jms.extensions APIs, which includes the classes and methods described in the following table.
Deprecated in this release of WebLogic Server. Replaced by
JMSModuleHelper.
|
|||
|
This API also supports NO_ACKNOWLEDGE
and MULTICAST_NO_ACKNOWLEDGE
acknowledge modes, and extended exceptions, including throwing an exception:
To create a JMS applications, use the javax.jms API. The API allows you to create the class objects necessary to connect to the JMS, and send and receive messages. JMS class interfaces are created as subclasses to provide queue- and topic-specific versions of the common parent classes.
The following table lists the JMS classes described in more detail in subsequent sections. For a complete description of all JMS classes, see the javax.jms or weblogic.jms.extensions Javadoc.
1Supports an optional JMS interface for processing multiple messages concurrently. 2Supports an optional JMS interface for processing multiple messages concurrently. 3Supports an optional JMS interface for processing multiple messages concurrently. 4Supports an optional JMS interface for processing multiple messages concurrently. |
For information about configuring JMS resources, see “Configuring JMS System Resources” in Configuring and Managing WebLogic JMS. The procedure for setting up a JMS application is presented in Setting Up a JMS Application.
A ConnectionFactory
encapsulates connection configuration information, and enables JMS applications to create a Connection. A connection factory supports concurrent use, enabling multiple threads to access the object simultaneously. You can use the preconfigured default connection factories provided by WebLogic JMS, or you can configure one or more connection factories to create connections with predefined attributes that suit your application.
WebLogic JMS defines two default connection factories, which you can look up using the following JNDI names:
You only need to create a user-defined a connection factory if the settings of the default factories are not suitable for your application. The main difference between the preconfigured settings for the default connection factories is the default value for the “XA Connection Factory Enabled” attribute which is used to enable JTA transactions, as shown in the following table.
An XA factory is required for JMS applications to use JTA user-transactions, but is not required for transacted sessions. For more information about using transactions with WebLogic JMS, see Using Transactions with WebLogic JMS.
All other default factory configuration attributes are set to the same default values as a user-defined connection factory.
For more information about the XA Connection Factory Enabled attribute, and to see the default values for the other connection factory attributes, see “ JMS Connection Factory: Configuration: Transactions” in the Administration Console Online Help.
Another distinction when using the default connection factories is that you have no control over targeting the WebLogic Server instances where the connection factory may be deployed. However, you can disable the default connection factories on a per-server basis.
For more information on enabling or disabling the default connection factories, see “ Servers: Configuration: Services” in the Administration Console Online Help.
To deploy a connection factory on specific independent servers, on specific servers within a cluster, or on an entire cluster, you must configure a new connection factory and specify the appropriate target, as explained in Configuring and Deploying Connection Factories.
Note: | For backwards compatibility, WebLogic JMS still supports two deprecated default connection factories. The JNDI names for these factories are: javax.jms.QueueConnectionFactory and javax.jms.TopicConnectionFactory . |
A system administrator can define and configure one or more connection factories to create connections with predefined attributes and WebLogic Server will add them to the JNDI space during startup. The application then retrieves a connection factory using WebLogic JNDI. Any user-defined connection factories must be uniquely named.
For information on configuring connection factories, see “ Configure connection factories” in the Administration Console Online Help.
A system administrator establishes cluster-wide, transparent access to JMS destinations from any server in the cluster by targeting to the cluster or by targeting to one or more server instances in the cluster. This way, each connection factory can be deployed on multiple WebLogic Server instances. For more information on JMS clustering, refer to “Configuring Clustered WebLogic JMS Resources” in Configuring and Managing WebLogic JMS.
The ConnectionFactory
class does not define methods; however, its subclasses define methods for the respective messaging models. A connection factory supports concurrent use, enabling multiple threads to access the object simultaneously.
Note: | For this release, you can use the JMS Version 1.1 specification connection factories or you can choose to use the subclasses. |
The following table describes the ConnectionFactory
subclasses.
To learn how to use the ConnectionFactory
class within an application, see Developing a Basic JMS Application, or the javax.jms.ConnectionFactory Javadoc.
A Connection
represents an open communication channel between an application and the messaging system, and is used to create a Session for producing and consuming messages. A connection creates server-side and client-side objects that manage the messaging activity between an application and JMS. A connection may also provide user authentication.
A Connection
is created by a ConnectionFactory, obtained through a JNDI lookup.
Due to the resource overhead associated with authenticating users and setting up communications, most applications establish a single connection for all messaging. In the WebLogic Server, JMS traffic is multiplexed with other WebLogic services on the client connection to the server. No additional TCP/IP connections are created for JMS. Servlets and other server-side objects may also obtain JMS Connections.
By default, a connection is created in stopped mode. For information about how and when to start a stopped connection, see Starting, Stopping, and Closing a Connection.
Connections support concurrent use, enabling multiple threads to access the object simultaneously.
Note: | For this release, you can use the JMS Version 1.1 specification connection objects or you can choose to use the subclasses. |
The following table describes the Connection
subclasses.
To learn how to use the Connection
class within an application, see Developing a Basic JMS Application, or the javax.jms.Connection Javadoc.
A Session object defines a serial order for the messages produced and consumed, and can create multiple message producers and message consumers. The same thread can be used for producing and consuming messages. If an application wants to have a separate thread for producing and consuming messages, the application should create a separate session for each function.
A Session is created by a Connection.
The JMS 1.1 Specification allows for a generic session to have a MessageConsumer for any type of Destination object. However, WebLogic JMS does not support having both types of MessageConsumer (QueueConsumer and TopicSubscriber) for a single session. In addition, having multiple consumers for a single session is not a common practice. The following commonly-used scenarios are supported, however:
Caution: | A session and its message producers and consumers can only be accessed by one thread at a time. Their behavior is undefined if multiple threads access them simultaneously. |
The following table describes the Session subclasses.
To learn how to use the Session class within an application, see Developing a Basic JMS Application, or the javax.jms.Session and weblogic.jms.extensions.WLSession javadocs.
In a non-transacted session, the application creating the session selects one of the five acknowledge modes defined in the following table.
The
Session object relies on the application to call an acknowledge method on a received message. Once the method is called, the session acknowledges all messages received since the last acknowledge.
This mode allows an application to receive, process, and acknowledge a batch of messages with one call.
For more information on the Acknowledge Policy attribute, see “
JMS Connection Factory: Configuration: General” in the Administration Console Online Help.
|
|||
The
Session object acknowledges receipt of a message once the receiving application method has returned from processing it; duplicate acknowledges are permitted.
|
|||
No acknowledge is required. Messages sent to a
NO_ACKNOWLEDGE session are immediately deleted from the server. Messages received in this mode are not recovered, and as a result messages may be lost and/or duplicate message may be delivered if an initial attempt to deliver a message fails.
This mode is supported for applications that do not require the quality of service provided by session acknowledge, and that do not want to incur the associated overhead.
|
|||
Messages sent to a
MULTICAST_NO_ACKNOWLEDGE session share the same characteristics as NO_ACKNOWLEDGE mode, described previously.
This mode is supported for applications that want to support multicasting, and that do not require the quality of service provided by session acknowledge. For more information on multicasting, see Using Multicasting with WebLogic Server.
|
In a transacted session, only one transaction is active at any given time. Any number of messages sent or received during a transaction are treated as an atomic unit.
When you create a transacted session, the acknowledge mode is ignored. When an application commits a transaction, all the messages that the application received during the transaction are acknowledged by the messaging system and messages it sent are accepted for delivery. If an application rolls back a transaction, the messages that the application received during the transaction are not acknowledged and messages it sent are discarded.
JMS can participate in distributed transactions with other Java services, such as EJB, that use the Java Transaction API (JTA). Transacted sessions do not support this capability as the transaction is restricted to accessing the messages associated with that session. For more information about using JMS with JTA, see Using JTA User Transactions.
A Destination
object can be either a queue or topic, encapsulating the address syntax for a specific provider. The JMS specification does not define a standard address syntax due to the variations in syntax between providers.
Similar to a connection factory, an administrator defines and configures the destination and the WebLogic Server adds it to the JNDI space during startup. Applications can also create temporary destinations that exist only for the duration of the JMS connection in which they are created.
Note: | Administrators can also configure a distributed destination, which is a single set of destinations (queues or topics) that are accessible as a single, logical destination to a client. For more information, see Distributed Destinations. |
On the client side, Queue
and Topic
objects are handles to the object on the server. Their methods only return their names. To access them for messaging, you create message producers and consumers that attach to them.
A destination supports concurrent use, enabling multiple threads to access the object simultaneously. JMS Queues
and Topics
extend javax.jms.Destination.
Note: | For this release, you can use the JMS Version 1.1 specification destination objects or you can choose to use the subclasses. |
The following table describes the Destination
subclasses.
Note: | An application has the option of browsing queues by creating a QueueBrowser object in its queue session. This object produces a snapshot of the messages in the queue at the time the queue browser is created. The application can view the messages in the queue, but the messages are not considered read and are not removed from the queue. For more information about browsing queues, see Setting and Browsing Message Header and Property Fields. |
To learn how to use the Destination
class within an application, see Developing a Basic JMS Application, or the javax.jms.Destination Javadoc.
A distributed destination resource is a single set of destinations (queues or topics) that are accessible as a single, logical destination to a client (for example, a distributed topic has its own JNDI name). The members of the set are typically distributed across multiple servers within a cluster, with each member belonging to a separate JMS server. Applications that use a distributed destination are more highly available than applications that use standalone destinations because WebLogic JMS provides load balancing and failover for the members of a distributed destination in a cluster.
A MessageProducer
sends messages to a queue or topic. A MessageConsumer
receives messages from a queue or topic. Message producers and consumers operate independently of one another. Message producers generate and send messages regardless of whether a message consumer has been created and is waiting for a message, and vice versa.
A Session creates the MessageProducers
and MessageConsumers
that are attached to queues and topics.
The message sender and receiver objects are created as subclasses of the MessageProducer
and MessageConsumer
classes.
Note: | For this release, you can use the JMS Version 1.1 specification message producer and consumer objects or you can choose to use the subclasses. |
The following table describes the MessageProducer
and MessageConsumer
subclasses.
The PTP model, as shown in the figure Point-to-Point (PTP) Messaging, allows multiple sessions to receive messages from the same queue. However, a message can only be delivered to one queue receiver. When there are multiple queue receivers, WebLogic JMS defines the next queue receiver that will receive a message on a first-come, first-serve basis.
The pub/sub model, as shown in the figure Publish/Subscribe (Pub/Sub) Messaging, allows messages to be delivered to multiple topic subscribers. Topic subscribers can be durable or non-durable, as described in Setting Up Durable Subscriptions.
An application can use the same JMS connection to both publish and subscribe to a single topic. Because topic messages are delivered to all subscribers, an application can receive messages it has published itself. To prevent clients from receiving messages that they publish, a JMS application can set a noLocal
attribute on the topic subscriber, as described in Step 5: Create Message Producers and Message Consumers Using the Session and Destinations.
To learn how to use the MessageProducer
and MessageConsumer
classes within an application, see Setting Up a JMS Application, or the javax.jms.MessageProducer and javax.jms.MessageConsumer javadocs.
A Message
encapsulates the information exchanged by applications. This information includes three components:
Every JMS message contains a standard set of header fields that is included by default and available to message consumers. Some fields can be set by the message producers.
For information about setting message header fields, see Setting and Browsing Message Header and Property Fields, or to the javax.jms.Message Javadoc.
The following table describes the fields in the message headers and shows how values are defined for each field.
Specifies one of the following: a WebLogic
JMSMessageID (described later in this table), an application-specific string, or a byte[] array. The JMSCorrelationID is used to correlate messages and is set directly on the message by the application before send() .
|
||
Specifies
PERSISTENT or NON_PERSISTENT messaging. This field is set on the producer or as parameter sent by the application before send() .
When a persistent message is sent, it is stored in the
WebLogic Persistent Store. The
send() operation is not considered successful until delivery of the message can be guaranteed. A persistent message is guaranteed to be delivered at least once.
WebLogic JMS does not store non-persistent messages in the persistent store. This mode of operation provides the lowest overhead. They are guaranteed to be delivered at least once unless there is a system failure, in which case messages may be lost. If a connection is closed or recovered, all non-persistent messages that have not yet been acknowledged will be redelivered. Once a non-persistent message is acknowledged, it will not be redelivered.
|
||
Specifies the destination (queue or topic) to which the message is to be delivered. This field is set when creating producer or as parameter sent by the application before
send() .
This value is overwritten by a call to
producer.send() , setting this value directly on the message has no effect. The values set by the producer can be queried using the message supplied to producer.send() or when the message is received by a consumer. When a message is received, its destination value must be equivalent to the value assigned when it was sent.
|
||
Specifies the expiration, or time-to-live value, for a message. This field is set by the application before
send() . Depends on timeToLive, which is set on the producer or as a parameter sent by the application to send() .
|
||
Contains a string value that uniquely identifies each message sent by a JMS Provider.This field is set internally by
send() .
This value is overwritten by a call to
producer.send() , setting this value directly on the message has no effect. The values set by the producer can be queried using the message supplied to producer.send() or when the message is received by a consumer. When the message is received, it contains a provider-assigned value.
|
||
Specifies the priority level. This field is set on the producer or as parameter sent by the application before
send() .
JMS defines ten priority levels, 0 to 9, 0 being the lowest priority. Levels 0-4 indicate gradations of normal priority, and level 5-9 indicate gradations of expedited priority.
You can sort destinations by priority by configuring a destination key, as described in
“Configure destination keys” in the Administration Console Online Help.
|
||
Specifies a flag set when a message is redelivered because no acknowledge was received. This flag is of interest to a receiving application.
If set, the flag indicates that JMS may have delivered the message previously because one of the following is true:
|
||
Specifies a queue or topic to which reply messages should be sent. This field is set directly on the message by the application before
send() .
|
||
Specifies the message type identifier (String) set directly on the message by the application before
send() .
The JMS specification allows some flexibility with this field in order to accommodate diverse JMS providers. Some messaging systems allow application-specific message types to be used. For such systems, the
JMSType field could be used to hold a message type ID that provides access to the stored type definitions.
|
The property fields of a message contain header fields added by the sending application. The properties are standard Java name/value pairs. Property names must conform to the message selector syntax specifications defined in the javax.jms.Message Javadoc. The following values are valid: boolean, byte, double, float, int, long, short, and String.
WebLogic Server supports the use of the following JMS (JMSX) defined properties as defined in the JMS 1.1. Specification:
System generated property that identifies the user sending the message. See “
Configure connection factory security parameters” and
Message ID Propagation Security Enhancement.
|
|
Although message property fields may be used for application-specific purposes, JMS provides them primarily for use in message selectors. You determine how the JMS properties are used in your environment. You may choose to include them in some messages and omit them from others depending upon your processing criteria. For more information, see:
A message body contains the content being delivered from producer to consumer.
The following table describes the types of messages defined by JMS. All message types extend javax.jms.Message, which consists of message headers and properties, but no message body.
For more information, see the javax.jms.Message Javadoc. For more information about the access methods and, if applicable, the conversion charts associated with a particular message type, see the Javadoc for that message type.
Note: | Session pool and connection consumer configuration objects are deprecated in this release of WebLogic Server. They are not a required part of the J2EE specification, do not support JTA user transactions, and are largely superseded by message-driven beans (MDBs), which are simpler, easier to manage, and more capable. For more information on designing MDBs, see “ Message-Driven EJBs” in Programming WebLogic Enterprise JavaBeans. |
A server session pool is a WebLogic-specific JMS feature that enables you to process messages concurrently. A server session pool factory is used to create a server-side ServerSessionPool
.
WebLogic JMS defines one ServerSessionPoolFactory
object, by default: weblogic.jms.extensions.ServerSessionPoolFactory:<
name>
, where <name
> specifies the name of the JMS server to which the session pool is created. The WebLogic Server adds the default server session pool factory to the JNDI space during startup and the application subsequently retrieves the server session pool factory using WebLogic JNDI.
To learn how to use the server session pool factory within an application, see Defining Server Session Pools, or the weblogic.jms.extnesions.ServerSessionPoolFactory Javadoc.
A ServerSessionPool
application server object provides a pool of server sessions that connection consumers can retrieve in order to process messages concurrently.
A ServerSessionPool
is created by the ServerSessionPoolFactory object obtained through a JNDI lookup.
To learn how to use the server session pool within an application, see Defining Server Session Pools, or the javax.jms.ServerSessionPool Javadoc.
A ServerSession
application server object enables you to associate a thread with a JMS session by providing a context for creating, sending, and receiving messages.
A ServerSession
is created by a ServerSessionPool object.
To learn how to use the server session within an application, see Defining Server Session Pools, or the javax.jms.ServerSession Javadoc.
A ConnectionConsumer
object uses a server session to process received messages. If message traffic is heavy, the connection consumer can load each server session with multiple messages to minimize thread context switching.
A ConnectionConsumer
is created by a Connection object.
To learn how to use the connection consumers within an application, see Defining Server Session Pools, or the javax.jms.ConnectionConsumer Javadoc.
Note: | Connection consumer listeners run on the same JVM as the server. |
![]() ![]() ![]() |