Skip navigation.
Downloads | Product Documentation | Support

Administration Console Online Help

# Messaging Bridge

[Attributes and Console Screen Reference for Messaging Bridge]

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

- What Is a Messaging Bridge?
- About the Bridge's Resource Adapters
- Configuring a Messaging Bridge
- 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

You may also want to refer these WebLogic JMS sections:

- JMS: Configuring
- JMS: Tuning
- JMS: Monitoring

# 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 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 connector adapters that are not provided with WebLogic Server).

A messaging bridge consists of two destinations that are being bridged: a source destination that the bridge reads messages from and a target destination where the bridge sends the messages that it receives from the source destination. 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 connector 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.

In addition to this document, BEA Systems provides messaging bridge examples that are available for download. Follow the links on the JMS Technology page at http://e-docs.bea.com/wls/docs81/messaging.html. These examples are distributed as `.zip` files that you can unzip into an existing WebLogic Server samples directory structure.

# About the Bridge's Resource Adapters

A messaging bridge uses resource adapters to communicate with the configured source and target JMS destinations. You need to associate both the source and target JMS destinations with a supported resource adapter in order for the bridge to communicate with them. The JNDI name for the adapter is configured as part of the resource 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 connector adapters for such products. Therefore, you must obtain a custom connector 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 connector adapter.

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

Table 119-1 Messaging Bridge Resource Adapters and JNDI Names

Adapter | JNDI Name | Description
--- | --- | ---
`jms-xa-adp.rar` | `eis.jms.WLSConnection FactoryJNDIXA` | Provides transaction semantics via the `XAResource`. Used when the required QOS is Exactly-once. This envelops a received message and sends it within a user transaction (XA/JTA). The following requirements are necessary in order to use this resource adapter: Any WebLogic Server implementation being bridged must be release 6.1 or later. The source and target JMS connection factories must be configured to use the `XAConnectionFactory`. Note: Before deploying this resource adapter, refer to the Using the Messaging Bridge to Interoperate with Different WebLogic Server Releases and Domains for specific transactional configuration requirements and guidelines.
`jms-notran-adp.rar` | `eis.jms.WLSConnection FactoryJNDINoTX` | Provides no transaction semantics. Used when the required QOS is Atmost-once or Duplicate-okay. If the requested QOS is Atmost-once, the resource adapter uses the `AUTO_ACKNOWLEDGE` mode. If the requested QOS is Duplicate-okay, `CLIENT_ACKNOWLEDGE` is used. Note: For more information about the acknowledge modes used in non-transacted sessions, see "WebLogic JMS Fundamentals" in Programming WebLogic JMS.

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

# Configuring a Messaging Bridge

Configuring a messaging bridge consists of the following tasks:

1. Create a Messaging Bridge.
2. Modify a Messaging Bridge Configuration for Your Environment.

When you initially create a message bridge, many attributes are set with the default value. You may need to change message bridge settings to better suit your environment. For example, you may wish to select QOS Degradation Allowed rather than have the messaging bridge use the initially configured QOS.

## Create a Messaging Bridge

Creating a messaging bridge consists of the following tasks:

1. Create source and target bridge destinations.
2. Deploy a resource adaptor.
3. Create a messaging bridge instance.
4. Deploy the messaging bridge.

To simplify these tasks, the Administration Console assists you in creating a messaging bridge by deploying an appropriate resource adaptor and setting the values of some attributes. You may need to review the message bridge configuration and modify some attribute settings to better suit your environment. See Modify a Messaging Bridge Configuration for Your Environment for more information on how to modify an existing messaging bridge.

Note: Click the Help button to access detailed information for each panel.

Use the following steps to configure a messaging bridge instance:

1. Click to expand the Services and Message Bridge nodes.
2. Click the Bridges node.
3. Click Configure a new Messaging Bridge link.
4. Configure the source destination.

- To create a new source destination, click the Create a New Bridge Destination button. Next, follow the instructions at Create a New Destination to create a source destination.
- If you have already configured a source destination, click the Use an Existing Bridge Destination button. Next, follow the instructions at Use an Existing Bridge Destination to configure the source destination for a bridge instance.

5. Configure the target destination.

