AE Tier

The ASSL formal model considers Autonomic Elements (AEs) to be analogous to software agents able to manage their own behavior and their relationships with other AE, through which they provide or consume computational services. At this level of the framework, ASSL describes the correlation between low-level system measurements, events, and actions, and higher-level AE service-level objectives.

ASSL AESLO Specification

AE SLO. At this tier, the ASSL framework specifies the AE’s service-level objectives (AE SLO). They could be expressed as a correlation of metrics and their thresholds (see Metrics below).

AE Self-Management Policies. ASSL considers the AEs as micro-autonomic systems, i.e. for each AE it specifies AE self-management policies. Their specification must be consistent with the higher-level AS self-management policies.

Friends. An AE exists surrounded by other AEs, those forming the "circle of friends" communicating with the AE. At this tier, the ASSL framework specifies the initial set of friends and groups in which the AE participates.

AE Interaction Protocol. At this tier, ASSL defines the private messages, channels and communication functions, these forming the AE interaction protocol (AEIP). AEIP has the same structure as ASIP. Two AEs exchange messages over their AEIP only if they have an agreement on it, i.e. they are friends. In addition, at this level the ASSL framework specifies the interaction interfaces exposed by the managed elements, where the latter are the resource managed by the AE.

ASSL Managed Element Specification

Managed Resource Interface. An AE typically controls one or more managed elements. In ASSL, this control is going over the managed resource interface. For each managed element, ASSL specifies a Java-like interface, i.e. a named collection of methods without implementation, which eventually, the managed resource can then implement an adapter to meet this interface.

ASSL Event Specification

Recovery Protocol. At this tier, the ASSL framework specifies a recovery protocol for serving AEs and their internal components. This protocol is a pessimistic message logging protocol, i.e. receiving of new messages is blocked until the preceding messages are not logged.

Behavior. At this tier, the ASSL framework specifies behavioral models by mapping metric conditions and events into potential actions and potential actions into outcomes, such as changes in the AS and AE configuration. The behavior models specified at this tier should be consistent with the specification of outcomes, actions, events and metrics.

Outcomes. Outcomes are an abstraction for action results. At this tier, the ASSL framework specifies outcomes that can be produced by the actions (see Actions below).

ASSL Metric Specification

Actions. At this tier, the ASSL framework describes actions that can be undertaken by an AE in response to an event or a metric condition determined by its threshold classes. To specify actions, ASSL provides a "Design by Contract" specification style. The principle behind this is that an action and its performers have a “contract” that guarantees certain conditions before and after performing this action.

Events. Events are one of the most important aspects in ASSL. They are widely used to specify many of the ASSL's structures, like fluents, self-management policies, actions etc. At this tier, the ASSL framework describes events that can take place in the AE's lifecycle.

Metrics. The AE-level metrics are private metrics, i.e. metrics that are not propagated to other AEs. We express the AE level metrics in the same way as the AS-level metrics, i.e. with a set of valid threshold classes determining the ranges for valid/invalid metric values.