Administration Guide

Using the WebLogic Messaging Bridge

The following sections explain how to configure and manage a WebLogic Messaging Bridge:

• What Is a Messaging Bridge?

• Messaging Bridge Configuration Tasks

• Using the Messaging Bridge to Interoperate with Different WebLogic Server Releases and Domains

• Using the Messaging Bridge to Access a Third-Party Messaging Provider

• Managing a Messaging Bridge

What Is a Messaging Bridge?

The WebLogic Messaging Bridge allows you to configure a forwarding mechanism between any two messaging products—thereby, providing interoperability between separate implementations of WebLogic JMS or between WebLogic JMS and another messaging product. You can use the WebLogic Messaging Bridge to integrate your messaging applications 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).

• WebLogic JMS with non-JMS messaging products (only by using specialized adapters that are not provided with WebLogic Server).

A messaging bridge consists of two destinations that are being bridged: a source destination from which messages are received, and a target destination to which messages are forwarded. For WebLogic JMS and third-party JMS products, a messaging bridge communicates with source and target destinations using the resource adapters provided with WebLogic Server. For non-JMS messaging products, a custom adapter must be obtained from a third-party OEM vendor or by contacting BEA Professional Services in order to access non-JMS source or target destinations.

Source and target bridge destinations can be either queues or topics. You can also specify a quality of service (QOS), as well as message filters, transaction semantics, and connection retry policies. Once a messaging bridge is configured, it is easily managed from the Administration Console, including temporarily suspending bridge traffic whenever necessary, tuning the execute thread pool size to suit your implementation, and monitoring the status of all your configured bridges.

Messaging Bridge Configuration Tasks

Before you can deploy a messaging bridge, you need to configure its required components:

• About the Bridge's Resource Adapters

• Deploying the Bridge's Resource Adapters

• Configuring the Source and Target Bridge Destinations

• Configuring a Messaging Bridge Instance

About the Bridge's Resource Adapters

The messaging bridge uses resource adapters to communicate with source and target JMS destinations. You need to associate both the source and target JMS destinations with a supported adapter in order for the bridge to communicate with them. The JNDI name for the adapter is configured as part of the adapter's deployment descriptor.

Note: Although WebLogic JMS includes a "General Bridge Destination" framework for accessing non-JMS messaging products, WebLogic Server does not provide supported adapters for such products. Therefore, you must obtain a custom adapter from a third-party OEM vendor and consult their documentation for configuration instructions. You can also contact BEA Professional Services for information about obtaining a custom adapter.

The supported adapters are located in the WL_HOME\server\lib directory and are described in the following table.

You will specify the appropriate adapter by its JNDI name when you configure each source and target bridge destination on the Administration Console.

Deploying the Bridge's Resource Adapters

Before you configure the messaging bridge components, deploy the appropriate resource adapters in the WebLogic Server domain that is hosting the messaging bridge, using either of the following methods:

• On the Administration Console — Select the Domain in which you will be deploying the adapters in, and then select Deployments —> Applications option, and then select the appropriate RAR adapter file, as defined in Table 10-1.

  • jms-xa-adp.rar

  • jms-notran-adp.rar

  • jms-notran-adp51.rar (Deprecated)

• Using the Auto Deployment feature — This method is used for quickly deploying an application on the administration server. By copying the adapters to the local \applications directory of the administration server, they will be automatically deployed if the server is already running. Otherwise, they will be deployed the next time you start WebLogic Server. The auto deployment method is used only in a single-server development environment for testing an application, and is not recommended for use in production mode.

Note: When configuring a messaging bridge to interoperate between WebLogic Server release 7.0 and release 5.1, then the release 5.1 resource adapter (jms-notran-adp51.rar) and the non-transaction adapter (jms-notran-adp.rar) must be deployed on the 7.0 domain running the messaging bridge.

For step-by-step instructions on deployment tasks using the Administration Console, or for more information on using the auto-deployment feature, see "WebLogic Server Deployment" in Developing WebLogic Server Applications.

Configuring the Source and Target Bridge Destinations

A messaging bridge connects two actual destinations that are mapped to bridge destinations: a source destination from which messages are received, and a target destination to which messages are sent. Depending on the messaging products that need to be bridged, there are two types of bridge destinations:

