CTL architecture

From ControlTier

This section describes core concepts that underly the CTL software and its use.

Contents 1 Framework 2 Command dispatcher 3 Projects 4 Nodes 5 Command Dispatching 6 Modules 7 Data Context 8 File share 9 Glossary

Framework

Framework built using the CTL APIs, to execute specified actions. The dispatching framework also provides projects for managing project configuration files, modules, resources and their instance data. Several utilities are included to execute commands and administer the framework.

Figure 1: CTL Software

The following diagram describes the components comprising the CTL framework.

Command dispatcher

The diagram below describes the command dispatching mechanism for a local command execution. When a user issues a command it is invoked via the Framework component. Internally, the Framework looks up the needed execution strategy based on the commands parameters. Local commands are executed by resolving the command to a module and command handler. The execution strategy loads the handler and creates a data binding context based on user input, command parameters, and model context data. The Framework then invokes the strategy to execute the command.

A module is a self contained component in the CTL system, responsible for its own data, its own activities, and the integrity of its actions. Module data is in the form of properties, key/value pairs, while its operations are defined in terms of commands.

The command dispatcher supports an object oriented programming paradigm. Modules are defined in terms of the ControlTier type model. Modules inherit commands from their "supertype", and can override inherited commands or define entirely new commands.

Users can define instances of types, called objects and call commands in the scope of their instance data. It is the framework's dispatcher that does the lookup for the named command specified by the user, resolve it to a command implementation and object, prepare a data context, and execute the implementation code.

For an internal view of the command dispatching mechanism see: Model-driven command dispatching

Projects

The framework repository is organized into projects. For each project name, the framework provides a file structure. Within each project, there is a space for configuration, a module library, and an resource model store.

Nodes

A machine hosting a CTL software instance is called a node. By convention a node can take on one of two roles, target node or admin node. A target node is one that receives commands from an admin and executes them. An admin node is a central server from which remote management of target nodes will be performed. Typically, the admin node hosts a #Repository.

Nodes are described with metadata in the nodes.properties configuration file. This metadata is used by the node dispatching mechanism, and facilitates keyword based filtering.

Command Dispatching

The internal dispatch mechanism supports an execution strategy referred to as nodedispatch. The dispatcher is able to lookup the node of the target, dispatching the command remotely or locally as appropriate. This feature provides network abstraction to distributed command execution and makes management of server pools and clusters more convenient.

The command dispatcher supports two styles of dispatching:

• Running ad hoc commands: Dispatch any command you would normally type at the shell to the nodes that match the filtering criteria.
• Running defined commands: Dispatch commands defined in a module to to the locations that match the filtering criteria.

The nodedispatch strategy uses SSH to invoke CTL actions on remote hosts.

Modules

A module is a packaged set of defined commands created to execute some set of procedures. Modules can be likened to a plugin to the framework. Once a module has been installed the framework's command dispatcher provides access to execute its commands.

New modules are developed with ProjectBuilder or generated by Graphical type editor.

Modules are organized into an inheritance hierarcy of super- and sub-types to support generic/specific behavior and provide a means for reuse.

The figure below shows how a user executes a command via CTL. The dispatcher receives the request to run a command, looks up the command's handler, and then, provides as input, a data context that can be managed within the framework.

Figure 2: CTL Dispatching

Module Structure

At a file level, a module has a directory stucture that organizes files into several locations. Modules are defined in an XML file called type.xml. The ProjectBuilder build-type command reads the type.xml file and generates an executable set of commands. Alternatively, Workbench can be used to develop any aspect of a type and then be generated into a CTL module.

Figure 3: Module structure

Inside the type.xml file, you define one or more commands. Commands can be used to control life cycle actions but can also be used to control processes and interface with other tools. The implementation of a command is called its handler. Command handlers are XML files that read property files to establish a data context and execute the defined action.

Given the supplied parameters, the dispatcher knows how to lookup command handlers in the module library, generate a data context, and execute them.

Figure 4: Command dispatcher mechanism

A fundamental tenet in CTL is to "soft code" commands by stating important detail in data files in order to separate the procedural logic from environment detail. This leads to commands that are more flexible and reusable in different environments.

Data Context

As mentioned earlier, commands in CTL are driven by a data context. The CTL framework assumes standard data files generated from the type.xml file but you are free to create and use data from any source for your commands.

Data you might store in the property files include:

• configuration data: app and environment settings
• dependency data: bindings to other objects
• any thing else your procedures need

The framework uses several configuration files where global configuration data is stored. Every command handler can access this global data as it is loaded by the dispatcher when the handler is loaded.

CTL uses Java property file format, key-value pairs, as its native format. Global configuration is stored in the framework.properties file.

Module Context

The module defines several standard property files:

1. module.properties: This contains metadata about the module.
2. type.properties: This contains attribute data
3. commands.properties: This contains metadata about each command such as command parameters.

Modules load this property data when executed. Other data can be stored in other files and read in by the command handler.

Resource Context

When there is a lot of data, or when your commands need to use different sets of data depending on environment or location, the CTL framework provides the capability of defining resources to organize and discretely maintain the data. See the Category:Resource model page for more information about defining and using resources.

The standard file for storing resource specific data is called the resource.properties file. This file can contain anything you wish and it is obtained and updated via the Managed-Entity Get-Properties command.

File share

An important facility for managing a network of CTL nodes is a central file share. The file share is used as a common repository for various artifacts. Once command modules have been developed they can be stored in the file share so that they can be distributed to nodes that require them. The file share can be a simple web server or if one wishes to publish files via PUT, a server based on WebDAV.

The file share organizes content into the following categories:

• Configuration: A set of configuration files that include information about nodes and their deployments. One such file, nodes.properties, describes the nodes in the environment to which you want to dispatch actions.
• Modules: A collection of packaged CTL control modules that can be deployed to CTL nodes.
• Packages: If you use CTL to manage deployment you can include a collection of software packages. These packages may be of various file types such as zip, tgz, rpm, war, jar, ear, etc.

Each project name on the file share has a directory for each of these content categories:

Glossary

• Command - Defined procedure that can be executed via CTL
• Command handler - An implementation of a Command
• Context - Data context made available during the execution of a handler
• Deployment - A registered deployment of a module or resource
• Framework - An instance of the CTL command dispatching mechanism and repository of command modules and management data.
• Module - A packaged set of Commands.
• Node - A registered host to which commands can be dispatched
• Project - A repository of modules and resources.
• Resource - A resource that has its own workspace and an associated module.
• Type - A resource type. If a subtype of Managed-Entity it may have a corresponding module.

v • d • e Modeler Guide Introduction Modeler Guide · Concepts · Modeler Getting started · Model-driven approach · CTL architecture · Model-driven command dispatching · File share Resource modeling Resource Model · Graphical resource editor · Graphical type editor · ProjectBuilder · Core Type Guide  · Type modeling · Attributes · Constraints Module development Module Development Guide · Modules · First type module · Workflow command · Command options Examples Creating packages · Mock Unix Service Example  · Mock Site Example  · Service Package Deployment Example  · Windows service  · Windows site  · Windows deployment · Builder Simple Example  · Continuous Deployment Example with Tomcat · Dukes Bank J2EE examples