Aspects revisited

Emperor Joseph II's famous complaint about Mozart -- "Too many notes" -- could also have been leveled at my "Patterns of Persistence" column. A number of people responded favorably to the column, but several wondered whether it was about JDO (Java Data Objects) or AOP (aspect-oriented programming). The connection between the two was JBoss 4.0, which -- according to the JBoss Group's visionary leader, Marc Fleury, -- treats persistence as an aspect that can be attached to an object, rather than as an intrinsic property of the object. In retrospect, though, JDO alone would have been more than enough to tackle in one column.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

Meanwhile, having introduced AOP, I should explain what I think it is and why I think it matters. Ken Wing Kuen Lee's "An Introduction to Aspect-Oriented Programming" is a concise and cogent primer on the subject. By way of example, Lee imagines a development shop where the policy is that methods, in any class, must invoke a logger on entry and exit. AOPers call this kind of requirement a "crosscutting concern," meaning that it affects classes without regard to their kinship in the class hierarchy. You can make a rule that programmers have to call the logger from every class, but there's no easy way to ensure that they'll do it at all, nevermind correctly. The AOP solution is to define a pattern that matches the set of methods that should call the logger, and to rewrite the code automatically so they do. That's what happens under the covers, anyway, but the idea is that the person who'd like to enforce the policy simply declares it, and tools make it so -- without requiring the cooperation or even the knowledge of the programmers responsible for the affected classes.

This kind of policy-driven interception and enhancement seems closely related to the way that middleware frameworks, including J2EE and COM+, declaratively control things such as security and transactions. The same idea is popping up in the realm of Web services management, where vendors are busily inventing systems that enable administrators to declare policies that are implemented by intercepting SOAP messages. AOPers might not be comfortable making this connection, but leading middleware wizards -- including Marc Fleury on the Java side, and Clemens Vasters in the COM+ and .Net Enterprise Services camp -- are clearly inspired by the AOP ideas.

So it was with great interest that I read Clemens' recent Weblog entry, "Summary of a Year with Aspects". Vasters, who is CEO of newtelligence, reviews a year-long effort to add policy-driven interception to the .Net Framework's encapsulation of Windows' COM+ middleware. His blow-by-blow report is full of revelations about the relationship between the unmanaged COM+ infrastructure and its .Net wrapper, Enterprise Services. Suffice it to say that, with Herculean effort, he got interception working. And then he hit a wall. In theory, aspects don't affect one another, but in practice they often can and do. His conclusion: "We need something like COM. No, not the technology itself, but we need something that does for aspects what COM did for objects: Allowing multiple parties to build composable parts that can be queried for their requirements and capabilities, and that implement well-known protocols for effective coordination."

Just when you thought it was safe to go into the water! Seriously, though, Clemens makes a great point. Actions have consequences, and as active intermediaries proliferate, we'll need to find ways to coordinate them.