Step by Step process to create a JMS bridge | Weblogic 11g

In situations where you have one WebLogic server enqueuing a JMS message to a JMS queue on a remote WebLogic server, you can improve both the performance and resilience, by creating a bridged JMS queue. This recipe explains how to do that. This recipe assumes that the JMS queue already exists on the remote JMS server, and that you wish to create a bridge to it from your local WebLogic server. You will need to know the administration credentials for your WebLogic server instance, to be able to create the bridges.

Follow these steps to create a JMS bridge:

1. Connect to your WebLogic Server administration console, and log in with your administration credentials. By default, the administration console is available at http://<adminserverhost>:<adminserverport>/console.

2. In the left-hand navigation pane, expand Services, Messaging, and then Bridges, as in the following screenshot:

3. This will display a summary of any existing JMS bridge destinations. Click on the New button to create a new bridge destination.

4. This will be the local end of the JMS bridge; give it a descriptive name and enter the connection details such as the URL for the local server, whether you wish the bridge to use XA or be non-transactional, and the JNDI name of the JMS connection factory to use. Click on Ok when you are done.

5. You will now be returned to the summary of bridge destinations, but should see your new bridge destination in the list. Click on New again, and create the remote end of the bridge.

6. Enter the connection details for the remote end of the JMS bridge, then click on Ok.

7.    Navigate to the Bridges section of the Messaging services in the left-hand navigation pane:

8. This will give you the summary screen, showing you all of your existing JMS bridges, which will probably be none if you have not created any yet. Click on New to create the bridge.

9. Enter the properties for the JMS bridge including its name. Select the checkbox to ensure that the bridge is started when you have finished creating it, then click on Next.

10. Select the JMS bridge destination that represents the local side of your JMS bridge, then click on Next.

11. Select the adapter type, which should be WebLogic Server 7 or higher, then click on Next.

12. Select the JMS bridge destination that represents the remote JMS destination, then click on Next.

13. Select the adapter type for the remote destination, which is probably WebLogic Server 7 or higher, then click on Next.

14. Select the targets for the bridge, which should be the servers on which the JMS producers are running, then click on Next.

15. Review the information about the changes needed to remote domains, then click on Finish.

A JMS bridge consumes messages from one JMS queue and enqueues them onto a different JMS queue. While it might sound like doing this would reduce the performance, it has a number of benefits. Firstly, it means that the component producing JMS messages does not need to make a network call to a remote server; it can instead enqueue the message locally with no network overhead, then continue processing. The bridge will ensure that the message reaches the intended JMS queue. Secondly, it means that poor performance on the remote JMS server (for example, if it is overloaded with messages) will not result in poor performance on the JMS producer. This decoupling from the external service can allow you to make performance guarantees for your services when you have external systems that you have little or no control over.

A second advantage of JMS bridges is resilience. If your SOA Suite application is enqueuing messages onto a remote JMS server, then if that remote server goes down and you are unable to enqueue messages, your application will fail. With a bridge between the two servers, you can still enqueue messages locally, and when the remote server comes back up, the bridge will reconnect and send any pending messages to the remote server.

An alternative to using a JMS bridge where you want to enqueue a JMS message to a remote WebLogic server in the same domain is to use a store-and-forward JMS destination. These are WebLogic-specific features that use the internals of the WebLogic JMS infrastructure to store a JMS message until it can be transactionally enqueued onto the remote server.

Store and Forward Agents (SAF) are another JMS feature within WebLogic that offer a similar functionality to JMS bridges, however, in our experience, they are not as performant, are less reliable, and no easier to configure than a JMS bridge.

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.