A Standard-based and Model-driven Approach for Managing Cloud Applications

In this section, we present our contribution that allows cloud application management by relying on TOSCA and OCCI. First, we give an overview of the proposed architecture and then we present how TOSCA concepts can be mapped to those of OCCI. We also describe how the automated generation of appropriate deployment artifacts can be achieved.

Overview

Our contribution ensures a standard-based approach to handle cloud applications in production environments. An overview of the proposed architecture is shown in Fig. 1. The architecture is composed of three parts: (1) The TOSCA Metamodel that is mapped to the OCCIware Metamodel, (2) the TOSCA Topologies that are mapped to OCCIware Configurations and (3) the OCCI Orchestrator. The TOSCA Metamodel provides an expressive model for cloud applications by relying on an appropriate formalization of TOSCA concepts. The concepts of this model are mapped to OCCIware concepts (cf. Sections 7.2.1 and  7.2.2 for more details). The TOSCA Topologies describe the structure of cloud applications. They instantiate the concepts of the TOSCA metamodel. These topologies are mapped to OCCI configurations that can be designed, edited, validated and deployed as cloud applications. Further information about TOSCA topologies can be found in Section 7.2.3. Finally, OCCI Orchestrator provides means to generate necessary OCCI artifacts and to deploy, via appropriate OCCI requests, the generated artifacts in the executing environment. Every artifact is handled in a seamless way thanks to the homogeneity provided by modeling principles.

To sum up, our approach uses MDE techniques in order to design, verify and deploy cloud applications at a high level of abstraction. In fact, our TOSCA Model describes explicitly concerns of a cloud application that can be instantiated and deployed in an executing environment, i.e., a IaaS Cloud.

Mapping the two standards

While both standards define a metamodel for cloud resources, their focuses are different. The focus of OCCI is to provide a standardized API and it does not define concepts to address reusability, composability, and scalability. Instances of OCCI are not meant to be stored persistently and to be reused later on as it is the goal of TOSCA. TOSCA on the other side does not define how the defined topology is deployed by means of API calls to the cloud provider as it is done with the OCCI HTTP rendering. Hence, both approaches have their strengths and weaknesses and it is worthwhile to investigate how to integrate them. The mapping between the two standards is possible and is done through three stages: (1) mapping of TOSCA normative types to the OCCIware metamodel, (2) mapping of TOSCA custom types to OCCIware mixins and (3) mapping of TOSCA instantiation concepts to OCCIware instantiation concepts. This mapping is proposed after a deep reading and understanding of both TOSCA and OCCI specifications. Each of the mapping stages will be detailed in the following subsections.

to OCCIware metamodel

We base our mapping on the TOSCA YAML specification  that defines the TOSCA normative types, and on the OCCIware metamodel . We chose the TOSCA YAML specification since it has a more concise syntax, is easier to read and is widely adopted by the community comparing to the TOSCA XML specification. TOSCA normative types model several types of components, called nodes, that interact through relationships. In the following, we present the main concepts of TOSCA and how they can be related to OCCI concepts. The entirety of this mapping is presented in Table [table1].

• Entity_type is an abstract concept used to define reusable elements in TOSCA, such as Node_type, Requirement_type, Relationship_type, Policy_type and Capability_type. This matches the purpose of attributes of OCCI Kinds or Mixins. Each Entity_type may have a description field that provides a description of the entity and a derived_from field that defines the parent this new entity derives from. They match the concepts of description and parent in OCCI, respectively. Each Entity_type may also have properties or attributes that define the properties that a certain entity is allowed to have. In our approach, we can map all the elements that inherit from Entity_types, namely Node_types and Relationship_types to OCCI mixins. Their properties become attributes in OCCI.

• Property & Attribute define the properties that a certain Entity_type is allowed to have. This matches the purpose of OCCI Attributes. A property definition should have a type, which matches the DataType concept in OCCI. Constraints can be applied to the attribute type, like the valid_values constraint that limits the property value to values declared in a list, and the greater_or_equal constraint indicating the number of an attribute. For example, CPU that represents a characteristic of an entity, e.g., Compute, is greater_or_equal than 2. These two constraints (valid_values and greater_or _equal) become an EnumerationType declaration and a minInclusive value in OCCI, respectively. A property may have several optional fields, for example the required field that indicates if a property is required or not can be matched to the required concept in OCCI.

• Node_type defines . The node types are separately defined for reusability purpose. In fact, the defined node types can be reused when a developer or an application architect wants to define the topology of a cloud application. Further information about the instantiation of the node types are given in Section 7.2.3. The Node_type concept matches a Mixin applied to a Kind Resource in OCCI. For example,
  tosca.nodes.BlockStorage becomes a mixin applied to Storage kind in OCCI. tosca.nodes.WebServer becomes a mixin that depends on
  tosca.nodes.SoftwareComponent mixin. The latter is in turn applied to Component kind in OCCI.

• Requirement_type defines that a certain
  Node_type requires a certain capability of another Node_type. This is encoded as OCL  constraints in OCCI mixins.

• Capability_type extends an Entity_type with a certain ability, e.g., providing an operating system for a processor or a container for a server. This concept complies to the concept of an OCCI Mixin. For example, tosca.capabilities.OperatingSystem becomes a mixin that represents the operating system of a certain node. It defines information regarding of the operating system such as its type, distribution and version.

