Introduction
Microsoft introduced Declarative Programming Style with release of MTS and COM+. MTS and COM+ provided many configurable services. E.g. "Transactional" attributes, Synchronization attributes, etc. The best thing about all these services is that it requires minimum efforts on developer side. All the services are configurable using the attributes. But we could never really add to set of attributes that MTS or COM+ provided. To some extent it helped us to visualize the capabilities of the future application frameworks.
In this article we are going to look at some features of .Net framework, which enable us to build highly configurable applications. We can build application frameworks, which help the developer to concentrate on developing the core business related functionality. Developers can invoke the services just by configuring/declaring few attributes. Developer can be ignorant of underlying framework plumbing.
But before we go to these features we need to understand concept called as Aspect Oriented Programming.
What is AOP?
Reusability is not new to us and we all make conscious efforts to achieve high degree of reusability.
Lets look at the way we use the reusable components. Lets take a scenario where we want to create a trace of an application execution. We want to log the name of each and every method that is executed and some other statistics such as how much time it took to execute the method.
So we write a simple logger class. We may provide features to log the details in a file or database table. We provide some methods to log details such as "BeginLog", "EndLog". Our program calls these methods. Each method that we want to execute, calls a method such as "BeginLog". To take a step further, we may use the magic of reflection to know which method has called the component method. At the end of the method we call the "EndLog" method to end the trace for the same method.
So even after having reusable component, developer needs to do lot of coding. But how about marking the method with just an attribute/aspect such as "LogEnable" and rest of the things are taken care by the underlying components? Well if you like this concept, then Welcome to Aspect Oriented Programming.
Aspect-oriented Programming (AOP) was invented at Xerox PARC in the 1990s.
In Aspect oriented programming, we provide the Attribute/Aspects to the class at various levels such as class/method/ property, etc. We can treat this aspect as metadata about the class. The run time can discover the metadata and provide the services required by the component.
How AOP works?
Looking at COM+ objects, we can think of attributes, such as Transaction, Security, Synchronization attributes, as aspects. The COM+ runtime provides stacks of objects, called as interceptors. These interceptors get in between the client and server and provide services such as Security, Transaction, Synchronization, etc.
The AOP framework works in the similar way. To design AOP framework we need the ability to Create Runtime that binds object and client together.
Describe the Metadata of the object. This metadata will provide the Aspect for the object.
AOP framework works solely depends on the interception and delegation. AOP framework performs interception and delegation at two levels-Object activation and Method Invocation.
At the time of object activation, run time uses the metadata (Aspects/Attributes) of the object to compose the stack of interceptors. The metadata helps to identify the services requested by the object. The interceptors are responsible to provide requested service. The runtime returns the reference to the interceptor instead of reference of the object, to the client. When client calls methods on the object, the interceptors intercept the call to do some pre processing. All the interceptors are chained to each other. The last interceptor in the chain directs the call to object. When the call is finished, all the interceptors get chance to post-process the method call.
The set of aspects together form the context for the class. The context helps to decide the right environment for the method execution. We will see in more details about contexts later.
AOP allows for better separation of tasks, which are commonly used.
The AOP approach has a number of benefits. First, it improves performance because the operations are more succinct. Second, it allows programmers to spend less time rewriting the same code. Overall, AOP enables better encapsulation of distinct procedures and promotes future interoperation.
AOP and .Net
One of the reasons why we can build the AOP oriented components in .Net is that it allows us to extend the .Net framework. .Net framework allows us provide the metadata for each component. To provide the custom attribute we need to develop custom attributes.
As you can see, the attribute class itself has some attributes. The AttributeTarget attribute will control the application of the attribute to class/method/property and so on.
[AttributeUsage(AttributeTargets.Class)]
public class ContextAtrbAttribute :Attribute
{
private string _fileName;
public ContextAtrbAttribute(string fileName)
{
this._fileName = fileName;
}
}
Now we can specify the metadata for the component using these attributes.
public class ContextClass: ContextBoundObject
{ }
Contexts in .Net
Now we have to look at the concept called as Contexts in .Net.
Context is a logical grouping of the objects that have same aspect values. With help of contexts we establish interceptors to intercept the calls on the objects.
Two objects with different contexts communicate to each other using .Net context architecture. Though we do not want to go into the details of context architecture we need to understand its basics.
Basics of Context architecture
Two objects with different contexts communicate to each other using the messages. These messages are passed thro' several message sinks.
These message sinks can be custom built. These sinks are chained to each other and these sinks pass the message to next sink till they reach the end of the chain. We can build the custom sinks and introduce them in the chain. This gives us the opportunity to intercept the message.
There are two processes that take place:
Firstly when we create a context bound object, the run time sets up the chain of message sinks. This chain is used when two objects from different contexts communicate to each other.
Secondly, when two objects in different contexts communicate to each other, the runtime forms proxy object between the caller and callee. The proxy is of two types - Transparent proxy and Real Proxy. The runtime forwards the message to the transparent proxy. This proxy serializes the stack in to message and passes it to the real proxy. The real proxy takes the message and sends it to first message sink in the channel. The first message sink intercepts the call. Message sink can preprocess the message. This message sink then passes the message to the next message sink. This process continues till the last sink i.e. Stack builder sink is reached. This sink de-serializes the message into the stack and calls on the method of the object. After the method call, the same sink again serializes the parameter values and return value into the stack and returns it to the previous sink. Each sink in the chain gets its turn to post process the message.
The sequence of flow is illustrated in Figure 1.
The messages are of 3 types - Construction messages, Method call message, and Response message.
From the above discussion its very clear that to intercept the calls on the object we need to build our custom sinks and link in the chain of sink at proper position.
Prerequisites
With all this we need to know what all classes we need to create to build our custom interceptors.
We need to use following namespaces -
using
System.Runtime.Remoting.Contexts;
using System.Runtime.Remoting.Activation;
using System.Runtime.Remoting.Messaging
First of all to make our class aware of "context" our class should inherit from "ContextBoundObject" .Net runtime will automatically create a separate context for it to live in whenever we create object of that class. .Net runtime establishes the proxies to participate in the calls across the contexts.
Secondly we need to build the ASPECTS. We need the attributes that we can apply to the class. So we have to create a class that implements IContextAttribute interface. It should also inherit from Attribute framework class. This class will define the attributes or the aspects that we want to apply to the class.
Next we want to define Context Properties. Based on the context properties, runtime will differentiate between two contexts. To create context properties, we need to implement "IContextProperty" interface and "IContributeObjectSink" interface.
We are only half done with all these classes. We will have classes required to define the contexts.
After this we need to define our own Message Sink. To do that we need to create a class that implements the "IMessageSink" interface.
Lets take look at all these steps in detail.
Implementation Detail
First we need to derive our class from ContextBoundObjects.
[ContextAtrb(@"c:\ContextClass.txt")]
public class ContextClass: ContextBoundObject
{
}
In the above example, the "ContextAtrb" attribute is the aspect provided for the class. This is called custom attribute. We have seen how to develop this custom attribute.
IContextAttribute interface
For this CustomAttribute to participate in this process of interception it should implement IContextAttribute interface. This interface has two methods
bool IsContextOK(Context ctx,IConstructionCallMessage msg);
void GetPropertiesForNewContext( IConstructionCallMessage msg);
These two methods are called by the interceptors/proxies for each attribute of the class.
The method IsContextOk provides us with opportunity to decide if the object being created should have the same context or not. The parameter ctx is the context of the caller. If we return the "true" value the object being created will posses the same context as that of the caller. The other parameter "msg" will be the message. This message can be Constructor message only as this method is called only at the time of the construction of the class.
GetPropertiesForNewContext
This method is called only when the IsContextOk method returns false. This method gives us opportunity to create the property for the context.
These properties can be implemented in a separate class. This class should be derived from two interfaces - IContextProperty, IContributeObjectSink. The context property allows us to link our own message sink in the chain of existing message sink.
As we discussed earlier, the interception mechanism works in two steps. The first step is to setup the required message sinks. The second step involves the actual interception.
This property class that implement IContributeObjectSink interface helps us to setup the required message sinks.
IContextProperty interface
IContextProperty has three methods.
string Name {get;}
public bool IsNewContextOK(Context ctx)
void Freeze (Context ctx)
Name
This is a read only property and returns the name of the property. The context class provided by .Net will add this property in its collection using this name. We can access this property using the method GetProperty of the context class.
IsNewContextOK
If this method returns true, then only the activation of the object will continue. If it returns false, the exception will be raised. This method is called after the context properties are created. Hence it gives the opportunity to check if the properties created are right for new context.
IContributeObjectSink interface
IcontributeObjectSink interface is most important interface. This interface will allow us to hook our own message sinks in the chain of the message sinks. We need to implement one method i.e.
IMessageSink GetObjectSink(MarshalByRefObject o, IMessageSink m_Next)
GetObjectSink
This method creates the message sink and returns it.
IMessageSink interface
Now the only part left is to create the message sink. To do so we need to write a class deriving from interface IMessageSink
This interface has methods
IMessageSink NextSink
IMessage SyncProcessMessage(IMessage imCall)
IMessageCtrl AsyncProcessMessage(IMessage im, IMessageSink ims)
In addition to all these methods we also have to implement the constructor.
Constructor
The constructor of the class should have a parameter of type IMessageSink. This parameter is the next message sink in the chain. The framework passes the next message sink in the chain to the class. This message sink should be returned in the method NextSink. The class has the freedom to change the message sink and return some other message sink as well. This next message sink will be linked as the next message sink in the chain.
SyncProcess
This method is called for each method call on the object. im parameter represents the messages of type Method call.
The sink gets created when the GetObjectSink method for context property is called. And the methods of this interface are called when the methods on the object are executed.
Implementation for all these interfaces is available in Listing 1.
Applications of AOP
This style of programming has found many applications. To start with the example of logging that we have seen in the beginning can be over simplified with this approach. We have to develop classes such as LogginAttribute, LoggingFileProperty and LogginSink. The LoggingSink class will intercept the call and do the logging. We can mark each class and its methods with the LogginAttribute. At the time of interception, the SyncProcessMessage method will find out the current method being called. It will check if the method has attribute "LoggingAttribute" and accordingly log the method details such as parameters and its values etc. Thus developers will just have to mark the methods with attribute and rest will be taken care by the framework.
The same applies for role-based security, declarative transactions and so on. The list is never ending.
Appendix
Listing 1
using
System;
using System.Runtime.Remoting.Contexts;
using System.Runtime.Remoting.Activation;
using System.Runtime.Remoting.Messaging;
using System.IO;
using System.Threading;
using System.Reflection;
namespace ContextBoundObjects
{
/// <summary>
/// We want to provide tracing functionality to all methods in this class.
/// </summary>
[ContextAtrb(@"c:\ContextClass.txt")] //Mark the class with Aspect.
public class ContextClass: ContextBoundObject //Inherit from ContextBoundObject.
{
private int Id = 100;
public void DoWork()
{
try
{
Utils.printInfo(MethodBase.GetCurrentMethod());
Console.WriteLine("Writing context - {0}", MyContextUtil.currentContextProp.Name);
}
catch (Exception exc)
{
Console.WriteLine(exc.ToString());
}
finally
{}
}
//To study the interception in case of property
public int myId
{
get
{
Utils.printInfo(MethodBase.GetCurrentMethod());
return Id;
}
}
}
/// <summary>
/// Define the ASPECT class. This is the custom atrribute.
/// </summary>
[AttributeUsage(AttributeTargets.Class)]
public class ContextAtrbAttribute :Attribute,IContextAttribute
{
private string _fileName;
public ContextAtrbAttribute(string fileName)
{
Utils.printInfo(MethodBase.GetCurrentMethod());
this._fileName = fileName;
}
// This method is called at the time of object activation.
public bool IsContextOK(Context ctx, IConstructionCallMessage msg)
{
Utils.printInfo(MethodBase.GetCurrentMethod());
//ctx is the context of the caller. If the context "ContextProp" is already defined. we do not want to create the context. Else we will create the new context.
if(ctx.GetProperty("ContextProp") == null)
return(false);
return(true);
}
//This method is called only if IsContextProp returns true. This method is called at the time of object activation.
public void GetPropertiesForNewContext(IConstructionCallMessage msg)
{
Utils.printInfo(MethodBase.GetCurrentMethod());
//msg parameter is of type Constructor. We create the properties of the context.
msg.ContextProperties.Add(new ContextProp(_fileName));
}
}
/// <summary>
/// This class defines the message sink. Sink is created at the time
/// of object activation.
/// </summary>
public class mySink:IMessageSink
{
private IMessageSink m_Next;
/// <summary>
/// Runtime passes the ims as the next sink.
/// </summary>
internal mySink(IMessageSink ims)
{
Utils.printInfo(MethodBase.GetCurrentMethod());
m_Next = ims;
}
/// <summary>
/// Returns the next sink in the chain.
/// </summary>
public IMessageSink NextSink
{
get
{
Utils.printInfo(MethodBase.GetCurrentMethod());
//Here you can add new message sinks to the chain.
return m_Next;
}
}
/// <summary>
/// Important method for interception. Every method/ property that is called on the object of "ContextClass" class, sink intercepts the method.The call is passed as parameter in the form of imCall.
/// </summary>
public IMessage SyncProcessMessage(IMessage imCall)
{
Utils.printInfo(MethodBase.GetCurrentMethod());
IMessage retMsg;
// Perform pre processing on the message Trace the calls on the object
string[] keyArray = new string[imCall.Properties.Count];
string[] valueArray = new string[imCall.Properties.Count];
ContextProp objContextProp;
objContextProp = MyContextUtil.currentContextProp; objContextProp.LogMessage(imCall.Properties["__MethodName"].ToString());
retMsg = m_Next.SyncProcessMessage(imCall); //Calls actual method - DoWork. imCall contains info about the method.
// Perform post processing on the message
return retMsg;
}
public IMessageCtrl AsyncProcessMessage(IMessage im, IMessageSink ims)
{
Utils.printInfo(MethodBase.GetCurrentMethod());
return m_Next.AsyncProcessMessage(im, ims);
}
}
public class ContextProp:IContextProperty, IContributeObjectSink
{
private string _logFileName;
internal static string PropName
{
get
{
Utils.printInfo(MethodBase.GetCurrentMethod());
return("ContextProp");
}
}
public ContextProp(string logFileName)
{
Utils.printInfo(MethodBase.GetCurrentMethod());
_logFileName = logFileName;
}
/// <summary>
/// This property is used to get the context property name.
/// </summary>
public string Name
{
get
{
Utils.printInfo(MethodBase.GetCurrentMethod());
return(PropName);
}
}
public void Freeze (Context ctx)
{
Utils.printInfo(MethodBase.GetCurrentMethod());
}
/// <summary>
/// This method gives us opportunity to check if the new context being created if right one.
/// </summary>
public bool IsNewContextOK(Context ctx)
{
Utils.printInfo(MethodBase.GetCurrentMethod());
//If you return False, then runtime will raise the System.Runtime.Remoting.RemotingException to the client.
return(true);
}
//Custom interface of the property.
public void LogMessage(string msg)
{
Utils.printInfo(MethodBase.GetCurrentMethod());
StreamWriter logFile;
logFile = File.AppendText(_logFileName);
logFile.WriteLine(msg);
logFile.Flush();
logFile.Close();
}
/// <summary>
/// This method allows to create the message sinnk relevant to the context properties. Different context properties can return the different message sinks. This way we can build the stack of the relevant message sinks.
/// </summary>
public IMessageSink GetObjectSink(MarshalByRefObject o, IMessageSink m_Next)
{
Utils.printInfo(MethodBase.GetCurrentMethod());
//Here we create the message sink and return.
return new mySink(m_Next);
}
}
/// <summary>/// This class is used to get the current context of the thread.
/// </summary>
public class MyContextUtil
{
public static ContextProp currentContextProp
{
get
{
return Thread.CurrentContext.GetProperty(ContextProp.PropName) as ContextProp;
}
}
}
/// <summary>
/// This class provides the static method. This method is used to trace the sequence of events in the interception process.
/// </summary>
public class Utils
{
public static void printInfo(MethodBase mBase)
{
Console.WriteLine("Class - {2} Method - {0} type - {1}",mBase.Name,mBase.MemberType.ToString(), mBase.ReflectedType.ToString());
}
}
}