Messaging Bridge in Weblogic

Messaging Bridge is a mechanism for interoperability between  JMS implementaions on different  weblogic versions or different domains or different vendors (Third party) JMS products. (like MQ).

A messaging bridge instance forwards messages between a pair of bridge source and target destinations. These destinations are mapped to a pair of bridge source and target destinations. The messaging bridge reads messages from the source bridge destination and forwards those messages to the target bridge destination. For WebLogic JMS and third-party JMS products, a messaging bridge communicates with source and target destinations using the Java EE Connector Architecture (JCA) resource adapters provided with WebLogic Server.

The messaging bridge communicates with source and destinations using JCA resource adaptors.



Source and destination targets either topics , queues or distributed destinations.We can configure remaining performance management task (QOS,message filters, connection retry policies etc) using admin console.

Messaging Bridge Components:

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.

Resource adapters for different types of JMS destinations are provided in exploded format or in a .rar file. In exploded format we can easily modify some parameters in deployment descriptor like max-capacity of the connection factory that specifies the maximum number of connections available for bridge instances.

Note:
Changing a deployment descriptor for a resource adapter using the exploded format does not update the descriptor packaged in the .rar file.

Also Check here: For Weblogic online video tutorials.

Table 2-1 Messaging Bridge Resource Adapters and JNDI Names

Adapter	JNDI Name	Description
jms-xa-adp	eis.jms.WLSConnectionFactoryJNDIXA	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 apply to use of this resource adapter: Any WebLogic Server implementation being bridged must be release 7.0 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 Configuring Interoperability for WebLogic Domains for specific transactional configuration requirements and guidelines.
jms-notran-adp	eis.jms.WLSConnectionFactoryJNDINoTX	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 AUTO_ACKNOWLEDGE mode. If the requested QOS is Duplicate-okay, CLIENT_ACKNOWLEDGE is used.

Available resourse adaptors in weblogic server

 ls | grep .rar
jms-local-adp.rar
jms-notran-adp51.rar
jms-notran-adp.rar
jms-xa-adp.rar
path: (weblogichome/server/lib)
/home/core/Oracle/Middleware/wlserver_10.3/server/lib

Creating a messaging bridge consists of the following tasks:

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

Managing message bridge instances:

• Monitoring the status of all configured messaging bridges in your domain.
• Suspending and restarting an active messaging bridge.
• Configuring the default execute thread pool size for your messaging bridges.
• Deploying a resource adapter.
• Creating a trusted security relationship.

Usage of Messaging Bridge:

Store and Forward Messaging

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

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

• Any two implementations of WebLogic JMS, including those from separate releases of WebLogic Server.
• WebLogic JMS implementations that reside in separate WebLogic domains.
• WebLogic JMS with a third-party JMS product (for example, MQSeries).

Replicating a Topic

A messaging bridge can be used to replicate a topic, similar to using the distributed topics feature available in WebLogic Server releases 7.0 and higher, consequently improving scalability and high availability in some scenarios. Topic replication is accomplished by configuring the bridge to subscribe to one topic and forward the topic's messages to another topic, in essence creating two topics with the same message stream.

Avoiding message bridge on below conditions:

• Receiving messages from a remote destination—Use a message driven EJB or implement a client consumer directly.
• Sending messages to a local destination—Send directly to the local destination.
• Environment with low tolerance for message latency. Messaging Bridges increase latency and may lower throughput. Messaging bridges increase latency for messages as they introduce an extra destination in the message path and may lower throughput because they forward messages using a single thread.
• Forward messages between WebLogic 9.0 and higher domains—Use WebLogic Store-and-Forward.

The WebLogic Messaging Bridge supports three different QOS levels:

• Exactly-once—The highest QOS guarantees that a message is sent to the remote endpoint once and only once. With Exactly-once, messages survive server crashes and network down time, while guaranteeing one occurrence of each message at the endpoint.
• At-least-once—Guarantees that a message is sent to the remote endpoint, but with the possibility of duplicates. With At-least-once, multiple copies of a message might show up on the remote endpoint because of network failures or server crashes that occur when the message is in transit.
• At-most-once—The lowest QOS guarantees that each message is sent to the remote endpoint only once, if at all. It does not guarantee that a message is sent to the endpoint. With At-most-once, messages may get lost because of network failures or server crashes. No duplicate messages will reach the endpoint.

Messaging Persistence

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

• The source destination is a queue.
• The source destination is a topic and the Durability Enabled attribute is set. This creates a durable subscription.

Setting the Number of Connection Factories

You may need to modify the capacity of the connection factory associated with each resource adaptor by adjusting the initial-capacity and max-capacity attributes the weblogic-ra.xmldescriptor file. In general, the value of the max-capacity attribute should be at least two times the number of bridge instances. For example:

The default configuration sets the value of the max-capacity attribute to 20. This setting is adequate for environments that have up to ten message bridge instances targeted. If you increase the number of bridge instances to 15, increase the max-capacity attribute to 30.

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

