|
Introduction to WebLogic JMS
The following sections provide an overview of the WebLogic Java Messaging Service (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:
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.
WebLogic JMS provides a full implementation of the JMS API. Specifically, WebLogic JMS:
The following figure illustrates the WebLogic JMS architecture.
Figure 1-2 WebLogic JMS Architecture
The major components of the WebLogic JMS Server architecture, as illustrated in the figure WebLogic JMS Architecture, include:
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 Queues and Topics are still managed by individual WebLogic Server instances in the cluster. For detailed information about WebLogic clustering, see the Using WebLogic Server Clusters.
The advantages of clustering include:
A system administrator can establish load balancing of destinations across multiple JMS 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.
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.
Note: Automatic failover is not supported by JMS for this release. For information about performing a manual failover, refer to "Recovering from a WebLogic Server Failure" on page 3-5.
In addition to the API specified by the JavaSoft JMS specification version 1.0.2, WebLogic JMS provides a public API, weblogic.jms.extensions, that includes classes and methods for the extensions described in the following table.
Refer to Step 6a: Create the Message Object (Message Producers) |
|
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 |
Refer to Using the JMSHelper Class Methods |
|
Convert between WebLogic JMS 6.0 and pre-6.0 JMSMessageID formats |
Refer to Setting Message Header Fields |
This API also supports NO_ACKNOWLEDGE and MULTICAST_NO_ACKNOWLEDGE acknowledge modes, and extended exceptions, including throwing an exception:
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|