MessagingBridge

 


Description

This class represents a WebLogic messaging bridge, which enables 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.

For WebLogic JMS and third-party JMS products, a messaging bridge communicates with a configured source and target destinations using the resource adapters provided with WebLogic Server. For non-JMS messaging products, you need to obtain a custom adapter from a third-party OEM vendor or contact BEA Professional Services to access non-JMS source or target destinations.

 


Syntax

<MessagingBridge


AsyncEnabled=( "true" | "false" )


BatchInterval="number


BatchSize="number


DeploymentOrder="number


DurabilityEnabled=( "true" | "false" )


IdleTimeMaximum="number


Name="String


Notes="String


QOSDegradationAllowed=( "true" | "false" )


QualityOfService=( "Exactly-once" | "Atmost-once" | "Duplicate-okay" )


ReconnectDelayIncrease="number


ReconnectDelayMaximum="number


ReconnectDelayMinimum="number


Selector="String


SourceDestination="BridgeDestinationCommon name


Started=( "true" | "false" )


TargetDestination="BridgeDestinationCommon name


Targets="list of Target names


TransactionTimeout="number


Type="String



/>

 


Parent Elements

 


Attributes

Attribute

Description

Range of Values and Default

AsyncEnabled Specifies whether the messaging bridge will work in asynchronous messaging mode.Note: This attribute only applies to messaging bridges whose source destination supports asynchronous receiving.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 set to false, the bridge is forced to work 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. Otherwise, the bridge will automatically switch to synchronous mode if it detects that MDBTransaction is not supported by the source destination. Admin Console field label: Asynchronous Mode EnabledDefault: true
BatchInterval The maximum time, in milliseconds, that the bridge will wait 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.Note: This attribute only applies to bridges that work in synchronous mode and whose QOS require two-phase transactions. Admin Console field label: Batch Interval (milliseconds)Default: -1
BatchSize The number of messages that are processed within one transaction.Note: This attribute only applies to bridges that work in synchronous mode and whose QOS require two-phase transactions. Admin Console field label: Batch SizeDefault: 10Minimum: 0
DeploymentOrder A priority that the server uses to determine when it deploys an item. The priority is relative to other deployable items of the same type. For example, the server prioritizes and deploys all EJBs before it prioritizes and deploys startup classes.Items with the lowest Deployment Order value are deployed first. There is no guarantee on the order of deployments with equal Deployment Order values. There is no guarantee of ordering across clusters. Default: 1000Minimum: 0Maximum: 231-1
DurabilityEnabled Specifies whether the messaging bridge allows durable messages.This only applies to a source destination that uses durable subscriptions, which allows the source JMS implementation to save messages that are sent to it while the bridge is not running. The bridge will forward these messages to the target destination when it is restarted. The administrator can choose not to be durable. Admin Console field label: Durability EnabledDefault: true
IdleTimeMaximum The maximum amount of idle time, in seconds, for the messaging bridge.If the bridge works in asynchronous mode, the maximum idle time defines the longest time the bridge will stay idle before it checks the sanity of its connection to the source.If the bridge works in synchronous mode, the maximum idle time defines the amount of time the bridge can block on a receive call if no transaction is involved. Admin Console field label: Maximum Idle Time (seconds)Default: 60Minimum: 0Maximum: 231-1
Name The name of this configuration. WebLogic Server uses an MBean to implement and persist the configuration. Admin Console field label: NameRequired: no
Notes Optional information that you can include to describe this configuration. Admin Console field label: NotesRequired: no
QOSDegradationAllowed Specifies whether the messaging bridge allows the degradation of its QOS when the configured QOS is not available. Admin Console field label: QOS Degradation AllowedDefault: false
QualityOfService The QOS (quality of service) values for the messaging bridge:

Exactly-once

Each message in the source destination will be transferred to the target exactly once. This is the highest QOS a bridge can offer.

Atmost-once

One message in the source will be transferred to the target only once with the possibility of being lost during the forwarding.

Duplicate-okay

Messages in the source will not get lost but some may appear in the target more than once.

