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 8.1

 

---

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 8.1 is compliant with Sun Microsystems' J2EE 1.3 specification.

JMS Specification

WebLogic Server 8.1 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 Online Help 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 "Distributed Destination Tasks" in the Administration Console Online Help.

• 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.
• 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 Creating Destinations Dynamically
Dynamically delete permanent queues or topics	Refer to Deleting Destinations Dynamically
Convert between WebLogic JMS 8.1 and pre-release 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 8.1

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

JMS Thin Client

At approximately 400k, the wljmsclient.jar file provides full WebLogic JMS functionality, yet greatly reduces the client-side WebLogic footprint by using a smaller library that contains only the set of supporting files required by client-side programs. The new client .jar file is available in the WL_HOME/server/lib subdirectory of the WebLogic Server installation directory (for example, c:\bea\weblogic81b\server\lib).

This .jar provides for full-featured WebLogic Server clients that can support clustering, load balancing, transactions, security, and failover. SeeWebLogic JMS Thin Client for more information.

Accessing Foreign JMS Providers

Using the Foreign JMS Server node on the Administration Console, you can quickly map a foreign JMS provider so that its connection factories and destinations appear in the WebLogic JNDI tree as a local JMS objects. A Foreign JMS Server configuration can also be used to reference remote instances of WebLogic Server in another cluster or domain in the local WebLogic JNDI tree. See "Accessing Foreign JMS Providers" in the Administration Console Online Help for more information.

Accessing JMS via Servlets and EJBs

New "wrappers" make it easier to use JMS inside a J2EE component. The wrappers provide features including automatic pooling of JMS Connection and Session objects (and some pooling of MessageProducer objects as well); automatic transaction enlistment for JMS providers that support XA; monitoring of the JMS connection and re-establishment after a failure; and security credentials that are managed by the container. See Using WebLogic JMS with EJBs and Servlets for more information.

Better Expired Message Handling

Active message expiration ensures that expired messages are cleaned up immediately. Moreover, expired message auditing gives you the option of tracking expired messages, either by logging when a message expires or by redirecting expired messages to a special destination. See "Handling Expired Messages" in the Administration Console Online Help for more information.

Improved Message Flow Control by Blocking Producers

The "Blocking Send" features help you to avoid receiving message quota errors by temporarily blocking message producers from sending messages to a destination (queue or topic) when the destination has exceeded its specified maximum message quota. See "Avoiding Quota Exceptions by Blocking Message Producers" in the Administration Console Online Help for more information.