Lamino

Constructo is a new project but its roots lie with an application framework that has a history of many years and is now in use in many enterprise applications.

I was working at a company using the ATG Dynamo application server (see sidebar). A basic component in Dynamo was the Nucleus, which you would now describe as an IoC framework. The Nucleus configured components that resided in a hierarchical namespace, corresponding to directories, and each component was defined by a property file that listed values for its properties.

Nucleus had the concept of CONFIGPATH, whereas same-named files, in corresponding directories, rooted at the configuration roots of the CONFIGPATH, were combined to define the component (latest files in the CONFIGPATH had precedence). Aside from using a client program at run-time to recover the final configuration text, you had no idea how a component was defined. And even then, you could not tell exactly how each layer in the CONFIGPATH was influencing the configuration.

In my company, we were building a large application that was already based in the concept of singleton service beans. The initialization code had grown to many hundreds of lines, painstakingly resolving the dependencies among beans to arrive at an initialization order that respected them. It was a sore point that I decided to deal with with a Dynamo-inspired configuration framework. Having seen the difficulty in dealing with many files, I decided to go for a single configuration XML. The syntax was using elements named after properties, but it would be instantly readable by a Spring user. The framework automatically resolved dependencies by producing a partial order of initialization.

Our configuration problem was partially solved. However, this was an application meant to be deployed to many sites, and be used in different modalities, such as command-line tools. Clearly, just having a comprehensive configuration text was half of the story. We needed a way of layering a configuration, such as subsequent layers would extend and differentiate the preceding layers, the way the Dynamo Nucleus was doing. Syntax for that was again influenced by Dynamo, as Dynamo had an XML language to define XML diffs. We needed something stricter, as we were dealing with a restricted language and not any kind of XML.

This configuration mechanism became a cornerstone of all later applications, which were built from the ground up to be extendible. It was an essential feature of productization for enterprise server-side applications.

Technical personnel (support engineers, quality engineers) became familiar with it, and they were able to tweek parameters of installed applications.

The current project is a complete rewrite and extension of the configuration mechanism in the application framework I described. It is written in XSLT, to emphasize the purely syntactic nature of its operation.