- To create a new target destination, click the Create a New Bridge Destination button. Next, follow the instructions at Create a New Destination to create a target destination.
- If you have already configured a target destination, click the Use an Existing Bridge Destination button. Next, follow the instructions at Use an Existing Bridge Destination to configure the target destination for a bridge instance.

6. Modify the configuration attributes for your messaging bridge instance. Click the Help button to see detailed information about the attributes on this panel.
7. Click Continue.
8. Select the servers and/or clusters on which you want to deploy your new bridge. See Targeting a Messaging Bridge to a Server, a Cluster, or a Migratable Target for general information on targeting a messaging bridge.
9. Click Continue.

A messaging bridge instance is created. The console checks your configuration and lists any tasks you must perform manually. You may need to perform one or more of the following tasks:

- At least one of the destinations is in a remote Weblogic domain. The "Guest Disabled" check box must not be checked on that domain.
- The "Enable Generated Credential" check box must not be checked. Use the same password as the credential on all Weblogic domains that participate in the bridge.
- The "Enable Generated Credential" check box must not be checked. Use the "system" user's password as the credential on all Weblogic domains that participate in the bridge.
- The "system" user must be configured in all domains with the same password. The "system" must be a member of the Administrators group in the domain where the bridge resides.
- The XA connection factory must be enabled for all domains.
- The jms51-interop.jar file must be in the CLASSPATH of the Weblogic Server 8.1 server instance.

10. Click Finish.
11. If necessary, perform any tasks displayed in Step 9. See Using the Messaging Bridge to Interoperate with Different WebLogic Server Releases and Domains and Using the Messaging Bridge to Access a Third-Party Messaging Provider for additional information on how to resolve these tasks.

### Create a New Destination

Use the following instructions to create a new destination for your messaging bridge instance:

1. Click the Drop-down arrow to view a list of message providers.
2. Select the message provider for your destination.
3. Click Continue.
4. Modify the configuration attributes for your destination. Click the Help button to see detailed information about the attributes on this panel.
5. Click Create the bridge destination.

### Use an Existing Bridge Destination

Use the following instructions to configure your messaging bridge instance for an existing destination:

1. Click the Drop-down arrow to view a list of destinations.
2. Select the destination for your messaging bridge.
3. Click Continue.
4. Click the Drop-down arrow to view a list of message providers.
5. Select the message provider for your destination.
6. Click Continue.

## Modify a Messaging Bridge Configuration for Your Environment

The following sections provide information on how to modify the configuation of individual message bridge components:

- Deploying the Bridge's Resource Adapters
- Configuring Source and Target Bridge Destinations
- Modifying an Existing Messaging Bridge Instance
- Targeting a Messaging Bridge to a Server, a Cluster, or a Migratable Target

### Deploying the Bridge's Resource Adapters

Before you configure the messaging bridge destinations, deploy the appropriate resource adapters in the WebLogic Server domain that is hosting the messaging bridge, as follows:

1. Select the domain in which you will deploy the adapters (for example, Examples).
2. Select the Deployments —> Connector Modules option to open the Resource Connectors page.
3. Follow the deployment assistant instructions to deploy the appropriate resource adapter, as defined in Table 119-1.

- `jms-xa-adp.rar`
- `jms-notran-adp.rar`
- `jms-notran-adp51.rar (Deprecated)`

4. You must target the resource adapter to the same WebLogic Server instance that the messaging bridge will be targeted to. For more information, see Targeting a Messaging Bridge to a Server, a Cluster, or a Migratable Target.

For more information on deploying resource adapters, see "Packaging and Deploying Connectors" in Programming WebLogic Server J2EE Connectors.

### Configuring 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 procedures 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 sections for specific configuration requirements and guidelines.

Note: When configuring third-party JMS provider bridge destination, you can use the Foreign JMS Server feature to quickly configure multiple source or target destinations. For more information, see Simple Access to Remote or Foreign JMS Providers.

#### Configuring JMS Bridge Destinations

A `JMSBridgeDestination` instance defines a unique name for a bridge's source and target destinations 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 Modifying an Existing Messaging Bridge Instance.

To configure a source or target JMS bridge destination, follow these steps.

