- The Service Availability Forum (SAF) defines a set of middleware services to support and enable high availability in a standardized manner. The Availability Management Framework (AMF) is the service in charge of managing the high availability of the services provided by an application under its control. In order to do so, the AMF service requires a configuration of the application, referred to as an AMF configuration. We are currently defining a UML profile for the modeling and analysis of AMF configurations. The configuration model and the runtime behavior of an AMF service implementation as a middleware are both defined in the AMF specification. It is not straightforward to extract from the large standard document the domain model, which requires the isolation of the configuration time characteristics from the runtime characteristics of the AMF service. In this paper, we report on our experience in designing a domain model for AMF configurations; we discuss some of the challenges we encountered during this process.
Service Availability Forum (SAF) [
To manage the availability of the services delivered by an application under its control, an
AMF service implementation requires a configuration, which describes the different
resources in use, their capabilities and limitations, their organization, relations, the
services to be provided, and their protection. The design and the upgrade of such
configurations have to be done very carefully in order to meet the high availability
requirement. We are undertaking a research project aiming at devising methods and
prototype tools for the design and analysis of AMF configurations as well as their
upgrade campaigns. In order to achieve this formally, we started with the definition of a
profile of the Unified Modeling Language (UML) [
Our main contributions in this paper are: (1) we provide a brief overview of the domain of availability management as it is defined in the SAF specifications; (2) we briefly describe the domain model of our UML profile; and (3) we discuss some of the challenges encountered in the process of designing the domain model.
The remaining part of this paper is structured as follows. In Section 2, we introduce some important AMF concepts used throughout the paper. In Section 3, we discuss the main issue of categorizing AMF requirements into configuration time versus runtime, and present a compilation of sample AMF requirements used throughout the paper. In Section 4, we describe the main characteristics of the domain model and we discuss some design decisions. In Section 5, we share the main lessons learned with respect to the under/overspecification problem through specific examples. In Section 6, we review related work before concluding the paper.
SAF AIS [
The basic entity of an AMF configuration is an AMF component, which represents a set of software and/or hardware resources that can provide some basic services referred to as component service instances (CSIs). The components are logically grouped into service units (SU) in order to combine their functionality into higher level services referred to as service instances (SIs). In order to protect these services using redundancy, SUs are grouped into service groups (SGs). An SG protects a set of SIs that are assigned to its SUs in different roles. When a particular SI is assigned to an SU, its composing CSIs are assigned to the components in the SU. The grouping of service groups forms an AMF application. From a deployment perspective, each SU is deployed on an AMF node, thus an SG is deployed on a node group. The set of all AMF nodes forms the AMF cluster. The notion of type is introduced in the AMF specification to capture common characteristics shared by all the entities that belong to the same type. In addition, the types define also the relation between entities. For example the SU type specifies the set of component types it contains, which defines components of what types must compose each of the SUs of the SU type. However, not all the entities are typed. The typed entities (and their corresponding types) are: the application (application type), the service group (SG type), the service unit (SU type), the component (component type), the service instance (service type), and the component service instance (CS type). The non-typed entities are: the cluster and the node. In a complete AMF configuration each typed entity should refer to its type.
AMF coordinates the redundant entities (SUs and their components) of an SG according
to a certain redundancy model. This defines the number of active SUs (respectively
components), the number of standby SUs (respectively components) to protect an SI
(respectively CSI). For each SI, AMF selects at runtime which SU shall act in which role
and makes the appropriate assignments via API callbacks to the components. In the AMF
specification [
Within an SU, each component has its component capability model which is defined as a triple (x, y, b), where x represents the maximum number of active CSI assignments and y the maximum number of standby CSI assignments the component can have for a particular component service type, and b determines whether it can support these roles simultaneously or not. The redundancy model used by an SG should be consistent with the capabilities of the components of its SUs. For example, a component that can have only one active or only one standby CSI assignment at a time (1, 1, false) can be used in an SG with a 2N redundancy model, but it is not valid for a SG with an N-way redundancy model, where each of the SUs may be active for some SIs and standby for others simultaneously, e.g. (n, m, true).
Since the AMF specification is about defining what a valid AMF configuration is and how it is manipulated at runtime by a compliant AMF service implementation, the first step in our process is to distinguish clearly between configuration time and runtime requirements. However, this is not straightforward and instead of two categories, the requirements defined in the AMF standard specification can be organized into three categories as shown in Fig. 1. The first category, configuration requirements, clearly encloses the requirements defining what an AMF configuration is. These constraints can be checked at configuration time. They should be reflected in the domain model in the class diagram or using OCL constraints. The second category of requirements, run-time requirements, is clearly related to the dynamic behavior of the AMF service and hence need to be satisfied by any AMF-compliant middleware. These requirements are out of the scope of our profile and therefore should not be captured either in the class diagram or using OCL constraints.
The challenges in the AMF requirements stem from the third category, the overlapping region in Fig. 1. Often the specification does not provide a clear cut as whether these are configuration requirements or AMF service runtime related requirements. As a configuration defines relations between the different entities involved, there is a temptation to define all of them at configuration time. This is wrong as some of these relations are defined only at runtime to allow more flexibility to the middleware implementing the AMF service. Some of these relations defined at runtime are however based on other related configuration time constraints to ensure that the configured application will provide and protect the service independently from the decisions taken by the AMF service implementation. Capturing and specifying these configuration time constraints without the related runtime relationships between the entities is not straightforward. Moreover, it is not clear which ones and to what extent these should be captured in the domain model. Indeed, here we are facing the traditional over- vs. underspecification problem. Over-specification occurs when we try to capture some requirements in our domain model but these requirements are not configuration time and related to the runtime behavior of the AMF service and to its manipulation of the configuration. On the other hand, under-specification occurs when we mistakenly consider a requirement as not checkable at configuration time. The consequence of such misinterpretations is a profile that may exclude valid AMF configurations when we over specify the requirements and/or that includes invalid configurations when all configuration time requirements are not captured. In Section 5, we elaborate more on this issue with specific examples.
Table 1 provides a set of requirements, taken from the standard, that we will use in the next sections to illustrate different issues and some design decisions. In the column Configuration/Run-time, we use the letter “C” to identify the requirements that we deem belong to the configuration requirements subset and, hence, can be checked in the configuration. The two other columns are used to indicate whether the requirement is captured in the class diagram of the domain model, using OCL constraints, or both. These issues are discussed further in the next sections. We use the letter “R” for the requirements related to the dynamic behavior of the AMF service and therefore are out of the scope of our profile. For the remaining set of requirements, identified with “?”, it is not clear how to define the constraints that would allow to check their satisfaction at configuration time without a risk of over-/under-specification.
The AMF profile is organized into packages for distinguishing between service, service provider and deployment concepts as defined in the standard. The service package is for the description of the concepts related to the definition of the services to be provided; the service provider package is for the description of the (logical and physical) resources defined in a system to provide services and their organization in terms of composition of their functionalities or in terms of redundancy. The AMF specification emphasizes the idea of service and service provider separation to enable the moving of services around service providers. The deployment package is for the description of deployment concepts such as clusters and nodes. Our profile overall architecture captures this idea as shown in Fig. 2. The domain model of the AMF profile is defined using a class diagram complemented with a set of OCL constraints to capture the configuration requirements. The requirement RQ 2 in Table 1, for instance, is captured explicitly in the model using a composition relationship between the local service unit class and the local component class. This is highlighted in the dashed region (A) in Fig. 3. Other requirements, such as RQ 19 in Table 1, are more complicated to be captured in the class diagram. Indeed, RQ 19 involves a relationship between components and SG, which is not explicit in the class diagram. The requirement is therefore expressed in OCL as follows: context MagicAmfContainerComponent inv: self.magicAmfLocalComponentMemberOf. magicSaAmfSUMemberOf.
oclIsKindOf(MagicAmfN-WayActiveSG) The domain model reflects component categories as defined in the specification, namely SA-aware, container, contained, proxy, proxied, local, external and pre-instantiable components. The class diagram in Fig. 3 shows the hierarchy of components for the first seven categories. We model pre-instantiable components differently; we use a specific configuration attribute, magicAmfCtIsPreinstantiable, at component type level (i.e., in the MagicSaAmfComponentType class as shown in Fig. 3) instead of using a specific class for this category of components. The rationale behind our decision is that modeling preinstantiable component category with a specific class would have required a further specialization of the local proxied components into a new class that represents non-preinstantiable components. This is indeed necessary to account for the requirement RQ 15 in Table 1. Obviously, this would have complicated further the component hierarchy. As a consequence of our modeling of the pre-instantiable component category, the requirements RQ 13 and RQ14 in Table 1 are captured in OCL using this new configuration attribute as follows: context MagicSaAwareCompType inv: self.magicSaAmfCtIsPreinstantiable = true context MagicAmfNon-ProxiedNon-SaAwareCompType inv: self.magicAmfCtIsPreinstantiable = false
In this section, we discuss some aspects of AMF configuration constraints over/underspecification, which we have encountered during the process of defining the domain model. We limit, however, this discussion to only two situations because of the lack of space.
The capability of a component, defined in the standard and introduced in Section 2, depends on the target component service type (CsType). Therefore, we capture the component capability model using two association classes as shown in the Fig. 4. The first association class, called MagicSaAmfCtCsType, captures the fact that a component type might support several CsTypes, each with different capability. The second is to capture that the capability of a particular component of a component type is further restricted with respect to a certain CsType by putting limitations on the number of active and standby that a component can take. In our domain model, this second association class is called MagicSaAmfCompCsType.
The issue related to the component capability shows up when the components grouped into an SU support overlapping sets of CsTypes and, in addition, the capability models of the components with respect to the common supported CsTypes are different. As stated in RQ 4 in Table 1, an AMF service implementation uses the configuration time relationship between components and CsTypes to assign CSIs to components. However, this assignment of CSIs to components happens only at runtime and under the control of an AMF service implementation. Different behaviors/runtime decisions of AMF for the same configuration, i.e., different assignments of CSIs to components, may lead to different availability levels. The configuration is not the right place where to control the assignments and therefore the level of availability obtained from AMF and this is not a configuration time decision.
We were tempted to capture and fix in our domain model these assignments at configuration time. This was wrong, and this over-specification has been avoided with the help of the domain expert.
Several requirements in the AMF specification relate proxy and their proxied components. For instance, the requirement RQ 17 in Table 1 specifies a location constraint between a proxy and a proxied component. In the initial version of our domain model, we related formally proxy and proxied components with an association as shown by the dashed association (A) in Fig. 5. The interactions with the domain expert showed that this relationship is not a configuration time relationship and it is only at run-time that an AMF service implementation selects and assigns a particular proxy component to a particular proxied component according to the requirement RQ 4 in Table 1. This association is therefore removed from our model as it represents a typical case of overspecification, which fixes runtime relationships at configuration time.
The requirement RQ 16, on the other hand, specifies a configuration time relationship between a proxy and a proxied component through the proxyCSI. This, however, needs to be captured in our model and this is achieved with the association end magicSaAmfCompProxyCSI of the association between MagicLocalProxiedComponent and MagicSaCSI classes as shown in Fig. 5. This is a particular CSI through which a proxy component is assigned the task of “proxying” a particular proxied component. Consequently, the constraints on the proxy-proxied relationship, such as the requirement RQ 17, can be expressed and checked at configuration time to the extent allowed by the proxyCSI configuration attribute. At configuration time, we have to ensure that there is at least a proxy component that is able to be the proxy component for the proxied component. This constraint translates to the existence of a proxy component that supports a component service type (CsType) to which the proxyCSI of the proxied component in question belongs to. The domain model should capture this constraint otherwise we fall into an under-specification case and may mistakenly consider as valid configurations that do not satisfy AMF requirements.
Several other situations like the ones related to container and contained components as shown in Fig. 5 - dashed line (B) - are not discussed here due to space limitations.
One of the UML profile standardized by the OMG [
The authors in [
An UML profile related to HIDENETS [
In this paper, we discussed our work in designing a profile for AMF configurations. We introduced our approach and current results before elaborating on challenges of capturing only necessary requirements into the domain model. These challenges are mainly due to the fact that the AMF standard specification defines simultaneously what a valid AMF configuration is and what the expected behavior from an AMF service implementation is. An AMF configuration is defined at configuration time, while an AMF service implementation decides at run-time of several assignments and relationships. In our initial attempts in defining the domain model, we have been tempted to capture more than what is required and go beyond configuration time requirements. Several iterations with the domain expert have been necessary to distinguish between the different categories of requirements in the AMF specification. Dropping the runtime requirements from the domain model has led to other difficulties in specifying related configuration requirements that are necessary for the definition of AMF configurations. A straightforward application of the domain model is the validation of AMF configurations. These are often built manually. The design of an AMF configuration is a tedious and error prone task due to the large number of AMF requirements that have to be taken into consideration. Consequently, checking the compliance of AMF configurations against the AMF specification is crucial. We have implemented a prototype tool for the validation of AMF configurations.
Our goal is to enable the rigorous modeling of AMF configurations and their analysis. Our work in defining the complete profile is in progress. The analysis package will be investigated and the dynamic behavior of the AMF service will be part of this package in order to enable the analysis of AMF configurations.
Acknowledgements. This work has been partially supported by the Natural Sciences and Engineering Research Council of Canada (NSERC) and Ericsson Software Research. We are very thankful to Dr. Maria Toeroe [Ericsson Inc., Montreal] who has been very instrumental as domain expert during this modeling process.