13.1 Event notification function
The event notification function records and makes available event histories.
13.1.1.1 Event history: an object representing significant actions.
Event producers interact with the event notification function to create event histories. The event notification function notifies event consumer objects of the availability of event histories.
The event notification function supports one or more event history types and has an event notification policy which determines the behaviour of the function, in particular
-- which objects can create event histories;
-- which objects are notified of the creation of a new event history;
-- the means by which such notifications occur;
-- persistence and stability requirements for event histories;
-- ordering relationships between interactions with event producer and event consumer objects.
An event consumer interacts with the event notification function to register for notification of new event histories. Depending upon the event notification policy, the interaction can
-- establish bindings to currently available event histories;
-- enable communication about event histories created subsequent to the interaction.
NOTE - Event histories with stringent persistence and stability requirements can be supported using the transaction and replication functions. Ordering and multi-casting notifications can be supported using the group function.
13.2 Checkpoint and recovery function
The checkpoint and recovery function coordinates the checkpointing and recovery of failed clusters.
The checkpoint and recovery function embodies policies governing
-- when clusters should be checkpointed;
-- when clusters should be recovered;
-- where clusters should be recovered;
-- where checkpoints should be stored;
-- which checkpoint is recovered.
The checkpointing and recovery of clusters is subject to any security policy associated with those clusters, in particular, where the checkpoint is stored and where the checkpoint is recovered.
Within the architecture defined by this Reference Model, the checkpoint and recovery function uses the cluster management function and the capsule management function.
Checkpointing is the responsibility of the object management function and the cluster management function. The checkpointing of a cluster is coordinated by its cluster manager: first the cluster manager uses the object management function to obtain a checkpoint of each object in the cluster; from these object checkpoints the cluster manager constructs a cluster checkpoint which it then makes persistent, using the storage function.
Depending upon the checkpointing policy, checkpointing a cluster can lead to checkpointing of other clusters which participate in common activities with the checkpointed cluster, subject to the following consistency rules:
-- the initial cluster must be in a consistent state before it is checkpointed;
-- there must be consistency between all of the cluster checkpoints of the various clusters being jointly checkpointed (e.g., all of the checkpoints reflect the same set of interactions having occurred between the clusters);
-- when a cluster is checkpointed, all other clusters having checkpoint constraints with the cluster must be checkpointed. This rule must be applied recursively to obtain a closed set of clusters which can be checkpointed consistently.
A cluster can be recovered either
-- in the capsule from which it was previously checkpointed, or
-- in another capsule (e.g., when the capsule in which the checkpoint occurred has subsequently failed).
Recovery of a cluster is the responsibility of the cluster manager for that cluster, or in the absence of that cluster manager, a capsule manager. The checkpoint and recovery function interacts with the cluster manager or the capsule manager as appropriate to instantiate the cluster checkpoint. Before recovering a cluster, the checkpoint and recovery function must ensure that the cluster has been removed (e.g., as a consequence of failure). The objects bound to recovered clusters must be able to detect that the cluster has recovered from a checkpoint (e.g., so that they may re-do interactions that occurred after the checkpoint was taken).
The recovery of one cluster can lead to the recovery of other clusters, for example those forming a joint checkpoint with the cluster that is recovered.
13.3 Deactivation and reactivation function
The deactivation and reactivation function coordinates the deactivation and reactivation of clusters. It embodies policies governing
-- when clusters should be deactivated;
-- where the checkpoint associated with a deactivation should be stored;
-- when clusters should be reactivated;
-- which checkpoint should be reactivated (e.g., the most recent);
-- where clusters should be reactivated.
The deactivation and reactivation of clusters is subject to any security policy associated with those clusters, in particular Within the architecture defined by this Reference Model, the deactivation and reactivation function uses the object management function, the cluster management function and the capsule management function. The deactivation and reactivation function is used by the migration function.
Deactivation of a cluster is a cluster management function and comprises the following steps:
-- the cluster manager for the cluster involved interacts with each object in its cluster to obtain a checkpoint that can be used to make a cluster checkpoint;
-- the cluster manager makes the cluster checkpoint persistent, using the storage function;
-- the cluster manager deletes the cluster (and can itself be deleted).
The deactivation and reactivation function reactivates a cluster by using the capsule management function to instantiate a checkpoint of the cluster in the target capsule (and includes creation of a cluster manager for the cluster). The target capsule can either be the capsule from which it was previously deactivated or another capsule (e.g., to balance infrastructure load across several nodes).
The group function provides the necessary mechanisms to coordinate the interactions of objects in multi-party binding.
13.4.1.1 Interaction group: A subset of the objects participating in a binding managed by the group function.
For each set of objects that is bound together in an interaction group, the group function manages
-- interaction: deciding which members of the group participate in which interactions, according to an interaction policy;
-- collation: derivation of a consistent view of interactions (including failed interactions), according to a collation policy;
-- ordering: ensuring that interactions between group members are correctly ordered with respect to an ordering policy;
-- membership: dealing with member failure and recovery, and addition and removal of members according to a membership policy.
NOTE - the behaviour of the binding object linking members of the group determines how interaction is to be effected.
The replication function is a special case of the group function in which the members of a group are behaviourally compatible (e.g., because they are replicas from the same object template). The replication function ensures the group appears to other objects as if it were a single object by ensuring that all members participate in all interactions and that all members participate in all interactions in the same order.
The membership policy for a replica group can allow for the number of members in a replica group to be increased or decreased. Increasing the size of a replica group achieves the same effect as if a member of the group had been cloned and then added to the group in a single atomic action.
For the replication function to be applied to a cluster, the objects comprising the cluster are replicated and configured into a set of identical clusters. The corresponding objects in each such replicated cluster form replica groups. Thus a replicated cluster is a coordinated set of replica groups.
The replication function is used by the migration function.
The migration function coordinates the migration of a cluster from one capsule to another. It uses the cluster management function and the capsule management function and embodies policies governing when clusters should be migrated and where they can be located.
Two possible means of migration are
-- replication, or
-- deactivation in one capsule followed by reactivation in another.
Migration of a cluster by use of the replication function comprises the following sequence of actions:
-- the old cluster is treated as a cluster replica group of size one;
-- a copy of the original cluster is created in the destination capsule, together with a cluster manager;
-- the objects in both the two clusters are formed into replica groups (of size two);
-- the objects in the old cluster are removed from the object groups (leaving groups of size one);
-- the old cluster (and its manager) is deleted.
13.6.2 Deactivation and reactivation
Migration of a cluster by deactivation and reactivation is coordinated by the cluster's manager, and comprises deactivating the cluster at its old location, followed by reactivating the cluster at its new location.
13.7.1.1 Transaction: An activity which leads to a set of object state changes consistent with a dynamic schema (and its constraining invariant schema).
13.7.1.2 Action of interest: An action in a transaction which leads to a state change of significance to the transaction.
13.7.1.3 Visibility: The degree to which a transaction can access object state concurrently with other transactions.
13.7.1.4 Recoverability: The degree to which object state changes resulting from failed transactions are cancelled.
13.7.1.5 Permanence: The degree to which failures can affect object state changes due to completed transactions.
The transaction function coordinates and controls a set of transactions to achieve a specified level of visibility, recoverability and permanence.
The transaction function
-- interacts with objects to monitor the occurrence of actions of interest, cancellation of the effects of actions of interest and the causality of actions of interest;
-- decides if actions of interest are in conflict;
-- interacts with objects to schedule the occurrence of actions of interest to prevent conflicts;
-- interacts with objects to cancel the effects of actions of interest that have occurred, in order to resolve conflicts.
It is subject to policies determining:
-- which actions are actions of interest;
-- which actions of interest conflict;
-- which actions of interest are to be cancelled to resolve conflicts.
13.8 ACID transaction function
The ACID transaction function is a special case of the general transaction function in which
-- visibility is specified as isolation of transactions from one another,
-- recoverability is specified as the requirement that transactions be atomic,
-- permanence is specified as the requirement that state changes arising from transactions be durable (i.e., stable), and
-- consistency is achieved by a correct execution of transactions with the atomicity, isolation and durability properties in conformance with the associated dynamic and invariant schemata.
The actions of interest for the ACID transaction function are
-- start transaction;
-- commit transaction;
-- abort transaction;
-- access state;
-- modify state;
-- cancellation of any of these.
Transaction policies are expressed as serializability rules for transactions.
13.9 Engineering interface reference tracking function
The engineering interface reference tracking function monitors the transfer of engineering interface references between engineering objects in different clusters to determine when the infrastructure associated with engineering interfaces is no longer required (i.e., when no object in another cluster is in a position to bind to the referenced interface).
The engineering interface reference tracking function maintains, within its scope
-- information on the possession of engineering interface references;
-- information on the existence of interfaces.
The engineering interface reference tracking function
-- is notified by stubs when an engineering interface reference is passed between clusters;
-- is notified by a cluster manager when all copies of an engineering interface reference are deleted in its cluster;
-- detects when no copies of an engineering interface reference are held outside the cluster supporting the engineering interface referred to and notifies the corresponding cluster manager;
-- notifies the managers of capsules in which there are holders of engineering interface references to an interface which has failed, or is deleted.
NOTE - The notification of engineering interface reference tracking events can be achieved using the event notification function.
The engineering interface reference management function is constrained by the engineering interface reference management policies of the engineering interface reference management domains to which it applies.