Continuing my musings about a universal configuration management tool I’ve drafted the basic architecture. This is summarised in the following diagram (after the break).
CM Tool Architecture
This simple architecture serves to isolate the key levels of abstraction in the CMS.
As with all multi-layer architectures the important feature is that each layer creates an abstraction then allows layers it serves to use a stable interface. The CM Data layer, for example, will need to deal directly with individual the tools we wish to interrogate. (Recall that I am currently only proposing a tool that analyses and reports the content of the underlying tools, writing a tool to also update the content of those tools adds a whole new set of challenges to the problem. Challenges I have no desire to deal with right now, but which will be served well by this architecture nonetheless.) The CM Data layer presents one, hopefully, stable interface to the CM Model, so the CM Model will not have to be changed is a tool changes its interface (changing its database schema, command line, API, or whatever method we use to access it).
CM Data
This layer presents a common interface to the CM tools that the CMS is fronting. CM Data can be divided into two categories.
- Item library — this holds the items the CM tools store; files, directories, symbolic links, etc.
- Data about items — this is data such as relationships between items, attributes of items (owner, author, date modified, and so on).
The CM Data layer will provide methods for accessing these data. Items will be held in a Repository and the data about these items will be held in a CMDatabase.
All version control tools are a Repository (they store items) and provide at least some data about those items (author, modified date, ancestor/successor relationships, contains relationships), so they provide some functions of a CMDatabase. More advanced tools (like Dimensions and Synergy/CM) provide the same Repository functions but they expand these considerably (adding in records such as change requests) and the CMDatabase functionality is also expanded. These points will be revisited and clarified as we proceed.
CM Model
The CM Model will provide an abstraction of common CM artefacts (items and their relationships, collections, baselines, branches, changes and so on). The point of this abstraction is to, once again, provide a consistent and stable model to the layers that use the CM Model. So, the code in the Business Logic and Presentation layers is written to use the CM Model rather than the various implementations of these artefacts presented by the underlying tools. This means our system can access, say, an Item without needing to know how it is represented in the tool or even which tool it is held in.
The CM Model is perhaps the most important part of the architecture to design. It needs to be sufficiently comprehensive to accommodate the various tools’ concepts but at the same time it needs to be as simple as possible and as stable as possible to preserve a stable interface to the rest of the system.
Business Logic
The Business Logic layer is where all of the rules about how the CM Model is to be interpreted and managed. The most challenging aspect of the Business Layer is the need to allow users to define their own rules without requiring them to program anything into the system (although we will surely make the tool easy to extend programatically). This layer will require a detailed set of user cases and a considerable investment of time in the early design if the final product is to be flexible enough to accommodate a wide variety of users.
The Business Logic layer’s functionality can be divided into two classes; those features of SCM that are fundamental and those that are definable. Establishing fundamental features may be a matter of diktat on my part, but never-the-less I will try to only hardcode rule when absolutely necessary, preferring instead to provide configurable rules. *scratched head* This could take some time.
Presentation
Finally there is the presentation layer. Here all of the various methods of presenting the system’s functionality are gathered. This is perhaps the simplest layer to define functionally but the most difficult to design aesthetically. Having established what the system can do in the other layers the function of the Presentation layer is to provide a method of allowing the user to request that functionality, and providing a means for the system to provide the results to the user. The challenge with user interface (UI) design is how to achieve these two functions in an easy to use and, preferably, intuitive way.
In the first instance I shall probably provide a command line interface as a priority with some form of rudimentary GUI as a secondary development. Once these are done other interfaces may be considered.
