Skip Headers
Oracle® Fusion Middleware Understanding Oracle WebLogic Server
12c Release 1 (12.1.1)

Part Number E24446-03
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

9 WebLogic Server Messaging

This chapter describes the Java Messaging System (JMS) in WebLogic Server.

This chapter includes the following sections:

Overview of JMS and WebLogic Server

Java Message Service

Roadmap for WebLogic Server Messaging

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. It fully supports the JMS 1.1 Specification, available at http://www.oracle.com/technetwork/java/jms/index.html, and also 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:

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 Programming JMS for Oracle WebLogic Server. For information on JMS API programming for WebLogic Server hosted consumer applications, see Programming Message-Driven Beans for Oracle WebLogic Server.

WebLogic JMS Architecture and Environment

Figure 9-1 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 Figure 9-1, 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. For more information, see "Overview of JMS Server" in Configuring and Managing JMS 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. For more information, see "What are JMS Configuration Resources?" in Configuring and Managing JMS 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

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 Administration Console to configure WebLogic messaging

Performance and tuning

Reference