The BEA WebLogic Message Bridge @ WEBLOGIC JOURNAL

The BEA WebLogic Message Bridge

Trsnsfer Messages Between JMS Providers

What is a messaging bridge? And why and where would you use it?

A messaging system is one in which applications are loosely coupled through the exchange of messages. In crude terms it is like an e-mail system for applications.

A messaging bridge in turns moves messages between any two messaging systems/products. 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 sent. Source and target bridge destinations can be either queues or topics.

BEA WebLogic introduced its messaging bridge in WebLogic 6.1, and has enhanced the features with later releases of WebLogic.

The WebLogic Messaging Bridge allows you to configure a forwarding mechanism between any two messaging products, thereby providing interoperability between separate implementations of BEA WebLogic JMS or between WebLogic JMS and another messaging product.

The WebLogic Messaging Bridge also provides the ability to 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 when necessary, tuning the execute thread pool size setting to suit your implementation, and monitoring the status of all your configured bridges.

Sample Application

This is a hypothetical application. It consists of two component applications, Stock Broker and Stock Exchange, that are deployed on Stock Broker Server and Stock Exchange Server respectively. Each component application should run independently of the other component, as well as communicating asynchronously with the other component. There is also a requirement that when one of the component applications sends a message the other component application should receive it as as soon as its server is in a running state.

Stock Broker Server is an online server that handles user requests. It will be able to take a stock purchase request and display whether the purchase request succeded or not, including the complete transaction history, if required. This server will not try to process the stock purchase request, but instead will send it to Stock Exchange Server for fulfillment.

Stock Exchange Server is an offline server that will receive messages from Stock Broker Server. It will receive the stock purchase requests and try to process them. This server might communicate with other external systems in order to fulfill the purchase request. For each stock purchase request received, this server will create a stock purchase response and will send the response back to Stock Broker Server.

In this implementation, Stock Broker is running on BEA WebLogic 8.1 and Stock Exchange is running on BEA WebLogic 7.0. WebLogic's JMS has been used for messaging on both servers, and WebLogic's Messaging Bridge has been used as a bridge between the two messaging systems. The choice of WebLogic 8.1 and WebLogic 7.0 along with WebLogic JMS messaging systems was here a matter of convenience. Conceptually, the messaging bridge can be used between any two messaging products.

As shown in Figure 1, Stock Broker Server has two queues, RequestSubmitQueue and ResponseReceiveQueue. Similarly, Stock Exchange Server has two queues, RequestReceiveQueue and ResponseSubmitQueue.

Stock Broker Server receives a stock purchase request from the user. SenderBean places the PurchaseRequestMessage on RequestSubmitQueue. Messaging Bridge1 forwards the message placed on RequestSubmitQueue of Stock Broker Server to RequestReceiveQueue of Stock Exchange Server.

Once a message is received on RequestReceiveQueue of Stock Exchange Server, ReceiveRequestMDB's (message driven bean) onMessage will be invoked by the container/server. ReceiveRequestMDB will get the object message and invoke ProcessRequestBean for fulfillment logic. ProcessRequestBean creates a PurchaseResponseMessage and invokes the SenderBean. The SenderBean is responsible for placing the PurchaseResponseMessage on the ResponseSubmitQueue. As soon as the message is placed on ResponseSubmitQueue, Messaging Bridge2 forwards that message to ResponseReceiveQueue of Stock Broker Server.

Once a message is received on ResponseReceiveQueue of the Stock Broker Server, ReceiveResponseMDBs onMessage will be invoked by the container/server. ReceiveResponseMDB will get the object message and invoke ProcessPurchaseResponseBean, which is responsible for processing the response and storing the response message to a flat file. The user can check the status of the current purchase request or the complete transaction history by accessing StockPurchaseResponse.jsp, which will invoke GetResponseFromStorage to get the list of response messages (transaction history) to be displayed.

