Next Previous Contents

## 2. ArchitectureThis section is an introduction to the Comanche architecture.

Comanche is designed around a modular architecture and has the following characteristics:

Even the most complex configuration programs can be reduced to follow these principles:

- Present information to the user and ask him for input.
- Receive input from the user.
- Act upon that input.

Comanche takes care of the first two items and leaves the third to the module author. It can optionally provide libraries to help with this step, but it gives him absolute freedom. The module author, not the framework is who knows better how to parse configuration files or take certain actions (like execute a external program or check environment variables). As stated before, the goal is to provide as much freedom as possible to the module authors and present them with a small, simple API.

To present information to the user, instead of having to hard-code interface and dialogs in the program itself, they are described in a mark up language based on XML (XML is a mark up language to represent structured data). The interface can be easily manipulated or even generated on the fly. The XML representation is platform independent, it can be rendered using a traditional UI toolkit or in a web based interface.

## 2.1 Simple API for developers

A lot of time was spent in designing a simple API. The plug-in or management module has to know how to:

- Deliver the XML description of the configuration options. This information will be rendered and presented to the user, who will manipulate it.
- Receive the results from the user (also encoded in XML format).
- Extract the results and act upon them.

This can be reduced to the following APIs calls:

- RequestDocument
- ReceiveDocument

There are some others API calls for initializing the plugIn, etc. but these two are the main ones. The dialogs, if fixed, can be stored in text files or alternatively can be generated on the fly. In a way the plug-in acts like a traditional cgi-bin application. But instead of generating HTML , it generates user interface data encoded in XML, and instead of accepting form variables, it accepts XML encoded data.

## 2.2 Support for multiple extension languages

Comanche is developed mainly in Tcl, but that does not preclude future use of other languages for building extension modules (plugins). Since the interface is well defined, small and-text based it is possible to encapsulate the protocol into HTTP or Fast cgi. Most programming languages support these interfaces, including Tcl, Perl, Java, Python, C, C++, etc. This is still not implemented, but the basics are there.

## 2.3 Easy addition and maintenance of configuration files

XML is not only used for exchange of information. It is also used for describing the interfaces and the configuration directives. Since XML is a text based language, it is easy to change the definition of directives or rearrange user interfaces without need to recompile.

## 2.4 Easy maintenance of different interfaces (and languages)

Since the information can be separated from the presentation it is possible to maintain several versions of the interface, based on the mother tongue and/or skill level of the end user.

The architecture of Comanche gravitates around three blocks:

- Namespace. Can be thought of as a hierarchical database or a directory server.
- Plugins. They provide the configuration functionality. They register themselves with the namespace, and populate it creating nodes.
- The console. It is the graphical tool used by the user to connect to the different namespaces (represented by computer icons in the tree)

These elements are usually part of the same program, but the system has been designed such it should be relatively easy to have them running in separate machines or processes. They could be tied together using simple protocols like HTTP + SSL, thus someone running a console in one machine can securely administer remote boxes. The protocol is designed to work well over moderately slow links. Alternatively, the console instead of being a traditional application can be a web server module that renders the interface and interacts with the user. All of this is transparent to the module developer, which still sees the same simple interface described above.

### Namespace

The namespace is the "central switch" of the Comanche architecture. It acts as a broker between the plugins and the console. It helps organize information about the plug-ins in a hierarchical manner, and to arbitrate communication between users and plugins (so an user can configure several plugins at the same time or several users can communicate with one plug in simultaneously). plugins register with the namespace and they create new nodes under existing categories (like network services or system).

Plugins can also extend other plugins. To do so, plugins inform the namespace which nodes they are interested in. For example, there may be a need to add SSL (Secure Sockets Layer, necessary for secure communications between the browser and the server) configuration support to Apache. Instead of rewriting the existing Apache plug in, an extension SSL plugin is created. It tells the namespace its interest in all nodes created by Apache. Whenever the namespace receives a request for the property pages for a given node, the SSL plugin is also given an opportunity to contribute to the answer, so it can add new property pages. In case the SSL module is not installed or enabled, no new pages appear.

### Console

The console is the end user interface. The console UI is divided in several areas, the main two are:

- A tree structure on the left. It allows the user to connect to the different managed machines, and navigate them by clicking and expanding nodes
- A right pane. It visualizes information related to the currently selected node.

The user navigates the tree on the left and configures the properties of the nodes by right-clicking on them and selecting the properties entry in the pop-up menu.

### Plugins

Plugins are modules that implement the specific management behaviour. They are the ones that populate the namespace that is browsed by the console. They produce the content of the property pages that are delivered to the user and they act upon the received changes.

Next Previous Contents