WO2015173706A1 - Generating consistent system configuration by model weaving - Google Patents

Abstract

A configuration generator uses a weaving model to generate a consistent system configuration, where the weaving model specifies relations among metamodels of input models and the system configuration to be generated. The configuration generator receives the weaving model as input, generates transformations for the input models, generates constraints for the system configuration, and executes the transformations to weave instances of the input models into the system configuration. As a result, the generated system configuration obeys the constraints and is consistent with the relations specified in the weaving model.

Description

GENERATING CONSISTENT SYSTEM CONFIGURATION BY MODEL WEAVING CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 61/992558 filed on May 13, 2014.

TECHNICAL FIELD

[0001] Embodiments of the invention relate to system configuration generation and management.

BACKGROUND

[0002] Complex systems are configured and managed using a management model that may consist of many fragments, each of which describes a different aspect of the system. In the component based architecture, each component or groups of components may have their own management model defined independently from each other. Examples of such model fragments and pieces include Ericsson Common Information Model (ECIM) fragments and the configuration models of services defined by the Service Availability Forum (SA Forum).

[0003] One problem with the conventional configuration generation techniques is that they focus on a single aspect of a system. Systems have different aspects that are interrelated and interact with one another. For example, the SA Forum defines a number of services (e.g., Availability Management Framework (AMF), Cluster Membership Service (CLM), Platform Management Service (PLM), etc.) that describe different aspects of the system. These services are related as a PLM execution environment hosts a CLM node, which in turn hosts components of AMF applications. A change in the PLM configuration potentially impacts the other two configurations. With the conventional techniques, the different aspects of the system may become inconsistent when an aspect of a system changes or is reconfigured.

SUMMARY

[0004] According to one embodiment, a method implemented by a computer system is provided for generating a system configuration. The method comprises receiving a weaving model as input, wherein the weaving model specifies relations among metamodels of input models and the metamodel of the system configuration to be generated; generating

transformations for the input models; generating constraints for the system configuration; and executing the transformations to weave instances of the input models into the system configuration to thereby generate the system configuration obeying the constraints and consistent with the relations specified in the weaving model.

[0005] According to another embodiment, a computer system is provided for generating a system configuration. The computer system comprises a memory and one or more processors. The one or more processors are adapted to: receive a weaving model as input, wherein the weaving model specifies relations among metamodels of input models and the system configuration to be generated; generate transformations for the input models; generate constraints for the system configuration; and execute the transformations to weave instances of the input models into the system configuration to thereby generate the system

configuration obeying the constraints and consistent with the relations specified in the weaving model.

[0006] According to yet another embodiment, a system is provided for generating a system configuration. The system comprises a receiver module adapted to receive a weaving model as input, wherein the weaving model specifies relations among metamodels of input models and the system configuration to be generated; a transformation generation module adapted to generate transformations for the input models; a constraint generation module adapted to generate constraints for the system configuration; and an execution module adapted to execute the transformations to weave instances of the input models into the system configuration to thereby generate the system configuration obeying the constraints and consistent with the relations specified in the weaving model.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 illustrates an example of an AMF configuration.

[0008] Figure 2 illustrates an example of a PLM configuration.

[0009] Figure 3 illustrates the mapping of AMF node to CLM node to PLM Execution Environment (EE). [0010] Figure 4 illustrates a Unified Modeling Language (UML) profile for CLM in relation with other profiles.

[0011] Figure 5 illustrates a PLM domain model.

[0012] Figure 6 illustrates a classification of PLM EE in PLM domain.

[0013] Figure 7 illustrates an Image-File entity and its classifications.

[0014] Figure 8 illustrates a classification of the PLM dependency entity.

[0015] Figure 9 illustrates a PLM configuration with dependency between VMs and VMMs.

[0016] Figure 10 illustrates a partial PLM configuration and the corresponding hardware dependency table.

[0017] Figure 11 illustrates an example of a weaving model.

[0018] Figure 12 illustrates a core weaving metamodel and its extension according to one embodiment.

[0019] Figure 13 illustrates system configuration generation with model weaving according to one embodiment.

[0020] Figure 14 illustrates the creation of a transformation model and a constraint model from configuration generation rules according to one embodiment.

[0021] Figure 15 illustrates the validation of modification requests and auto adjustment of a system configuration according to one embodiment.

[0022] Figure 16 illustrates a method for generating a system configuration according to an embodiment.

[0023] Figure 17 illustrates a system or apparatus for generating a system configuration according to an embodiment.

[0024] Figure 18 illustrates a system or apparatus for generating a system configuration according to another embodiment.

DETAILED DESCRIPTION

[0025] The various features of the invention will now be described with reference to the figures. These various aspects are described hereafter in greater detail in connection with exemplary embodiments and examples to facilitate an understanding of the invention, but should not be construed as limited to these embodiments. Rather, these embodiments are provided so that the disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. [0026] Many aspects of the invention are described in terms of sequences of actions or functions to be performed by elements of a computer system or other hardware capable of executing programmed instructions. It will be recognized that the various actions could be performed by specialized circuits, by program instructions being executed by one or more processors, or by a combination of both. Moreover, the invention can additionally be considered to be embodied entirely within any form of computer readable carrier or carrier wave containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0027] In some alternate implementations, the functions/acts may occur out of the order noted in the sequence of actions. Furthermore, in some illustrations, some blocks may be optional and may or may not be executed.

[0028] The following is a list of acronyms:

AIS Application Interface Specification

AMF Availability Management Framework

AMW Atlas Model Weaver

ATL Atlas Transformation Language

CCB Configuration Change Bundle

CLM Cluster Membership

DSML Domain Specific Modeling Language

EE Execution Environment

EMF Eclipse Modeling Framework

FRU Field Replaceable Unit

HE Hardware Element

HOT Higher Order Transformation

HPI Hardware Platform Interface

FMM Information Model Management

MDD Model Driven Development

MM Metamodel

NG Node Group

NG set Node Group set

OCL Object Constraint Language

OS Operating System

OVF Open Virtualization Format

PLM Platform Management SA Forum Service Availability Forum

SG Service Group

SI Service Instance

SU Service Unit

UML Unified Modeling Language

VM Virtual Machine

VMG Virtual Machine Group

VMG set Virtual Machine Group set

VMM Virtual Machine Monitor

WMM Weaving MetaModel

WModel Weaving Model

[0029] The SA Forum solution defines a platform independent middleware for managing the high availability for the applications under its control. The SA Forum middleware exposes two sets of interfaces: the Hardware Platform Interface (HPI) and the Application Interface Specification (AIS). The AIS specification is comprised of twelve services and two frameworks which collaborate with each other to facilitate the provisioning of service with high availability. The AIS are classified into four functional groups: the platform related services, basic management infrastructure services, and general utility services, beside two frameworks. These services and frameworks are referred to as AIS services hereinafter. Many of the AIS services come with a configuration that reflects the system from the point of view of that service and specifies the organization and the characteristics of the entities under the control of that service. An integration of all these configurations forms the system

configuration that is a logical representation of the entities (software or hardware) of the system, their characteristics and relations. The integration of the service configurations (also known as configuration fragments) for creating the system configuration is a challenging task and needs careful attention to the relation between the configuration fragments. The complexity of the integration job is due to overlapping entities (entities which are controlled by more than one service) and/or complex relations and the constraints between the entities from different configuration fragments. If these relations and the constraints are not well defined, modifying an entity in the configuration fragment used by a particular service may cause inconsistency and disturb other services managing the same or related entities. The integration of the configuration fragments consists of defining these relations considering certain requirements or aspects of the domain such as security, availability, performance, etc. [0030] Embodiments of the invention provide a configuration system and method based on model driven development (MDD) concepts and techniques to consolidate the

configuration fragments into a consistent system configuration and maintain the system configuration consistency despite runtime modifications. Model weaving and model transformation are used to specify the relations between the elements of these configuration metamodels and their integration. To preserve the system configuration consistency at runtime, the constraints governing the relations between the system entities are extracted from the transformation rules (e.g., Higher Order Transformation (HOT) rules). These constraints are later used for validating the requested modifications before being applied to the configuration. An auto adjustment method is described to eliminate the inconsistencies due to runtime modifications, with the help of the constraint model and the configuration generation rules (e.g., Atlas Transformation Language (ATL) transformation).

[0031] An example of tightly coupled model fragments, in the context of SA Forum middleware, includes the AMF and the PLM configuration models. To maintain high availability, the redundant AMF entities, which include both the active and the standby components assigned to provide and protect a service at the AMF level, are configured on separate redundant pieces of hardware at the PLM level. Otherwise, the failure of a piece of hardware may take out all of the redundant AMF entities. Such relations between the configuration models go beyond each of the fragments. The configuration system and method described herein take into account these relations when the system configuration is designed, and the relations are maintained throughout the life-cycle of the system which may evolve through configuration changes.

[0032] A consistent configuration can be described in a domain specific language, where all the constraints that the configuration satisfies are implied. Using such a domain specific language, only valid configurations can be described. Such domain specific language can also be used to generate configurations through model transformations provided the required input is available as model instances. Such technique was discussed in U.S. Patent Publication No. 2011-0270595, incorporated herein by reference.

