Resource Model

From ControlTier

The ControlTier Resource Model is a generic, object-oriented datastore that lets you construct concrete representations of your real-world systems and components (Resources), as well as abstracted scripts and workflows to operate on them.

This document describes how the Resource model lets you represent a business service and support the automation of your key service management processes using the Type system.

Contents 1 Summary 2 Basic Concepts 2.1 Nomenclature Note 3 Types 3.1 Properties 3.2 Commands 3.3 Conceptual Layers 3.4 Model Design Process 4 Configuration: Relationships and Settings 4.1 Relationships: Compositional Structure 4.2 Settings 5 Documents 6 Defining Types 7 Defining Resources

Summary

The ControlTier Resource Model is the central storage place for most data used by the ControlTier software, and can be viewed and interacted with directly using the Graphical resource editor. All of the Type and Resource data within the Model can also be managed as XML, and loaded into the server by executing a shell command.

These are the data that are stored within it:

• Components - each software, service or logical grouping of components is stored as a Resource
• Configuration data - individual strings and configuration values are stored as Settings
• Classifcation - each component is classified as a certain Type, giving it a certain set of behaviors and restrictions
• Defined Commands - each scripted process or workflow is defined as a Command within a Type

(Note, the Resource Model does not store files, however. These are represented by the Package type and the file content is stored in the File share.)

The data from the Resource Model is used to produce metadata used by other ControlTier systems, such as the Command dispatcher, and the ControlTier client.

Basic Concepts

There are four basic concepts in the modeling system:

1. Resources
2. Relationships
3. Properties
4. Types

Resources 

every "thing" that we want to represent in the system is called a Resource.

Relationships

every Resource can have multiple other Resources as "parents". Most Resources can have multiple other Resources as "children".

Properties

every Resource can have literal values attached to it which are identified by certain names

Type 

a class of Resources, which confers on its members the ability to have certain Properties, Relationships, and other specific traits. Types can be sub-typed to introduce new traits. Every Resource of a certain Type is also considered a member of its super-Types. This produces a hierarchy of Types, and a system of inheritance of traits.

These basics allow you to model things in your environment, as well as relationships between them and some of the pertinent data about them. Types allow you to differentiate between the concept of a computer Node and a software Service, because the Resources of each of those Types will have different needs: different Properties will be necessary, as well as the ability to have only certain other Types of Resources as children.

This is the basics of the modeling system, covered in more depth in the Type modeling section.

Nomenclature Note

The direction of a relationship between two Resources is often mentioned in this and other documents in a few different ways, but the meaning is the same:

A → B

1. B is a "Child Resource" of A, and A is a "Parent Resource" of B
2. B is one of A's "resources", and A is one of B's "referrers"
3. B is a "dependency" of A, and A "depends on" B

In all cases they refer to the same concepts: a relationship from one Resource directed at another, or the inverse.

Types

At its core the Resource Model is generic, and so could be used to represent any components or systems that you like, however ControlTier comes with a predefined set of types which are a useful starting point.

Among the included types are so-called Base types. These constitute a very generic underpinning for the rest of the included types, and define all of the Properties in use in the system. Resource is the single base Type from which all the other Types extend, and Managed-Entity is a sub-type of it which introduces the "managable" IT and software components layer.

Next is a layer called the Core types, and on top of that is large suite of types designed for managing or interacting with specific Third-party software packages, and this suite is called the Elements types.

This is the conceptual hierarchy of these types:

• Resource
  • Base Types
    • Core Types
      • Elements Types

However to get started, there are only a few key Base and Core types that you should understand:

• Setting - a resource that defines a string value
• Node - a resource that represents a computer/host.
• Deployment - a resource that represents an installable component or software
  • Service - a subtype, which represents a software service with a controllable state
• Package - a resource that represents a file
• Mediator - a resource that represents a composition of other resources
  • Site - a subtype which represents a composition of Services
  • Updater a subtype which defines process for manipulating a set of other resources

If there are no predefined Types which suit your needs, you should consider starting with these and creating subtypes to solve your problem.

Properties

