Skip Headers
Oracle® Fusion Middleware Configuring and Managing the Messaging Bridge for Oracle WebLogic Server
12c Release 1 (12.1.1)

Part Number E24375-01
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

3 Designing a Messaging Bridge

This chapter describes how to design, configure, and tune a Messaging Bridge.

This chapter includes the following sections:

When to use a Messaging Bridge

The following sections provide information on when to use a messaging bridge:

Store and Forward Messaging

A messaging bridge provides high availability for remote destinations. Store and forward messaging enables a local client to produce to a local destination and have those messages automatically forwarded to the remote destination when it is available. This allows a local client to continue to produce messages when a remote destination is not available. See Messaging Persistence.

Use the WebLogic Messaging Bridge to provide an administrative solution to store and forward messages between:

  • Any two implementations of WebLogic JMS, including those from separate releases of WebLogic Server.

  • WebLogic JMS implementations that reside in separate WebLogic domains.

  • WebLogic JMS with a third-party JMS product (for example, MQSeries).

Replicating a Topic

A messaging bridge can replicate a topic, similar to using the distributed topics feature available in WebLogic Server releases, consequently improving scalability and high availability in some scenarios. (For information about using distributed topics, see "Using Distributed Destinations" in Programming JMS for Oracle WebLogic Server.) Topic replication is accomplished by configuring the bridge to subscribe to one topic and forward the topic's messages to another topic, in essence creating two topics with the same message stream. See "Create messaging bridge instances" in Oracle WebLogic Server Administration Console Help.

When to Avoid using a Messaging Bridge

The following sections provide information on when to avoid using messaging bridge:

Table 3-1 summarizes information on when to use WebLogic Messaging Bridge or other forwarding technologies:

Table 3-1 Comparing Message Forwarding Technologies

Feature Messaging Bridge Message Driven Beans WebLogic Store-and-Forward

Implementation mechanism

Administrative

Programmatic

Administrative

Support for foreign and legacy providers

Yes

No

No, use to forward messages between WebLogic 9.0 and higher domains.


Selecting a Quality-of-Service (QOS) Level

The WebLogic Messaging Bridge supports three different QOS levels:

In some instances, the target destination may not be able to provide the quality of service configured for the bridge. In these cases, configure the bridge instance to allow the quality of service to be degraded by setting the QOSDegradationAllowed flag. See "Create messaging bridge instances" in Oracle WebLogic Server Administration Console Help.

Messaging Persistence

Store-and-forward messaging enables a local JMS client to produce messages to a local destination and have those messages automatically forwarded to a remote destination when it is available. The bridge forwards these messages to the target destination when it is restarted. A messaging bridge stores and forwards messages to a target destination under the following conditions:

Message Ordering

If an application message is in a transaction, saving the message in the persistent store must be part of the user transaction to preserve exactly-once semantics. In particular, the message is removed from the persistent store as part of the transaction rollback if the application decides to rollback the transaction. However, forwarding is not part of the application transaction. The sending agent does not forward a transactional message until the transaction commits. Within a transaction, message ordering is preserved based on when the messages are sent.

To ensure message ordering, configure a message unit-of-order. See "Using Message Unit-of-Order" in Programming JMS for Oracle WebLogic Server.

Setting the Number of Connection Factories

Consider modifying the capacity of the connection factory associated with each resource adaptor by adjusting the max-capacity attribute in the weblogic-ra.xml descriptor file. In general, the value of the max-capacity attribute should be at least two times the number of bridge instances. For example, if your environment has up to ten message bridge instances targeted, a max-capacity attribute setting of 20 in the default configuration is adequate. But if you increase the number of bridge instances to 15, increase the max-capacity attribute to 30.

Note:

Do not change Message Bridge adapter initial-capacity value. Oracle recommends that the initial-capacity value be set to zero (the default) as bridge instances may fail to function with ResourceAllocation errors.

Use the following steps to modify the weblogic-ra.xml descriptor file:

  1. Using the editor of your choice, update the attribute with the desired value. See Example 3-1.

  2. Deploy the updated adapter.

  3. Stop and restart any bridge instance that requires the new values.

Example 3-1 Example weblogic-ra.xml Descriptor File

<weblogic-connection-factory-dd>

     <connection-factory-name>WLSJMSConnectionFactoryLocal</connection-factory-name>
     <jndi-name>eis/jms/WLSConnectionFactoryJNDILocal</jndi-name>
          <pool-params>
               <initial-capacity>0</initial-capacity>
               <max-capacity>20</max-capacity>
          </pool-params>

</weblogic-connection-factory-dd>

Preserving Message Properties

Set PreserveMsgProperty to preserve message properties in a message header when a message is forwarded by a bridge instance. In previous releases, message properties are inherited from the Default Delivery Mode attribute on the connection factory used when a message is forwarded to its target destination. If the Default Delivery Mode is persistent, a non-persistent message is forwarded as a persistent message resulting in a significant performance loss.

When PreserveMsgProperty is enabled, an incoming non-persistent message is forwarded by the bridge to the target destination as a non-persistent message and an incoming persistent message is forwarded to the target destination as a persistent message. See "Configure messaging bridge instances" in Oracle WebLogic Server Administration Console Help.

The behavior of a messaging bridge instance is determined according to the following guidelines:

Table 3-2 Message Properties Preserved at Target Destination by WebLogic Server Release

Property WebLogic Server 9.0 and Higher Prior to WebLogic Server 9.0 Foreign JMS Servers

Message ID

Yes

No

No

Timestamp

Yes

No

No

User ID

Yes

No

No

Delivery Mode

Yes

Yes

Yes

Priority

Yes

Yes

Yes

Expiration Time

Yes

Yes

Yes

Redelivery Limit

Yes

No

No

Unit-of-Order name

Yes

No

No


Using the JMSXUserID Property with a Messaging Bridge

The messaging bridge does not disclose a message's JMSXUserID across messaging bridge boundaries. A JMSXUserID is a system generated property that identifies the user sending the message, see the JMS Specification, published by Oracle, at http://www.oracle.com/technetwork/java/jms/index.html.

Using Distributed Destinations as Source and Target Destinations

A messaging bridge can send to and receive from "distributed destinations". Oracle recommends the following configurations:

Tuning a WebLogic Messaging Bridge

The main objective when tuning a messaging bridge is to improve overall messaging performance. Raw speed, though important, is only one of several performance-related factors. Other performance factors include reliability, scalability, manageability, monitoring, user transactions, message-driven bean support, and integration with an application server. See "Tuning WebLogic Message Bridge" in Performance and Tuning for Oracle WebLogic Server.