1. Expand the Services —> Messaging Bridge node.
2. Click the JMS Bridge Destinations node to open the JMS Bridge Destinations page in the right pane.
3. Click the Configure a new JMS Bridge Destination link. A Configuration dialog shows the tabs associated with configuring a new JMS bridge destination.
4. On the Configuration General tab, define the general configuration attributes for a JMS bridge destination:

- Enter 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 8.1, for the source destination you could change the default bridge destination name to "61SourceDestination". Then, when you create the corresponding target destination, you could name it as "81TargetDestination". 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.
- Specify the JNDI name of the resource adapter used to communicate with the messaging bridge destinations:

`eis.jms.WLSConnectionFactoryJNDIXA` (default) — QOS is Exactly-once

`eis.jms.WLSConnectionFactoryJNDINoTX` — QOS is Atmost-once or Duplicate-Okay

For more information on which resource adapter name to use, see Messaging Bridge Resource Adapters and JNDI Names.

- Leave the Adapter Classpath field blank when connecting to source and target destinations that are both running on WebLogic Server 6.1 or later. When connecting to either a source or target destination that is running on WebLogic Server 6.0 or earlier, the Adapter Classpath field must indicate the location of the classes for the earlier WebLogic Server release. When connecting to a third-party JMS provider, the bridge destination must supply the provider's `CLASSPATH` in the WebLogic Server `CLASSPATH`.
- Specify the URL of the JNDI provider used to look up the connection factory and destination.
- Specify the context factory used to get the JNDI context.
- Specify 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 for transactions, the JMS connection factory has to be an XA connection factory. For more information about connection factory and QOS requirements, refer to the Attributes table in Messaging Bridge --> Configuration --> General.

- Specify the JNDI name of the actual JMS destination being mapped to the JMS bridge destination.
- Indicate whether the destination type is either a Queue or Topic.
- Optionally, enter 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.

For more information about JMS bridge destination attributes, see JMS Bridge Destination --> Configuration.

5. Click Create to create an instance of the bridge destination with the name you specified in the Name field. The new instance is added under the JMS Bridge Destination node in the left pane.

When you finish defining attributes for a source JMS bridge destination, repeat these steps to configure a target JMS bridge destination, or vice versa. Then follow the instructions for Modifying an Existing Messaging Bridge Instance.

#### Configuring General Bridge Destinations

A general `BridgeDestination` instance defines a unique name for the actual source and target general bridge destinations within the WebLogic domain, the name of the 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 connector adapters for such products. Therefore, you must obtain a custom connector 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 connector adapter.

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

To configure a source or target general bridge destination, follow these steps.

1. Expand the Services —> Messaging Bridge node.
2. Click the General Bridge Destinations node to open the General Bridge Destinations page in the right pane.
3. Click the Configure a new General Bridge Destination link. A Configuration dialog shows the tabs associated with configuring a new general bridge destination.
4. On the Configuration General tab, define the general configuration attributes for a general bridge destination:

- Enter a general bridge destination name that is unique across a WebLogic Server domain. For example, if you are bridging between WebLogic Server releases 6.1 and 8.1, for the source destination you could change the default destination name to "61SourceDestination". Then when you create the corresponding target destination, you could name it as "81TargetDestination". 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.
- Specify the JNDI name of the adapter used to communicate with the bridge destinations.

`eis.jms.WLSConnectionFactoryJNDIXA` (default) — QOS is Exactly-once

`eis.jms.WLSConnectionFactoryJNDINoTX` — QOS is Atmost-once or Duplicate-Okay

For more information on which resource adapter name to use, see Messaging Bridge Resource Adapters and JNDI Names.

Note: 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.

- Leave the Adapter Classpath field blank when connecting to source and target destinations that are both running on WebLogic Server 6.1 or later. When connecting to either a source or target destination that is running on WebLogic Server 6.0 or earlier, the Adapter Classpath field must indicate the location of the classes for the earlier WebLogic Server release. When connecting to a third-party JMS provider, the bridge destination must supply the provider's `CLASSPATH` in the WebLogic Server `CLASSPATH`.
- Specify all the properties defined for a bridge destination. Each property must be separated by a semicolon (for example, DestinationJNDIName=myTopic;DestinationType=topic;). For a complete listing of the required properties for JMS implementations, refer to the Attributes table in General Bridge Destination --> Configuration.