1. Using the editor of your choice, update the attribute with the desired value. 
2. Deploy the updated adapter.
3. Stop and restart any bridge instance that requires the new values.
Listing 3-1 Example weblogic-ra.xml Descriptor File

<weblogic-connection-factory-dd>

     <connection-factory-name>WLSJMSConnectionFactoryLocal</connection-factory-name>

     <jndi-name>eis/jms/WLSConnectionFactoryJNDILocal</jndi-name>

          <pool-params>

               <initial-capacity>0</initial-capacity>

               <max-capacity>20</max-capacity>

          </pool-params>

</weblogic-connection-factory-dd>

Preserving Message Properties

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

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

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

• The PreserveMsgProperty is not enabled. This setting provides the same forwarding behavior as previous releases.
• The default value of PreserveMsgProperty when configuring a messaging bridge instance is not enabled.
• The PreserveMsgProperty is enabled. Message properties are preserved as described the following table:

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

  Property	WebLogic Server 9.0 and Higher	WebLogic Server 8.1, 7.0	Foreign JMS Servers
  Message ID	Yes	No	No
  Timestamp	Yes	No	No
  User ID	Yes	No	No
  Delivery Mode	Yes	Yes	Yes
  Priority	Yes	Yes	Yes
  Expiration Time	Yes	Yes	Yes
  Redelivery Limit	Yes	No	No
  Unit-of-Order name	Yes	No	No

Using Distributed Destinations as Source and Target Destinations

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

• If the source is a distributed destination, the bridge is pinned to one of the members when it connects to the destination. It stays connected to that member until an event occurs that breaks the connection. On reconnection, the bridge uses the next available member. Once a bridge is connected, it does not receive messages from other members of the distributed destination. It is a best practice to configure one bridge for each member of a distributed destination using the member's JNDI Name.
• If the target is a distributed destination, the best practice is to send to the distributed destination using the distributed destination’s JNDI Name and disable server affinity. This allows the distributed destination to load balance incoming messages. See “Load Balancing for JMS” in Using WebLogic Server Clusters.

Interoperating with Different WebLogic Server Releases:

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.
• If a JMS file store is being used for persistent messages, the JMS file store name must be unique across domains.

Configuring Interoperability for WebLogic Domains

Configuring interoperability between domains depends on the QOS:

• Configuring Interoperability for Exactly-once QOS
• Configuring At-least-once or At-most-once QOS

Configuring Interoperability for Exactly-once QOS

Use the following guidelines to configure interoperability when a bridge running on a release 7.0 or higher domain must handle transactional messages (using the Exactly-once QOS) between two release 7.0 or later domains

• You must correctly configure either Cross Domain Security or Security Interop Mode for all participating domains.
Keep all the domains used by your process symmetric with respect to Cross Domain Security configuration and Security Interop Mode. Because both settings are set at the domain level, it is possible for a domain to be in a mixed mode, meaning the domain has both Cross Domain Security and Security Interop Mode set. 
• 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 the XA connection factory is enabled for the domains by selecting the XAConnection Factory Enabled check box.
• Deploy the transaction resource adapter, jms-xa-adp.rar, on the domain where the messaging bridge is running.
• 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.

Configuring At-least-once or At-most-once QOS

There are no special security configuration requirements for the bridge to interoperate between two releases of 7.0 or later domains. However, if you wish to provide more secure communication between domains, you can configure Cross Domain Security.

Note:

Keep all the domains used by your process symmetric with respect to Cross Domain Security configuration—all domains use Cross Domain Security (or are on the appropriate exception lists) or none of the domains have Cross Domain Security configured. For more information, see:

Interoperating with Foreign Providers

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.

How do I enable debugging for the messaging bridge?

You can enable debugging for the messaging bridge using either of the followings methods:

• Add the following lines to your WebLogic start script (before the weblogic.Server line):

   -Dweblogic.debug.DebugMessagingBridgeStartup=true

   -Dweblogic.debug.DebugMessagingBridgeRuntime=true

• Add the following statements to the ServerDebug entry in your configuration file (config.xml) for the server that the messaging bridge is running on:

   DebugMessagingBridgeStartup="true"

   DebugMessagingBridgeRuntime="true"

Once debugging is enabled for the messaging bridge, the debugging messages are sent to the server log by default. However, if you want them to appear in the Administration Console, add “DumpToConsole” to the statements show above. For example:

   -Dweblogic.debug.DebugMessagingBridgeStartupDumpToConsole=true




Is there another way to monitor the messaging bridge without using the Administration Console?

Yes, there is a run-time MBean (MessagingBridgeRuntimeMBean) for each bridge instance. WebLogic Server run-time MBeans provide a snapshot of information about domain resources. When a particular resource in the domain (such as a messaging bridge) is instantiated, an MBean instance is created which collects information about that resource.

The MessagingBridgeRuntimeMBean has a getState() method that currently returns a String (“Active” or “Inactive”) and a getDescription() method, which returns a String with more detailed information. The name of a bridge runtime MBean consists of the WebLogic Server instance name and the bridge name. If a bridge named mybridge, runs on WebLogic Server instance named myserver, the bridge runtime MBean will be named myserver.bridge.mybridge.