Configuring JMS Bridges on Weblogic Server
Some background on JSM Bridges:
· The bridge allows you to configure a forwarding mechanism between any two messaging products (WLS-WLS-any version, WLS to any 3rd party JMS vendor, any 3rd party vendor - anyother 3rd party vendor)
· 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.
Advantages of using a Messaging Bridge:
- 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
- Allowing transparency
- Replicating a Topic
- A messaging bridge can be used to replicate a topic, similar to using the distributed topics feature
WLS Bridges support these three types of QOS(Quality of Service) 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.
Architecture for this PoC:
Step by Step Instructions:
1. Create new domain named 'LocalDomain' with admin server listening on 7001
2. Follow the below steps to create WLS resources in the domain:
i. **Local and Edit**
ii. Create a JMS Server (LocalJMSServer)
iii. Create a new store(FileStore0)
iv. Associate JMS Server to FileStore0
v. Target to Admin Server
vi. Create a new JMS Module
vii. Deploy it to the Admin Server
viii. Create new Connection Factory (JNDI: JMS/LocalCF)
ix. Create a new source Queue (JNDI: JMS/LocalQ)
x. Click on New Sub Deployment -> name it LocalQSub -> target it to LocalJMSServer
xi. **Activate Changes**
xii. Restart for changes to come into effect
3. Create new domain named 'RemoteDomain' with admin server listening on 8001
4. Follow the below steps to create WLS resources in this domain:
xiii. **Local and Edit**
xiv. Create a JMS Server (RemoteJMSServer)
xv. Create a new store(FileStore0)
xvi. Associate JMS Server to FileStore0
xvii. Target to Admin Server
xviii. Create a new JMS Module
xix. Deploy it to the Admin Server
xx. Create new Connection Factory (JNDI: JMS/RemoteCF)
xxi. Create a new source Queue (JNDI: JMS/RemoteQ)
xxii. Click on New Sub Deployment -> name it RemoteQSub -> target it to RemoteJMSServer
xxiii. **Activate Changes**
xxiv. Restart for changes to come into effect
xxv. Click on Services > Messaging > Bridges > JMS Bridge Destinations
xxvi. **Local and Edit**
xxvii. Create a New JMS Bridge Destination >> Name: LocalQ >> Connection URL: t3://LocallIP:7001 >> Connection Factory JNDI Name: JMS/LocalCF >> Destination JNDI Name: JMS/LocalQ
xxviii. Create a New JMS Bridge Destination >> Name: RemoteQ >> Connection URL: t3://RemoteIP:8001 >> Connection Factory JNDI Name: JMS/RemoteCF >> Destination JNDI Name: JMS/RemoteQ
xxix. **Activate Changes**
xxx. **Local and Edit**
xxxi. Click on Services > Messaging > Bridges
xxxii. Create New JMS Bridge >> Name: JMSBridge >> Quality Of Service: Almost-once >> Check Started >> Existing Source Destination: LocalQ >> Existing Target Destination: RemoteQ >> Target it AdminServer
xxxiii. **Activate Changes**
5. Make your producer listen on t3:// LocalIP:7001 and Connection Factory: JMS.LocalCF and Destination Queue: LocalQ
6. Make your consumer listen on t3:// RemoteIP:8001 and Connection Factory: JMS.RemoteCF and Destination Queue: RemoteQ
Producer / Consumer Screenshots:
Further Reading:
· http://download.oracle.com/docs/cd/E11035_01/wls100/bridge/design.html#wp1172930
· http://download.oracle.com/docs/cd/E11035_01/wls100/bridge/bridgeTOC.html
· http://download.oracle.com/docs/cd/E11035_01/wls100/bridge/bridgefaq.html

Hi Unni,
ReplyDeletehow are you doing..
i went through your all wlst scripts are usefull..
now i got messaging bridges in wls 10.1 env and tried to write wlst script to monitor status .. but no luck
I open SR with support becoz there was no option to monitor bridge from admin console..
i got feedback which will fix in inext relese..
waiting for reply.. thank you
Hello,
ReplyDeleteFollow these steps to Monitor messaging bridge instances on weblogic admin console:
1. To monitor the status of all configured messaging bridges in your domain:
2. In the left pane of the console, expand Environment and select Servers.
3. Select the specific server instance where the messaging bridge is configured.
4. In the right pane, select the top Services tab, then select Bridge.
5. Select the bridge instance whose status you want to monitor.
*** Given below are the enumerated notifications (Monitoring states) that Admin Console displays, please refer docs for more info ***
WARN: Failed to find the source adapter
WARN: Failed to find the target adapter
Found both of the adapters and making connections
WARN: Stopped by the administrator
WARN: Failed to look up the source adapter
WARN: Failed to look up the target adapter
Found two adapters and about to make connections
WARN: Failed to connect to the source
Connected to the source
WARN: Failed to connect to the target
Connected to the target
Forwarding messages
WARN: Failed to connect and will reconnect later
*** --- ***
--- OR ---
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.
--- **---
Thx,
Unni
Hi Unni,
ReplyDeleteCould you please assist me by giving a look to my query posted on oracle forums.
Here is the link.
http://forums.oracle.com/forums/thread.jspa?threadID=1127719&tstart=0
I shall be thankful to you.
Preet