[0033] Alternatively, the constraints may be encoded in a program that generates a configuration from the input that it receives, as described in U.S. Patent No. 8006130 and U.S. Patent Publication No. 2009-0164767, also incorporated herein by reference.

[0034] Different methods for calculating and adjusting AMF and PLM configurations that guarantee hardware redundancy when one or the other configuration is given as an input were also defined in U.S. Patent Application Serial No. 13/690373 and U.S. Patent Application Serial No. 13/872680, also incorporated herein by reference.

[0035] For the sake of simplicity, the following description is based on the configurations of the AMF, PLM and CLM services of the SA Forum middleware. It is understood that the system and method described herein can be extended to more general modeling context where the consistency preservation is an important issue during the integration of partial models. The validation and auto adjustment approaches are also applicable in a more general context where the consistency of the integrated model is to be maintained.

[0036] In one embodiment, a model weaving technique is used to define fine-grained relations or correspondences between models or metamodels, and to consolidate relations and/or overlaps between different models into a single model. The fine-grained

correspondences between models can be defined by a weaving model. In one embodiment, the weaving model interrelates the models by defining the relations between model elements with "links." An example of a weaving model 1101 (WModel 1101) and a weaving metamodel 1106 (WMM 1106) is shown in Figure 11. Figure 12 illustrates an example of a core WMM 1210 and its extension 1230, in which link types are defined in WLink 1213. Further details of Figures 11 and 12 will be provided in later parts of the description.

[0037] The model weaving technique inter-relates different models via links established between elements of different models or metamodels. This technique is adapted to generate a consistent system configuration from configurations of the sub-systems, by applying the relations defined through the weaving model to the configuration elements. To apply the technique, the profiles of the input models and their relations are defined as well as the profile of the output model. In one embodiment, the weaving metamodel is extended to define the transformation from the input models to the output model.

[0038] To maintain the consistency of the system configuration, the constraints of the system configuration are derived from the weaving model. These constraints then are used to validate changes to the system configuration. However, if a change violates any constraints, it is not discarded immediately. Instead, the relation of the conflicting configuration is checked, and the information in the constraints may be used to select the weaving transformations that can adjust the conflicting configuration elements to resolve the conflict and maintain consistency.

[0039] The following steps provide an overview of a process (also referred to as a

"generation process") for generating and maintaining a consistent system configuration: [0040] 1. Define the metamodel of the input models, i.e., the configuration fragments that compose the system configuration (e.g., PLM and AMF profiles).

[0041] 2. Extend the weaving metamodel with additional concepts and relations for the targeted domain; for example, extend WLinks 1213 defined in the core WMM 1210 of Figure 12 to abstract the relation of PLM and AMF entities.

[0042] 3. Define the weaving model that relates the elements of the input metamodels with the elements of the output metamodels using the links and link end of the weaving metamodel.

[0043] 4. Create HOT rules that translate the weaving model to ATL

transformation code that can generate from instances of the input models an instance(s) of the output model(s).

[0044] 5. Use the HOT to generate the ATL transformations (T) for the input models and the Object Constraint Language (OCL) constraints (C) for the system

configuration. This step is also referred to as the transformation generation process.

[0045] 6. Run the ATL transformations to weave instances of the input models into consistent system configurations. This step is also referred to as the configuration generation process.

[0046] 7. Use the generated constraints to validate and safeguard the consistency of system configuration through applying them to runtime configuration changes.

[0047] 8. Use the applicable constraints (C) to identify additional system configuration elements that are impacted by the changes and, when feasible, use the applicable ATL transformations (T) and auto-adjust the impacted system configuration elements to keep the configuration consistent. Otherwise, reject the changes.

[0048] In an alternative embodiment, the constraints (C) can be generated during the configuration generation process (i.e., step 6) using the ATL transformations. Steps 1-4 can be performed manually for any new metamodels or new relations (e.g., new extensions to an existing metamodel). Once the metamodels and relations are defined, steps 5-6 are automated, and they can be repeated as often as needed. Step 5 is repeated each time new configuration metamodels are interrelated, and it is fully automatic for all already defined relations. Step 6 is repeated each time a system is configured or reconfigured. Steps 7 and 8 are applicable any time the system is reconfigured.

[0049] One embodiment of the invention follows the Model Driven Development (MDD) paradigm. The MDD paradigm focuses on abstracting the concepts of the domain by creating models containing elements that are representing those concepts. Using the MDD paradigm, the problem domain can be expressed in a high level of abstraction instead of at the levels of programming and computing concepts. In order to adopt MDD, a modeling framework is adopted that facilitates the generation, validation and auto adjustment of the system

configuration.

[0050] In one embodiment, the domain concepts, syntax and semantics of the CLM and PLM services, as well as their relations and constraints, are captured using Domain Specific Modeling Languages (DSML), with the help of the Unified Modeling Language (UML) Profiling mechanism. Specifically, UML profiles for the CLM and PLM services are defined. The UML profile that has already been defined for the AMF service of the SA Forum is used.

[0051] When the configuration is generated and deployed in the live system, the risk of inconsistency still exists, as the administrator or management applications may request to modify some elements in the configuration and these modifications may affect other services working with the same or related entities. So the modifications are validated before being applied. The validation is performed with respect to the consistency rules of the system configuration, which are also called the system constraints. System constraints can be extracted from the generation process and collected to form a constraint model. In the generation process, all these constraints are implicitly taken care of by the generation rules in order to create a consistent and well defined configuration model.

[0052] During the validation, a modification can be applied to the configuration safely if none of the constraints of the constraint model are violated by the modification. However, if the requested modification violates some constraints, an auto adjustment mechanism may be used to resolve the potential conflicts that may be caused by the modification. This adjustment may not be possible in all cases and it depends on the impacted model elements and the constraints. In one embodiment, this adjustment process is automated with the help of the constraint model (which specifies the side effects of the modification to be repaired) and the configuration generation rules (which help to recreate the inconsistent parts). The constraints can be used for diagnosing the affected entities. For correcting the inconsistencies, the configuration generation rules (the revised version of final transformation used in the configuration generation) may be reused to make the auto adjustment happen.

[0053] The first part of the detailed description presents the definition of high availability and a solution provided by the SA forum for providing high availability. Additionally, the description also explains AMF, CLM, and PLM, which are part of the SA Forum middleware and the context for the configuration management. [0054] Service Availability. Availability is a non-functional requirement for many applications. The availability of a system is measured based on the reliability of its components and the required time to repair the system in case of failure. It is measured using the following formula: ~ MT&F - MTTB

[0055] In this formula MTBF (Mean Time Between Failure) represents the elapsed time between inherent failures of a system during operation and MTTR (Mean Time To Repair) shows the required time to restore the system. High Availability (HA) is achieved for the system when it is available 99.999% of the time, i.e., less than 5.25 minutes downtime per year.

[0056] The Availability Management Framework. AMF maintains service availability by coordinating and managing redundant software entities that compose the applications deployed within a cluster. To be managed by AMF an application needs to be described according to the AMF configuration model, part of a standardized information model. In this configuration a set of components (e.g., software and/or hardware resource) that can collaborate to combine their services forms a Service Unit (SU), while the workload associated with provisioning the services is represented as a Service Instance (SI). To protect the services SUs are deployed redundantly, and each set of redundant SUs form a Service Group (SG). From AMF perspective, an application may consist of multiple different SGs.

[0057] At runtime, AMF maintains the availability of a service by assigning the representing SI in active and in standby roles to different SUs of the protecting SG. When the SU in the active role fails, AMF dynamically shifts the active assignments from this faulty SU to the standby thus maintaining the SI and the service it represents available. AMF uses the view of a logical cluster, which consists of a number of cluster nodes. Ideally each SU should be instantiated on a different cluster node. An AMF node is a logical container for the AMF components and their SUs. SUs may be allocated to particular nodes, which means the allocated SU can be instantiated only on those specific AMF nodes, which is called a Node Group (NG). Similar to the SU allocation, SGs can also be allocated to NGs. The NG configured for an SG determines the set of nodes its SUs can be instantiated on. A simple example of an AMF configuration 100 is shown in Figure 1. In this example Appl consists of one SG (SGI). This SG has two SUs (SU1, SU2) and protects the service represented by SI. Each of the SU1 and SU2 is hosted on a separate node: Nodel and Node2. AMF assigns the active and standby roles on behalf of SI to the SUs at runtime and in case of failure of the one with the active role; AMF changes the standby SU's assignment to active.

[0058] The Cluster Membership Service. The cluster Membership Service (CLM) is one of the AIS services, responsible for forming the logical cluster from configured logical nodes and also providing membership information about the configured nodes of the cluster for other services and applications requiring this information. Based on CLM specification:

[0059] A cluster node is a logical representation of all the software running on an instance of operation system (which from PLM perspective is called the execution environment).

[0060] A cluster is a set of nodes collaborating to provide a set of services defined by the SA Forum AIS.

[0061] The Platform Management Service. The Platform Management Service (PLM) is one of the platform services of AIS which is responsible of providing a logical view of the hardware (called Hardware Elements) and the low level software including the operating system and virtualization layers (called Execution Environments), to other services. This logical view is provided through the PLM configuration, as part of the information model of the SA Forum.

