Administration Console Online Help
[Attributes and Console Screen Reference for Messaging Bridge]
The following sections explain how to configure and manage a WebLogic Messaging Bridge:
You may also want to refer these WebLogic JMS sections:
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:
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://download.oracle.com/docs/cd/E13222_01/wls/docs81/messaging.html. These examples are distributed as .zip
files that you can unzip into an existing WebLogic Server samples directory structure.
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.
Provides transaction semantics via the 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. |
||
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 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 consists of the following tasks:
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.
Creating a messaging bridge consists of the following tasks:
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:
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:
Use the following instructions to create a new destination for your messaging bridge instance:
Use the following instructions to configure your messaging bridge instance for an existing destination:
The following sections provide information on how to modify the configuation of individual message bridge components:
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:
For more information on deploying resource adapters, see "Packaging and Deploying Connectors" in Programming WebLogic Server J2EE Connectors.
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:
JMSBridgeDestination
instance for each actual source and target JMS destination being mapped to a messaging bridge.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.
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.
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.
CLASSPATH
in the WebLogic Server CLASSPATH
.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.
For more information about JMS bridge destination attributes, see JMS Bridge Destination --> Configuration.
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.
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.
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.
CLASSPATH
in the WebLogic Server CLASSPATH
.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.
For more information about the general bridge destination attributes, see General Bridge Destination --> Configuration.
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.
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:
Enter a messaging bridge name that is unique across a WebLogic Server domain. |
|
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. |
|
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. |
|
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. |
|
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:
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. |
|
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. |
|
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. |
|
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 |
|
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. |
|
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.
For more information, see Targeting a Messaging Bridge to a Server, a Cluster, or a Migratable Target.
For more information about the bridge's connection retry attributes, see the Attributes table in Messaging Bridge --> Configuration --> Connection Retry.
For more information about the bridge's transaction attributes, see the Attributes table in Messaging Bridge --> Configuration --> Transactions.
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.
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.
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.
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.
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:
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
.
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
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.
system
user to the same value in all participating domains on the SecurityUse 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.
jms-xa-adp.rar
, on the 8.1 domain where the messaging bridge is running, as described in Deploying the Bridge's Resource Adapters.eis.jms.WLSConnectionFactoryJNDIXA
.
When configuring a messaging bridge involves interoperability with a third-party messaging provider, you must configure the following:
CLASSPATH
in the WebLogic Server CLASSPATH
.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.)JMSBridgeDestination
instance for the third-party messaging product being bridged, provide vendor-specific information in the following attributes: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.
Once a messaging bridge is up and running, it can managed from the console.
To monitor the status of all configured messaging bridges in your domain:
To temporarily suspend and restart an active messaging bridge:
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.