Introduction to WebLogic JMS

 

The following sections provide an overview of the WebLogic Java Messaging Service (JMS):

• What Is JMS?

• WebLogic JMS Features

• WebLogic JMS Architecture

• WebLogic JMS Extensions

What Is JMS?

An enterprise messaging system, also referred to as Message-Oriented Middleware (MOM), 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:

• Enables Java applications sharing a messaging system to exchange messages

• Simplifies application development by providing a standard interface for creating, sending, and receiving messages

The following figure illustrates WebLogic JMS messaging.

Figure 1-1 WebLogic JMS Messaging

As illustrated in the figure, WebLogic JMS accepts messages from producer applications and delivers them to consumer applications.

WebLogic JMS Features

WebLogic JMS provides a full implementation of the JMS API. Specifically, WebLogic JMS:

• Provides a single, unified messaging API.

• Implements the JavaSoft JMS specification version 1.0.2a, including the latest JMS API - Errata.

• Support clustering.

• Supports messaging for applications that span different operating systems and machine architectures.

• Can be configured by setting attributes from the WebLogic Administration Console and/or using the JMS API to override values.

• Allows interoperability between JMS applications and other resource managers (primarily databases) using the Java Transaction API (JTA) transactions. JMS applications can participate in transactions with other Java APIs that use JTA.

• Supports messages containing Extensible Markup Language (XML).

• Supports multicasting allowing the delivery of messages to a select group of hosts using an IP multicast address.

• May use either a database or file for persistent message storage.

• Can be used with other BEA WebLogic Server APIs and facilities, such as Enterprise Java Beans (EJB), JDBC connection pools, Servlets, and RMI.

WebLogic JMS Architecture

The following figure illustrates the WebLogic JMS architecture.

Figure 1-2 WebLogic JMS Architecture

Major Components

The major components of the WebLogic JMS Server architecture, as illustrated in the figure WebLogic JMS Architecture, include:

• WebLogic JMS servers implementing the messaging facility

• Client applications

• JNDI (Java Naming and Directory Interface), which provides a server lookup facility

• Backing stores (file or database) for storing persistent data

Clustering Features

The WebLogic JMS architecture implements clustering of multiple JMS servers by supporting cluster-wide, transparent access to destinations from any server in the cluster. Although WebLogic Server supports distributing JMS destinations and connection factories throughout a cluster, JMS Queues and Topics are still managed by individual WebLogic Server instances in the cluster. For detailed information about WebLogic clustering, see the Using WebLogic Server Clusters.

The advantages of clustering include:

• Load balancing of destinations across multiple servers in the cluster

  A system administrator can establish load balancing of destinations across multiple JMS servers in the cluster by configuring multiple JMS servers and using targets to assign them to the defined WebLogic Servers. Each JMS server is deployed on exactly one WebLogic Server and handles requests for a set of destinations.

  Note: Load balancing is not dynamic. During the configuration phase, the system administrator defines load balancing by specifying targets for JMS servers.

• Cluster-wide, transparent access to destinations from any server in the cluster

  A system administrator can establish cluster-wide, transparent access to destinations from any server in the cluster by configuring multiple connection factories and using targets to assign them to WebLogic Servers. Each connection factory can be deployed on multiple WebLogic Servers.

  The application uses the Java Naming and Directory Interface (JNDI) to look up a connection factory and create a connection to establish communication with a JMS server. Each JMS server handles requests for a set of destinations. Requests for destinations not handled by a JMS server are forwarded to the appropriate server.

  Connection factories are described in more detail in WebLogic JMS Fundamentals.

• Scalability

  Scalability is provided by:

  • Load balancing of destinations across multiple servers in the cluster, as described previously.

  • Distribution of application load across multiple JMS servers via connection factories, thus reducing the load on any single JMS server and enabling session concentration by routing connections to specific servers.

  • Optional multicast support, reducing the number of messages required to be delivered by a JMS server. The JMS server forwards only a single copy of a message to each host group associated with a multicast IP address, regardless of the number of applications that have subscribed.

    Note: Automatic failover is not supported by JMS for this release. For information about performing a manual failover, refer to "Recovering from a WebLogic Server Failure" on page 3-5.

WebLogic JMS Extensions

In addition to the API specified by the JavaSoft JMS specification version 1.0.2, WebLogic JMS provides a public API, weblogic.jms.extensions, that includes classes and methods for the extensions described in the following table.

Table 1-1 WebLogic JMS Extensions

Extension	For more information. . .
Create XML messages	Refer to Step 6a: Create the Message Object (Message Producers)
Define a session exception listener	Refer to Defining a Session Exception Listener
Set or display the maximum number of pre-fetched asynchronous messages allowed on the session	Refer to Dynamically Configuring Multicasting Configuration Attributes
Set or display the multicast session overrun policy that is applied when the message maximum is reached	Refer to Dynamically Configuring Multicasting Configuration Attributes
Dynamically create permanent queues or topics	Refer to Using the JMSHelper Class Methods
Convert between WebLogic JMS 6.0 and pre-6.0 JMSMessageID formats	Refer to Setting Message Header Fields

This API also supports NO_ACKNOWLEDGE and MULTICAST_NO_ACKNOWLEDGE acknowledge modes, and extended exceptions, including throwing an exception:

• To the session exception listener (if set), when one of its consumers has been closed by the server as a result of a server failure, or administrative intervention.

• From a multicast session when the number of messages received by the session but not yet delivered to the messages listener, exceeds the maximum number of messages allowed for that session.

• From a multicast consumer when it detects a sequence gap (message received out of sequence) in the data stream.