Admin Console field label: Quality Of ServiceRequired: noDefault: Exactly-once
ReconnectDelayIncrease The incremental delay time, in seconds, that the messaging bridge will wait longer between one failed reconnection attempt and the next retry.This attribute works with the ReconnectDelayMinimum and ReconnectDelayMaximum attributes. After the first failure to connect to a destination, the bridge will wait for the number of seconds defined by ReconnectDelayMinimum.Each time a reconnect attempt fails, the bridge will increase its waiting time by the number of seconds defined by ReconnectDelayIncrease. The maximum delay time is defined by ReconnectDelayMaximum. Once the waiting time is increased to the maximum value, the bridge will not increase its waiting time anymore.Once the bridge successfully connects to the destination, its waiting time will be reset to the minimum value defined by ReconnectDelayMinimum. Admin Console field label: Incremental Delay (seconds)Default: 5Minimum: 0Maximum: 231-1
ReconnectDelayMaximum The longest time, in seconds, that the messaging bridge will wait between one failed attempt to reconnect to the source or target and the next retry.This attribute works with the ReconnectDelayMinimum and ReconnectDelayIncrease attributes. After the first failure to connect to a destination, the bridge will wait for the number of seconds defined by ReconnectDelayMinimum.Each time a reconnect attempt fails, the bridge will increase its waiting time by the number of seconds defined by ReconnectDelayIncrease. The maximum delay time is defined by ReconnectDelayMaximum. Once the waiting time is increased to the maximum value, the bridge will not increase its waiting time anymore.Once the bridge successfully connects to the destination, its waiting time will be reset to the initial value defined by ReconnectDelayMinimum. Admin Console field label: Maximum Delay (seconds)Default: 60Minimum: 0Maximum: 231-1
ReconnectDelayMinimum The minimum amount of time, in seconds, that the messaging bridge will wait before it tries to reconnect to the source or target destination after a failure.This attribute works with the ReconnectDelayMaximum and ReconnectDelayIncrease attributes. After the first failure to connect to a destination, the bridge will wait for the number of seconds defined by ReconnectDelayMinimum.If the second trial also fails, it will increase its waiting time by the number of seconds defined by ReconnectDelayIncrease. The maximum delay time is defined by ReconnectDelayMaximum. Once the waiting time is increased to the maximum value, the bridge will not increase its waiting time anymore.Once the bridge successfully connects to the destination, its waiting time will be reset to the initial value defined by ReconnectDelayMinimum. Admin Console field label: Minimum Delay (seconds)Default: 15Minimum: 0Maximum: 231-1
Selector The message selector for the messaging bridge.The message 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. Admin Console field label: SelectorRequired: no
SourceDestination The source bridge destination for the messaging bridge.This must be an instance of either the JMS Bridge Destination (JMSBridgeDestinationMBean) or the General Bridge Destination (BridgeDestinationMBean), which are used to define the source destination that the messaging bridge will read messages from. Admin Console field label: Source Bridge Destination
Started The initial state of the messaging bridge (that is, the state when the bridge boots).If the value is true, the bridge is in working condition. If the value is false, the bridge is temporarily stopped.Note: This does not indicate the run-time state of the bridge. Admin Console field label: StartedDefault: true
TargetDestination The target bridge destination for the messaging bridge.This must be an instance of either the JMS Bridge Destination (JMSBridgeDestinationMBean) or the General Bridge Destination (BridgeDestinationMBean), which are used to define the target destination that the messaging bridge will send the messages it receives from the source destination. Admin Console field label: Target Bridge Destination
Targets The targets in the current domain on which this item can be deployed. Admin Console field label: TargetsRequired: no
TransactionTimeout The amount of time, in seconds, that the transaction manager will wait for each transaction before timing it out.Transaction timeouts are used when the QOS for a bridge requires transactions. If a bridge is configured with Exactly-once QOS, the receiving and sending is completed in one transaction. Admin Console field label: Transaction TimeoutDefault: 30Minimum: 0Maximum: 231-1
Type Returns the type of the MBean. Required: no

Skip navigation bar  Back to Top Previous Next