Application Interface Specification
Besides reducing the complexity of high-availability applications and shortening development time, the specifications intended to ease the portability of applications between different middleware implementations and to admit third party developers to a field that was highly proprietary in the past.
The different services and frameworks of the interface specifications have been designed to be modular and, to a certain degree, independent of one another.
This allows a system providing only AIS and no HPI to exist and vice versa.
The Platform Management Service (PLM) provides a logical view of the hardware and the low-level software of the system.
In case of EEs, PLM is in charge of retrieving all necessary information about the health of the operating system and any available virtualization layer.
The administrative operations specified for the object classes represent operations that can be performed on the entities represented by the objects, e.g. locking a service unit or exporting the contents of the IM in XML format.
Runtime objects and attributes reflect the current state of the entities they represent – they are of descriptive nature.
Since the output format is public, third party tools can read these log files.
The notification service is - to a great degree - based on the ITU-T Fault Management model (as found in the X.700 series of documents) as well as on many other supportive recommendations.
These mechanisms can be used to preserve the integrity of the high-availability infrastructure and of SA Forum applications, including their data, by protecting against unauthorized access.
SEC responds to these authorization requests with a granted or denied indication, and it is up to the AIS Service to allow or disallow the operation accordingly.
SEC provides these indications based on the set of security policies configured via IMM.
It coordinates the workload of the different entities under its control depending on their state of readiness to provide services.
The basic logical entity of this information model is the component, which represents a set of resources to the Availability Management Framework that encapsulate some specific application functionality.
The fundamental principle of fault tolerant design is to provide the services by a set of redundant entities and therefore components need to be able to act as a standby on behalf of the CSI.
The Availability Management Framework configuration includes recovery and repair policies.
These range from the simple 2N model (also known as 1+1, or active-standby) to more sophisticated ones such as the N-way redundancy model, which allows for more than one standby assignment on behalf of the same component service instance or the N-way-active that allows multiple active assignments.
The deployment configuration constitutes an essential part of the information model managed by the IMM Service.
But the main purpose of SMF is enabling the evolution of a live system by orchestrating the migration from one deployment configuration to another.
The Software Management Framework defines an XML schema to be used to specify an upgrade campaign.
During this migration, SMF To accomplish all these tasks, the SMF implementation interacts at least (1) with AMF in order to maintain availability, (2) with IMM to carry out changes to the information model, and (3) with NTF to receive notifications that may indicate error situations caused by the ongoing campaign.
The Software Management Framework also provides an API for client processes to register their interest in receiving callbacks when a relevant upgrade campaign is initiated in the cluster and as it progresses through significant milestones.
The process creating the checkpoint may choose between synchronous and asynchronous replica-update policies.
In case of asynchronous replication, co-location can also be selected to optimize update performance.
The single message queue thus supports point-to-point or multi-point-to-point communication patterns.
It allows the users of the service to select and use their own naming schema without assuming any specific hardware or logical software configuration.
The same naming conventions, standard predefined types and constants, API semantics, library life cycle control, etc.
The usage model is typical of an event-driven architecture, in which the application performs a setup and then receives callbacks as events occur (fig 6).
Many AIS Services provide the capability of tracking changes in the entities that they implement.
Considering an AIS implementation that supports both versions Vx and Vy, a process can initialize the library specifying either Vx or Vy: Note, however, that a process may initialize the library multiple times each time with the version appropriate to the functionality it intends to obtain.
