Next Previous Contents

## 5. Distributed architecture

The architecture of the system has being designed with distributed operation in mind. This translates into the following ideas:

- Few, well defined API calls. The idea is to reduce the traffic over the net and to simplify the implementation of different front end clients.
- The inter process protocol is based on XML, which in turn is based in text and can be easily transported over other protocols and manipulated by other languages.
- There is no notion of a single user. Requests can be server concurrently in a web server like fashion. Little or no state is kept.

There are still issues that need to be addressed like delegation of authority and how to prevent administrators working concurrently on a configuration from interfering with each other

## 5.1 Different models for distributed operation

At least two models have been considered for developing an architecture that would allow for remote administration of machines

### Web based approach

Namespace and plugins would reside in the remote machine. A web front end would also reside in the same machine and would accept requests from client browsers.

### Distributed application approach

The other approach is to encapsulate the protocol between the console client and the namespace over HTTP and have them reside in different servers. This would require installation of a Tcl client in the administrator machine, but would allow centralized administration from a single machine (the web based approach would require connecting to each machine that requires administration)

## 5.2 Few, well defined API calls

The API calls between the three architectural blocks are few and well defined, as explained in the following sections:

### Namespace / Plug-in

The communication that takes place requires the following information to be exchanged.

The plugins need to register with the namespace and explain which nodes it is interested in extending, etc.

    registerPlugInInterests
            The information that the plug in would provide would be
            name
            version
            description
            node types that it provides
            node types that it extends
            category the plug in belongs to: network services, user management,
            system management

The plugIns needs to query the tree structure, add and remove nodes, etc The API functions to perform that are:

        getRootNode
        addNode
        configureNode
        removeNode
        getChildren

The namespace needs to request and deliver information from the plug in

- deleteNodeRequest (When the user wants to delete a node)
- requestXuiDocument (The user requests a document. it can be a property page, a wizard or a right pane content)
- answerXuiDocument (the user has filled some information and it has to be returned to the plug in for processing)
- populateNodeRequest (The user is exploring a node and double-clicks on it, the namespace takes note and urges the plugin to add nodes. This allows for dynamically generating trees (useful for navigating a server's filesystem, for example.)

### Namespace / View

Similarly, the view needs to access the namespace, basically for the same purpose: query the tree structure, request information for display to the user and deliver back the user feedback. For those purposes it uses the previously detailed functions. In addition, the namespace informs the view when certain events occur: a node has been added or modified, etc

Also the namespace keeps track of which view has browsed which nodes and thus avoid informing the views of event regarding nodes the user has not yet browsed.

A future option may to request not to be notified of updates, and have the user refresh the display when necessary. This may be useful for slow links or the web based interface.

## 5.3 Inter process protocol based on XML

The interprocess communication that takes places is based on XML. The data ,object and method invoked are encoded in XML.

The interprocess communication is hidden in the infrastructure. The API offered to the module author is identical, no matter if the plug in is being used locally or remotely. When a component of the system talks to another component, it does so using xui objects. The system keeps track if the component that is being called is remote or local, if it is local, it directly passes the xuiObject to the called entity. If the entity is remote, it performs a remote call and serializes the object into XML. At the other end, the serialized object is transformed again into a xui Object.

How does the system know if the object called is remote or local? First, objects must register themselves before being able to invoke / receive any methods. If the object is accessible locally (for example, namespace and plug ins are living in the same Tcl interpreter) nothing is done and future communication takes place directly. If the object being registered is accessing the system remotely, a "fake object" will be created that will remember how to access the remote object. This fake object will then be accessed normally as a local object by the rest of the system. When a method is invoked in this fake object, it will in turn take the arguments, the method and the identity of the caller, serialize them and sends it to the remote object. This also involves timeouts (that can be tuned depending on the situation) so if the remote end becomes unavailable the application will get informed and the object will get deleted.

All this process is greatly simplified by the fact that arguments are passed as xuiObjects, which are composed of only a few building blocks. Thus arbitrary functions can be called with arbitrary arguments, since the system knows how to serialize them. This allows for greater flexibility, since this generic mechanism avoids:

- having to declare each one of the possible functions.
- having to explicitily distinguish between remote and local operations.

The XML protocol can be encapsualted in a variety of transport protocols:

- Over HTTP, both directly (using GET and POST methods) or over XMl-RPC
- Plug-In communication with the namespace could also be done using a Fast-CGI approach.

Note: none of the above is yet implemented. Comanche can only run as a local application right now.

## 5.4 Concurrency handling

The namespace server will act in a similar fashion to a web server, in the sense that it can serve requests simultaneously. In fact, initial feasibility tests where performed using the tclhttpd web server. In both cases, XML-RPC was used as the underlying communication mechanism. Requests are served in a first come first served basis. There is a single process running and speed is not likely to be an issue (the network part is usually the bottleneck. Because of that network transmission is done using fileevents (fileevents is a Tcl feature that allows serving of multiple requests using callbacks to detect when a socket has received new data or the data scheduled to send has been effectively transmitted).

Concurency means several problems need to be addressed: what happens when two different users are configuring the same application or where the same user configures the application using different windows (in the case of the web interface, opening several browser windows). There is the potential for the following scenarion to happen: Administrator A selects property pages for virtualhost v1. Administrator B selects property pages for the same virtual host. Administrator B presses OK and commits the changes. Administrator A presses OK and commits the changes.

The following can happen:

- Administrator A will overwrite administrator B changes. Administrator B does not even know that. This is Bad
- Changes could be merged a la CVS style. But the concept of merging changes is more ambiguous here. Merging could also lead to inconsistencies.

Alternative, more desirable solutions are the following:

- Only one admin can be editing a node/service at a given time. Users with enough rights should be able to kick out other admins to avoid deadlock situations (the administrator browser crashed, but the admin appears to the system as still logged, preventing anyone else from administering the machine). Some schema of auto-logout after a period of inactivity could also be implemented.
- More than one admin can be logged and editing the same node. If the previously described situation with admin A and admin B occurs, the solution is to prevent Admin A to commit its changes, informing it that the node has been modified in the mean time and the information is no longer valid.

## 5.5 Delegation of authority

Currently there is no concept of users or privileges in Comanche. It needs to run with the privileges required to edit by hand the configuration files of the programs it is configuring. It would however, be interesting to have some authentication and delegation schema for certain situations: an ISP may be hosting hundreds of web sites as virtual hosts for their customers. In the current situation, the customer must explain what changes it needs to make to the configuration files and the ISP staff performs that for them. This has an obvious administrative overhead and slow turn around time. This problem is partially solved currently :

- Using Frontpage server extensions. This allows customers to use proprietary Ms tools to configure and maintain their web servers. This extensions have a track record of security problems and messy code, so they are not very popular with ISPs, which however have to install them due to customer demand.
- Use .htaccess files. These files allow per directory configuration files If its used is enable, Apache will look for every one of these files and apply the parameters that it finds. They are used for example to allow users to specify password protected pages and directories. .htaccess files are however, a serious performance hit for highly loaded servers

In summary, delegation of authority is an interesting feature, but poses a series of challenges that are out of the scope of a first implementation of Comanche. The architecture, however, if flexible enough to implement such hooks for authentication and delegation. These controls could be placed when views register with the namespace, when xuiRequests and xuiAnswers are requested, etc.

Next Previous Contents