• JMS Bridge Destination - For JMS messaging products, whether it is a WebLogic JMS implementation or a third-party JMS provider, you need to configure a JMSBridgeDestination instance for each actual source and target JMS destination being mapped to a messaging bridge.

• General Bridge Destination - For non-JMS messaging products, you need to configure a generic BridgeDestination instance for each actual source and target destination being mapped to a messaging bridge.

Before starting the procedure in this section, refer to the Using the Messaging Bridge to Interoperate with Different WebLogic Server Releases and Domains for specific configuration requirements and guidelines.

Configuring a JMS Bridge Destination

A JMSBridgeDestination instance defines a unique name for the actual JMS queue or topic destination within a WebLogic domain, the name of the adapter used to communicate with the specified destination, property information to pass to the adapter (Connection URL, Connection Factory JNDI Name, etc.), and, optionally, a user name and password.

You need to configure a JMSBridgeDestination instance for each actual source and target JMS destination to be mapped to a messaging bridge. Therefore, when you finish defining attributes for a source JMS bridge destination, repeat these steps to configure a target JMS bridge destination, or vice versa. You will designate the source and target JMS Bridge Destinations in Configuring a Messaging Bridge Instance.

To configure a JMS bridge destination, follow these steps.

1. In the Administration Console, click the Messaging Bridge node.

2. Click the JMS Bridge Destinations node to open the Bridge Destinations tab in the right pane.

3. In the right pane, click the Configure a new JMS Bridge Destination link. A Configuration dialog shows the tabs associated with configuring a new JMS bridge destination.

4. Define the attributes in the Configuration tab.

   The following table describes the attributes you set on the Configuration tab.

   Table 10-2 JMS Bridge Destination Attributes on the Configuration Tab

   Attribute	Description
   Name	A JMS bridge destination name for the actual JMS destination being mapped to the bridge. This name must be unique across a WebLogic domain. For example, if you are bridging between WebLogic Server releases 6.1 and 7.0, for the source destination you could change the default bridge destination name to "70to61SourceDestination". Then, when you create the corresponding target destination, you could name it as "70to61TargetDestination". Once the bridge destinations are configured, these names are listed as options in the Source Destination and Target Destination attributes on the Bridges —> General tab.
   Adapter JNDI Name	The JNDI name of the adapter used to communicate with the bridge destinations. For more information on which adapter name to enter, see Messaging Bridge Adapters and JNDI Names.
   Adapter Classpath	When connecting to a destination that is running on WebLogic Server 6.0 or earlier, the bridge destination must supply a CLASSPATH that indicates the locations of the classes for the earlier WebLogic Server implementation. When connecting to a third-party JMS provider, the bridge destination must supply the provider's CLASSPATH in the WebLogic Server CLASSPATH.
   Connection URL	The URL of the JNDI provider used to look up the connection factory and destination.
   Initial Context Factory	The factory used to get the JNDI context.
   Connection Factory JNDI Name	The JMS connection factory used to create a connection for the actual JMS destination being mapped to the JMS bridge destination. Note: In order to use the Exactly-once QOS, the connection factory has to be a XAConnection Factory. For more information about connection factory and QOS requirements, see Messaging Bridge Attributes on the General Tab.
   Destination JNDI Name	The JNDI name of the actual JMS destination being mapped to the JMS bridge destination.
   Destination Type	Select either a Queue or Topic destination type.
   User Name and Password	The user name and password that the messaging bridge will give to the bridge adapter. Note: All operations done to the specified destination are done using that user name and password. Therefore, the User Name/Password for the source and target destinations must have permission to access the underlying JMS destinations in order for the messaging bridge to work.

   
    

5. Click Create to create the JMS bridge destination.

6. When you finish defining attributes for a source JMS bridge destination, repeat these steps to configure a target JMS bridge destination, or vice versa.

Configuring a General Bridge Destination

A general BridgeDestination instance defines a unique name for the actual queue or topic destination within the WebLogic domain, the name of the resource adapter used to communicate with the specified destination, a list of properties to pass to the adapter, and, optionally, a user name and password.

Note: Although WebLogic JMS includes a "General Bridge Destination" framework for accessing non-JMS messaging products, WebLogic Server does not provide supported adapters for such products. Therefore, you must obtain a custom adapter from a third-party OEM vendor and consult their documentation for configuration instructions. You can also contact BEA Professional Services for information about obtaining a custom adapter.

