As said before, the AOP Alliance goals are not to provide new models or better implementations of existing tools. In fact, the AOP Alliance goals are to specify normalized API for the components that are identified in common Aspect Oriented Environments (AOEs) implementations. If we manage to do this, it will be possible to build better AOEs than existing ones by integrating the components that best fit the context in which we want to use AOP. In particular, it should be possible to use the very best of AOP, even in complex environments such as J2EE application servers.
So, if we refer to figure 1, the AOP Alliance's role should be to define the API of the identified components. The most important components are the low-level ones because their implementations will influence the environment in which the AOE can be used. Some technical caracteristics may also have deep inpact on the resulting system properties (e.g. are the aspects can be dynamically woven/unwoven? is the system scalable regarding distribution? can the system cohabit with built-in aspects such as persistence or transactions?). However, the high-level components are also quite interesting for tools such as IDE, debuggers, modelling tools, and so on. Having a common AOP concepts manipulation API will help the tools to better support several AOP implementations in different environments.
The AOP Alliance could provide some reference implementations for some components (by using existing tools). However, it would be better if existing tools (most of the tools creators are in the Alliance) provide their own implementations of the defined APIs. These implementations will validate the API correctness.
The AOP Alliance will not tackle the weaving logic and the configuration logic since it really depends on the AOE implementation. However, we should also provide some reference implementation in order to show how our API should be used to build AOEs.
Finally, the AOP Alliance will not address the third layer (development-level). We should let the development tools implementors use our API when the AOP tools they integrate implement it.