9 WebLogic Server Messaging
This chapter includes the following sections:
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 2.0 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:
-
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 on JMS API programming for WebLogic Server hosted consumer applications, see Developing Message-Driven Beans for Oracle WebLogic Server.
WebLogic JMS Architecture and Environment
Figure 9-1 illustrates the 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 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.xsdschema. For more information, 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
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 |
|
|
Reference |