Arturo Viveros ,
· 5 min read

5 Reasons to avoid WLS SAF Agents within your FMW Architecture

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.

  2. You’d be violating several service-orientation design principles as well as ignoring proven design patterns. Let’s list the 8 service-orientation design principles: Standardized Service Contract, Loose Coupling, Abstraction, Reusability, Autonomy, Statelessness, Discoverability, Composability. So, the SAF solution would be in violation of practically all of the latter, except perhaps Statelessness (because of the use of persistent stores). Especially worrisome is the very obvious tight coupling as well as the lack of abstraction and autonomy.

  3. You’d be locking-down your business functionality to a prohibitively proprietary technology (including the “t3(s)” protocol), and a really old one indeed. SAF Agent technology was actually introduced by BEA Systems in 2006 as a new feature in WLS 9.0, which was meant as an improvement and / or complement of the even older WLS Messaging Bridge. As you all know, BEA was later acquired by Oracle (2008) which took over WebLogic and eventually made it it’s flagship application server with the release of version 11g. So, we’re talking about more than 10 years, and if you’re already in 12c, it goes back 11 to 13 versions. Though Oracle has kept SAF as part of the WLS toolset, it is not one of the technologies which has enjoyed substantial focus, development, improvement & industry alignment unlike many others. Even if you take a look at WLS’s 9.0 console, you’ll notice that configuration options are practically the same as in the newest version; so, you’ll probably be better off communicating your WLS domains in a standards-based, decoupled fashion rather than choosing SAF. Alternatives abound and picking the most suitable one depends on specific requirements, licensing, etc.

  4. You’d be disregarding critical non-functional concerns such as: scalability, portability, reliability, monitoring, etc. The SAF solution can make a great proof-of-concept when implementing a vanilla scenario in a Dev environment, but when you consider the inherent complexity of a production environment it just doesn’t scale or stack up well, which is a killer in itself. Also, besides the obvious lack of portability to other application servers (because of its proprietary nature), it doesn’t even guarantee portability and / or backwards compatibility with other WLS versions. By experience, even a scenario with domains in different minor versions (e.g. 12.2.1.3 - 12.2.2.1) is bound to cause you a lot of trouble. To make it worse, there is not too much out-of-the-box support when it comes to monitoring a SAF solution, besides what WLS Admin Console & the server log give you which is very limited. So, if you’ve decided to deploy SAF, have your Ops guys prepared to have netstat & wireshark as their debugging / troubleshooting tools.
  5. There isn’t a lot of available information to help you out should you run into any trouble (and you most probably will). Official documentation is very superficial and even though there are a couple of comprehensive blogposts on the matter, good old “Saint Google” won’t be able to answer your prayers this time, as it will only find a small array of abandoned / unresolved SAF related threads in the most common middleware forums including OTN. So, if you’re very lucky maybe you’re in touch with this engineer which used to work for BEA 10 years ago, and maybe he will remember something helpful about SAF, but who knows?. This lack of implementation references and community knowledge (as opposed to many other FMW features) also says a lot; it’s like when you’re trying to pick a restaurant and you see this dodgy place, with a strangely appealing look and almost no people dining in, while all of the other ones are quite full and a little more on the conventional side. You can always talk yourself into going into the funky one, maybe you’ll discover a hidden jewel and feel like a genius afterwards, but the odds are that you’ll probably end up having an unpleasant experience while wasting your time and money. So better take a deep breath, come back to your senses and play the percentages here as this is clearly a high-risk / low-reward scenario.

Take a look at the image below, a very clear Do / Don’t picture if you take into account what was just discussed. If you need to communicate those domains, keep it simple and just make sure to apply the service orientation principles to a meaningful extent whether you design your solution to push, pull, broadcast or else.

…and that’s all I have to say about that; I certainly hope you found the post interesting and useful, thanks for reading!!