WebLogic Message Bridge
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.
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.
Once a messaging bridge is configured, it is easily managed from the administration console, including temporarily suspending bridge traffic when necessary, and monitoring the status of all your configured bridges.
EXAMPLE :-
Let 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.
-------------->
Let Stock Broker is running on WebLogic 9.x and Stock Exchange is running on WebLogic 10.x
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 messaging bridge can be used between any two messaging products.
-------------->
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.
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.
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.
Once a messaging bridge is configured, it is easily managed from the administration console, including temporarily suspending bridge traffic when necessary, and monitoring the status of all your configured bridges.
EXAMPLE :-
Let 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.
-------------->
Let Stock Broker is running on WebLogic 9.x and Stock Exchange is running on WebLogic 10.x
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 messaging bridge can be used between any two messaging products.
-------------->
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.
No comments:
Post a Comment