Note: 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.

- Optionally, enter the user name and password that the messaging bridge will give to the bridge adapter.

Note: The User Name/Password for the source and target destinations must have permission to access the underlying source and target destinations in order for the Messaging Bridge to work.

For more information about the general bridge destination attributes, see General Bridge Destination --> Configuration.

5. Click Create to create an instance of the general bridge destination with the name you specified in the Name field. The new instance is added under the General Bridge Destination node in the left pane.

When you finish defining attributes for a source general bridge destination, repeat these steps to configure a target general bridge destination, or vice versa. Then follow the instructions for Modifying an Existing Messaging Bridge Instance.

### Modifying an Existing Messaging Bridge Instance

Note: 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 sections for specific configuration requirements and guidelines.

To modify a messaging bridge, follow these steps:

1. Expand the Services —> Messaging Bridge node.
2. Expand the Bridges node to open the Messaging Bridges tab in the right pane.
3. Click the messaging bridge that you want to modify. A dialog shows the tabs associated with configuring a new messaging bridge.
4. On the Configuration General tab, define the general configuration attributes for a messaging bridge:

Table 119-2 Messaging Bridge Attributes on the General Tab

Attribute | Description
--- | ---
Name | Enter a messaging bridge name that is unique across a WebLogic Server domain.
Source Destination | Select the source destination from which messages are received by the messaging bridge. Following the example target JMS bridge destination name that was previously suggested for connecting WebLogic Server releases 6.1 and 8.1, you would select the "61SourceDestination" 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. Following the example target JMS bridge destination name that was previously suggested for connecting WebLogic Server releases 6.1 and 8.1, you would select the "81TargetDestination" name that you created on the JMS Bridge Destination -> Configuration tab.
Selector | Specify a selector 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 quality-of-service guarantee for forwarding a message across a messaging bridge. The valid qualities of service are: Exactly-once (default) — 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 | Indicate whether 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 QOS Degradation Allowed is not selected, 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, specify the maximum amount of time the messaging bridge will sit idle before checking the health of its connections. For bridges running in synchronous mode, this determines the amount of time the messaging bridge can block on a receive call if no transaction is involved.
Asynchronous Mode Enabled | Indicate whether a messaging bridge works in asynchronous mode. Messaging bridges that work in asynchronous mode are driven by the source destination. The messaging bridge listens for messages and forwards them as they arrive. When Asynchronous Mode is disabled, 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 EJB.
Durability Enabled | This is used only for JMS topics or for third-party 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 All Messaging Bridges.

For more information about the general messaging bridge attributes, see the Attributes table in Messaging Bridge --> Configuration --> General.

5. Click Apply to save your changes. If you selected the Started check box, the bridge will be in a running state once it is targeted.
6. Optionally, on the Target and Deploy tab, select an independent server instance, a cluster, or a migratable server target on which to deploy the messaging bridge. This must the same target where the bridge's resource adapter was deployed. You can also reconfigure deployment targets later if you wish.

For more information, see Targeting a Messaging Bridge to a Server, a Cluster, or a Migratable Target.

7. Optionally, on the Connection Retry tab, change the attribute fields or accept the default values as assigned. Since the source and target destinations for a messaging bridge will not always be available, the messaging bridge must be able to reconnect to the destination at some periodic interval. These attributes govern the time between reconnection attempts. Then, click Apply to save your changes.

For more information about the bridge's connection retry attributes, see the Attributes table in Messaging Bridge --> Configuration --> Connection Retry.

8. Optionally, on the Transactions tab, change the attribute fields or accept the default values as assigned. Then, click Apply to save your changes.

For more information about the bridge's transaction attributes, see the Attributes table in Messaging Bridge --> Configuration --> Transactions.

### Targeting a Messaging Bridge to a Server, a Cluster, or a Migratable Target

You can choose the servers, clusters, or migratable targets in your domain on which you would like to deploy a messaging bridge. You can also reconfigure deployment targets later if you wish.

1. Expand the Messaging Bridge —> Bridges node to show the list of messaging bridges defined in your domain.
2. Click the messaging bridge that you want to assign to a server, cluster, or migratable target. A dialog displays in the right pane showing the tabs associated with the messaging bridge instance.
3. Click the Target and Deploy tab to display the following targeting options.

