Philosophical Questions
Having just got back from
TheServerSide Symposium in Boston, I can report that AOP was definitely
the talk of the conference. What was surprising to me, however, was the
lack of focus on AspectJ. Most comments were of the form "it's too
powerful for most developers" or that the special compiler makes it
difficult to sell in most organizations. Instead, most of the talks
focused on newer "pure Java" AOP frameworks.
I personally find AspectJ to be a well
designed implementation of AOP concepts. On my weblog (http://www.freeroller.net/page/mschinc), I've been documenting my own exploration of
the capabilities that AspectJ provides. Looking closer at "pure Java"
approaches like AspectWerkz (http://aspectwerkz.codehaus.org/) something has been bothering me, but I haven't
been able to put my finger on it. I'd like to put a couple of questions
out to the list and see where your thoughts are on the subject.
1) Can Aspects themselves be broken
down into smaller sub-components?
Most of the Java AOP frameworks break
out aspects into a number of different pieces. For example, you
implement your advice as one Java class, your introductions as another
and then define (usually using XML) the pointcuts and the relationships
between the components. So one Aspect could actually require many files
to implement and define. Does the complexity of this approach interfere
with the AOP philosophy? My fear is that when the implementation
requirements are complex, from a language point of view, you start to
lose track of the problem you are actually trying to solve.
As an aside, I think the AspectWerkz
design for advice is broken. Because each type of advice is a class
(pre, post and around) and each advice class extends a pre-existing
class, you can't share any information between different types of
advice on the same pointcut.
2) Can pointcuts be modeled separately
from advice?
This follows on the above point, but
it's one that I find a little odd. Most (all?) of the pure Java
approaches define their pointcuts in one file and their advice in
another. Presumably this means that advice can be reused across
multiple different aspect definitions. From a philosophical point of
view, can advice be modeled truly independently from pointcuts? I would
think that certain types of advice, particularly when dealing with
cflow and other advanced join points, really require the pointcut
definition to be present in order to make sense.
3) What role, if any, should metadata
play in AOP?
I know Gregor has commented on the use
of metadata a couple of times, but the JBoss group is charging ahead
with their "AOP" product which encourages developers to use class
metadata to load library aspects. This strikes me as wrong in many
ways, but the message that is reaching the development community is
that interceptors and metadata are all you need to do AOP. Is this just
a function of what's easy to implement, or are people really having
trouble grasping the concepts?
I'm looking forward to hearing your
thoughts.
Cheers,
Merrick