Properties are named values that can be set for each Resource. Certain Resource Types define specific Properties that can be used, and all Subtypes inherit those properties.

The ControlTier type system has pre-defined Properties for each of the Base types. Custom Properties are not supported, but Setting resources are used to introduce custom key/value pairs for resources.

Commands

Types that represent "manageable" components can define Commands. These commands may run a shell script, or an Ant based script, or they may be Workflows which run a sequence of other Commands, or they may be Dispatch Commands which send another command to a set of other Resources. Commands are how you define your processes and procedures in the ControlTier system, and Types let you group them by their purpose.

Commands can be run in either of two contexts:

1. Module context ("static") - without reference to any Resources
2. Object context - the command is invoked with knowledge of a particular Resource that belongs to the Type (known as the Object).

By defining "Object" context commands in a Type you give the Resources of that type the ability to run those commands with their own contextual data. This means your commands can be abstracted to operate on any Resource of that Type, and the input dataset to the command will be dynamic based on which Resource you are using.

The mechanism for importing the data from the Resource Model for the particular Resource you are using is done automatically, but there are ways to import other bits of data from the Model (See Resource model Ant Tasks), or to alter the scope of the data that gets imported for you.

Conceptual Layers

The ControlTier core types divide the conceptual space into these layers:

• Physical Layer: This level contains instances of actual things in the physical world. (Nodes, Packages, Deployments, Services,...)
• Logical Layer: Describes patterns of structure and use of resources in distributed environments and integrated-software systems. (Sites)
• Process Layer: Describes coordinated processes that span the logical and physical layers. (Builders, Updaters, Mediators)

The Core Type Model defines a set of types that support the definition of these layers.

Model Design Process

Using the Core Types as a starting point, you can begin to represent your business service in the context of its physical environment, as well as, capture other essential relationships between components.

These steps can be useful for this process:

1. Define Physical Layer: Using Node, Package, Service (if it is a long running process) or Deployment (if it is not a long running process)
2. Define Logical Layer: Use the Site type to define sets of Services that represent a cohesive set of Services.
3. Define Process Layer: Use the Builder, Updater (and possibly Mediator) types to automate coordinated build and deployment
4. Optionally, create subtypes of the Core Types to integrate with your particular tools and procedures.

Configuration: Relationships and Settings

There are two aspects of configuration represented in a ControlTier model: Relationships and Settings

Relationships: Compositional Structure

Relationships are used to compose Resources together to form larger structures. When you have two related Resources, the procedures that can be run on one Resource can typically "see" into the specific Properties and Setting values for the other. This allows you to write your procedures in a generic way, and let the run-time dataset used by the procedures be determined dynamically from your compositional configuration.

Typically, there are two reasons ways to use relationships:

1. between connected physical resources - Nodes, Packages, Services
2. between logically related resources by means of a common "compositional" resource.

Below is an example between several physical resources (a Node hosting Apache, Tomcat deployments, and another host with a Mysql deployment). Also note that these Services have relationships to related Package resources:

These relationships are not strict hierarchies but are actually graph structures.

Below is an example that shows how the three Services mentioned above can be related through their relationship to a Resource called "estore[Site]":

Settings

Setting Resources let you define a string value, and then attach that Setting to another Resource. This is useful both for configuring a single component (e.g. port numbers, file paths, etc.), and for configuring multiple Resources with a shared Setting value (e.g TCP port numbers for connecting two services).

Here is an example Service resource with two Setting resources, showing particular values:

Documents

The Resource Model also has a secondary citizen called a "Document" (aka "Transform").

Document

Defines a file template and a file output path, and belongs to a Resource

Each Resource can own multiple Documents. Documents let you easily generate configuration files based on templates. The template can be in XSLT format, or be simple text files that use Token expansion to replace embedded strings with property or Setting values from the Resource.

Thus you can define a Document to generate the configuration for a piece of software and have it use values from your Resource's properties to fill in the specific configuration details.

Defining Types

The Types in your Model can be defined either graphically via the Workbench GUI, or via XML using the type.xml format.

Defining Resources

The Resources in your Model can be defined either graphically via the Workbench GUI, or via XML using the project.xml format.

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