In this sample application, any one or both of the messaging bridges can be turned off. At that time all the messages will be queued and will be forwarded to the target bridge destination as soon as the bridge is turned on again.

Similarly, if the server that is acting as a target destination of a messaging bridge is down (not in a running state), all of the messages will be queued and sent to the destination server's corresponding queue as soon as the target server becomes available (running state) again.

Example Scenario Demonstrating the Use of the Messaging Bridge
Let's assume that Stock Broker Server is in a running state, and Stock Exchange Server is brought down for regular maintenance or for some unforeseen reason.

A user enters a stock purchase request on Stock Broker Server. The Stock Broker Server takes the user's request, places the request on RequestSubmitQueue. Messaging Bridge1, which is responsible for forwarding the message, detects that Stock Exchange Server is not in a running state and does not do anything.

Stock Exchange Server is brought up to a running state. Messaging Bridge1 forwards the queued request to Stock Exchange Server. Stock Exchange Server processes/fulfills the request, creates a response message and places it in the ResponseSubmitQueue.

Now assume that Stock Broker Server becomes unstable and has to be brought down.

Stock Broker Server is brought up. As soon as it is in a running state, Messaging Bridge2 forwards the response message from ResponseSubmitQueue to ResponseReceiveQueue. The Stock Broker Server stores the response in a flat file and displays it whenever the user wants to view it.

This is just one example, but as we saw above, no messages were lost and there was no application logic required to do any additional processing when the target server was down.

Features Provided by the Message Bridge
By using the message bridge in the sample application, there was no runtime dependency between the two applications. Any one of the applications can be down and it will not impact the second application. Basically, all the messages on the first server will be queued and the messaging bridge will automatically start sending messages to the target destination as soon as the second server is up and running. It provides flexibility when you have the Stock Broker Application and Stock Exchange Application deployed on different versions of WebLogic. The Stock Broker Application and Stock Exchange Application can run on any version of WebLogic, which allows loose coupling in terms of software infrastructure.

One more advantage is that it also provides future flexibility to go with a completely different JMS implementation (e.g., MQSeries) or a non-JMS messaging product (Tuxedo) for Stock Exchange Application.

Configuring JMX Queues

Following are the steps required in setting up the JMS Bridge. The steps required for both servers are provided. (Note: We will use the notation of step A to signify that we are working on Stock Broker Server [BEA WebLogicServer 8.1], whereas step B signifies that we are working on Stock Exchange Server [BEA WebLogic Server 7.0]. Also, the screenshots of the BEA WebLogic Administration Console are provided only for Stock Broker Server, as a very similar configuration was used on both servers.)

Configure a JMS Connection Factory For Stock Broker Server
Using the WebLogic Administration Console, go to stockBrokerDomain > Services > JMS > Connection Factories. Click on "Configure a new JMS Connection Factory"

The Name and JNDI Name have been specified as: SB_JMSConnectionFactory.
All the other values have been set to default values (see Figure 2).
Select the Transactions tab and check the box for "XA Connection Factory Enabled". This is required if your application uses transactions across the messaging bridge and if you specify the "Quality of Service" of the messaging bridge as "Exactly-once".

For Stock Exchange Server
Using the WebLogic Administration Console, go to stockExchangeDomain > Services > JMS > Connection Factories. Click on "Configure a new JMS Connection Factory".

The Name and JNDI Name have been specified as SE_JMSConnectionFactory.
All other values have been set to default values.
Select the Transactions tab, check the box for "User Transactions Enabled", and click on the "Apply" button. Then check the box for "XA Connection Factory Enabled" and click on the "Apply" button. ("User Transactions Enabled" must be checked first, as there is a known bug in BEA WebLogic 7.0.) These steps are required if your application uses transactions across the messaging bridge and if you specify the "Quality of Service" of the messaging bridge as "Exactly-once".

Configure a JMS Server For Stock Broker Server
Using the WebLogic Administration Console, go to stockBrokerDomain > Services > JMS > Servers. Click on "Configure a new JMS Server".

