Introduction to WebLogic JMS

The following sections provide an overview of the Java Message Service (JMS) for BEA WebLogic Server:

• What Is JMS?

• Implementation of Java Specifications

• WebLogic JMS Features

• WebLogic JMS Architecture

• WebLogic JMS Extensions

• JMS Enhancements in WebLogic Server 7.0

 

---

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.

 

---

Implementation of Java Specifications

WebLogic Server is compliant with the following Java specifications.

J2EE Specification

WebLogic Server 7.0 is compliant with Sun Microsystems' J2EE 1.3 specification.

JMS Specification

WebLogic Server 7.0 is fully compliant with the JMS Specification - version 1.0.2b and can be used in production.

 

---

WebLogic JMS Features

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

• Provides a single, unified messaging API.

• Strictly adheres to the JMS Specification - version 1.0.2b.

• Supports 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, including support for distributed transactions and the two-phase commit protocol. JMS applications can also participate in transactions with other Java APIs that use JTA, including non-WebLogic XA compliant message brokers.

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

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

• Can be used with other 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

• Persistent storage (file or database) for storing persistent message 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 topics and queues are still managed by individual WebLogic Server instances in the cluster.

For more information about configuring clustering for WebLogic JMS, see Configuring WebLogic JMS Clustering. For detailed information about WebLogic Server clustering, see Using WebLogic Server Clusters.

The advantages of clustering include the following:

• Load balancing of destinations across multiple servers in the cluster

  • An administrator can establish load balancing of destinations across multiple 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.

  • An administrator can also configure multiple physical destinations as members of a single distributed destination set within a cluster. Producers and consumers are able to send and receive to the distributed destination. In the event of a single server failure within the cluster, WebLogic JMS then distributes the load across all available physical destination members within the distributed destination set.

    For more information on distributed destinations, see "Configuring Distributed Destinations" in the Administration Guide.

• 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 either enabling the default connection factory for each server instance in the cluster, or by configuring one or more connection factories and targeting them to one or more server instances in the cluster. This way, 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.

• Migratability

  As an "exactly-once" service, WebLogic JMS takes advantage of the migration framework implemented in WebLogic Server for clustered environments. This allows WebLogic JMS to properly respond to migration requests and bring a JMS server online and offline in an orderly fashion. This includes both scheduled migrations as well as migrations in response to a WebLogic Server failure. For more information, see Configuring JMS Migratable Targets.

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

 

---

WebLogic JMS Extensions

In addition to the API specified by Sun Microsystems' JMS Specification, WebLogic JMS provides a public API, weblogic.jms.extensions, which includes classes and methods for the extensions described in the following table.

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 7.0 and pre-6.0 JMSMessageID formats	Refer to Setting Message Header Fields
Set a redelivery delay for messages	Refer to Setting a Redelivery Delay for Messages
Set a message delivery time for producers	Refer to Setting a Delivery Time on Producers
Set a delivery time for messages	Refer to Setting a Delivery Time on Messages
Set a scheduled delivery time for messages	Refer to Setting a Scheduled Time-to-Deliver Override

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.

 

---

JMS Enhancements in WebLogic Server 7.0

The following JMS enhancements are new to this release of WebLogic Server.

High Availability Enhancement

WebLogic JMS takes advantage of the migration framework implemented in the WebLogic Server core for clustered environments. This allows WebLogic JMS to properly respond to migration requests and bring a JMS server online and offline in an orderly fashion. This includes both scheduled migrations as well as migrations in response to a WebLogic Server failure.

For more information, see "Managing JMS" in Programming WebLogic JMS.

Distributed Destinations within a WebLogic Cluster

The highly available implementation of WebLogic JMS offers a level of service continuity in the event of a single server failure by enabling you to configure multiple physical destinations as members of a single distributed destination set. Specifically, an administrator can configure multiple instances of a given destination within a cluster. If one instance within the cluster fails, then other instances of the same destination will be able to provide service to JMS producers and consumers.

For more information, see "Developing a WebLogic JMS Application" in Programming WebLogic JMS and "Managing JMS" in the Administration Guide.

Flow Control

Using the Flow Control feature, you can enable a JMS server or destination to slow down message producers when it determines that it is becoming overloaded. Specifically, when a JMS server/destination exceeds its specified bytes or messages thresholds, it instructs producers to limit their message flow.

For more information, see "Managing JMS" in the Administration Guide.

WebLogic Messaging Bridge

A messaging bridge (also known as a JMS bridge) is responsible for transferring messages between two JMS providers. The WebLogic Server Messaging Bridge feature allows you to configure a store and forward mechanism between any two messaging providers—including separate implementations of WebLogic JMS.

For more information, see "Using a WebLogic Messaging Bridge" in the Administration Guide.

Message Paging

The Message Paging feature can free up virtual memory during peak message load periods by swapping out messages from virtual memory to persistent storage when message loads reach a specified threshold. From a performance perspective, this feature can greatly benefit WebLogic Server implementations with the large message spaces that are required by today's enterprise applications.

For more information, see "Managing JMS" in the Administration Guide.