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.
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).
ASSL AESLO Specification|
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.
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 Managed Element 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
ASSL Event Specification|
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).
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.
ASSL Metric Specification|
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
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