As I look through our aspect configuration I notice that there is a distinct pattern throughout. The configuration, some of which is XML and some of which is provided by Java source code, can be divided into three kinds.

The first kind is the configuration about a single aspect. It defines the aspect, be it an advice or introduction, and declares its relationship with the world. Its dependencies and what it provides. What goes in and what comes out.

The second kind is the configuration that declares how different aspects should relate in a specific system. It imports aspects, declares precedence between them, and how they should be grouped depending on annotations and what interfaces specific objects implement. What goes in and what comes out. But on a higher level.

The third kind is the configuration that describes specific classes, or "sets of objects". It defines the introductions applied to particular classes, which in a cascading fashion will also determine to some degree what advice will be added. Introductions can be added on a very granular basis, i.e. to a specific class, or to sets of classes, like a package.

The first kind forms the atoms of an AOP application. The smallest lego blocks available. The second kind determines the rules for how the atoms form together into molecules; the natural laws so to speak. These become the building blocks of real structures, and depending on how they are formulated you get different orders of stability, flexibility and/or chaos. The third kind is the actual application, as it is perceived by clients of it, and hence it can be extremely varied.

In terms of reusability the first kind of configuration is extremely reusable as each individual aspect make minimal assumptions about how they are used, even though "minimal" can be quite substantial in some cases. The second kind is less reusable since it imposes assumptions about what set of aspects need to be available for its "laws" to function properly. This is because the second kind is what it responsible for describing how aspects interact, and if some of them cannot be used for some reason the laws suddenly don't behave as they were intended. The third kind is even less reusable as it makes a lot of assumptions about what is available, and the configuration is rather specific in terms of what the end result is supposed to do.

The resulting components adhere to a strictly defined behaviour (depending on the quality of the second kind of configuration, of course), which can be used by other components, and even individual aspects. In this sense, even though everything is separate, they are also inherently intertwined in a symbiotic fashion where it is difficult to separate one from the other.

By acknowledging that there are different kinds of configuration it is possible to introduce a degree of order into an AOP application. Everything is not equal, everything is not the same, which is what gives the developer a possibility to ensure that any new aspect (s)he creates fits into an existing system in a non-disruptive manner.

Harmony follows and everyone is happy.

The End.