The Name has been specified as SB_JMSServer.
All other values have been set to default values (see Figure 3).

For Stock Exchange Server
Using WebLogic Administration Console, go to stockExchageDomain > Services > JMS > Servers. Click on "Configure a new JMS Server".

The Name has been specified as SE_JMSServer.
All other values have been set to default values.

Configure JMS Queues For Stock Broker Server
Using the WebLogic Administration Console, go to stockBrokerDomain > Services > JMS > Servers > JMSServer > Destinations.

Click on "Configure a new JMS Queue".
a. The Name and JNDI Name have been specified as RequestSubmitQueue.
b. All the other values have been set to default values (see Figure 4).
Click on "Configure a new JMS Queue".
a. The Name and JNDI Name have been specified as ResponseReceiveQueue.
b. All the other values have been set to default values.

For Stock Exchange Server
Using the WebLogic Administration Console, go to stockExchangeDomain > Services > JMS > Servers > JMSServer > Destinations.

Click on "Configure a new JMS Queue".
a. The Name and JNDI Name have been specified as: RequestReceiveQueue.
b. All other values have been set to default values.
Click on "Configure a new JMS Queue".
a. The Name and JNDI Name have been specified as ResponseSubmitQueue.
b. All the other values have been set to default values.

Deploy the JMS Transaction Adapter in the Application Domain For Stock Broker Server
Using the WebLogic Administration Console, go to stockBrokerDomain > Deployments > Connector Module. Click on "Deploy a new Connector Module" and upload the jms-xa-adp.rar file from WebLogic's server/lib directory.

For Stock Exchange Server
Using the WebLogic Administration Console, go to stockExchangeDomain > Deployments > Connector Modules. Click on "Deploy a new Connector Module" and upload the jms-xa-adp.rar file from the WebLogic Server/lib directory.

Configure JMS Bridge Destinations For Stock Broker Server
Using the WebLogic Administration Console, go to stockBrokerDomain > Services > Messaging Bridge > JMS Bridge Destinations.

1. Click on "Configure a new JMS Bridge Destination". These values have been set:

Name: JMSBridge1Source
Adapter JNDI Name: eis.jms.WLSConnectionFactoryJNDIXA (default value, but this resource adapter needs to be deployed for the bridge to function properly) Connection URL: t3://localhost:7001 (the URL of the Stock Broker Server) Connection Factory JNDI Name: SB_JMSConnectionFactory (the connection factory that we created earlier) Destination JNDI Name: RequestSubmitQueue (the queue that JMSBridge1Source is trying to read the messages from) Destination Type: Queue (optional username/password that the adapter will use to access this bridge destination). If you specify username/password, the following step is required:
a. Go to stockBrokerDomain > Security.Select Advanced tab
- Uncheck "Enable Generated Credential".
- Specify the new credential and make sure that it is set to the same value across the two application domains (stockBrokerDomain and stock ExchangeDomain).

All other values have been set to default values (see Figure 5). 2. Click on "Configure a new JMS Bridge Destination". These values have been set:

Name: JMSBridge1Destination
Adapter JNDI Name: eis.jms.WLSConnectionFactoryJNDIXA (default value, but this resource adapter must be deployed for the bridge to function properly) Connection URL: t3://localhost:7003 (the URL of the Stock Exchange Server, which is the server on which the bridge's target destination is running.) Connection Factory JNDI Name: SE_JMSConnectionFactory (the connection factory that we created earlier). Destination JNDI Name: RequestReceiveQueue (the queue where JMSBridgeDestination will place the new messages that were transferred over the bridge) Destination Type: Queue. (An optional username/password that the adapter will use to access this bridge destination can also be set. If you specify the username/password, please set up credentials.)

All other values have been set to default values.

Configure JMS Bridge Destinations for Server B
Using the WebLogic Administration Console, go to server2Domain > Services > Messaging Bridge > JMS Bridge Destinations.

