Introduction
In the days where business agility is becoming the definite need of any business / IT infrastructure, quite frequently we are ending up with facing scenarios where we need to develop applications that are flexible and easily manageable.
The flexibility in an application’s architecture is demanded by the emerging business competitions, pressure to sustain the challenges created by the innovative business models, need to sustain the growing customer’s base of an established business, etc. Say for example you are building an e-commerce system with an innovative business model, targeting a niche market. Soon, it is becoming hot in the market and your system is witnessing a rapidly growing user base, in a short span of time. The system starts crawling, failing to sustain the increased user load there by creating significant loss to your business and to the goodwill you have created with your hard work and innovation.
Situations that may pull your business down may be like:
- Changes in the regulations / policies of the government because of which you may need to incorporate some more rules into your system, while keeping it running
- Need to switch from your payment gateway to another one who is offering services at a discounted price, to increase the revenue
- Need to shift from one packaging company to other (like say from FedEx to UPS) as there is a need to increase of the speed of the delivery
- Demand to shift from a particular financial outsourcing services provider to another
- Etc.
The architecture that could excel in such an agile environment can be called “Pluggable Architecture”. There are proven methodologies (Patterns) that can constitute the design to realize such architectures. AOP is one of such available patterns / methodologies widely adopted in the market.
Background
AOP – Aspect Oriented Programming is a methodology that helps in keeping the “cross-cutting concerns” separate from the code blocks that encapsulate business logic. “Cross-cutting” here refers to the code blocks that are non-business specific and that are repeated across different classes spread across different layers. Examples of cross cutting concerns are: Logging, Exception Handling code blocks specific to instrumentation of the code, etc. There may be many numbers of such concerns which need to be abstracted from the business logic specific code.
The basic thumb rule to identify a cross-cutting concern is: If a concern is repeated across classes spread over layers / tiers, then it is a cross-cutting concern.
AOP Benefits
The facility to separate the cross-cutting concerns helps in:
- Selectively applying the cross cutting concerns, as required. Say some logic related to profiling the code for performance monitoring would be required only at the time of testing but not in the production environment so they can be enabled/disabled based on the environment as required.
- Applying any changes / fixing bugs in the cross-cutting code logic, without affecting the business logic code in the production environment.
- Evolution of the different parts of the system in different paces.
- Arriving at a final solution where the code is easy to understand and maintain
Need for a Rating Methodology
Having realizing the benefits of AOP, the next step is to look for ways to implement it in our application development. In this case, instead of starting from scratch, the best way is to leverage the research and effort put by many hardworking tech savvies around the world through the availability of open source frameworks / utilities.
When we are in the stage of looking for adopting an open source AOP framework, lots of open source AOP frameworks are available in the market and hence, we need to choose the best possible one for our development. Choosing the best possible one could be a difficult task as always there will be conflicts of thoughts and difference of opinions, especially when we are in a team. Especially when we are in a position to convince our customers for the adoption of a particular framework, we cannot choose a particular AOP framework, unless we have some good justifications.
Will it not be good, if we have rating methodology where we can analyze and evaluate the available AOP frameworks qualitatively and quantitatively enabling us to rate the AOP frameworks in the market so that we can make an informed decision in a short span of time. The result of such a thought process is the following “Frameworks Rating Methodology”.
Open Source AOP Frameworks Rating Methodology
As a part of this effort, I had identified some of the attributes (which can be expanded / refined) and assigned points for each of the AOP frameworks (which is subjective – It is based on my research and information available to me. You can change it as per your observation and conviction.)
The list of the open source AOP frameworks that are considered for this rating process are:
The Rating attributes identified and used for this rating process are:
| Quality of the Methodology adopted |
There are different approaches available to achieve AOP in .NET. Each of the available open source AOP frameworks adopted different approaches. Basically AOP can be achieved either at compile time or at runtime. According to me, runtime will always be a overhead when compared to compile time, as it is a one time process. Details on the available approaches available at: http://www.ayende.com/Blog/archive/2007/07/02/7-Approaches-for-AOP-in-.Net.aspx When I was investigating the details of approach adopted by these open source frameworks, information clarity is available only for some of the frameworks. I had assigned points based on my thought process and perception. It may differ from person to person based on the availability of the information and depth of the research. |
| Community support |
When we choose a particular open source framework for our development projects, unless there is a wider community support, we cannot go with it, as it may be a high risk during the course of deployment or in the later stage of production support. |
| Visibility of any Implementations / Industry-wide adoption |
Again, as a part of finalizing architecture for a solution, our clients may be looking for proven case studies / industry wide adoptions of the products that we choose. The same thing is applicable here as well. Availability of proven case studies will provide us some confidence on that framework especially when we go for large scale, enterprise level solution development. In this investigation process, I could rarely see any proven case studies for any of these listed frameworks. |
| Ease of adoption by developers |
This is again subjective and can vary from person to person. |
| Learning curve required |
This is again subjective and can vary from person to person. |
| Memory Footprint / overhead |
This could be a key attribute on rating a particular framework. Only some of the framework’s groups are explicit on memory foot print of their products. As this could be a significant factor affecting the performance and resource consumption especially on large scale deployments, I would suggest the respective framework providers to publish benchmark case studies / lab results, which would provide us good confidence on the framework. |
| Available version in the market (Is it a RC or still in alpha stage)/ Documentation |
Some of the frameworks on its early stages development. Periodical releases of the subsequent versions of the frameworks are the indications of the aggressive development and enthusiasm of the community behind those frameworks. Also, availability of the documentation (API, Conceptual, and Architecture) is a definite need for any framework to understand them clearly. |
I have assigned very low points if the information is not clear or if it is not available or if it is vague.
Guidance for Rating Attributes
- 0 – bad, Not known, Not clear, sufficient information not available
- 1 – To be improved, some information is available
- 2 – Good, sufficient information is available
- 3 – Very good, no major overhead, no major memory footprint, excellent information is available
Here is the resulting rating matrix:
|
Preliminary Rating Matrix
|
|
Available Open Source .NET AOP Frameworks / Utilities
|
|
NAspect – Puzzle.
Net |
Aspect# |
Policy Injection Appli-
cation Block |
PostSharp |
Seasar |
Aspect
Dng |
Spring.Net |
| Quality of the Methodology adopted |
2 |
2 |
2 |
3 |
2 |
2 |
2 |
| Community support |
2 |
2 |
3 |
3 |
1 |
1 |
3 |
|
Visibility of any Implementations / Industry-wide adoption
|
1 |
0 |
2 |
2 |
0 |
0 |
1 |
| Ease of adoption by developers |
2 |
1 |
2 |
3 |
2 |
1 |
2 |
| Learning curve required |
1 |
1 |
2 |
3 |
1 |
1 |
2 |
| Memory Footprint / overhead |
1 |
0 |
1 |
3 |
0 |
0 |
1 |
| Available version in the market (Is it a RC or still in alpha stage)/ Documentation |
2 |
2 |
3 |
3 |
2 |
1 |
3 |
| Total |
11 |
8 |
15 |
20 |
8 |
6 |
14 |
Conclusion
Whenever we go for implementing a particular methodology or concept like AOP, we will always leverage the existing open source frameworks. Since there are a number of open source frameworks available in the market, it will always be good to have some concrete justifications as a base for selecting a particular framework for adoption.
Adopting a rating process like the one explained in this article will ensure that the frameworks are subjected to both qualitative & quantitative evaluation process, resulting in a meaningful decision.
From the matrix, the frameworks that emerged in the ‘top 3 ‘list of are:
