Glossary

Autonomic

Refers to the self-managing characteristics of distributed computing resources, adapting to unpredictable changes while hiding intrinsic complexity to operators and users.

Blueprint

A description of an application or system, which can be used for its automated deployment and runtime management. The blueprint describes a model of the application (i.e. its components, their configuration, and their relationships), along with policies for runtime management. The blueprint can be described in YAML.

See also
  • Documentation for the entity, policy and enricher blueprints that Apache Brooklyn supports out-of-the-box.

Effector

An operation on an entity.

Enricher

Generates new events or sensor values (metrics) for an entity, usually by aggregating or modifying data from one or more other sensors.

Entity

A component of an application or system. This could be a physical component, a service, a grouping of components, or a logical construct describing part of an application/system. It is a “managed element” in autonomic computing parlance.

Policy

Part of an autonomic management system, performing runtime management. A policy is associated with an entity; it normally manages the health of that entity or an associated group of entities (e.g. HA policies or auto-scaling policies).

Sensor

An attribute of an entity.

YAML

A human-readable data format.

See also

Apache jclouds

An open source Java library that provides a consistent interface to many clouds. Apache Brooklyn uses Apache jclouds as its core cloud abstraction.

See also

CAMP and TOSCA

OASIS Cloud Application Management for Platforms (CAMP) and OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) are specifications that aim to standardise the portability and management of cloud applications.

See also