Architecture (TNG)

From ControlTier

Jump to: navigation, search

This document describes a new architecture for the ControlTier system addressing most of the issues raised in the roadmap wish list.



The diagram below describes the CTL system components in relation to each other. Centralized management is done via a single webapp called "CTL Center" utilizing a set of REST accessible services. These services in turn manage data in an RDB and files in a WebDAV server. Remote commands are executed via the CTL clients installed on hosts where processes are managed. External tools that manage host infrastructure (virtual or physical) can be integrated to share Node definition data to the CTL system.

Each of the components is described further in its own section.

Figure: System components


CTL Center

The "CTL Center" (say control center) serves as the graphical operations console to manage processes through the ControlTier infrastructure. Users log in and depending on their role and access navigate through a dashboard to one of several tools, either to view past and current activity, execute a command or process or administrate the system.

Functional areas

Features found in existing webapps

CTL Center's feature set is similar to those found across several webapps currently developed by ControlTier developers:

Figure: CTL Center feature areas


Administrative functions reside in a separate area of the interface and support the following:

CTL Server


Services are accessible using the REST model.

CRUD operations for resource (nodes, resources, resource sets) and process model definitions
CRUD+Run,Kill operations for on-demand and scheduled process and command execution
Event registration and querying of report messages
Upload and request packaged system artifacts (controllers, processes)
Shared workflow session data


Several queues support the operation of the system:

Jobs governing internal processes such as reporting and notifications
Jobs managing client management tasks (eg client installation, artifact distribution)
User-defined jobs to execute commands and processes on demand or on a scheduled basis


Domain model:


System artifacts:

User artifacts:

CTL Client

CTL Server connector

Receives requests from the #CTL Server and also acts as an extension point to support future communication transports.

Dispatcher API

A java-based API used by CTL tasks, types, CTL Server and the process language.

Figure: Dispatcher client API layer


Module type

A new fundamental type "Module" is introduced to support all control types. It effectively replaces the Managed-Entity type (though Managed-Entity can subtype Module to maintain the large base of existing types).

The Module type will provide a basic set of primitives and resource model features that allow most use cases to use it directly, without the need for creating subtypes.


Module supports a number of low level commands useful for executing commands via the command dispatcher.

callCall a defined commandcall [common-opts] -type <> -name <> [-args <>]
execExecute a system command and/or scriptexec [common-opts] -executable <> [-args <>] [-script <>] [-scriptfile] [-spawn]
relayrelay command to matching resourcesrelay [common-opts] -name <.*> -type <.*> [-errorcommand <>] [-threadcount <1>]
sequenceexecute multiple commandssequence [common-opts] -commands <> [-errorcommand <>] [-threadcount <1>]

Supports a easily extensible set of instance properties.

Session data

Dispatcher performatives to support session data access

Data storage

Directory hierarchy

The CTL directory hierarchy (aka "depot") is simplified and made more coherent. This is done by consolidating the "module" and "entity" directory structures into one. The directory names are also revised to adhere to the rationalized set of terms:

File system structure

`-- projects/
    `-- projName/
        |-- modules/
        |   `-- moduleName/
        |       |-- bin/
        |       |-- commands/
        |       |   |-- cmdA.xml
        |       |   `-- cmdB.xml
        |       |--
        |       |-- lib/
        |       |-- templates/
        |       |--
        |       `-- type.xml
        `-- resources/
            `-- resType/
                `-- resName/
                    `-- var/

Shell commands

Besides the existing ctl and ctl-exec shell commands two new ones are introduced:

processes definitions into usable artifacts (types, processes, resources, libraries)
executes a controltier process

The role of the ctl-project command may also change with the CTL Server's planned functionality to drive artifact management on the client hosts.


The new architecture aims to rectify some of the inconsistencies and complexities encountered in the current 3.4 based system. It also introduces a new concept of a self contained process definition that will support a new programming model that offers an easier learning curve and direct control over defining multi step distributed processes.


The resource model is defined in two layers,


The process definition will allow users to write a "dispatcher script" that can control multi-step processes comprised of ad hoc and defined commands.


Process artifacts

use model

The sources process definition can be maintained in a directory structure and then "built" into a packaged archive that is then distributed to the ControlTier system. The source file structure assumes a directory named by the process. It contains the process definition file and possibly extra resource definitions, as well as, user specific files.

`-- processName/
    |-- process.xml
    |-- resources/
    |    |-- resources1.xml
    |    `-- resources2.xml    
    `-- files/
        |-- aFile
        `-- bFile

Process artifacts are published under this policy:


Access control

Personal tools