You need to configure a BridgeDestination instance for each actual source and target destination to be mapped to a messaging bridge. You will designate the source and target general bridge destinations in Configuring a Messaging Bridge Instance.

To configure a general bridge destination, follow these steps:

1. In the Administration Console, click the Messaging Bridge node.

2. Click the General Bridge Destinations node to open the Bridge Destinations tab in the right pane.

3. In the right pane, click the Configure a new General Bridge Destination link. A Configuration dialog shows the tabs associated with configuring a new general bridge destination.

4. Define the attributes in the Configuration tab.

   The following table describes the attributes you set on the Configuration tab.

   Table 10-3 General Bridge Destination Attributes on the Configuration Tab

   Attribute	Description
   Name	A bridge destination name for the actual destination being mapped to the bridge. This name must be unique across a WebLogic domain. For example, if you are bridging between WebLogic Server releases 6.1 and 7.0, for the source destination you could change the default bridge destination name to "70to61SourceDestination". Then, when you create the corresponding target destination, you could name it as "70to61TargetDestination". Once the bridge destinations are configured, these names are listed as options in the Source Destination and Target Destination attributes on the Bridges —> General tab.
   Adapter JNDI Name	A bridge destination must supply the JNDI name of the adapter used to communicate with the bridge destinations. WebLogic Server does not provide adapters for non-JMS messaging products. Therefore, you must use a specialized adapter from a third-party OEM vendor, or contact BEA Professional Services to obtain a custom adapter.
   Adapter Classpath	Defines the CLASSPATH of the bridge destination. This is attribute is mainly used to connect to a destination running on WebLogic Server 6.0 or earlier. When connecting to a third-party product, you must supply the product's CLASSPATH in the WebLogic Server CLASSPATH.
   Properties	Specifies all the properties defined for a bridge destination. Each property must be separated by a semicolon (for example, DestinationJNDIName=myTopic;DestinationType=topic;). For non-JMS messaging products that use adapters provided by a third-party OEM vendor, you should consult the vendor's documentation for property configuration instructions. The following properties are required for all JMS implementations: ConnectionURL= URL used to establish a connection to the destination. InitialContextFactory= Factory used to get the JNDI context. ConnectionFactoryJNDIName= The JMS connection factory used to create a connection for the actual JMS destination being mapped to the JMS bridge destination. DestinationJNDIName= The JNDI name of the actual JMS destination being mapped to the JMS bridge destination. DestinationType= Queue or topic.
   User Name and Password	The user name that the messaging bridge will give to the bridge adapter. Note: All operations done to the specified destination are done using this user name and password. Therefore, the User Name/Password for the source and target bridge destinations must have permission to access the underlying source and target destinations in order for the messaging bridge to work.

   
    

5. Click Create to create the general bridge destination.

6. When you finish defining attributes for a source general bridge destination, repeat these steps to configure a target general bridge destination, or vice versa.

Configuring a Messaging Bridge Instance

A messaging bridge instance communicates with the configured source and target bridge destinations. For each mapping of a source destination to a target destination, whether it is another WebLogic JMS implementation, a third-party JMS provider, or another non-JMS messaging product, you must configure a MessagingBridge instance via the Administration Console. Each MessagingBridge instance defines the source and target destination for the mapping, a message filtering selector, a QOS, transaction semantics, and various reconnection parameters.

Before starting the procedure in this section, refer to the Using the Messaging Bridge to Interoperate with Different WebLogic Server Releases and Domains or Using the Messaging Bridge to Access a Third-Party Messaging Provider for specific configuration requirements and guidelines.

To configure a messaging bridge, follow these steps:

1. In the Administration Console, click the Messaging Bridge node.

2. Click the Bridges node to open the Bridges tab in the right pane.

3. Click the Configure a new Messaging Bridge link in the right pane. A Configuration dialog shows the tabs associated with configuring a new messaging bridge.

