The difference between callhandlers and behaviors is mainly historical.
In the beginning, there was the Policy Injection block. Handed down from Mount Sinai... no, wait, different story..
Basically, when we originally wrote PIAB, it was based around the concept of call handlers. These are objects that implement "aspects" and are invoked based on matching rules that check the method being called to see if it's a candidate for the
aspect or not.
Behaviors, are, essentially, the exact same thing - an implementation of an "aspect" that can intercept a call or the return value from that call. In fact, if you look at the type definitions for call handlers and behaviors, there's essentially
identical. So what's the difference?
There's one subtle but very important difference here. Remember my statement "... are invoked based on matching rules that check the method being called ..."? Behaviors have NO matching rules involved - they always run for every call
on the intercepted object, period. If the behavior only works when called on particular methods, then the behavior author is responsible for doing the checking inside the Invoke method to determine if it's appropriate to run or not.
This difference is the reason we implemented two separate abstractions. CallHandlers are written assuming they just run; that assumption isn't valid in the context of a behavior. We felt it was safer to have two different but similar types to make the author
and user aware of the difference in semantics.
This "always runs" semantic gives behaviors one piece of power that call handlers don't have - the ability to implement methods that the underlying object doesn't implement itself. Which was the whole point - to get the ability to add interface
implementations through the interception mechanism. This was a feature I wanted from the start of PIAB, but couldn't get in there until Entlib 5.
So I hope this helps explain the difference.
As for how to implement the interface, basically you create a class that implements IInterceptionBehavior. Inside the implementation of the Invoke method, check the MethodInfo on the input (input.MethodBase) to see if it's one of the methods on the interface
you're implementing, and if it is, well, do whatever you want. Note the the behavior doesn't need to actually implement the interface in question (that is, have the interface on it's class declaration) in order to provide the implementation of the methods.
It's completely dynamic and done at runtime.
For an example that does this, see the documentation on interception on MSDN.
Hope this helps,