[0062] Using such a configuration enables PLM to act as a mediator between the software services (including AIS services or any other service which implements the necessary interface) and the hardware parts of the system which is managed by HPI. This means that PLM maps the logical hardware elements needed by the services to hardware entities at HPI level (representing the physical hardware). It also enables other services and applications to become aware of the state changes of the hardware and the execution environment.

[0063] A simplified example of a PLM configuration 200 is shown in Figure 2. The PLM domain is the root object of all entities in the PLM configuration. In the PLM configuration each Hardware Element (HE) with computational capability can host a PLM Execution

Environment (EE) represented as the HE's child, which can be: a Virtual Machine Monitor (VMM) or an Operating System (OS). If it is an OS, it may host VMMs thus allowing for multiple children. If it is a VMM it also can have multiple children, but in this case the child EEs represent Virtual Machines (VMs). So these dependencies between the PLM entities (HEs and EEs) are based on a hierarchical organization of the entities reflecting that an HE/EE requires some other HEs/EEs of the system for proper functioning.

[0064] There is another kind of dependency that can be defined explicitly between PLM entities and specifies the dependent entity, the potential sponsors and a number representing how many sponsors should be available and in service so that the dependent can provide the service.

[0065] An AMF node is mapped into a cluster node managed by the CLM, and an AMF cluster is mapped to a CLM cluster. Each cluster node should be hosted on an OS instance to be able to use it for service provisioning. Therefore, each cluster node is mapped into a PLM EE representing an OS instance. This mapping if it exists is a one to one mapping. An overall picture of the mapping 300 between the AMF node, CLM node and PLM EE is shown in Figure 3.

[0066] System Configuration Management Framework. The system configuration is a reference for all services working in the system defining the software and hardware elements of the system and their attributes. It's a model reflecting one consistent view of the entities composing the whole system, the relation among entities and their constraints. Having a well- defined system configuration with respect to the consistency rules of the domain, one can avoid the problem of conflicting information. Otherwise if the relations and the constraints were not well defined, modifying an element in the system configuration used by a particular service may cause disturbance to various services using related entities.

[0067] The Modeling Framework. As previously mentioned, a solution described herein for the system configuration management is based on the model driven paradigm. The modeling framework consists of three domains: the AMF configuration, the CLM

configuration and the PLM configuration.

[0068] In one embodiment, DSML is used to capture the specific concepts of each domain. UML metamodel is used because UML has become the de facto standard for modeling and design and proved to have several advantages for domain specific modeling languages. The UML metamodel is extended by means of the UML Profiling mechanism. A UML profile is defined for each domain containing all the respective domain concepts, their relationships and their constraints. The AMF domain has been tailored previously, so it is used to define UML profiles for the CLM and PLM domains accordingly.

[0069] Two steps are taken for defining the profiles. In the first step a complete model of all concepts of the domain is created. The model describes all concepts their relations and constraints of the domain. This includes the defined concepts in the CLM, PLM

specifications as well as those that are proposed for enriching the domain e.g., for better support of platform requirements in the virtualized and cloud environments. In the second step, a UML Profile is created by mapping the elements of the domain model into the stereotypes, tagged values and constraints in the UML metamodel. For each concept in the domain model the UML metaclasses are examined to find the metaclass which has the closest meaning to that concept, and that metaclass is extended. The defined extension satisfy the following requirements: (1) it is complete by containing all the elements needed by the domain; (2) it does not contradict nor violate the UML metamodel; (3) it reuses metaclasses based on their semantics; (4) it reuses as many UML relationships between the stereotyped elements as possible; and (5) it constrains the stereotyped elements to behave according to the rules of the domain.

[0070] CLM Domain. As mentioned previously, CLM is one of the AIS platform services and it is responsible for forming one logical cluster from configured logical nodes. If the other services and applications need the membership information about configured nodes of the cluster, they use CLM. The CLM domain consists of the CLM node and CLM cluster concepts. The cluster comprises a set of administratively configured nodes or so called cluster nodes. The cluster nodes collaborate with each other to provide a set of services defined by the AIS. Each AMF node should be mapped to a CLM node in order to be able to provide service and a CLM node can host at most one AMF node. On the other hand the CLM node may be hosted on a PLM Execution Environment and again this mapping if exists is one to one. Similar to the mapping of AMF nodes to CLM nodes, each AMF cluster may be mapped to at most one CLM cluster and each CLM cluster may host at most one AMF cluster.

[0071] There are certain rules and constraints in each domain that cannot be specified by the elements and their relations. Defining these constraints is necessary for having a well- defined model. Some of these rules may deal with the configuration attributes and parameters to be considered and the constraints on their values, while other constraints may affect the structure of the model (well-formedness). For the CLM domain, these constraints are expressed formally in Object Constraint Language (OCL). An example of a structural constraint can be: If an AMF node is mapped on a CLM node, then the AMF cluster is mapped on the same CLM cluster containing that CLM node. This constraint in OCL can be expressed as follows:

context SaAmfNode

invariant: self.saAmfNodeClniNode -> notEmptyO implies

self. safAmfNode saAmfCluster. saAmfClusterClmCluster. safCluster self.saAmfNodeClniNode. SaClmNode_ SaClmCluster. safCluster

[0072] CLM UML Profile. Once the CLM domain model is completed by defining all the concepts, their relationships, and the specific constraints that govern the structure and the behaviour of these concepts, the CLM profile can be created. For this purpose each concept in the CLM domain model should be corresponded to a stereotype which extends a UML metaclass.

[0073] The CLM cluster concept is herein used as an example of mapping domain concepts to the UML metamodel. The CLM cluster is a logical entity consisting of a number of CLM nodes and because it has a grouping role, it can be mapped to the UML metaclass "Package " because according to the UML specification, "a package is used to group elements, and provides a namespace for the grouped elements". The stereotype

"SaClmCluster " refers to this entity. The relationships in the CLM domain are also mapped to the Association metaclass of the UML. Table 1 shows the concepts of CLM domain and their correspondent stereotypes and the UML metaclass that they extend.

Table 1 : UML metaclasses for CLM profile

[0074] Figure 4 illustrates a UML profile for CLM (i.e., CLM profile 400) in relation with other profiles. It shows that the CLM profile 400 consisting CLM stereotypes( SaClmCluster, SaClmNode) from CLM domain and other stereotypes from the AMF domain

(SaAmf Application, SaAmfCluster, SaAmfNode) and the PLM domain (SaPlmEE) which have relationship with the CLM domain concepts. As some constraints exist between the entities from these domains, the related elements are demonstrated in the CLM profile 400.

[0075] PLM Domain. The PLM service is responsible for providing a logical view of the hardware as Hardware Elements (HEs) and the low level software - including the operating system and virtualization layers - as Execution Environments (EEs). This logical view is provided through a PLM configuration. PLM connects the AIS services, and the hardware parts of the system, which is managed by Hardware Platform Interface (HPI) by mapping the logical HEs represented in the PLM configuration to the real hardware entities discovered and managed by HPI.

[0076] The PLM domain concept is the root object of all the elements in the PLM configuration. The PLM domain is composed of one or more PLM Entities. The PLM Entity is an abstract concept and can be specialized to the PLM HE and PLM EE. In the PLM domain the PLM HE is a logical representation of any piece of hardware. It can represent diverse hardware components, such as a CPU, a Field Replaceable Unit (FRU) or even a fan or a power supply.

[0077] The PLM EE is a logical entity representing an environment capable of running software. A CLM node can be mapped only on an EE which is an Operating System (OS). A Virtual Machine (VM) or a Virtual Machine Monitor (VMM) are other examples of the EEs. The EEs should be mapped to the FIEs with computational capabilities. Each HE with computational capability can host an EE that is represented as the FIE's child, this child EE can be: an OS or a bare metal hypervisor (i.e., a special kind of VMM which runs on the hardware and does not require to be installed inside an OS). Note that although the VM is considered as an EE, it cannot run directly on the hardware and needs a VMM to host it, so the VM cannot be a direct child of an HE. An OS as an EE object, may itself host VMMs thus may have multiple children. The VMM can also have multiple children (the VMs). As a result FIEs and EEs form a tree and there is a dependency between PLM entities (HEs and EEs) which reflects that an HE/EE hosts some other HEs/EEs of the system. Beside the hierarchical dependency between the PLM entities (HEs, EEs) defined as body of the tree, another kind of dependency is also defined in the PLM configuration This type of dependency is represented by the PLM dependency class in the PLM domain model and captures the information of the dependent entity, its potential sponsor entities and an attribute indicating the required number of sponsors for this dependent entity.

[0078] Figure 5 illustrates a PLM domain model 500. In Figure 5, an overall picture of the elements forming the PLM domain model 500 as they are defined in the PLM specification is shown as a UML class diagram. The described structure of the PLM domain model 500 was designed to resolve the current needs of the AIS services while some architectures like the virtualization were not of great concern at that time but with emerging the new architectures, as for the cloud, a more elaborated configuration is needed. The PLM domain model 500 is redefined by adding necessary elements to enrich the model for further uses of virtualization architectures, and then the PLM profile is created based on the new domain model. In the following, these refinements of the PLM domain are explained in more details.

[0079] Redefining the PLMEE. As previously mentioned the EE is a logical entity representing any environment which can run software. This environment can be a single OS or a virtual machine or a hypervisor monitoring different VMs or a combination of them. The EE definition is very general and includes a wide range of entities without considering their specific characteristics. The general EE entity is classified into more specific entities especially those appropriate for the virtualization purpose. Based on this specialization, a class hierarchy of PLM EEs is specified in a class diagram 600 in Figure 6.

[0080] At the top level of this hierarchy is the general EE. At next level, the VM, VMM and OS are distinguished, which are shown as UML abstract classes inheriting from the EE general class. The children of these classes are those who inherit from one or more of these middle classes. These classes at the bottom of the EE class hierarchy are more specialized and can be used to represent the actual entities for serving as platform entities. An

explanation for each of these classes is provided below:

[0081] Single OS: This class represents an OS as an EE without virtualization options, e.g., SUSE Linux™ enterprise server.

[0082] OS integrated with VMM: This class represents an OS and this OS includes and integrates a VMM or a hypervisor e.g., Windows™ server 2008 with Hyper-V.

[0083] VMM: This class is for the case where the VMM is a separate program installed on an OS, e.g., VMware™ workstation.

[0084] All in One: There are certain OSs that integrate both the VMM and the VM and are therefore capable of hosting different VMs with the same OS as the guest. These VMs can be seen like different threads running on the host OS but with their own separate memory and resources. An example of this kind of EEs is the Solaris™ versions 10 and 11

containers/zones.

[0085] Bare Metal VMM: This type of VMM is an OS-independent hypervisor which is installed and run directly on the physical hardware such as VMWare™ vSphere ESXi hypervisor.

[0086] VM without OS: This class represents the VMs which can host different OSs as desired.

[0087] VM with OS: This class represents the VMs tightly coupled with a given OS installed in them.

[0088] Image-File: A New PLM Entity. Another proposed refinement to the PLM domain model is adding a new kind of entity called Image-File as a new classification of the PLM Entity abstract class. The Image-File entity is an abstract class and will be classified into further more specific classes: OS-Image, VM-Image, and App-Image. The Image-File entity and its classifications 700 are illustrated in Figure 7. Next, each class is explained in more details. [0089] OS-Image: This class represents an image of all files of an OS. The OS-Image can be used for creating different OS instances and an OS can be instantiated with any of the OS- Image replicas.

[0090] VM-Image: This class represents the image file containing all the required information for running the VM on a VMM; this may include the VM configuration information (e.g., the memory size, processor, etc.)

[0091] App-Image: App-Image class represents the image file containing the executable components of applications. The App-Image file should be mounted in an execution environment so that its constituent software components can be executed.

[0092] Redefining PLM Dependency. Based on the PM specification, the PLM

dependency entity captures the information of the dependent entity (EE/HE), its potential sponsor entities and an attribute indicating the required number of sponsors for this dependent entity which are the configuration attributes of PLM dependency class in PLM domain model. Another attribute is added to distinguish which sponsor entity/entities from the potential sponsors are sponsoring the dependent entity at runtime.

[0093] Figure 8 illustrates another refinement, a classification of the PLM dependency entity 800, which is useful in virtualized environments. The dependency entity is classified into three more specific entities: the VM to VMM, VM to VM-Image and OS to App-Image which are explained in the following:

[0094] VM to VMM: This entity intends to reflect the relations of the VM to its sponsor VMMs instead of using the traditional hierarchical relations. Through this class it can be defined on which VMMs the VM can be hosted and one of those VMMs should be available so that the VM can stay in service. This way of demonstration of VM to VMM dependency makes the VM live migration possible that is an important feature in the virtualization.

[0095] VM to VM-Image: This entity represents the dependency of each VM to the VM- Images that can be used for that VM. The VM-Images are replicas (they have the same content), so choosing any of the sponsor VM-Images will provide the exact same VM.

[0096] OS to App-Image: This entity represents the relation of an OS to the App-Image containing the executable components. The OS entity is the only PLM EE that a CLM node can be mapped to, but it can act as an execution environment for AMF node only if it has the executable components of the application hosted on that AMF node. So the OS needs the App-Image file for providing service (serving as an execution environment).

[0097] PLM UML Profile. Once all the concepts of the PLM domain model, the relationships among them, and the specific constraints that govern their structure and their behaviour have been defined, the PLM profile can be created. For this purpose, the full set of domain concepts is examined, and the most appropriate UML metaclasses are identified for each concept. Since UML 2.0 supports inheritance relationship between the stereotypes, there is no need to map all concepts to the corresponding metaclasses; but rather some of them can directly inherit from the newly created stereotypes.

[0098] A specific case of PLM EE is presented as an example of the mapping of domain concepts to the UML metamodel. The PLM EE in PLM domain is a logical entity

representing an environment capable of running software. The PLM EE is mapped to the UML metaclass Node because a node in the UML specification is defined as "a

computational resource upon which artifacts may be deployed for execution" and this is the closest definition to the PLM EE. A new stereotype called "MagicSaPlmEE" is created to refer to the PLM EE entity. For the other concepts of the PLM domain, the same approach is followed to find the closest mapping from the UML metaclasses. Table 2 presents the domain concepts and their corresponding stereotype as well as the UML metaclasses that they extend. Those entities in the PLM domain that are not mapped directly to the UML metaclasses, inherit from their parent stereotype. All of the relationships between the concepts of the PLM domain are also mapped to the Association metaclass of the UML.

Table 2: UML metaclasses for PLM profile

[0099] Definition of the Relation between Configuration Fragments. As previously explained the system configuration is a representation of all the configurable elements of the system and their relationships. Generating such a complete inventory of system elements from scratch and manually would be a difficult job. One can facilitate the generation process by creating configurations for various services of the system and combining these

configurations based on their specific relations. In the following, a special feature of providing hardware redundancy for logical redundant entities is explained in more details. [00100] Appropriate Distribution of the Logical Entities on Physical Hardware. High availability can be achieved through software and hardware redundancy and the appropriate management of these resources. In the SA Forum architecture software redundancy for the applications is achieved using redundant SUs in SGs for providing and protecting services. As a result of separation of concern among the SA Forum middleware frameworks and services, AMF handles software redundancy independently of the deployment platform, which is managed by PLM. The two respective configurations are put into relation through the CLM service. An AMF node is mapped into a CLM node, which is at the end of the chain a PLM EE. This PLM EE is running on a physical hardware node represented by a PLM HE. Because of virtualization allowing for multiple EEs on a single HE, many SUs of the same SG may end up running on the same HE and therefore break the principle of no single point of failure. For assuring service availability, SUs for a given SG are deployed on different HEs, and therefore ensure hardware redundancy for the services even in the context of the VM migration.

[00101] The PLM configuration is enabled to capture all the necessary relations between hardware elements and low level software e.g. VMs and VMMs, and is related to the AMF configuration, which captures the relations between the software entities in such a way that at runtime AMF does not need to be aware of the runtime changes at the PLM level. For simplicity, the concept of the CLM node in the relation between the AMF node and PLM EE is skipped as they are 1 : 1.

[00102] To provide protection against hardware failures, AMF is to distribute the assignments of the same SI to SUs instantiated on different hardware elements so that in case of failure of one hardware element with an active assignment, another SU with a standby assignment is located on a redundant hardware element and it is still available to provide the service represented by the SI. Since AMF may assign the SI to any SUs of the protecting SG, this means that SUs of each SG should be instantiated on different HEs. To ensure this the SUs of an SG should be configured on different HEs, e.g., each SU is tied to a given AMF node, without virtualization maps to an HE. With virtualization each SU should be instantiated on a VM of a different HE. The AMF configuration can limit each individual SU to a set of AMF nodes by setting its NG attribute. Thus, each SU is to be configured for the NG formed by the VMs of a different HE.

[00103] A most important feature of such a configuration is that the NGs configured for the SUs of an SG are hosted on different hardware elements and therefore no matter how AMF selects the node for each SU, it is always guaranteed that when the assignments for the same SI are given to different SUs they land on different HEs. These Hardware-disjoint NGs do not have nodes that eventually map to a common HE.

[00104] To achieve hardware redundancy at the deployment in virtualized environments, the number of AMF nodes, VMs and HEs should be equal to or greater than the number of SUs in the largest SG, in terms of SUs, in the configuration. This is a necessary but not a sufficient condition: Because of the predefined dependencies between the VMs and VMMs in the PLM configuration, it may not be feasible to use all HEs for each SG. Therefore, rather than taking a top down approach, another approach is to start from a given platform configuration and determine the sets of HE-disjoint VMs, which in turn correspond to hardware-disjoint NGs forming an NG set. The NGs of an NG set in turn can be used to configure the SUs of SGs in the AMF configuration. This means that the number of hardware-disjoint NGs will depend on the PLM configuration. Partitioning the VMs into HE- disjoint sets can be achieved in a number of ways but not all of them may be suitable for a given AMF configuration.