4. Define the attributes in the General tab.

   The following table describes the attributes you set on the General tab.

   Table 10-4 Messaging Bridge Attributes on the General Tab

   Attribute	Description
   Name	Enter a name for the messaging bridge that is unique across a WebLogic domain.
   Source Destination	Select the source destination from which messages are received by the messaging bridge. For example, for a JMS messaging bridge, you should select the "JMS Source Bridge Destination" name that you created on the JMS Bridge Destination —> Configuration tab.
   Target Destination	Select the target destination to which messages are sent from the messaging bridge. For example, for a JMS messaging bridge, you should select the "JMS Target Bridge Destination" name that you created on the JMS Bridge Destination —> Configuration tab.
   Selector	Allows you to filter the messages that are sent across the messaging bridge. Only messages that match the selection criteria are sent across the messaging bridge. For queues, messages that do not match the selection criteria are left behind and accumulate in the queue. For topics, messages that do not match the connection criteria are dropped. For more information on using selectors to filter messages, see "Developing a WebLogic JMS Application" in Programming WebLogic JMS.
   Quality Of Service (QOS)	Select a QOS guarantee for forwarding a message across a messaging bridge. The valid qualities of service are: Exactly-once—Each message will be sent exactly once. This is the highest quality of service. In order to use this QOS: Any WebLogic Server implementation must be release 6.1 or later. The source and target JMS connection factories must be configured to use the XAConnectionFactory. The transaction jms-xa-adp.rar adapter must be deployed and identified in the Adapter JNDI Name attribute as "eis.jms.WLSConnectionFactoryJNDIXA" for both the source and target destinations. Atmost-once—Each message is sent at most one time. Some messages may not be delivered to the target destination. Duplicate-okay—Each message is sent at least one time. Duplicate messages can be delivered to the target destination.
   QOS Degradation Allowed	When selected, the messaging bridge automatically degrades the requested QOS when the configured one is not available. If this occurs, a message is delivered to the WebLogic startup window (or log file). If this option is not selected (false), and the messaging bridge cannot satisfy the requested QOS, it will result in an error and the messaging bridge will not start.
   Maximum Idle Time (seconds)	For bridges running in asynchronous mode, this is the maximum amount of time, in seconds, the messaging bridge sits idle before checking the health of its connections. For bridges running in synchronous mode, this dictates the amount of time the messaging bridge can block on a receive call if no transaction is involved.
   Asynchronous Mode Enabled	Defines whether a messaging bridge works in asynchronous mode. Messaging bridges that work in asynchronous mode (true) are driven by the source destination. The messaging bridge listens for messages and forwards them as they arrive. When the value is false, the bridge works in synchronous mode even if the source supports asynchronous receiving. Note: For a messaging bridge with a QOS of Exactly-once to work in asynchronous mode, the source destination has to support the MDBTransaction interface described in the weblogic.jms.extensions Javadoc. Otherwise, the bridge automatically switches to synchronous mode if it detects that MDBTransactions are not supported by the source destination. For more information about MDBTransactions, see "Using Message-Driven Beans" in Programming WebLogic Enterpise Java Beans.
   Durability Enabled	This attribute is used only for JMS topics or for destinations with similar characteristics as a JMS topic. By enabling durability, a messaging bridge creates a durable subscription for the source destination. This allows the source JMS implementation to save messages that are sent to it when the bridge is not running. The bridge will then forward these messages to the target destination once it is restarted. If this attribute is not selected, messages that are sent to the source JMS topic while the bridge is down cannot be forwarded to the target destination. Note: If a bridge must be taken permanently offline, you must delete any durable subscriptions that use the bridge. For information on deleting durable subscribers, see "Deleting Durable Subscriptions" in Programming WebLogic JMS.
   Started	Indicates the initial state of the messaging bridge when it is configured and whenever the server is restarted. You can also use this field to dynamically start and stop the messaging bridge. To stop the bridge, clear the check box. Conversely, reselect the check box to restart the bridge. Note: Unless there is a configuration issue that prevents the messaging bridge from starting, this field indicates the expected run-time state of the messaging bridge. For information on monitoring all the configured messaging bridges in your domain, see Monitoring Messaging Bridges.

   
    

5. Click Create to create the messaging bridge.

6. On the Connection Retry tab, define the bridge's reconnection time intervals according to the following table.

   The source and target destinations for a messaging bridge will not always be available. As such, the messaging bridge must be able to reconnect to the destination at some periodic interval. These attributes govern the time between reconnection attempts.

   Table 10-5 Messaging Bridge Attributes on the Connection Retry Tab

   Attribute	Description
   Minimum Delay (seconds)	The minimum delay, in seconds, between reconnection attempts. When a messaging bridge boots and cannot connect to a destination, or a connection is lost and the messaging bridge is first attempting to reconnect, it attempts to reconnect in this specified amount of seconds.
   Incremental Delay (seconds)	The delay increment, in seconds, between reconnection attempts. Each time a bridge fails to reconnect, it adds this amount of seconds to the delay before making its next reconnection attempt.
   Maximum Delay (seconds)	The maximum delay, in seconds, between reconnection attempts. Each reconnection attempt is delayed further by the Incremental Delay amount of seconds, but it is never delayed by more than this value.

   
    

