本文介绍了面向切面编程(AOP)技术，概述了多种AOP实现方案如AspectJ、AspectWerkz等，并探讨了AOP组件标准化的重要性，旨在促进软件复用及提升开发效率。
[url]http://aopalliance.sourceforge.net/motivations.html[/url]
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.
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.
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
