0 Replies Latest reply on Dec 16, 2004 9:41 AM by infectedrhythms

    Servlet with broker pattern.


      This is the first of a couple of message I hope to write on AOP in Java.

      The purpose of the messages is to compare some of the newer proposals,
      like Rickard's, JBoss, Jadvise and AspectWerkz to "good old fashioned"

      My goal is not to champion AspectJ over the other proposals. I assume
      there are very good reasons (the "XML issue") for there to be AOP systems for Java other
      than AspectJ.

      Instead my goal is to identify some of the key features of AspectJ that
      I believe other AOP systems should also have, and start a discussion
      about whether the other proposals have those properties, could have
      those properties, and whether it would be a good idea.

      This initial message just enumerates and describes some key properties
      of AspectJ. The message is primarily focused on the pointcuts and
      advice part of AspectJ.

      -elements of the join point model are orthogonal-

      Perhaps the most important property of the AspectJ design is that
      the elements of the join point model are orthogonal. That is, the
      join points, the pointcuts, and the advice are orthogonal -- they
      can be used in any combination. This was one of the hardest things
      to achieve in the design, but it is very important, and it is at
      the core of what leads to several of the other nice properties below.

      -pointcut language is compositional-

      The pointcut language is compositional. This means that you
      can take pointcuts and compose them to form other pointcuts.
      This means that you can build up crosscutting structure in
      a similar manner to what we know about building up procedural
      structure or class structure.

      -pointcut language supports named abstractions-

      The pointcut language supports named abstractions. The user
      can define a pointcut like the well-known move pointcut:

      pointcut move(): call(void FigureElement+.set*(..));

      And then use it elsewhere by name. For example in an advice

      after() returning: move() {

      If you aren't familiar with this example, see the tutorial
      at http://www.parc.com/groups/csl/projects/aspectj/

      This is just like the naming we know how to do in procedures
      and methods. The name defines an abstraction, elsewhere we
      can use the abstraction by name.

      The combination of supporting named abstraction and being
      compositional means we can say nice things like:

      after() returning: move() && !cflowbelow(move()) {

      and easily understand what that means.

      -static typing-

      Pointcut and advice declarations in AspectJ are statically
      typed. This supports separate compilation and it means that
      that actual weaving becomes typesafe. Which means the
      weaving can happen later than compile time, like load time
      or even in the VM.

      For the programmer this means I can be confident, when I see
      an advice like:

      after(FigureElement fe) returning: move(fe) {

      That this advice will never result in a runtime type error, no
      matter what classes it is woven against.

      Its critical to have type safety, or else we are asking people
      to take a step back in order to take a step forward.

      The combination of the above means that named pointcuts are
      really very solid abstractions of logical events. This means
      we can easily change things on either the defining or the use
      side of a named pointcut.

      For example, I can change the definition of move() to:

      pointcut move(): call(void FigureElement+.set*(..))
      && initialization(FigureElement);

      without having to first go and look at all the advice that
      directly or indirectly depends on move. Or I can add some
      new advice without having to look at the exact definition
      of move().

      Note that when I say "without having to go and look" I mean
      it in exactly the sense as we can change a procedure body
      without having to go and look at all the callers, or add a
      new call to a procedure without having to go and look at
      the body of the procedure. By this I mean that the name
      of the procedure, the result type and the argument types
      define an interface, and many changes are possible that
      stay within the bounds of the interface. So what this
      really means is that we OFTEN don't have to go look. Of
      course sometimes we do, for procedures or pointcuts.

      The guarantee we get is just like with statically typed
      procedures. If we keep the pointcut interface the same
      we can change either side and know that the program will
      still compile and weave.


      The combination of the above properties, and in particular the
      orthogonality of the join point model makes AspectJ feel fairly
      extensible. For example, when we added advice execution join
      points we just had to add the join points and a new pointcut.
      They just dropped into the language with no other problems. We
      can't be sure of course about future extensions, but we have
      some optimism about this based on our experience so far.

      --other properties--

      There are a number of other critical properties that AspectJ
      has that any AOP for Java should also have. Because this message
      is already long, I will just list them:

      - static advice (declare warning, error, soften)
      - intertype declarations
      - code structure model (support IDE and other browser tools)
      - Open Source open standard

      The next step is to address to what extent the other proposals
      have these properties, in particular to what extent Bill's new
      design does. I'd appreciate the help, since I don't know the
      details of Bill's new design.