[] [] [] []
Next: Conclusion Up: High-Level Components Previous: AOP API   Contents

   
Configuration API

Many aspects can be implemented in a generic fashion. This means that they implement a logic that is potentially reusable for any program in which you would want to weave the aspect functions. Most of the time, this aspect-reusing process implies a parameterization of the generic aspect (for instance, tell a generic persistence aspect which class should be persistent and how). In AspectJ, this can be done by subclassing abstract aspects. But it can also be done by using external tools (e.g. pre-processors). In J2EE environment, the configuration process of the built-in aspects (technical concerns of the EJB container) is parameterized by XML deployment files. In JBoss/AOP and other frameworks, the configuration can also be done using XML files. In JAC, the configuration can be done in Java programs with the aspect configuration API or by using a specific scripting-like language, and so on.

It would be great if we could normalize a configuration API. It would make AOEs integration easier for development tools. It would also facilitate the reusing of specific configurations from an AOE to another (e.g. AspectJ and JBoss/AOP).

Note that it is maybe unrealistic to make the aspects portable from an AOE to another because of the potentially important differences. But it seems less unrealistic to make the aspect configurations portable, which is already a first step towards AOEs interoperablity.


[] [] [] []
Next: Conclusion Up: High-Level Components Previous: AOP API   Contents
Renaud Pawlak 2003-07-12