C2B2 logo icon

Bridging Message Destinations in Weblogic

 

Since version 9, Weblogic has provided Store And Forward (SAF) in addition to traditional JMS messaging bridge capabilities. At first glance, it’s understandable to come to theconclusion that SAF is just a rebranded JMS message bridge, implemented in aslightly different, but ultimately pointless, way. Digging a little deeper,this doesn’t seem to hold true - why spend the time maintaining SAF if it holdsno benefit over a bridge? There must be a benefit!

Why do I even need a bridge?

There are a number of reasons why you might want to use amessaging bridge rather than connecting directly to a queue. The most commonwould be if you have a service which needs to interact with a remote queuedestination.

Generally speaking, it’s a bad idea to connect directly to aremote queue.  For a start, messagingbridges already have all the necessary code in place to handle all the manyexceptions that could happen from network issues, an unreliable remote queueand everything in between, so unless you have a very good reason – why reinventthe wheel?
 
Another very important reason why you might want to handleall this with a bridge is to avoid the blame game! When things inevitably gowrong, I know I would much rather place the blame squarely at someone else’sfeet – so if you can blame your software vendor by removing all responsibilityfrom your applications, I say take that chance!
 

What’s involved in Weblogic’s bridge implementation?

Setting up a messaging bridge in Weblogic is quitestraightforward. You’ll first need to create source and target destinations andthen create a bridge to link the two together. The easiest way to do that is touse the admin console but, as with most Weblogic capabilities, it can bescripted with WLST. Scripting would be preferred, purely because it provides arecord of the changes you’ve made and a reference from which you can roll-back ifanything needs to change.
 

What about Store And Forward?

SAF is a little more involved than creating a messagingbridge. You first need to create a SAF Agent. This is what will handle theactual movement of the messages and is very configurable in terms of reliablysending messages. An agent can be either dedicated to send, to receive or to doboth. Once your agent is created, you will need to create a Remote Context andan Imported Destination. Think of these like the source and target destinationsof a traditional messaging bridge – they work differently but the remote contextis concerned with the external service and the imported destination isconcerned with the local service.
 
All this will give you a similar set up to a messagingbridge. It works differently, but the results will be the same – messages movedfrom A to B. One of the extra things you can create is a SAF Error Handler,which allows you to set an error handling policy of discarding, logging,redirecting or always forwarding the message.
 

So which is better?

Ultimately, the deciding factor in which you want to use mightcome down to whether or not both endpoints are both Weblogic 9.0+, but whatabout scenarios where either is possible?
 
Well, for most situations it will come down to your ownpreferences and how flexible you want to be in the future; are you sure you’llhave Weblogic available on both endpoints a year or two in the future?
 
Where SAF comes into its own is in reliable messaging withWeb Services Reliable Messaging (WSRM) capabilities and the fact that SAF,unlike a traditional bridge, will support exactly-once messaging without XA,providing a performance advantage.
 
As with most technology comparisons, when you ask “which isbetter?” the answer is invariably “it depends!”