7. Click Apply to store new attribute values.

8. On the Transactions tab, define the transaction attributes for the messaging bridge according to the following table.

   Table 10-6 Messaging Bridge Attributes on the Transactions Tab

   Attribute	Description
   Transaction Timeout	Defines the number of seconds the transaction manager waits for each transaction before timing it out. Transaction timeouts are used when a bridge's quality of service requires two-phase transactions.
   Batch Size	Defines the number of messages that the messaging bridge transfers within one transaction. Batch Size only applies to bridges that work in synchronous mode and whose quality of service require two-phase transactions.
   Batch Interval (milliseconds)	Defines the maximum time, in milliseconds, that the bridge waits before sending a batch of messages in one transaction, regardless of whether the Batch Size amount has been reached or not. The default value of -1 indicates that the bridge will wait until the number of messages reaches the Batch Size before it completes a transaction. Batch Interval only applies to bridges that work in synchronous mode and whose quality of service require two-phase transactions.

   
    

9. Click Apply to store new attribute values.

10. On the Targets tab, assign WebLogic Server instances to associate with the messaging bridge according to the following table.

    Table 10-7 Messaging Bridge Attributes on the Targets Tab

    Attribute	Description
    Migratable Targets	Defines a WebLogic Server migratable target where the messaging bridge will be deployed. When WebLogic Server is first booted, the messaging bridge initially is available only on the user-preferred server. Afterwards, the bridge can be migrated to another server in the migratable target using either the Administration Console or the command-line tool. For more information, see "Migration for Pinned Services" in Using WebLogic Server Clusters.
    Clusters	Defines a WebLogic Server cluster where the messaging bridge will be deployed. The messaging bridge will be available on all servers in the selected cluster.
    Servers	Defines the WebLogic Servers where the messaging bridge will be deployed. The messaging bridge will be available on all the selected WebLogic Servers.

    
     

11. Click Apply to store new attribute values.

Using the Messaging Bridge to Interoperate with Different WebLogic Server Releases and Domains

The following interoperability guidelines apply when using the messaging bridge to access JMS destinations in different releases of WebLogic Server and in other WebLogic Server domains.

• Naming Guidelines for WebLogic Servers and Domains

• Message Properties

• Configuring Interoperability for WebLogic Domains

• Using the Messaging Bridge To Access Destinations In a Release 6.1 or Later Domain

• Using the Messaging Bridging To Access Destinations In a Release 6.0 Domain

• Using the Messaging Bridging To Access Destinations In a Release 5.1 Domain

Note: When the messaging bridge is used to communicate between two domains running different releases of Weblogic Server, a best-practice recommendation is for the messaging bridge to be configured to run on the domain using the latest release of Weblogic Server.

Naming Guidelines for WebLogic Servers and Domains

Unique naming rules apply to all WebLogic Server deployments if more than one domain is involved. Therefore, make sure that:

• WebLogic Server instances and domain names are unique.

• WebLogic JMS server names are unique name across domains.

• All JMS connection factories targeted to servers in a cluster are uniquely named.

• If a JMS file store is being used for persistent messages, the JMS file store name must be unique across domains.

Message Properties

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.

If you configure a bridge instance to forward non-persistent messages, configure and use a connection factory that has the Default Delivery Mode set to Non-Persistent.

Configuring Interoperability for WebLogic Domains

Unless the Exactly-once QOS (quality of service) is required for handling two-phase transactions sent across the messaging bridge, there are no special security configuration requirements for the bridge to interoperate between two release 6.1 or later domains.

However, you must follow these steps when a bridge running on release 7.0 domain must handle transactional messages (using the Exactly-once QOS) between two release 6.1 or later domains

1. For each server participating in the transaction, set the Security Interoperability Mode flag according to Table 7-2 before rebooting. See Using Security Interoperability Mode.

   Note: When Security Interoperability Mode is set to performance, you are not required to set domain trust between the domains.

