Configuration using Aspects

In a previous article I wrote that code and configuration are one in the same thing, only differing in the constraints enforced on its target audience. One consequence of this is that you can apply the design patterns we employ on code and apply them for configuration.

There are two issues with configuration. The first is that configuration has a profound effect on the behaviour of software such that it is critical that exceptions be traceable to erroneous configuration. The second issue is whether configuration can be applied only at initialization or at any time during a software's lifestyle.

The first mental block that we overcame in reasoning about configuration is that there is no difference between it and code. The second mental block is that there is no difference between configuration and defining class schema. Configuration is analgous to runtime defineable classes.

So in general the static and the dynamic states of code is dependent on configuration. Configuration defines code not the otherway around. Think of a superclass that defines a subclass. Configuration is the superclass, the subclass is code. The configuration does not know about the code, the code however knows about the configuration.

Therefore if behaviour breaks in code and it is a consequence of a configuration, then exceptions would be informed enough to pin-point the cause. One of the major difficulties of code bases that use a lot of configuration files is that it is extremely difficult to discover the root cause of failures. When a configuration variable is read, one should always record and propagate the origin of this information.

We could turn the tables such that configuration depends on code. That is, configuration is not a passive data source that does care what part of code uses its information. Rather, you could build configuration such that it is required to specify exactly what part of code it affects.

The above design is a kind of injection. The original code doesn't know about configuration, it is oblivious to it. The effect of this is that it does not obfuscate code with configuration lookup and initialization, however a similar effect can be employed using Dependency Injection. The advantage of this approach is that structure, scope and lookup can potentially be defined in the same place. With the advent of Annotations, this style of configuration may become more prevalent in the future. The disadvantage of this approach is that configuration is too tightly coupled to code.

The other issue of Configuration is the question as to when can changes take effect. Runtime configurability can be a complicated matter. In the passive approach of configuration above, it is not explicit what parts of code a configuration affects. Creating a general algorithm for starting and stopping components based on implicit knowledge of its dependencies may be an effort in futility. The best one may be able to do is to start and stop a system in a coarse grained manner.

What is needed is a mechanism that explicitly defines structure, code and lookup at the same time decouples code and configuration. A possible implementation of this is to use an Aspect to manage configuration. Configuration is defined in a stuctures that is traversed and constructed by the aspect. The aspect then injects the composed configuration into the base code. Think of it as Dependency Injection using Aspects.

One final point to remember, configuration tends to be a runtime artifact, therfore the above idea may only work for aspects that are applied to runtime instances and not to static classes.

[update] Incidentally, Jonas Boner has an interesting demonstration of Dependency Injection with AOP.