[00105] Relevant Information from the PLM Configuration. The starting point for forming an NG set is the PLM configuration containing the information about HEs, EEs, their types and relations, where the EEs representing the VMs are located directly under the PLM domain object and the VMMs eligible of hosting each VM are listed in the dependency object of the VM (as explained previously that VM to VMM dependency object is used to represent the relation of a VM and its potential VMMs instead of the parent-child relation). VMMs are represented in the model as EEs that are hosted on an HE or an OS. Figure 9 illustrates a PLM configuration 900 with dependency between VMs and VMMs.

[00106] The PLM dependency object provides the information that each VM has a dependency on a number of VMMs, and each VMM is hosted on an HE. Therefore, the HEs where each VM can be hosted are identified. This information may be presented in a hardware dependency table. Figure 10 shows an example of a hardware dependency table 1010 extracted from the PLM configuration 1020 of the same figure that is simplified by connecting the VMs directly to the VMMs that they depend on.

[00107] An Algorithm for Creating a Set of Hardware-disjoint NGs. Algorithm 1 determines the HE-disjoint sets of VMs and their corresponding hardware-disjoint NG set, for a given PLM configuration taking the hardware dependency table of the configuration as the input.

[00108] The algorithm starts with initializing three sets: A containing all VMs and two empty sets named Leftovers and NGset. The set of HEs that each VMi can be mapped to is defined as HE-VMi on Line 6. The rest of the algorithm is divided in two parts. The first part (Line 8 to 26) determines the set of NGs and their associated HEs {HE-NGi) by repeating the process of selecting the VM associated with the lowest number of HEs and the VMs that are associated with exactly the same set of HEs, removing them from A and moving to Leftovers any VM, which has any common HE with them (i.e., not HE-disjoint). The second part goes through the leftover VMs one by one and adds any of them that is HE-disjoint with all defined NGs except one. The VM is added to the NG with which it overlaps in terms of HEs. The other VMs remain in the leftovers.

Algorithm 1: Defining HE-disjoint groups of VMs

Input: HW_Dependency Table from the PLM configuration

Output: Set of HE-disjoint NGs in NGset and a set of unused VMs in leftovers

1 : A := set of all VMs in PLM configuration

2: Leftovers := { }

3: NGset := { }

4: // Identify the HEs related to each VMi based on HW_Dependency Table of the PLM configuration

5 : for each VMi in A do

6: HE-VMi := {HEs related to VMi in HW_Dependency Table}

7: end for

8: // Select among remaining VMs the VM associated with the lowest number of HEs in HW_Dependency Table and remove from A the VMs that are not HE-disjoint with it

// n is the counter of the NGs

n := 0

repeat

select VMi from A such that |HE-VMi| < |HE-VMj| for any VMj in A

n := n+1

NGn := {VMi}

HE-NGn := HE-VMi

A := A - {VMi}

for each VMj in A

if HE-VMj = HE-NGn then

NGn = NGn u {VMj}

A = A - {VMj }

else if HE-VMj n HE-NGn≠ {} then

Leftovers := Leftovers u {VMj}

A = A - {VMj }

end if

NGset := NGset u {NGn}

until A= {}

//Adding the leftover VMs to formed NGs iff they intersect with only one NG with respect to their HEs for each VMi in Leftovers do

// k is the counter of NGs with which VMi has common HEs

k := 0

for each NGj in NGset do

if HE-VMi n HE-NGj≠ {} then

k++

temp :=j

end if

end for

if k = 1 then

NGtemp = NGtemp u {VMi}

HE-NGtemps := HE-NGtemp u HE-VMi

Leftovers := Leftovers - {VMi}

end if

end for

[00109] Applying Algorithm 1 to the example of Figure 10 results in creating two

hardware-disjoint NGs, NGl and NG2, determined by following the steps of the algorithm follows:

[00110] Initially, A = {VM1,VM2,VM3,VM4,VM5,VM6}, Leftovers = { }, NGset = { }.

[00111] First NG is created with VMI that maps to two HEs: NGl = {VM1 } with the set of HE-NG1 = HE-VM1 = {HE1,HE2} A = {VM2,VM3,VM4,VM5,VM6}

[00112] VM2,VM3,VM5,VM6 are removed from A and put into Leftovers because of having HEs in common with NG: 1

NGl = {VM1 } with HE-NG1 = {HE1,HE2}, NGset = {NGl }

A = {VM4}

Leftovers = {VM2,VM3,VM5,VM6}

The algorithm repeats previous steps and creates NG2

NG2 = {VM4} with HE-NG2 = {HE4,HE5}

NGset = {NGl, NG2}

A = { }

Leftovers = {VM2,VM3,VM5,VM6}

[00113] While handling the leftovers, VM3, VM6 can be added to NGl because they have HE2 in common with NGl and by adding them the HE-disjoint rule for the NGs remains satisfied. This extends the set of HEs of NGl with HE3. VM2 cannot be added to neither

NGl nor NG2 because in either case the disjoint rule is violated. Similarly, VM5 also cannot be added to neither NGl nor NG2.

[00114] The algorithm terminates with:

NGl = {VM1,VM3,VM6} with HE-NG1 = {HE1, HE2, HE3 J

NG2 = {VM4} with HE-NG2 = {HE4, HE5}

NGset = {NGl, NG2}

A = { }

Leftovers = {VM2,VM5}

[00115] The NGs resulting from this algorithm (NGl, NG2) are hardware-disjoint and can be used in the configuration whenever hardware redundancy is required. If the SUs of an SG are configured to be hosted on these NGs, the hardware redundancy is guaranteed for that SG regardless which VMMs host the VMs selected for the SUs and the failure of a single hardware element will not affect service availability. The VMs remaining in the Leftovers set at the end of the algorithm cannot be used for the purpose of hardware redundancy.

[00116] To form the NGs in this algorithm, the heuristics of selecting the VMs which are associated to the lowest number of HEs may be used. The VMs having a superset of the HEs of these NGs are pruned, before being distributed into the different NGs, i.e., before expanding the set of HEs associated with the NGs. The algorithm terminates as A and Leftovers are finite sets. Its complexity is O(|A|²) in the worst case. Note that different heuristics may lead to other algorithms and therefore different NG sets with different hardware disjoint NGs. It is worth mentioning that the HE-disjointness between the NGs of an NG set remains valid even in case of VM migration, because the migrated VM can be hosted only on a set of VMMs (that are defined for the VM through its dependency object), and all the possible hosts (VMMs) of the VMs in the hardware dependency table are considered for calculating the HE-disjointness NGs.

[00117] Once the NG sets are defined with hardware-disjoint NGs with the help of different algorithms, the most appropriate node group set is selected for each service group in order to have a more efficient use of our resources and better distribution of load among VMs. The node group selection is based on certain criteria such as the number of SUs inside the SGs, priority of services protected by SGs, service loads and node capacity.

[00118] Generation of the System Configuration through Model Weaving. The previous sections described the importance of the system configuration and the overall process for generating a concrete and concise system configuration based on the PLM and AMF configurations. In the second part of the description, the process is explained in more details regarding how to express the relations of different elements of input models with the MDD solutions and how to transform them into a complete and integrated system configuration model. In the following, the model weaving technique is introduced and its benefits are described, and then it is explained how the model weaving technique can serve in the system configuration generation process.

[00119] Model Weaving. Model weaving is an MDD technique which aims to solve the problem of mapping between the heterogeneous data by considering the mappings as models and establishing the element correspondences in a generic way. The Weaving models containing the mappings can then be used by model transformation languages to translate the source models into the target models. Model weaving is especially useful when there are different models and each model describes some characteristics of the whole system. These models may have overlapping elements (the same physical entities with different logical representations) or various types of relations may exist between the elements of these models. The fine-grain correspondence between models, defined by a weaving model, is useful in many application scenarios such as: tool interoperability; transformation specification;

linking entities across models; traceability; and model merging.

[00120] Figure 11 is a diagram illustrating the WModel 1101 and its relations to two other models a 1102 and b 1103. The WModel conforms to the WMM 1106, and models 1102, 1103 conform to their respective metamodels 1104 and 1105. All of the metamodels 1104, 1105 and 1106 conform to a metametamodel 1107.

[00121] Figure 12 illustrates the core WMM 1210 and its extension 1230 used by a model weaver to create a weaving model according to one embodiment. An example of a model weaver is an Atlas Model Weaver (AMW), which was developed as a plugin for Eclipse™ Modeling Framework (EMF) to allow the creation of links between model or metamodel elements; thus creating a weaving model which is conform to an extensible WMM. The AMW plugin can be used to create weaving models manually or semi-automatically. The AMW plugin is integrated with the ATL for executing matching transformations.

[00122] In the core WMM 1210, WElement 1211 is the base element from which all other elements inherit. WModel 1212 represents the root element that contains all model elements. WLink 1213 denotes the link type. WLink 1213 has a reference end to associate it with a set of link endpoints (WLinkEnd 1214). Each WLinkEnd 1214 references one WElementRef 1215. WElementRef 1215 is not referenced directly by WLink 1213 because the same model element may be referenced by different link endpoints; for example, one model element may participate in more than one mapping expression. WModelRef 1216 is similar to

WElementRef 1215, but it contains references to the models.

[00123] In the embodiment of Figure 12, WLink 1213 has been extended to include Disjoint Distribution 1231 and Equal Correspondence 1232 to specify the requirements of the target domain for the relations among model elements.

[00124] Weaving AMF and PLM Models into the System Configuration Model. As mentioned before, the model driven approaches increase the level of abstraction and can help to solve the problem of complexity in generating the results as well as reducing the risk of potential errors and inconsistencies. Handling the configuration generation from a higher level of abstraction also increases the maintainability, reusability and extendibility of the solution.

[00125] Figure 13 illustrates a process for generating a system configuration using the model weaving technique according to one embodiment. The first step in this generation process is to create the links between the elements of the input models and the target models. In this example, the input models are an AMF UML profile 1304 and a PLM UML profile 1305, which were defined previously, and the target model is the UML profile of the system configuration 1320. This UML profile for the system configuration 1320 at this stage is a combination (union) of the two source profiles (the AMF and PLM UML profiles 1304 and 1305) without any relation between the elements of the two profiles. The relations will be created with the weaving model (WModel) 1 101. The links and the linked elements are specified based on a weaving metamodel (WMM) 1106 which, according to embodiments of the invention, is an extended version of the core WMM of AMW.

[00126] After the WModel 1101 is created, it is transformed via HOT 1330 to a

transformation model that conforms to a model transformation language; e.g., the ATL, because the WModel 1101 itself is a static representation of the correspondences between the elements and cannot be executed to create the new target model. The mapping specifications in WModel 1101 are independent of the transformation language; any transformation language can be used. In one embodiment, the WModel 1101 resulted from the first step is transformed into an ATL transformation 1340. There is another output model resulted from the generation process called the constraint model 1360. The constraint model 1360 conforms to an OCL metamodel 1350 and is useful for the validation and auto adjustment of the system configuration. The constraint model 1360 may be generated from the HOT 1330 (shown as the arrow AA); or alternatively from the ATL transformation 1340 (shown as the arrow BB). After the WModel 1101 is transformed into an executable transformation format, the final ATL transformation 1340 takes the AMF model 1302 and PLM model 1303 as inputs, and generates the complete system configuration model 1310 with respect to all the relations and constraints (the constraint model 1360) previously defined between the PLM and AMF metamodels (the UML profiles 1304 and 1305). The generated system configuration model 1310 conforms to the generated constraints model 1360 as well as the system configuration profile 1320. The constraints model 1360 completes the system configuration profile 1320, and is used together with the system configuration profile 1320 for validating configuration modification requests at runtime.

[00127] The generation process can be summarized into the following steps:

[00128] First, the core WMM of AMW is extended to support the definition of the special concepts and relations.

[00129] Second, a WModel is created by linking the elements of the AMF, PLM

metamodels (expressed in UML profiles) to the elements of the system configuration metamodel (expressed in UML profile) using the links and link ends from the WMM.

[00130] Third, a HOT (also referred to as the HOT rules) is provided for translating the

WModel into the ATL transformation code. The HOT is itself an ATL transformation model which takes a model (WModel) as the input and transforms it to another transformation. The other output of this step is the constraint model that formalizes the constraints which are applied by the transformation rules implicitly. [00131] Finally, running the ATL transformation with the AMF, PLM models as the input, the system configuration model is generated as the output of the generation process. If there is a request for modifying the system configuration at runtime, the constraint model is used for the configuration validation and auto adjustment purposes.

[00132] Extension of the Core WMM for the System Configuration Generation. Although the implementation of the core WMM in the AMW is designed for two input models (the left model and the right model) and one output model (WModel), the WMM may be modified to support more models as the input and output. A modified version of the core WMM may have three input models: the AMF, PLM and the system UML profiles and the output model is the WModel. In the other words, the WModel defines the relation between the elements of the AMF and PLM metamodels as the left and right models, respectively, to the elements of the system configuration metamodel as the target model. The WMM can also be extended to be more compatible for different applications as in each case some concepts and relations are specifically used in those domains.

[00133] In the core WMM, WLink denotes the link type that can be extended to more specific link types suitable for representing the domain concepts. As an example of extended link types, two relations exist between the entities of the input and output profiles. To represent these relations in the WModel, special link types were added to the core WMM extending the WLink element. Figure 12 illustrates the additional link types to the core WMM 1210 that is represented with the UML notation according to one embodiment.

[00134] Referring to Figure 12, a first link type called "Equal Correspondence" 1231 is a mapping of entities from the AMF and PLM profiles (the left and right models) to the same entities of the system profile (the target model). Because the system profile is the union of the AMF and PLM profiles and extra relations between them, many entities from these profiles are copied to the target model. The Equal Correspondence link 1231 performs this task by simply mapping the equal entities between these models.

[00135] The other link type extending the Wlink of the core WMM is called "Disjoint Distribution" 1232, which aims to abstract the special type of relations between elements of the AMF and PLM profiles and the system profile. More specifically, this link type 1232 is used for describing the concept of the hardware redundancy requirement for redundant software entities explained earlier. This specific relation is originated from one of the domain requirement in the SA Forum architecture. It is about placing redundant software entities of the AMF domain (i.e., AMF SUs) on hardware disjoint EEs of the PLM domain, to make sure that redundant SUs grouped in one SG responsible for providing the same service instance will be placed on separate hardware to avoid single point of failure.

[00136] Creation of the WModel and the HOT. Once the WMM is completed, the WMM can be used to create a WModel that conforms to it. In one embodiment, the core WMM is changed by adding the aforementioned link types 1231 and 1232. Alternatively, the WLink of the core WMM may be extended in such a way that all the link types are defined in the WModel instead of the WMM. In order to do so the AMW plugin can be customized for that purpose. In the WModel, the mapping between the elements of the source (the left and right) and the target models is defined by the links. There can be various types of links that each represents a special kind of relation between the elements of the system. The aforementioned two link types defined in WMM are used to set the mapping between elements of the right/ left model and the target model. The Equal Correspondence link type 1231 is used to define the mapping between those elements of the input model which are exactly the same in the target. An example of using this link type is mapping the "SaAmfSU" element from the AMF Profile (the left model) to the same entity, "SaAmfSU," in the system profile (the target model):

Model SysConfigWeaving

«WLink» Equal Correspondence EQ1

«Left» Equal Element SaAmfSU

«Target» Equal Element SaAmfSU

«WLink» Equal Correspondence EQ2

«Right» Equal Element SaPlmHE

«Target» Equal Element SaPlmHE

[00137] Additionally, the mapping between relevant entities of the models can be defined using the Disjoint Distribution link type 1232 to realize the hardware disjointness concept. This type of relation is used to relate the entities of the two profiles (AMF and PLM profiles) in the system profile. It creates an association between the MagicSaPlmEEVM from the PLM profile and the MagicSaAmfNode from the AMF profile. It satisfies the constraint defined for guarantying that the SUs of the same SG in the AMF configuration that are hosted on the AMF nodes will reside on separate PLM HEs. The Disjoint Distribution link used in the weaving carries this meaning, but as it is merely a static representation of the relation between the entities, it would not be able to perform the calculation of HW-disjoint node groups or the node group selection. These calculations are performed in the next step.

[00138] Once the WModel is completed, it is translated into a model transformation language code such as ATL by using a HOT. The HOT is itself a transformation model (e.g., in ATL) that receives the WModel as input and transforms it to a final transformation (which is also in the ATL format) as output. The HOT has certain rules that translate the WModel and its links into a transformation model and to the respective rules. For instance, an HOT rule which translates the WModel into the module in ATL may be:

rule CreateModule {

from

amw : AMW!Model

to

atl : ATL!Module(

isRefining <- false,

name <- 'FinalTransformation',

inModels <- Set {amw. right, amw. left},

oufModels <- amw.target,

elements <- Set{amw. correspondences},

)

[00139] This HOT rules aims to create the module section in ATL, the inModels, which specifies the input metamodels for the generated transformation {amw. right and amw. left that are the UML profiles of AMF and PLM). The outModel indicates the output metamodel of the final transformation {amw.target that is the UML profile for the system configuration). Finally, the elements of the final transformation are created by transforming the set of correspondences (links) of the weaving model {Setfamw. correspondences}). Each link type and its linkEnds of the WModel are also translated to the elements of the transformation model with HOT rules. For instance, the HOT rule for transforming the Equivalence

Corresponding link of the WModel into a matched rule in the final transformation is:

rule TransformEqualCorrespondenceLink {

from

amw : AMW!EqualCorrespondence

to

atl : ATL!MatchedRule (

name <- amw. name,

isAbstract <- amw.isAbstract,

isRefining <- false,

inPattern <- (if (not amw.left.oclIsUndefined()) then

amw. left

else

amw.Right

endif), oufPattern <- amw. Target,

}

[00140] The above HOT rule creates only the skeleton of the correspondent matched rule in the final transformation. Some other rules in HOT are used to create other elements of the transformation model (e.g., the InPattern, OutPattern elemets).

[00141] The use of the HOT facilitates the abstraction of the transformation process and increase the reusability and maintainability of the transformation process. Thus, when defining a rule in the HOT for transforming a link type from the WModel into a transformation rule (in the final ATL transformation), all the relations mapped by that link type are created as the final transformation rules and there is no need to create the rules individually. The final ATL transformation, which is created as a result of the HOT, can generate the system configuration from the input models (i.e., the AMF and PLM

configuration models).

[00142] Maintaining Configuration Consistency: Configuration Validation and Auto Adjustment. The automatic generation of the system configuration from the fragment configurations of the applications and middleware services is helpful for a configuration designer in a way that it reduces the efforts and also the potential errors that may happen during a manual process. Once the configuration is generated, it will be deployed and different collaborating middleware services can use it. While at runtime, the administrator or the management applications may request to add, modify or delete elements from the configuration. Not all modifications in the system configuration are free of side effects. As explained earlier, there are relations and constraints between the elements of the

configuration fragments that are taken care of during the generation process, but at run time there is no explicit way to check the consistency of the configuration after the modification to make sure that all the constraints are satisfied. The following description presents a systematic approach to solve this problem based on the MDD paradigm. There are already ad-hoc solutions that are either designed for special systems or follow specific program- centric approaches. An example of such systems is the IMM service the of SA Forum middleware. In the FMM service all changes of configuration objects are performed in the context of Configuration Change Bundles (CCB). A CCB may contain a number of change requests which can be creation, deletion, or modification requests. FMM has a CCB validator that performs two types of validation, local and global validation: the local validation consists of the type and constraints checking of an attribute or an object while the global validation consists of making sure that the configuration, as it would appear if all the modifications in the CCB were applied, is consistent and valid.

[00143] In the model driven approach, the constraints that were distinguished and defined during the configuration generation are used for validating the requested modifications at system runtime. The constraints are used for checking consistency of the configuration in case of applying those modifications. In some cases, if the modification requests violate the consistency constraints (constraints between the elements), there might still be a chance to manipulate other parts of the configuration so that it prevents the inconsistency. An auto adjustment engine may be used for performing the required extra modifications to provide the relevant adjustment and keep the configuration valid and consistent. This can be achieved because the rules among the elements of the system are known during the generation process.

[00144] Finding a solution for the mentioned problem not only helps in the configuration management context, but also can be seen as a more general approach in MDD. In other words, when a valid model is generated with predefined rules, the constraints can be extracted from the rules and reused for validating similar models (which may have been created with other methods) or the same model after certain modifications. The constraints created from the generation process specify the interrelation of the elements originating from different input models that cannot be checked without the generated constraints model. These constraints can be added to the target metamodel and/or used in a validator for validating the modifications.

[00145] Capturing the Constraints of the System Configuration. Constraints are important parts of metamodels as they define the rules which cannot be expressed only with the syntax of a modeling language. They cover a vast variety of options that include the restrictions on the value and/or number of attributes of an element, the relationship between the elements or a combination of these restrictions. In this sense they are the rules that govern the

characteristics of the elements of a model and how they can be related to each other.

Negligence in properly defining the constraints results in having a model that have the necessary elements but not in a correct syntax or relation. As the constraints are imposed on models based on the intrinsic characteristics of a domain, specifying the constraints formally for the domain model can guaranty that all the created models are following the same rules.

[00146] As described above, the weaving model contains the links between elements of the input and the output metamodels, and it is used for generating the transformation rules for creating the system configuration model as the target model. The transformation rules are generated by considering the special kind of relations between the elements of the

metamodels. The specialty of relations is due to the constraints that are obeyed in the target model. In other words, the transformation rules are generated based on the constraints existing in the target domain, i.e., the system configuration metamodel. As a result, the created system configuration model adheres to all the constraints. As these constraints are used for the runtime validation and auto adjustment, they can be retrieved while the transformation rules are being defined and collected in another output model. The constraint model 1360 conforms to a metamodel (e.g., the OCL metamodel 1350). [00147] Figure 14 is a diagram illustrating the creation of a transformation model and a constraint model according to one embodiment. The HOT rules 1330 are created from the elements of the weaving metamodel 1106, an ATL metamodel 1412 and the OCL metamodel 1360. The solid arrows represent how the HOT 1330 takes the WModel 1101 as the input, and create an ATL transformation model 1340 and a constraint model 1360 as the output (shown as the arrow AA). Alternatively, the constraint model 1360 may be generated from the ALT transformation model 1340. The ATL transformation model 1340 is used to generate the system configuration model from input models (e.g., AMF and PLM configuration models). The constraint model 1360 later will be used for validation and auto adjustments.

[00148] In one embodiment, the constraints specified in the constraint model 1360 can be categorized into three types that include: (1) constraints of an element that concerns only the attributes of the same element; (2) constraints between the elements of one domain or intra- domain constraints; and (3) constraints between elements of multiple domains or inter- domain constraints.

[00149] Although there is only one domain (that is the system domain) after the

configuration generation, this domain is created by integrating the elements of different domains. Here, the intra and inter domain constraints mean constraints of each input domain and the constraints between the input models, respectively.

[00150] Each of these constraint types can be extracted differently from the HOT 1330 based on the link type specified in the WModel 1101. The first and the second types of the constraints can be obtained from the regular links of the WModel 1101 as they reflect the constraints in a single domain. This consists of the constraints of the input metamodels and also additional constraints that might be needed on those elements in the target model. These constraints can be captured from the filtering option of the transformation rules. Filters in the model transformations that prune the input and only transfer the necessary elements and relations. The third type of constraints are captured from the special links of the weaving. The special links specify the special relation between the elements of multiple domains (the input models). As they were defined when designing the transformation rules, these constraints can be expressed in another format that conforms to a constraint metamodel (e.g., the OCL metamodel 1350).

[00151] Once the constraint model 1360 is created, it can be used for validating the system configuration models, checking the validity of configuration change requests and also proposing actions for preventing the inconsistencies that may be caused by the change requests. [00152] Validation of the Requested Modifications. The system configuration as a runtime model is always exposed to changes and it is important to assure that these changes are not violating the consistency and integrity of the configuration. Modification requests to the configuration might be originated from the administrator or from the management applications, but in both cases there is the possibility that modifying part of the configuration impact other parts. Such side effects can be avoided by careful validation of the change requests before applying them in the configuration. This validation can be categorized in two steps: the first step is about validating the request itself to verify the legitimacy of the changes against the predefined constraints of the configuration, e.g., the type checking or checking if the new values fall in the fixed range of an attribute. The second step of validation deals with the consistency of the changes which means checking the impacts of the requested changes in the whole configuration and not just on the specified elements in the request. The validation rules for both steps are created with respect to the constraints of the system which were previously captured in the constraint model 1360.

[00153] Figure 15 illustrates the validation of modification requests and auto adjustment of a system configuration according to one embodiment. An administrator or the management applications may initiate a configuration modification request which will then be passed to a validator engine (validator 1510). The validator 1510 is responsible for verifying the modification request against the constraints of the system configuration. This means checking if the configuration will still stay valid after applying the requested changes. The validator 1510 first checks the correctness of the request and its legitimacy. If the first checking was successful, the validator starts the second step of validation, otherwise informs the requester about the failure and its reason. The second step of validation is checking the consistency of the configuration in case of applying a requested modification. If the modification does not violate the consistency, it can be applied in the system configuration. Otherwise, the request will not be discarded as the modification might be still possible with some adjustments performed by an auto adjustment engine 1520.

[00154] Auto Adjustment of the Configuration. Auto adjustment of the configuration provides a mechanism for reacting to the changes based on predefined rules and logics. As explained before, the validation of the changes can protect the system from inconsistency but at the same time may be too restrictive in some cases. In one embodiment, the auto adjustment engine 1520 is used to fix the inconsistencies in the system with additional modifications. Figure 15 illustrates a process in which the auto adjustment engine 1520 works in collaboration with the validator 1510 according to one embodiment. The auto adjustment engine 1520 starts its operation when the validator 1510 detects some inconsistency risks in the requested modifications because of consistency violation. The auto adjustment engine 1520 attempts to smooth the hardness of validation process and re-arranges the request such that the request can be applied in the configuration without violating its consistency.

[00155] In other words, when an element (or some of its attributes) in the configuration is subject to change, these changes propagate in the model and affect other elements. Finding the affected elements and the proper treatment for neutralizing the side effects take place based on the constraints existing between the elements and the configuration generation rules. The constraints help to find where the consistency of the configuration is compromised regarding the relation of the elements. After diagnosing parts of the configuration that may become problematic, the auto adjustment engine 1520 recreates those parts of the

configuration by considering the modification request. Configuration generation rules 1540 (e.g., the ATL transformation 1340 of Figure 13) as previously described can be reused for recreating parts of the configuration that are affected by the modification request.

[00156] The above description have presented a model driven framework for the generation, validation and auto adjustment of system configurations. The advantages of the configuration generation system and module include, but are not limited to, the following:

[00157] The modeling framework and the approaches are based on MDD standards such as UML, OCL, model weaving, and ATL which makes the work easier to use, maintain, and extend.

[00158] The special relation is defined between the AMF and PLM configuration models to provide hardware redundancy for redundant software entities of the SA Forum middleware to avoid the single point of failure.

[00159] The special relations are captured between the elements of the input models (the AMF and PLM configurations) and the target model (the system configuration) in a weaving model. The static relations of the weaving model are translated into an executable model transformation format with the help of the HOT. The system configuration can be obtained by executing this final transformation. The HOT helps to increase the abstraction at the transformation level. This means that other models can be added to the integration process using the predefined weaving link types as those link types are already translated in the HOT. The constraint model is another output of the HOT that can be extracted from the rules as the rules implicitly consider these constraints for the generation process.

[00160] Maintenance of the configuration consistency during the system runtime is another important issue addressed with the help of validation and auto adjustment. The requested modifications at runtime are validated against the system constraints (created from the generation process) before applying them, and the modifications are diagnosed to determine whether they endanger the consistency of the configuration or not. The auto adjustment engine adds extra modifications to neutralize the risk of inconsistency. The operation of the auto adjustment engine is performed in two steps: diagnosing the impacted system

configuration elements due to the requested modifications with the help of constraints, and adjusting or recreating those impacted system configuration elements with the help of the generation rules.

[00161] Figure 16 illustrates a method 1600 for generating a system configuration according to an embodiment. In one embodiment, the method 1600 may be executed on a computer system, such as the one illustrated in Figure 18, or on a system 1700 illustrated in Figure 17.

[00162] In one embodiment, the method 1600 begins with the computer system receiving a weaving model as input, wherein the weaving model specifies relations among metamodels of input models and the system configuration to be generated, block 1601; generating transformations for the input models, block 1602; generating constraints for the system configuration, block 1603; and executing the transformations to weave instances of the input models into the system configuration to thereby generate the system configuration obeying the constraints and consistent with the relations specified in the weaving model, block 1604. It is noted that the steps of the method 1600 can be executed in a different order from what is shown in Figure 16, and some of the steps can be executed in parallel. For example, the constraints may be generated during the transformation generation step. Alternatively, the constraints may be generated during the step of executing the transformation.

[00163] Figure 17 illustrates a system 1700 for generating a system configuration according to one embodiment. In one embodiment, the system 1700 comprises a receiver module 1701 adapted to receive a weaving model as input, wherein the weaving model specifies relations among metamodels of input models and the system configuration to be generated; a transformation generation module 1702 adapted to generate transformations for the input models; a constraint generation module 1703 adapted to generate constraints for the system configuration; and an execution module 1704 adapted to execute the transformations to weave instances of the input models into the system configuration to thereby generate the system configuration obeying the constraints and consistent with the relations specified in the weaving model. [00164] Figure 18 illustrates a computer system 1800 within which a set of instructions, for causing the machine to perform any one or more of the methodologies, e.g., methods, steps or logic, discussed herein, may be executed. In one embodiment, the computer system 1800 may be part of a network system, and/or operate in a cloud computing environment where multiple server computers in one or more service centers collectively provide computing services on demand. While only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines (e.g., computers) that individually or jointly execute one or more sets of instructions to perform any one or more of the methodologies discussed herein.

[00165] The computer system 1800 includes a processing device 1802, such as one or more general-purpose processors, each of which can be: a microprocessor, a central processing unit (CPU), a multicore processors, or the like. The processing device 1802 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. In one embodiment, the processing device 1802 is adapted or operative to execute the operations of a configuration generator 1822, which contains instructions executable by the processing device 1802 to perform the method 1600 of Figure 16.

[00166] In one embodiment, the processor device 1802 is coupled to one or more memory devices such as: a main memory 1804 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), etc.), a secondary memory 1818 (e.g., a magnetic data storage device, an optical magnetic data storage device, etc.), and other forms of computer-readable media, which communicate with each other via a bus or interconnect 1830. The memory devices may also include different forms of ROMs, different forms of random access memories (RAMs), static random access memory (SRAM), or any type of media suitable for storing electronic instructions. In one embodiment, the memory devices may store the code and data of the configuration generator 1822, which may be entirely or partially stored in one or more of the locations shown as dotted boxes and labeled by the reference numeral 1822, or in other location(s) not shown in Figure 18.