1. Click on "Configure a new JMS Bridge Destination". These values have been set:

Name: JMSBridge2Source
Connection URL: t3://localhost:7003 (the URL of the Stock Exchange Server). Connection Factory JNDI Name: SE_JMSConnectionFactory (the connection factory we created earlier). Destination JNDI Name: ResponseSubmitQueue (the queue that JMSBridgeSource is trying to read the messages from) Destination Type: Queue. (An optional username/password that the adapter will use to access this bridge destination can also be set. If you specify the username/password please set up credentials.)

All other values have been set to default values.

2. Click on "Configure a new JMS Bridge Destination". The values have been set.

Name: JMSBridge2Destination
Connection URL: t3://localhost:7001 (the URL of the Stock Broker Server, which is the server on which the bridge's target destination is running). connection factory JNDI Name: SB_JMSConnectionFactory (the connection factory we created earlier) Destination JNDI Name: ResponseReceiveQueue (This is the queue in which JMSBridgeDestination will place the new messages that were transferred over the bridge) Destination Type: Queue. (An optional username/password that the adapter will use to access this bridge destination can also be set. If you specify the username/password, please set up credentials.)

All other values have been set to default values.

Configure Messaging Bridge(s) On Stock Broker Server (Stock Broker > Stock Exchange)
Using the WebLogic Administration Console, go to stockBrokerDomain > Services > Messaging Bridge > Bridges.

Click on "Configure a new Messaging Bridge Destination". These values have been set:

Name: JMSMessagingBridge1
Source Bridge Destination: JMSBridge1Source
Target Bridge Destination: JMSBridgeDestination
Quality of Service: Exactly-once (Make sure that XA Connection Factory is enabled for the JMSConnectionFactory created earlier, along with deploying the bridge resource adapter described earlier.)

All other values have been set to default values (see Figure 6).

On Stock Exchange Server (Stock Exchange > Stock Broker)
Using WebLogic Administration Console, go to stockExchangeDomain > Services > Messaging Bridge > Bridges. Click on "Configure a new Messaging Bridge Destination". These values have been set:

Name: JMSMessagingBridge2
Source Bridge Destination: JMSBridge2Source (4.5.B.1)
Target Bridge Destination: JMSBridge2Destination (4.5.B.2)
Quality of Service: Exactly-once (make sure that XA Connection Factory is enabled for the JMSConnectionFactory created earlier, along with deploying the bridge resource adapter)

All other values have been set to default values.

Summary

The BEA WebLogic Messaging Bridge is a J2EE device provided by WebLogic (from version 6.1 onward) and is used to transfer messages between two JMS providers. You can use the message bridge to move messages from a destination in one JMS provider to destination in another JMS provider. (One example could be transferring a message in a queue on the WebLogic JMS server to a topic in Sonic MQ JMS Server)

In addition to offering interoperability between different JMS providers, the bridge also allows interoperability between different versions of WebLogic JMS. Although the bridge itself will run on version 7.0 or greater, it can be used to forward messages to destinations running on version 5.1 and greater.

No coding is required; it is purely configuration. There is a built-in capability to ensure quality of service and connection management (Exactly-once, Duplicates-okay, and Atmost-once). It is easy to configure multiple bridges, and there is an ability to dynamically start and stop individual bridges.

References

Configuration of Messaging Bridge: http://edocs.bea.com/wls/docs81/ConsoleHelp/domain_messagingbridge_con fig_general.html

Console Help: http://edocs.bea.com/wls/docs70/ConsoleHelp/messaging_bridge.html

Using the BEA WebLogic Messaging Bridge: http://edocs.bea.com/wls/docs70/adminguide/msgbridge.html

Enterprise Integration Patterns: www.enterpriseintegrationpatterns.com/MessagingBridge.html

Related Links

About Vijay Chinta
Vijay Chinta is an enterprise architect at Nokia. His primary area of expertise is J2EE development for enterprise applications in the fields of telecommunication and transportation.