Developer Partner Community

5 Reasons to avoid WLS SAF Agents within your FMW Architecture by Arturo Viveros

Juergen Kress
PaaS Partner Adoption


I know that this is quite an extremist title, and my colleagues will surely get a good laugh out of it since we actually just had some quite interesting experiences with SAF.

That being said, this post is not intended to bash this technology or to say it does not work (because it actually does); it’s just that if you look at the current technological landscape there are so much better options, and at least for me, from an Architectural point of view, it would be really difficult to justify deploying a SAF Agent (or WLS JMS Bridge) based solution into a production environment.

So, my hope is that if you’re considering SAF as your way to go, the following five reasons compel you to rethink your solution, take a long look at service-orientation design priciples / patterns and possibly spare yourself some major stress and hair-pulling. This is especially true if your organization is already in version 11g / 12c and even more if SOA Suite, OAG or any other advanced integration technology is available to you. Let’s dive straight into those points:

1. You’d be setting up a backdoor into your system and opening the floodgates. SAF agents are a JMS bridging technology usually used to connect different WLS domains in a point-to-point fashion; simply put, it’s almost the rough equivalent of using a crossover cable. Moreover, these domains are commonly in different networks, have different ownership and may be hosting distinct service inventories which you should be careful of compromising by setting off such an intrusive component. Of course you’ll be setting up domain trust in order to enable SAF, but this is no more than a palliative, as the messages which are flowing through can have multiple origins (database, file, web service, another queue or topic, or anything WLS may be connected to), and they only have to reach the right JMS local destination in order to be blindly stored and forwarded by the agent. To make it worse, when these messages reach the other side, by design they will most probably make their way up to the peer’s integration / application layer, coming from the backside and creating a lot of potential issues. Read the complete article here.

WebLogic Partner Community

For regular information become a member in the WebLogic Partner Community please visit: http://www.oracle.com/partners/goto/wls-emea ( OPN account required). If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Forum Wiki

Technorati Tags: PaaS,Cloud,Middleware Update,WebLogic,WebLogic Community,Oracle,OPN,Jürgen Kress

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.