[00167] The computer system 1800 may further include a network interface device 1808. A part or all of the data and code of the configuration generator 1822 may be transmitted or received over a network 1820 via the network interface device 1808.

[00168] In one embodiment, the computer system 1800 stores code (composed of software instructions) and data using computer-readable media, such as non-transitory tangible computer-readable media (e.g., computer-readable storage media such as magnetic disks; optical disks; read only memory; flash memory). The term "non-transitory computer-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The computer system 1800 may also receive and transmit (internally and/or with other electronic devices over a network) code and data using transitory computer-readable transmission media (e.g., electrical, optical, acoustical or other form of propagated signals).

[00169] In one embodiment, a non-transitory computer-readable medium stores thereon instructions that, when executed on one or more processors of the computer system 1800, cause the computer system 1800 to perform the method 1600 of Figure 16.

[00170] It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. Although the present invention has been described with reference to specific exemplary embodiments, it will be recognized that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

CLAIMS What is claimed is:

1. A method (1600) implemented by a computer system (1800) for generating a system configuration, comprising:

receiving (1601) a weaving model (1101) as input, wherein the weaving model specifies relations among metamodels of input models and the system configuration to be generated;

generating (1602) transformations (1340) for the input models;

generating (1603) constraints (1360) for the system configuration; and

