The More the Merrier

At his July 2004 breakfast meeting with software architects in Sydney, Australia, Bill Gates announced Microsoft's plans to embrace aspect-oriented programming. The news has pessimists worrying that Microsoft might seek to redefine AOP as only about attributes, a technology Microsoft introduced in C#.

But I think that won't happen, for a few reasons. First, AOP and attributes are synergistic. Attribute-enabled AOP is more powerful than either alone. On the Java platform, support for attributes will shortly be added to all the AOP languages. It would benefit .NET programmers to have that same functionality. (It's no surprise that AOP and attributes are synergistic—developers of AOP built aspects with that in mind.)

Also, AOP is no threat to Microsoft. As I noted last month, AOP can be used as a tool to make platforms more useful and valuable, provided the vendor is clever about the platform-control game. And say what you want about Microsoft, but they're very clever about platform control.

In April, I summarized attributes, explaining that they introduce into C# the basic syntactic hook required to enable Lisp-style macros. Attributes make it possible to tag parts of a program with information that can be used in various ways. Of most interest in this discussion is that tools can use attributes to determine where to extend semantics of the program, by modifying the program or the environment in which it executes. Attributes and AOP solve different modularity problems, however. Attributes provide modularity similar to that of methods, procedures and macros. With methods, wherever you explicitly call the method, you get the behavior of its implementation. Similarly, wherever you explicitly type the attribute, you can arrange to get additional behavior from the attribute.

AOP advice and introduction have a different kind of modularity. They can reach out and add behavior, even to join points that don't request it explicitly.

AOP Enhances Attributes

By default, attributes are just syntax. There's no standard way to associate runtime behavior with an attribute, so people sometimes use low-level and too-powerful mechanisms such as bytecode manipulation to add attribute behavior.

AOP provides a great mechanism for associating behavior with attributes. Once AOP pointcuts are attribute-aware, you can use AOP advice to define the behavior that should be associated with an attribute:

 pointcut transaction(): call([Transaction] * *(..));<br>
 
 around(): transaction() {
   <i>appropriate code around
   call to proceed</i> }

A common complaint about AOP is that pointcuts that rely on naming conventions may be dangerous. Some worry that the name pattern will match unintended join points.

Attributes will let you replace pointcuts that rely on naming conventions with pointcuts that use attributes. So instead of writing execution(void com.bigboxco..*.set*(..)), you just tag each setter method with a Setter attribute, and the pointcut becomes execution([Setter] * *.*(..)). Now only methods that explicitly have a setter tag will match the pointcut.

Because AOP pointcuts are compositional, you can rely on the setter naming convention by default and use attributes to tag exceptions to the rule. Then you write a pointcut like:

 pointcut setter(): 
     execution(![NotSetter] void *.set*(..));

When should you use attributes instead of non-attribute pointcuts? Use attributes when join points need to be identified based on a property that requires human insight to decide. Non-attribute-based pointcuts are good when the property can be determined by computer.

Attribute names should describe the join points being tagged, rather than the advice that will apply. This makes it natural for multiple aspects to add advice to join points with specific tags. For example, tagging a field as [SensitiveInformation] might be useful for encryption, authentication and auditing aspects. [ReadOnly] is a good name for an attribute; [ReadLock] ties too closely to specific behavior. Similarly, you can tag in terms of business concepts and then advise those in a variety of contexts, from publishing business events to handling security or managing persistence and transactions.

Once attributes are embedded into an AOP framework, all the AOP power can work with them. For example, using the popular cflow pointcut, it's possible to distinguish between top-level and nested transactions:

pointcut topLevelTransaction():
     transaction() && !cflowbelow(transaction());
 pointcut nestedTransaction():
     transaction() && cflowbelow(transaction());

Here, I'm just showing examples of using attributes with advice, but you can also use them with introduction. For a familiar example, you might decide to explicitly tag Subject and Observer classes. Having done that, an aspect could add add/remove observer methods using a syntax similar to this:

 void [Subject]*.addObserver([Observer] obs) { ... }

Microsoft working with AOP will also be great. Today, AOP languages for .NET are less mature than those for Java simply because the initial research and development was almost entirely Java-based. But we now have a pretty good idea of what AOP should be, and the developers of the Java AOP languages have started work on integrating AOP and attributes. It's a good time for serious work to begin on AOP for .NET.