Policy Injection App Block of EntLib 3.0 - An implementation of AOP

Posted by Hugh Ang at 2/25/2007 08:03:00 PM

Details have finally emerged about Policy Injection App Block (PIAB) in the upcoming EntLib 3.0 - see here and here. I have been curious and wanting to see this as this is a form of Aspect-Oriented Programming (AOP). I have worked quite a bit on my company's framework, which has a different variation of AOP. What I like about PIAB from p&p is that it doesn't impose restriction of AOP at physical boundaries, as opposed to, say, binding AOP to the service boundary. The arguments for binding AOP to only the service boundary are basically concerning about the undisciplined use of AOP, thus causing aspect "meatballs" throughout the application. I think the decoupling of AOP from physical application boundaries bring more benefits and goodness to the application architecture. Remember that we could configure attributes, such as transaction, security for components in MTS and later COM+. If a framework makes the aspect feature highly configurable, I wouldn't agree to the "meatballs" argument. Besides, any language or framework in existence today, while making developers lives easier, still can't be savior of all problems without disciplines from developers - This is where good development process comes in. So I think most of the developers would appreciate the freedom that PIAB offers.

The PIAB implementation, though, seems to be somewhat controversial. Instead of a few sound alternatives, they picked remoting. p&p didn't want to mess around the runtime by using CLR profiler APIs or JIT Debugger callbacks to rewrite IL at runtime. However, the reason for not using IL rewriting, should not be they are obscure or not supported by PSS. Instead, The CLR already has ContextBoundObject, which is designed for this very purpose of interception. Don Box's Essential .NET book has a good coverage of this topic in chapter 7. As a matter of fact, I have seen a lot of AOP implementations using ContextBoundObject in the field. So I really don't understand the argument "not recommended for customer code" in Edjez's blog. Maybe the CLR team can shed some light on this. Honestly I don't see why remoting is a better choice and wouldn't be replaced in future releases of EntLib. We know that remoting was not designed to BE an interception mechanism, although with an interception mechanism.

Although not stated by the blogs, I suspect that the lack of "new" interception in the object builder framework may have been a driver to using remoting instead of ContextBoundObject. But based on my experience so far, besides being internally used by the other blocks, object builder hasn't got wide adoption, due to lack of documentation and API complexities. An important success factor for a framework, no matter how good the framework is, is the ease of use of its APIs. I am waiting to get my hands on the February CTP of EntLin 3.0 to see how easy the PIAB can be used in conjunction with object builder. I am hoping that tying PIAB to object builder doesn’t make it more cumbersome to use as opposed to intercepting “new” with ContextBoundObject and making it completely transparent for the client code.

3 comments:

Thinkj - Thinking blog said...

so much happened in software industry in the past couple of years make me feel like an outsider now. I remember someone said longtime ago about future decapitation of ContextBoundObject. looks like it is still around. I feel that any AOP based on current .net framework would have to involve some kind of "hacking" to achieve the true unintrusive expression. I wonder why Microsoft's wouldn't bake some native support of AOP hook into .net framework. Such things will make a lot exciting .net products possible.

njbaige said...

In java world, AOP and IOC are very hot and popular such as spring component. (There is also Spring.net in .net platform, but the function is limitary). Hoping the comming EntLib 3.0 will make AOP concept more powerful and we lives easier :)

Hugh Ang said...

Xin, such mechanim at CLR level does exist, e.g. profiling API for IL rewriting. A framework can be built along that line to dynamically inject proxies. Unfortunately p&p doesn't want to ship code that is beyond using .NET FCL therefore the remoting "hack" :-) Of course there are other alternatives, such as using LCG from the System.Reflection.Emit namespace, but the interception will need interface definition and factory creation in order to work.