That's where they agree. After that, they diverge. Clemens thinks that we have to learn to deal with these issues because the web services world is a pipeline of services. This is especially true in a GXA based view of the world. The mechanism for weaving aspects is not the hard problem, its making those aspects work together when they aren't supposed to know anything about each other. His solution to this is to apply transaction management techniques and turn each aspect into a very light weight semi-transactional resource manager.

Craig is down on AOP because services are not generally orthogonal, but his argument is weakened by relying on the fact that COM+ services are not orthogonal. He is giving up on AOP (at least an interception or attribute based form) and saying that we just have to write the code by hand since we have to baby sit all the interactions between the aspects/services. That leaves the problem of too much typing, which he proposes to solve using code generation. At this point, you already know what I'm going to say... Macros are a good way to solve the code generation problem without resorting to a separate tool.

There's a lot tangled up in here, a lot of it stems from trying to figure out how to use AOP to solve problems in existing systems. It's nice to see people from the .NET side of the world making contributions to clarify what AOP is all about. At the same time, we shouldn't be limiting the applicability of AOP because COM+ is broken. In the Java world, we have people busily reimplementing service frameworks to allow for use in AOP settings. The JBoss AOP stuff comes first to mind, but they aren't the only ones. We're still in the experimental phases of AOP, clarification, not codification should be the focus.