Bea WebLogic Server JMS - Part 1 Basic JMS

This is the first blog in a series about WebLogic JMS (WLS 10.0). Full description can be found here.

The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems.

WebLogic Server is compliant with the Java Platform, Enterprise Edition (Java EE) Version 5.0 specification and fully compliant with the JMS 1.1 Specification and can be used in production.

The major components of the WebLogic JMS are:

• JMS servers that hosts a set of modules and any associated persistent storage that reside on a WebLogic Server instance.
• JMS modules contains configuration resources conform the weblogic-jmsmd.xsd schema.
• JNDI (Java Naming and Directory Interface), which provides a resource lookup facility. JMS resources such as connection factories and destinations are configured with a JNDI name.
  
• WebLogic persistent storage (file store or JDBC-accessible) for storing persistent message data.

Messaging Models
JMS supports two messaging models: point-to-point (PTP) and publish/subscribe (pub/sub). 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.
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.

Message Persistence
Messages can be specified as persistent or non-persistent.

• A persistent message is guaranteed to be delivered once-and-only-once. The message cannot be lost due to a JMS provider failure and it must not be delivered twice. It is not considered sent until it has been safely written to a file or database.
  
• Non-persistent messages are not stored. They are guaranteed to be delivered at-most-once, unless there is a JMS provider failure, in which case messages may be lost, and must not be delivered twice. 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.

WebLogic JMS extensions
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.
See weblogic.jms.extensions.

JMS API
To create a JMS applications, use the javax.jms API. For a complete description of all JMS classes, see the javax.jms or weblogic.jms.extensions Javadoc.

ConnectionFactory
A ConnectionFactory encapsulates connection configuration information, and enables JMS applications to create a Connection. 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. The default connection factories are: weblogic.jms.ConnectionFactory and weblogic.jms.XAConnectionFactory.
An XA factory is required for JMS applications to use JTA user-transactions, but is not required for transacted sessions. 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. A connection factory supports concurrent use, enabling multiple threads to access the object simultaneously.

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

Session
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. WebLogic JMS does not support having both types of MessageConsumer (QueueConsumer and TopicSubscriber) for a single session.

Destinations
A Destination object can be either a queue or topic, encapsulating the address syntax for a specific provider. 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. 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.

Producer and Consumer
A MessageProducer sends messages to a queue or topic. A MessageConsumer receives messages from a queue or topic.

Message
A Message encapsulates the information exchanged by applications and it has header- and property fields and a body. Some header fields:

JMSCorrelationID

Specifies one of the following: a WebLogic JMSMessageID, 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().

There are two common applications for this field.

The first application is to link messages by setting up a request/response scheme, as follows:

1. When an application sends a message, it stores the JMSMessageID value assigned to it.
2. When an application receives the message, it copies the JMSMessageID into the JMSCorrelationID field of a response message that it sends back to the sending application.

The second application is to use the JMSCorrelationID field to carry any String you choose, enabling a series of messages to be linked with some application-determined value.


JMSDeliveryMode

Specifies PERSISTENT or NON_PERSISTENT messaging. This field is set on the producer or as parameter sent by the application before send().
JMSMessageID

Contains a string value that uniquely identifies each message sent by a JMS Provider.This field is set internally by send().
JMSReplyTo

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().

A message body contains the content being delivered from producer to consumer and can be one of the following types:
Bytes, Map (name/value pairs), Object (serializable), Stream (same as Bytes only primitive types allowed), Text, XML (Weblogic extension and facilitates message filtering which is more complex when done on a test message that happens to contain XML data)