9 WebLogic Server Messaging

The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems. JMS simplifies application development by providing a standard interface for creating, sending, and receiving messages.

This chapter includes the following topics:

Overview of JMS and WebLogic Server

The WebLogic Server implementation of JMS is an enterprise-class messaging system that is tightly integrated into the WebLogic Server platform and fully supports the JMS 2.0 Specification. The JMS 2.0 Specification is available at http://www.oracle.com/technetwork/java/jms/index.html. WebLogic JMS provides numerous WebLogic JMS Extensions that go beyond the standard JMS APIs.

Java Message Service

An enterprise messaging system enables applications to asynchronously 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 that is implemented by industry messaging providers. Specifically, JMS:

  • Enables Java applications that share a messaging system to exchange messages

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

WebLogic JMS supports both client and server applications; in addition to Java, it has client libraries for C APIs and Microsoft .NET. WebLogic JMS accepts messages from producer applications and delivers them to consumer applications. For more information on JMS API programming with WebLogic Server, see Developing JMS Applications for Oracle WebLogic Server. For information about JMS API programming for WebLogic Server hosted consumer applications, see Developing Message-Driven Beans for Oracle WebLogic Server.

WebLogic JMS Architecture and Environment

The following figure illustrates the WebLogic JMS architecture.

Figure 9-1 WebLogic JMS Architecture

Description of Figure 9-1 follows
Description of "Figure 9-1 WebLogic JMS Architecture"

In the preceding figure, A1 and B1 are connection factories, and B2 is a queue.

The major components of the WebLogic JMS architecture include:

  • JMS server: a managed message container for a set of JMS queues and topics. Destination configuration is located in JMS XML modules that can target one or more JMS servers, and a single logical destination can be distributed across multiple JMS servers. A JMS server's primary responsibility for its targeted destinations is to maintain information on what persistent store is used for any persistent messages that arrive on the destinations, and to maintain the states of durable subscribers created on the destinations. You can configure one or more JMS servers per domain, multiple JMS servers may run on the same WebLogic server, and a JMS server can manage one or more JMS modules. See Overview of JMS Servers in Administering JMS Resources for Oracle WebLogic Server.

  • JMS connection hosts and connection factories: any WebLogic server in a cluster can act as a JMS connection host for JMS applications. A JMS application gains access to WebLogic JMS by (a) obtaining a connection factory reference from JNDI, (b) obtaining a connection from this factory, and finally (c) using the connection to send or receive messages. JMS messages flow from an application, through its connection host, and then to any destination on a JMS server that is in the same cluster as the connection host. An application can use either default connection factories or custom connection factories that are configured using a JMS module.

  • JMS destinations: hold JMS messages and are hosted on JMS servers. WebLogic JMS applications typically obtain JMS destination references via JNDI and then send and receive messages to these destinations using their respective JMS connections. A single logical WebLogic destination can be configured to be distributed across multiple JMS servers within the same cluster. A WebLogic JMS client can transparently communicate with any WebLogic JMS destination that is hosted in the same cluster as the client's connection host.

  • JMS modules: contain configuration resources, such as standalone queue and topic destinations, distributed destinations, and connection factories, and are defined by XML documents that conform to the weblogic-jms.xsd schema. See What are JMS Configuration Resources? in Administering JMS Resources for Oracle WebLogic Server.

  • Client JMS applications: either produce messages to destinations or consume messages from destinations.

  • JNDI (Java Naming and Directory Interface): provides a lookup facility for JMS connection factories and destinations.

  • WebLogic persistent storage: a server instance's default store, a user-defined file store, or a user-defined JDBC-accessible store for storing persistent message data.

Roadmap for WebLogic Server Messaging

The WebLogic Server documentation set includes several introductory, procedural, and reference topics, including examples, that help you understand how to develop and administer WebLogic JMS resources.

Table 9-1 Roadmap for WebLogic Server Messaging

Major Task Subtasks and Additional Information

Learning more about WebLogic Server messaging

Getting started with WebLogic JMS

Using new WebLogic JMS features

Programming WebLogic messaging

Understanding clients for WebLogic messaging

Configuring WebLogic messaging

Using the WebLogic Server Administration Console to configure WebLogic messaging

Performance and tuning