- Independent Servers—you can select a server or servers where the messaging bridge will be deployed. The messaging bridge will be available on all the selected servers.
- Clusters—you can select a cluster where the messaging bridge will be deployed. The messaging bridge will be available on all servers in the selected cluster. You can also target an individual server or servers within a cluster.
- Migratable Targets—you can select a WebLogic Server migratable target where the messaging bridge will be deployed. When WebLogic Server is first booted, the messaging bridge is initially available only on the user-preferred server. After that, the bridge can be migrated to another server listed in the migratable target.

Note: This must be the same target where the bridge's resource adapter was deployed. For more information, see Deploying the Bridge's Resource Adapters.

4. Click Apply to save your assignments.

# 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 on different releases of WebLogic Server and in other WebLogic domains.

- Resource Naming Rules for Inter-Domain Interoperability Using the Messaging Bridge
- Message Properties
- Configuring Interoperability for WebLogic Domains
- Using the Messaging Bridge To Access Destinations In a Release 6.1 or Later 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.

## Resource Naming Rules for Inter-Domain Interoperability Using the Messaging Bridge

Within a domain, each server instance must be named uniquely and must not use the same name as the domain. This unique naming rule also applies to all configurable JMS objects, such as JMS servers, stores, templates, connection factories, session pools, and connection consumers. Additionally, in order for Weblogic domains to successfully interoperate using the Messaging Bridge, all participating resources (except connection factories) must have unique names across the interoperating domains. This rule includes domains from different releases of WebLogic Server.

For example, you cannot create a WebLogic Server instance named myserver in a version 8.1 domain named mydomain81 if there is already a server instance named myserver in a version 7.0 domain named mydomain70. On the JMS subsystem level, you cannot have two similarly named JMS servers (e.g., myJMSServer) residing in separate interoperating domains.

Therefore, you must adhere to the following rules when using the Messaging Bridge to interoperate between domains:

- All domain names must be unique across your enterprise.
- All WebLogic Server instance names must be unique within a domain and across all interoperating domains.
- All JMS server names must be unique within a domain and across all interoperating domains.
- If a JMS store (file or JDBC) is being used for persistent messages, all store names must be unique within a domain and across all interoperating 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 Using Security Interoperability Mode before rebooting.

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 8.1 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 Resource Naming Rules for Inter-Domain Interoperability Using the Messaging Bridge.
- Make sure that interoperability between the domains is correctly configured, as described in Configuring Interoperability for WebLogic Domains.
- Make sure that the XA connection factory is enabled for the 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 8.1 domain where the messaging bridge is running, as described in Deploying the Bridge's Resource Adapters.
- When configuring the JMS bridge destinations, as described in Configuring JMS Bridge Destinations, 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 Modifying an Existing 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 JMS Bridge Destinations.

# Managing a Messaging Bridge

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

- Monitoring All Messaging Bridges
- Stopping and Restarting a Messaging Bridge
- Configuring the Messaging Bridge Execute Thread Pool Size

## Monitoring All Messaging Bridges

To monitor the status of all configured messaging bridges in your domain:

1. Expand the Server node.
2. Select the server instance where the messaging bridges are configured. A dialog displays in the right pane showing the tabs associated with the selected server instance.
3. Select the Services —> Bridge tab.
4. Click the Monitor all Messaging Bridge Runtimes text link.
5. A table displays showing all the messaging bridge instances for the server and their status (either as running or not running).

## Stopping and Restarting a Messaging Bridge

To temporarily suspend and restart an active messaging bridge:

1. Expand the Messaging Bridge node.
2. Select the messaging bridge instance that you want to suspend.
3. On the Configuration —> General tab, clear the Started check box to suspend the bridge.
4. To restart the bridge, select the Started check box.

## Configuring the Messaging Bridge Execute Thread Pool Size

You can configure the default execute thread pool size for your messaging bridges. For example, you may want to increase or decrease 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 specific server instance where the messaging bridge is configured.
3. In the right pane, select the Services —> Bridge tab.
4. Enter a new value in the Messaging Bridge Thread Pool Size field.
5. Click Apply to save your changes.