2. Configure domain trust for the all participating bridge domains.

   1. In all participating WebLogic Server 6.x domains, change the password for the system user to the same value in all participating domains on the Security—>Users tab in the Administration Console. See Changing the System Password.

   2. Establish domain trust by setting a security credential for all domains to the same value in all participating domains. If you have participating 6.x domains, set the security credential for all domains to the same value as the system password in all participating WebLogic Server 6.x domains.

   • For 7.x domains, see Enabling Trust Between WebLogic Domains in Managing WebLogic Security.

   • For 8.x domains, see Enabling Trust Between WebLogic Domains in Managing WebLogic Security.

   • For 9.x domains, see Enable trust between domains in Administration Console Online Help.

Using the Messaging Bridge To Access Destinations In a Release 6.1 or Later Domain

Use these guidelines when configuring a messaging bridge on a release 7.0 domain to provide "Exactly-once" transactional message communication between two release 6.1 or later domains.

Note: The Exactly-once quality of service for two-phase transactions is only supported for release 6.1 or later.

• If a JMS file store is being used for persistent messages, the JMS file store name must be unique across WebLogic domains, as described in Naming Guidelines for WebLogic Servers and Domains.

• Make sure that interoperability between the domains is correctly configured, as described in Configuring Interoperability for WebLogic Domains.

• Make sure that the transaction connection factory is enabled for both domains by selecting the XAConnection Factory Enabled check box on the Services —> JMS —> Connection Factories —> Configuration —> Transactions tab.

• Deploy the transaction resource adapter, jms-xa-adp.rar, on the 7.0 bridge domain, as described in Deploying the Bridge's Resource Adapters.

• When configuring the JMS bridge destinations, as described in Configuring a JMS Bridge Destination, do the following for both the source and target destinations:

  • In the Adapter JNDI Name field, identify the transaction adapter's JNDI name, eis.jms.WLSConnectionFactoryJNDIXA.

  • Do not enter anything in the Adapter Classpath field.

• On the Messaging Bridge —> Configuration —> General tab, select a Quality Of Service of Exactly-once, as described in Configuring a Messaging Bridge Instance.

Using the Messaging Bridging To Access Destinations In a Release 6.0 Domain

When configuring a messaging bridge involves interoperability between WebLogic Server 7.0 and a release 6.0 domain, you must configure the following items on the release 7.0 domain that the bridge is running on:

Note: The Exactly-once QOS for transactions is not supported for WebLogic Server 6.0. For more information on the bridge QOS options, see Messaging Bridge Attributes on the General Tab.

• Deploy the non-transaction resource adapter, jms-notran-adp.rar on the 7.0 bridge domain, as described in Deploying the Bridge's Resource Adapters.

• When configuring the JMS source and target destinations, as described in Configuring a JMS Bridge Destination, do the following:

  In the Adapter JNDI Name field:

  • For the source and target destinations, specify the non-transaction adapter's JNDI name as eis.jms.WLSConnectionFactoryJNDINoTX.

  In the Adapter Classpath field:

  • For the 7.0 destination, leave the field blank.

  • For the 6.0 destination, indicate the location of the classes for the WebLogic Server 6.0 release.

    For example, if you have WebLogic Server 6.0 GA installed in a directory named WL60_HOME, then set the Adapter Classpath as follows for the 6.0 JMS bridge destination:

    WL60_HOME\lib\weblogic60.jar

• On the Messaging Bridge —> Configuration —> General tab, select a Quality Of Service of Atmost-once or Duplicate-okay, as described in Configuring a Messaging Bridge Instance.

Using the Messaging Bridging To Access Destinations In a Release 5.1 Domain

Note: The jms51-interop.jar file and jms-notran-adp51.rar file are deprecated, see "WebLogic Server 5.1 End-of-Life Announcement" in Supported Configurations.

When configuring a messaging bridge involves interoperability between WebLogic Server 7.0 and release 5.1, you must configure the following on the release 7.0 domain that the bridge is running on:

Note: The Exactly-once QOS for transactions is not supported for WebLogic Server 5.1. For more information on the bridge QOS options, see Messaging Bridge Attributes on the General Tab.

• The jms51-interop.jar file in the WL_HOME\lib directory must be in the CLASSPATH of the WebLogic Server 7.0 implementation.

