AOP Alliance (Java/J2EE AOP standards)

http://aopalliance.sourceforge.net/motivations.html
AOP Alliance (Java/J2EE AOP standards)
Motiviations

Aspect-Oriented Programming (AOP) is a programming technique that will be able to enhance several existing middleware environments (such as J2EE), or development environements (e.g. JBuilder, Eclipse).

Several projects now provide AOP-related techniques such as generic proxies, interceptors, or bytecode translators.

    * ASM: a lightweight bytecode translator.
    * AspectJ: an AO source-level weaver. New Language.
    * AspectWerkz: an AO framework (bytecode-level dynamic weaver+configuration).
    * BCEL: a bytecode translator.
    * CGLIB: high-level API for class artifact manipulation and method interception.
    * JAC: an AO middleware (bytecode-level dynamic weaver+configuration+aspects). Framework.
    * Javassist: a bytecode translator with a high-level API.
    * JBoss-AOP: interception and metadata-based AO framework.
    * JMangler: a bytecode translator with a composition framework for translations.
    * Nanning: an AO weaver (framework).
    * Prose: an AO bytecode-level dynamic weaver (framework).
    * ... and many others (email me to add a new one)

All these projects have their onw goals and speficities. However, several common basic components are still usefull (and sometimes required) to build a full AO system. For instance, a component that is able to add metadata on the base components, an interception framework, a component that is able to perform code translation in order to advice the classes, a weaver component, a configuration component, and so on.

To us, it would be great to be able to reuse different components coming from different projects to build a full AO system, and for three main reasons.

    * Firstly, several components already exist and it would be stupid to rebuild them.
    * Secondly, various implementation of the same component may be useful and be more-or-less suited depending on the environement. For instance:
          o the program tranformation can be done at a bytecode or a the source-code level, at compile or at run time, using an interception or a code insertion mechanism depending on the implementation of the component that translates the base program,
          o the weaver may be used within a standard Java context or within an EJB context, which may imply some implementation differencies
    * Thirdly, having common interfaces and components would help in reusing aspects on different weaving environements... this will greatly improve sofware reusing.

For these reasons, we think that a standarization of the interfaces of the aspect-oriented components would be great and will bring great simplifications for the entire AOSD community, but also for all the communities that will to use AOP in a close future.