executing (1604) the transformations to weave instances of the input models into the system configuration to thereby generate the system configuration obeying the constraints and consistent with the relations specified in the weaving model.

2. The method of claim 1, further comprising:

applying the constraints to runtime changes to the system configuration to thereby validate the runtime changes.

3. The method of claim 1, further comprising:

identifying, using the constraint, system configuration elements that are impacted by runtime changes and potentially become inconsistent with the relations; and

automatically adjusting the impacted system configuration elements to maintain consistency of the system configuration with the relations.

4. The method of claim 1, wherein the weaving model conforms to a weaving metamodel (1106) that has been extended to include one or more link types (1231, 1232) that specify a requirement for the relations.

5. The method of claim 4, wherein the one or more link types comprises an equal correspondence link type (1232) that specifies a mapping of entities from the input models to same entities of the system configuration.

6. The method of claim 4, wherein the one or more link types comprises a disjoint distribution link type (1231) that specifies a hardware redundancy requirement for placing redundant software entities of one input model onto disjoint hardware entities of another input model.

7. The method of claim 1, wherein the input models includes an Availability

Management Framework (AMF) configuration model and a Platform Management (PLM) configuration model.

8. The method of claim 1, wherein the transformations are generated using Higher Order Transformation (HOT) rules (1330).

9. The method of claim 8, wherein the constraints are generated from the HOT rules.

10. The method of claim 1, wherein the transformations include Atlas Transformation Language (ATL) transformations (1340).

11. The method of claim 10, wherein the constraints are generated from the ATL transformations.

12. The method of claim 1, wherein the constraints include Object Constraint

Language (OCL) constraints.

13. A computer system (1800) for generating a system configuration, comprising:

a memory (1804, 1818);

one or more processors (1802) coupled to the memory, the one or more processors adapted to:

receive a weaving model (1101) as input, wherein the weaving model specifies relations among metamodels of input models and the system configuration to be generated;

generate transformations (1340) for the input models;

generate constraints (1360) for the system configuration; and

execute the transformations to weave instances of the input models into the system configuration to thereby generate the system configuration obeying the constraints and consistent with the relations specified in the weaving model.

14. The system of claim 13, wherein the one or more processors are further adapted to: apply the constraints to runtime changes to the system configuration to thereby validate the runtime changes.

15. The system of claim 13, wherein the one or more processors are further adapted to: identify, using the constraint, system configuration elements that are impacted by runtime changes and potentially become inconsistent with the relations; and

automatically adjust the impacted system configuration elements to maintain consistency of the system configuration with the relations.

16. The system of claim 13, wherein the weaving model conforms to a weaving metamodel (1106) that has been extended to include one or more link types (1231, 1232) that specify a requirement for the relations.

17. The system of claim 16, wherein the one or more link types comprises an equal correspondence link type (1232) that specifies a mapping of entities from the input models to same entities of the system configuration.

18. The system of claim 16, wherein the one or more link types comprises a disjoint distribution link type (1231) that specifies a hardware redundancy requirement for placing redundant software entities of one input model onto disjoint hardware entities of another input model.

19. The system of claim 13, wherein the input models includes an Availability

Management Framework (AMF) configuration model and a Platform Management (PLM) configuration model.

20. The system of claim 13, wherein the transformations are generated using Higher

Order Transformation (HOT) rules (1330).

21. The system of claim 20, wherein the constraints are generated from the HOT rules.

22. The system of claim 13, wherein the transformations include Atlas Transformation

Language (ATL) transformations (1340).

23. The system of claim 22, wherein the constraints are generated from the ATL transformations.

24. The system of claim 13, wherein the constraints include Object Constraint

Language (OCL) constraints.

25. A system (1700) for generating a system configuration, comprising:

a receiver module (1701) adapted to receive a weaving model (1101) as input, wherein the weaving model specifies relations among metamodels of input models and the system configuration to be generated;

a transformation generation module (1702) adapted to generate transformations ( 1340) for the input model s;

a constraint generation module (1703) adapted to generate constraints (1360) for the system configuration; and

an execution module (1704) adapted to execute the transformations to weave instances of the input models into the system configuration to thereby generate the system configuration obeying the constraints and consistent with the relations specified in the weaving model.