• Relationship_type encodes the relationships between the Node_types, e.g., it encodes that a specific application component is deployed on a specific virtual machine. This becomes a Mixin applied to a Kind Link in OCCI. For example, tosca.rel­ationships.AttachesTo becomes a mixin applied to StorageLink in the OCCI Infrastructure extension.

• Data_type defines complex data types of TOSCA properties. This concept matches the OCCIware
  RecordType concept which is used to define structures. For example, NetworkInfo becomes a record type which contains data about the network attribute. Each RecordType has at least one RecordField which represents a field of the record. In our example, networkid and networkname are record fields of the network attribute and expect a string type value.

• Interface_type defines the allowed Operations that can be executed on Node_type or on a Relationship_type. This becomes a Mixin that contains only Actions in OCCI. For example,
  tosca.interfaces.node.lifecycle.Standard becomes a
  mixin that contains information which operations can be performed on a node type, e.g., create, configure and delete.

We can map all the elements that inherit from Entity_types, namely Node_types, Requirement_types, Relationship_types, , Datatype_types, Interface_types and Capability_types to OCCI mixins. However, TOSCA introduces some additional concepts, such as Group_types, , and Artifact_types, that have no one-to-one correspondents in OCCI. This issue is out of the scope of this article.

TOSCA custom types to OCCIware mixins

The TOSCA specification defines basic root types called TOSCA normative types. These are default types for describing the cloud infrastructure and application. We showed in Section 7.2.1 how we mapped these concepts to the OCCIware metamodel. However, most of the application components are not part of the normative types but extend the TOSCA normative types. These are the custom types. They are defined in several YAML files that are scattered over the internet in GitHub repositories. In fact, during our study, we observed that the community around TOSCA is quite active. Several projects, such as Alien4Cloud¹, Cloudify², CELAR³, SeaClouds⁴, DICER⁵ and INDIGO-DataCloud⁶ have raised. Each project has been defining new TOSCA custom types or modifying existing types according to its need. In fact, there is no centralized repository for all these types, which leads to an inconsistent use of TOSCA types across organizations. For example,tosca.nodes.Mysql⁷ and tosca.nodes.Database.
MySQL⁸, tosca.Rsyslog⁹ and tosca.nodes.
SoftwareComponent.Rsyslog¹⁰ are two couples of redundant node types that are semantically equivalent but differently defined. In our approach, we collected 30 custom TOSCA types defined in TOSCA projects and mapped them and exhaustively to OCCIware mixins.

By mapping TOSCA normative types, defined in the YAML specification, and the diverse added custom types, to those of OCCIware metamodel, we designed a TOSCA Model which conforms to the OCCIware metamodel.

TOSCA instantiation concepts to OCCIware instantiation concepts

The TOSCA specification allows the definition of a cloud application by reusing a set of nodes that are connected to other nodes using relationships. For the definition of provisionable elements, TOSCA defines some ready-to-use topologies that represent popular cloud applications and describe their deployment. A topology is a composition of multiple nodes that may be connected through relationships. Hence, topologies use the concepts of Entity_templates, namely Node_templates, Relationship_templates and Group_templates. We explain in the following, how TOSCA topologies can be mapped to OCCIware configurations and we provide a summary in Table 2.

• A Topology_template defines a reusable and
  portable representation of the structure of an application to facilitate understanding of its functional components and eliminating unnecessary details. It consists of a set of Node_templates and Relationship_templates. Each Topology_template is mapped into a Configuration in OCCI.

• A Node_template specifies the occurrence of a node in a topology template. Each Node_template refers to a Node_type and instantiates the semantics of its properties, attributes, requirements, capabilities and interfaces. It gets to be transformed into a Resource with a MixinBase in an OCCI Configuration. A MixinBase refers to a Mixin and instantiates the attributes of the referenced mixin outside the owner entity in order to separate the entity attributes from the mixin ones.

• A Relationship_template specifies the occurrence of a relationship between nodes in a topology template. Each Relationship_template refers to a Relationship_type and instantiates the semantics of its properties, attributes, interfaces, etc. It can be transformed into a Link with a MixinBase in an OCCI Configuration.

• A Group_template defines a group of nodes that share some semantics, e.g. an autoscaling group is a group of VMs that would be scaled together. It can be transformed into a number of Resources and Links in OCCI.

The mapping detailed above is used to propose a fully model-driven cloud orchestrator which we define in the next subsection.

Model-driven cloud orchestration

To deploy the cloud application specified in the TOSCA topology, we use a combined approach of TOSCA and OCCI, as shown in Fig. 1. By utilizing both standards we benefit from their individual advantages while neglecting their drawbacks. Namely the matured design time capabilities of TOSCA topologies combined with the uniform interface provided by OCCI allowing to instantiate the desired cloud application . Based on the modeled TOSCA topology, an OCCI PIM is generated, i.e., a (PIM) OCCIware Configuration. The resulting configuration, containing the modeled TOSCA resources as OCCI elements, then serves as input for the OCCI Orchestration process initially described in . In general, the concept resembles a models@run.time approach  which derives imperative steps from a declarative description in order to adapt the running system.

, a PSM is generated from the (PIM) OCCIware Configuration that contains all information required for deployment. To generate (PSM) OCCIware Configuration, a M2M transformation is applied that can be configured to add