• The release 5.1 resource adapter (jms-notran-adp51.rar) and the non-transaction adapter (jms-notran-adp.rar) must be deployed on the 7.0 bridge domain, as described in Deploying the Bridge's Resource Adapters.

• When configuring the JMS source and target destinations, as described in Configuring a JMS Bridge Destination, do the following:

  In the Adapter JNDI Name field:

  • For the 7.0 destination, specify the non-transaction adapter's JNDI name as eis.jms.WLSConnectionFactoryJNDINoTX.

  • For the 5.1 destination, specify the 5.1 adapter's JNDI name as eis.jms.WLS51ConnectionFactoryJNDINoTX.

  In the Adapter Classpath field:

  • For the 7.0 destination, leave the field blank.

  • For the 5.1 destination, indicate the location of the classes for the WebLogic Server 5.1 release, as well as the location of the jms51-interop.jar file for the 7.0 release.

    For example, if you have WebLogic Server 5.1 GA installed in a directory named WL51_HOME and your WebLogic Server 7.0 release is installed in WL81_HOME, then set the Adapter Classpath as follows for the 5.1 destination:

    WL51_HOME\classes;WL51_HOME\lib\weblogicaux.jar;
    WL70_HOME\server\lib\jms51-interop.jar

    Note: If your implementation is using a 5.1 Service Pack, the corresponding sp.jar files must also be added to the Adapter Classpath field.

• On the Messaging Bridge —> Configuration —> General tab, select a Quality Of Service of Atmost-once or Duplicate-okay, as described in Configuring a Messaging Bridge Instance.

Using the Messaging Bridge to Access a Third-Party Messaging Provider

When configuring a messaging bridge involves interoperability with a third-party messaging provider, you must configure the following:

• Before starting WebLogic Server:

  • Supply the provider's CLASSPATH in the WebLogic Server CLASSPATH.

  • Include the PATH of any native code required by the provider's client-side libraries in the WebLogic Server system PATH. (This variable may vary depending on your operating system.)

• In the JMSBridgeDestination instance for the third-party messaging product being bridged, provide vendor-specific information in the following attributes:

  • Connection URL

  • Initial Context Factory

  • Connection Factory JNDI Name

  • Destination JNDI Name

Note: The messaging bridge cannot provide the "Exactly-once" quality of service when the source and target bridge destinations are located on the same resource manager (that is, when the bridge is forwarding a global transaction that is using the XA resource of the resource manager). For example, when using MQ Series, it is not possible to use the same Queue Manager for the source and target bridge destinations.

For more information on configuring the remaining attributes for a JMS Bridge Destination, see Configuring a JMS Bridge Destination.

Managing a Messaging Bridge

Once a messaging bridge is up and running, it can managed from the Administration Console.

• Stopping and Restarting a Messaging Bridge

• Monitoring Messaging Bridges

• Configuring the Execute Thread Pool Size

Stopping and Restarting a Messaging Bridge

To temporarily suspend and restart an active messaging bridge:

1. Expand the Messaging Bridge node and the Bridges node.

2. Select the messaging bridge instance that you want to stop.

3. On the Configuration General tab, clear the Started check box to stop the bridge.

4. To restart the bridge, select the Started check box.

Monitoring Messaging Bridges

You can monitor the status of all the messaging bridges in your domain from the Administration Console:

1. Expand the Servers node and select the server instance where the messaging bridges are configured.

2. A dialog displays in the right pane showing the tabs associated with the selected server instance.

3. Select the Services tab.

4. Select the Bridge tab.

5. Click the Monitoring all Messaging Bridge Runtimes text link to display the monitoring data.

6. A table displays showing all the messaging bridge instances for the server and their status (either as running or not running).

Configuring the Execute Thread Pool Size

You can configure the default execute thread pool size for your messaging bridges from the Administration Console. For example, you may want to increase the default size to reduce competition from the WebLogic Server default thread pool. Entering a value of -1 disables this thread pool and forces a messaging bridge to use the WebLogic Server default thread pool.

1. Expand the Servers node.

2. Select the server instance where the messaging bridge is configured. A dialog displays in the right pane showing the tabs associated with the selected server instance.

3. Select the Services tab.

4. Select the Bridge tab.

5. Enter a new value in the Messaging Bridge Thread Pool Size field.

6. Click Apply to save your changes.

For more information about tuning execute threads, see "Tuning WebLogic Server Applications" in the Performance and Tuning Guide.