Thus was born the notion of "Cross Cutting Concerns" that allowed routines of common utility to cut across many different classes. These crosscutting units became known as Aspects and the discipline of using them became Aspect-Oriented Programming. Aspects modularized behaviors and made reuse across different classes much easier. Special languages were developed to support the notion of Aspects, the first of these being AspectJ from Xerox PARC. Although AOP has been developing for nearly a decade, it has only been usable for the last couple of years. Java, with the reflective nature of its runtime system, has been the primary language to which aspects have been added. Rod Johnson, author of J2EE without EJB, built an Aspect Oriented Framework called the Spring Framework, which has gained a lot of popularity with developers with its ability to incrementally add new functionality and switch in different implementations of services. The Alfresco™ system uses Spring as the foundation of its Aspect-Oriented approach.

Content Management is a perfect example of a class of systems that can use AOP Content Management is used for many different types of applications: web content management, document management, records management and image management. These applications use a common set of functionality that includes such capabilities as versioning or content storage management. Some behavior, such as locking, may be used by some, but not all of these applications. Meta-data, such as the industry standard Dublin Core set of meta-data, might be useful for document or records management, but not necessarily for image or media management. Some functionality may be optional and useful for some applications, such as categorization and auto-categorization, but add too much of a performance drag for high-performance content management applications such as some types of simple records management. In a purely object-oriented approach, all this functionality is made available to all types of content that might use it, adding a space and time burden to applications that do not need it.

In the AOP approach, a system uses a pattern of development called Dependency Injection. Dependency Injection is to take method on an interface, such as fetch or save, and to inject a handler that does additional processing either before, after or instead of the standard call. For instance, to add a read lock on a content object, we could make a lock call before a fetch and an unlock call after a save or release call. The calling application should not be aware whether a read lock has been added or not, so the dependency injection should be automatic and not require any additional programming. The Spring Framework provides us with the ability to wire in these automatic behaviors as a configuration exercise rather than add code at all the places we need to use it. Transaction control is an example of a capability that can be added in without programming and providing us with robust control of content. In addition, the Spring Framework gives us a number of aspects that we use extensively by only configuring them in, such as: transactions, n-tier partitioning, caching, web service calls, authentication, and service call authorization.

The first advantage of the AOP approach is performance. The Alfresco system does not use code or manage data that are not needed. This eliminates a lot of unnecessary data transferring and persistence. It also lessens the amount code that needs to be executed access or save content. We can also configure remoting calls or remove them as necessary. This means that we do not need a three-tier architecture if it is not necessary for applications such as web applications or portals. If a portal runs in the same JVM as the content repository, it is likely to run much faster without compromising security. However, if applications require a multi-tier architecture for consolidation or process partitioning purposes, the Alfresco system can layer its architecture simply by configuration.

The second advantage is the adaptability of the content repository. We can add new capabilities such as new automatic processing or new access controls without recoding the repository. We use dependency injection to add it at well know locations such as at content access and save points. This same mechanism also makes it possible for us to add new web services without a great deal of effort. Alfresco has also added the ability to drive these aspects using a rule-base and making them meta-data driven. New aspects can be introduced to a content object simply by changing its meta-data. Since there are clear boundaries and introduction mechanisms for aspects, there is no reason why these aspects need to be implemented in Java. The Alfresco system will be introducing the ability to add new aspects using PHP, Perl and other popular languages.

The Alfresco architecture has been organized into service layers to take maximum advantage of this Aspect-Oriented approach. We will be adding new aspects on a regular basis that should not require changing the underlying system. Some of the early aspects include categorization, versioning, transformation and auto-classification. Our intention is to encourage others to create aspects as well and use the open source community to make it available to all Alfresco users. The Alfresco system will allow users to add new content capabilities dynamically without changing their entire infrastructure. This will allow users to adapt to new business requirements and rely on a stable, performant basis for content management.