MODACloudML development Initial version

Transcription

1 Grant Agreement N FP Title: Authors: Editor: Reviewers: Identifier: Nature: MODACloudML development Initial version Marcos Almeida (SOFTEAM), Danilo Ardagna (POLIMI), Elisabetta Di Nitto (POLIMI), Nicolas Ferry (SINTEF), Santo Lombardo (POLIMI,) Majid Shokrolai (POLIMI), Arnor Solberg (SINTEF) Nicolas Ferry (SINTEF) Victor Muntés-Mulero (CA) and Victor Munteanu (IeAT) Report Version: 1 Date: 30/9/13 Status: Diss. level: Final Public Executive Summary This deliverable presents the initial version of the MODACloudML languages and models. This version of the language focuses on the IaaS level and relies on the MODAClouds model-driven approach which defines three layer of abstraction: the Cloud-enabled computational Independent Model (CCIM), the Cloud Provider- Independent Model (CPIM), and the Cloud Provider-Specific Model (CPSM). The modelling concepts and metamodels of each of the models with a functional perspective defined at these various layers of abstraction are detailed and illustrated with the OFBiz use case. Copyright 2012 by the MODAClouds consortium All rights reserved. The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/ ] under grant agreement n (MODAClouds).

2 Members of the MODAClouds consortium: Politecnico di Milano Stiftelsen Sintef Institute E-Austria Timisoara Imperial College of Science, Technology and Medicine SOFTEAM Siemens Program and System Engineering BOC Information Systems GMBH Flexiant Limited ATOS Spain S.A. CA Technologies Development Spain S.A. Italy Norway Romania United Kingdom France Romania Austria United Kingdom Spain Spain Published MODAClouds documents These documents are all available from the project website located at Public Final version 1.0, dated 30/9/2013 2

3 Contents 1 INTRODUCTION CONTEXT AND OBJECTIVES STRUCTURE OF THE DOCUMENT THE OFBIZ USE CASE MODACLOUDML OVERVIEW OVERALL ARCHITECTURE MODACLOUDML MODELS IN A NUTSHELL SUPPORT THE MODELING Tools Resource model as a catalogue of Deployable artefacts and cloud patterns MODACLOUDML MODELS THE CLOUD-ENABLED COMPUTATION INDEPENDENT MODELS Business Requirements QoS Requirements Service Definition Service Orchestration Usage Model Service Implementation Data Model THE CLOUD PROVIDER-INDEPENDENT MODELS Design alternatives and deployment model Data model THE CLOUD PROVIDER-SPECIFIC MODELS Design Alternatives and Deployment Model Data model CONCLUSION AND ROADMAP BIBLIOGRAPHY Public Final Version 1.0, dated 30/9/2013 3

4 Table of Figures Figure 1. Dependencies between OFBiz components [3]... 7 Figure 2. Refinement of the OMG MDA... 8 Figure 3. Models presented in this deliverable... 9 Figure 4. CPIM (Cyan: services, Yellow: free quotas and costs, Orange: elements, Purple: scaling policies, Green: provider) Figure 5. CPIM (Purple: resources, Green: platforms, Cyan: softwares, Yellow: locations) Figure 6. CPIM-IaaS (Cyan: virtual HW, Yellow: links and costs, Purple: profiles, Green: compute resource) Figure 7. AWS CPSM - EC2 Micro Instance Details (yellow: CPIM classes, cyan: CPSM classes) Figure 8. AWS CPSM - EC2 (yellow: CPIM classes, cyan: CPSM classes) Figure 9. AWS CPSM - DynamoDB and RDS (yellow: CPIM classes, cyan: CPSM classes) Figure 10. AWS CPSM - RDS Instance (yellow: CPIM classes, cyan: CPSM classes) Figure 11. AWS CPSM - EBS and S3 Overview (yellow: CPIM classes, cyan: CPSM classes) Figure 12. Legend of the UML diagrams presented in this section Figure 13. CCIM overview Figure 14. Package structure of the CCIM metamodel Figure 15. Business requirements overview Figure 16. Requirement diagram example Figure 17. Service definition overview Figure 18. Service definition example Figure 19. Service orchestration overview Figure 20. Example static view of orchestration Figure 21. Business process example Figure 22. Example of usage model Figure 23. Service implementation overview Figure 24. The TOGAF notation Figure 25. Service implementation example Figure 26 Data model overview Figure 27 Data model example (Budget) Figure 28 Data model example (Payment) Figure 29. Type part of the DSML metamodel Figure 30. Instance part of the DSML metamodel Figure 31. Life-cycle of an artefact Figure 32. Life-cycle of a node Figure 33 OfBiz GDM example (Payment) Figure 34 GDM XSD datamodel Figure 35 OfBiz HDM 1 example (Payment) Figure 36 OfBiz HDM 2 example (Payment) Figure 37 HDM XSD datamodel Figure 38 OfBiz FDM example (Payment) Figure 39 FDM XSD datamodel Figure 40. Instance part of the deployment model at the CPSM level Figure 41 SimpleDB data model Figure 42 HBase datamodel Figure 43 MongoDB datamodel Public Final version 1.0, dated 30/9/2013 4

5 Public Final Version 1.0, dated 30/9/2013 5

6 1 Introduction 1.1 Context and Objectives Cloud computing is a computing model enabling ubiquitous network access to a shared and virtualized pool of computing capabilities (e.g., network, storage, processing, and memory) that can be rapidly provisioned with minimal management effort [1]. Cloud solutions are highly heterogeneous and the provided features are often incompatible. This diversity hinders the exploitation of the full potential of cloud computing by increasing the complexity of development and administration of multi-cloud systems. As highlighted by D4.1.1, stacks, libraries and frameworks lack in software engineering methodologies and tools to design, deploy and maintain multi-cloud systems. The MODACloudML platform proposes to address this challenge. The MODACloudML platform relies on a model-driven approach developed as a Domain-Specific Language (DSL) for the design and execution of applications on multiple clouds. Model-driven engineering is a branch of software engineering, which aims at improving the productivity, quality and cost-effectiveness of software development by shifting the paradigm from code-centric to model-centric. Models and modelling languages, as the main artefacts of the development process, enable developers to work at a higher level of abstraction focusing on cloud concerns rather than implementation details. Model transformation, as the primary technique to generate (parts of) software systems, restrains developers from repetitive and error-prone tasks such as coding. This approach, which is commonly summarized as model once, generate anywhere, is particularly relevant when it comes to design and management of applications across multiple clouds, as well as migrating them from one cloud to another. The model-driven engineering approach adopted by the MODACloudML platform allows the developers to build the system at various levels of abstraction. The three envisioned levels are: (i) the Cloudenabled Computation Independent Model (CCIM) to describe an application and its data, (ii) the Cloud-Provider Independent Model (CPIM) to describe cloud concerns related to the application in a cloud-agnostic way, and (iii) the Cloud-Provider Specific Model (CPSM) to describe the cloud concerns needed to deploy and provision the application on a specific cloud. This document presents the initial version of the MODACloudML language and the models used at these various abstraction layers. For this version of the MODACloudML language and models we focus mainly on the IaaS level, with the exception of the part of the language dedicated to data that also focuses on PaaS. The modelling concepts and the metamodels of each of them are detailed and illustrated with the OFBiz use case, which will be part of the M12 demonstration. 1.2 Structure of the Document The remainder of the document is organized as follows. Section 2 presents the OFBiz application, which will be used as a use case throughout this whole deliverable. Section 3 introduces the overall architecture of MODACloudML including a brief outline of all its models. Section 4 details the models including the CIM, CPIM and CPSM levels. For each of them, their metamodel is introduced and then their main concepts are illustrated with respect to our use case. Finally, Section 5 presents the roadmap for the future MODACloudML development. Public Final version 1.0, dated 30/9/2013 6

7 2 The OFBiz use case In order to illustrate our modelling concepts we will use OFBiz as our main use case throughout this document. Indeed, OFBiz can be deployed at the IaaS level and is distributed with a demo setup deployed in a real production environment which is representative of real business applications. Apache Open For Business (OFBiz) is a framework distributed under the Apache 2.0 license that offers a fully developed Enterprise Resource and Planning (ERP) and Customer Relationship Management (CRM) systems for the rapid development of business applications [2]. The main OFBiz's components and their dependencies are depicted in Figure 1. Figure 1. Dependencies between OFBiz components [3] OFBiz offers the following services: an e-commerce application, a customer service, a company portal, an ordering manager, a project manager, a human resource manager, a manufacturing component, and a marketing application. OFBiz is available as a standalone application which includes a database, a Tomcat application server, and an Apache web server. Sample data are also available to easily test the system with dummy customers, products, etc. As illustrated in Figure 1, in order to maintain and manage OFBiz, a framework is offered which relies on several components such as: The entity engine to easily specify the database to be used (e.g., MySQL, Derby, PostgreSQL). This engine also set up the tables' definition when the database is empty. The service engine to support service oriented architectures including a background execution system. Form widgets to easily reuse HTML forms. Security engine to manage screen authentication and users and group permissions. Statistical and log mechanisms to log activities within the system Public Final Version 1.0, dated 30/9/2013 7

8 3 MODACloudML Overview MODACloudML is supported by the MODAClouds IDE (see D4.3.1 [10]), more precisely it provides the functional, operational and data modelling environments as well as some modules enabling the analysis of nonfunctional characteristics of a multi-cloud system (see D5.2.1 [11]). This section presents an overview of the MODACloudML approach and architecture. First, we introduce the model-driven architecture and secondly we briefly acquaint all the models that can be manipulated within the MODACloudML environment. 3.1 Overall architecture The MODACloudML architecture is inspired by the OMG Model-Driven Architecture (MDA) [4], which is a model-based approach for the development of software systems. The MDA relies on three types of models for three layers of abstractions. The closer to the system a layer is, the more technical the description. These three MDA layers, from the more abstract to the more detailed, are: The Computational Independent Model (CIM), which describes what the system is expected to do but hides all the technical details related to the implementation of the system. The Platform Independent Model (PIM), which describes views of the systems in a platform independent manner so that it can be mapped to several platforms at the PSM levels. The Platform Specific Model (PSM), which refines the PIM with technical details required for specifying how the system can use a specific platform. Some of the main benefits of the MDA are to facilitate the portability, interoperability and reusability of parts of the system which can be easily moved from one platform to another, as well as the maintenance of the system through human readable and reusable specifications at various levels of abstraction. From the cloud perspective, the introduction of a new layer of abstraction improves the portability and reusability of cloud related concerns amongst several clouds. Indeed, even if the system is designed for a specific platform including framework, middleware, or cloud services, these entities often rely on similar concepts, which can be abstracted from the specificities of each cloud provider. Typically, the topology of the system in the cloud as well as the minimum hardware resources required to run it (e.g., CPU, RAM) can be defined in a cloud-agnostic way. Thanks to this new abstraction layer, one can map a platform specific model to one or more cloud providers. Figure 2. Refinement of the OMG MDA Public Final version 1.0, dated 30/9/2013 8

9 Accordingly, the MODACloudML architecture (see Figure 2) refines the PSM abstraction layer by dividing it into two sub-levels: the Cloud Provider-Independent Models (CPIM) level and the Cloud Provider- Specific Models (CPSM) level. At the higher level of abstraction, the CPIM includes cloud concepts that are independent of any cloud provider. A CPIM can then be refined with cloud provider-specific details to specify how to run the system on this specific cloud. From a cloud perspective, both the CIM and the PIM layers which represent an application independently from the underlying hardware architecture can be grouped under Cloud-enabled Computational Independent Models (CCIM). In the rest of this document we will refer to CCIM as the Cloud-enabled Computational Independent Model. Each of these layers can embed several models for the functional, operational and data modelling concerns addressed by MODACloudML. 3.2 MODACloudML models in a nutshell In this subsection, we present for each layer of the architecture an overview of the various models that can be manipulated within the MODACloudML environment. Figure 3 depicts the distribution of the models to be defined within WP4 across our three layers of abstraction. The models manipulated by the MODACloudML IDE are grouped within the dashed box. The models out of the box can be used to support their specifications. Figure 3. Models presented in this deliverable The list of models defined in WP4 to be manipulated within the MODAClouds IDE is the following: CCIM models: Requirements Model: completes and formalizes the service functional description. Business and QoS requirements specified according to the metamodels described in D5.2.1 [11] can be associated with a Service or with a specific service operation. Service Definition Model: describes the software to be developed as a set of components or services. It includes the typical constructs needed for describing the structure of a software system and can be mapped into the model used within WP5 related to non-functional concerns (see MODAClouds deliverable D5.2.1 [11]). Data Model: describes the main data structures associated with the software to be. It can be expressed in terms of typical ER diagrams and enriched by a metamodel that specifies functional and nonfunctional data properties. Usage Model: specifies the way users are expected to exploit the functionality of the software to be. It will consider at least a 24 hours time-horizon. Each single point in time of the usage model can be Public Final Version 1.0, dated 30/9/2013 9

10 mapped into the usage model used in WP5 (see MODAClouds deliverable D5.2.1 [11] regarding the search for optimal solutions). Service Orchestration: describes the behaviour of the glue between components and services. It can be annotated with stochastic information used to express the probability for some behavioural path to be followed. With such an extension it can be mapped to the models defined within WP5 (see MODAClouds deliverable D5.2.1 [11]). CPIM models: Design Alternative and Deployment Model: describe the assignment of application components to underlying resources and the design alternatives and constraints that will drive the search of optimal solutions performed by design time exploration tools (see MODAClouds deliverable D5.2.1 [11]). Data Model: describes data model in terms of logical models as flat model, hierarchical model and relational model. CPSM models: Design Alternative and Deployment Model: as at the CPIM level, describes the assignment of application components to underlying resources and the design alternatives and constraints that will drive the search of optimal solutions performed by design time exploration tools that depend on the characteristics of the cloud resources of a specific Cloud Provider (see the MODAClouds deliverable D5.2.1 [11]). Data Model: describes the data model based on the specific data structures implemented by the Cloud providers. For the sake of completeness, we briefly introduce here the other models, whose metamodel are not defined in this deliverable, which can be manipulated by the MODAClouds IDE. These models can be defined at both CPIM and CPSM levels: Monitoring rules: describe monitoring rules aiming at controlling the execution of specific application components/data/connectors assigned to specific resources (see D5.2.1 [11]) QoS Model: includes information concerning QoS characteristics of cloud resources. It includes cost information thus offering the possibility to estimate an upper-bound for application costs (see D5.2.1 [11]). This overall set of models is a refinement of the initial one presented in D3.2.1 [9]. The following changes have been made: (i) at the CCIM level, the application and service behaviour and the application and service architecture models are refined with our service-oriented approach into service definition and service orchestration models; (ii) at both CPIM and CPSM levels, the allocation model and the design alternative and architectural constraints models have been grouped into a single model called the design alternative and deployment model since both were related to the deployment of an application on the cloud. 3.3 Support the modeling All these models are supported by the MODACloudML IDE as well as by specific tools. These tools are responsible for manipulating the models and for making operational the semantic related to their concepts. In addition, resources models have been defined by analysing the most common patterns in cloud systems. The specifications of these resources and patterns together with well-known patterns such as the three levels (i.e., IaaS, PaaS, SaaS) of cloud solutions or from [5] ease the specification of models involving cloud concepts. In the next sections we briefly present the tools associated to the models we will detail in this deliverable (for a detailed presentation please refer to D3.2.1 [9] and D4.3.1 [10]) and describe the resource model Tools The CCIM models which define what the system is expected to do but hide the cloud-related concerns. They are supported by the Functional Modeling Environment (see D4.3.1) and propose to use state of the practice tools and methods to describe the applications that are to be deployed in the cloud. Public Final version 1.0, dated 30/9/

11 The CPIM and CPSM models which propose a new way to describe the deployment, provisioning and data models of multi-cloud systems can also be edited by the Functional Modeling Environment. The CloudML DSML developed in collaboration between MODAClouds and PaaSage is part of MODACloudML and is used to specified design alternatives and deployment models. Specific tools are then responsible for the operational semantic associated to the models. More precisely, the deployment and provisioning tool is a specific tool supporting design alternative and deployment models whilst the data mapping tool provides the support for the data models. More details about these tools are provided in D4.3.1 [10] and D3.2.1 [9] Resource model as a catalogue of Deployable artefacts and cloud patterns In addition to these MODACloudML models, a general model representing a cloud environment can be used as a catalogue of available resources and classical cloud patterns. This catalogue is particularly useful as a basis for the specification of cloud-related models (both CPIM and CPSM). It will be used in order to evaluate performance and cost of application as proposed by the decision making and analysis tools as well as during the selection of the resource (storage or computational resources) to be used by a multi-cloud system. As discussed in Section 3.1, the resource model at the CPIM level described in Figure 4 abstracts and describes cloud resources in a cloud provider independent way. It has been obtained by analysing the most common cloud systems and is described in Section The resource model at the CPSM level and some examples of mapping of CPIM concepts to specific cloud provider concepts is discussed in Section Resource model-cpim At the CPIM level the goal of the resource model presented in Figure 4 is to represent a pattern of the general structure of a cloud environment, without expressing in detail the features of cloud services offered by the available cloud providers. Public Final Version 1.0, dated 30/9/

12 Figure 4. CPIM (Cyan: services, Yellow: free quotas and costs, Orange: elements, Purple: scaling policies, Green: provider). A cloud system is always owned by a Cloud Provider that is a specialization of the general abstract concept of Provider (see Figure 4). Typically, a Cloud Provider offers to the end users several Cloud Services. A Cloud Service can be classified into three main classes: IaaS-Service, PaaS-Service and SaaS-Service. An IaaS-Service is composed of one or more Cloud Resources, while a PaaS-Service is composed of one or more Cloud Platforms and, similarly, a SaaS-Service is composed of one or more Cloud Softwares. Cloud Softwares can either be deployed on Cloud Platforms or run directly on Cloud Resources (i.e., resources of the infrastructure layer) without any middleware platform or even run on a pool of computing resources. A Cloud Element represents either a Cloud Resource, a Cloud Platform or a Cloud Software, and can be characterized by a Cost Profile (see D5.2.1 [11] for further details). A Cloud Service can also have Scaling Policies, which are composed by Scaling Rules describing the metric of interest, the threshold value and the activation rule. Usually, two types of Scaling Rules need to be defined in a real system: one to perform a scale-in (i.e., removing an instance from the pool) and another to perform a scale- Public Final version 1.0, dated 30/9/

13 out (i.e., adding an instance to the pool). The Scaling Policy itself is associated to one or more Resource Pools, which aggregate one or more homogeneous Compute resources, which are Cloud Resources (see Figure 5). So at the end, a Scaling Policy is defined on a set of homogeneous Compute resources. Figure 5 represents other features of Cloud Resources, Cloud Platforms and Cloud Softwares. Figure 5. CPIM (Purple: resources, Green: platforms, Cyan: softwares, Yellow: locations) For some Cloud Resources it is possible to define a Location (expressed in terms of Region, Sub Region and Virtual Area), which specifies where is located the hardware infrastructure providing the cloud resources. A Cloud Resource represents the minimal resource unit of a given Cloud Service and can be classified into Compute or Cloud Storage. A Compute unit represents a general computational resource, like a Virtual Machine (VM). A Cloud Storage unit is a resource able to store any kind of unstructured or structured data and it can be classified into Filesystem Storage or Blob Storage. A Filesystem Storage is a storage unit based on a file system, so it contains files and folders organized in a hierarchical structure. Virtual Hard Disks (VHDs) are concrete examples of Filesystem Storage units. A Blob Storage is a storage unit based on a flat structure composed by data containers. A Cloud Platform is a software framework exposing a defined Application Programming Interface (API) that can be used to develop custom applications and services. The platform also provides an execution environment for such custom applications and services. A Cloud Platform always runs on at least one Cloud Resource. Frontend, Middleware, Backend and Database platforms are three possible specializations of a Cloud Platform. Frontend platforms can host frontend services, which are directly exposed to the end users and are supposed to interact with them providing data to backend services. Backend platforms can host backend services, which are hidden to the end users and are supposed to process data coming from frontend services eventually providing them some intermediate results. Middleware platforms can host services like message queues or task queues, which are used to decouple Frontend instances from Backend instances. A Database platform (DB) is able to store structured or semi-structured data and can be classified into Relational DB or NoSQL DB. A Relational DB is a database platform based on the relational model, so database entries are organized into tables and can be accessed and manipulated through relational query languages. A NoSQL DB is a database platform based on a distributed architecture, into which data is not required to have a relational structure. Furthermore, these databases use query languages different from SQL and they cannot guarantee all the ACID properties (Atomicity, Consistency, Isolation, Durability). Databases are considered as cloud platforms because they Public Final Version 1.0, dated 30/9/

14 provide interfaces to access structured or semi-structured data and can be configured by the user, but it is not possible to control their underlying infrastructure (IaaS level). A Cloud Software is an application or a service that can be deployed on Cloud Platforms or can run directly on Compute Resources. A Cloud Software can be provided by a Cloud Provider within its offered SaaS or can be provided by an Application Service Provider who uses the Cloud Platforms or directly the Cloud Resources offered by a Cloud Provider. Finally, a Cloud Software can be possibly classified into REST Software or SOAP Software, like stateless or statefull services, depending on whether it is a REST-based or a SOAP-based software. Figure 6 shows detailed features of a Cloud Resource that is a particular Cloud Element and a Cloud Element can be tied to one or more Cloud Elements through point-to-point Links in order to create a virtual network of Cloud Elements. Figure 6. CPIM-IaaS (Cyan: virtual HW, Yellow: links and costs, Purple: profiles, Green: compute resource). A Resource Pool is a set of Compute Cloud Resources associated to an Allocation Profile, which is a set of Allocations specifying how the number of allocated instances within the Resource Pool changes in a certain reference period Resource model-cpsm A resource model at the CPSM level can be thought as a particular instance of resource model at the CPIM level representing the features of cloud services offered by a particular cloud provider. In this section we will present one example of Cloud Provider Specific Model referred to Amazon Web Services (AWS) 1. Considering the Amazon cloud, we can distinguish some relevant IaaS services like: Elastic Compute Cloud (EC2), Simple Storage Service (S3), Elastic Block Store (EBS), Relational Database Service (RDS) and the NoSQL database DynamoDB. Amazon itself can be considered as a realization of the Cloud Provider concept within the CPIM. Since a Cloud Provider offers one or more Cloud Services, we can extend the relation provides 1 aws.amazon.com Public Final version 1.0, dated 30/9/

15 to all the aforementioned cloud services. Some of them can be classified as IaaS-Services, like EC2, S3 and EBS; the others (RDS and DynamoDB) can be classified as PaaS-Services. Considering that S3 provides storage with a flat file system, an S3 Instance is a realization of the Blob Storage of the CPIM. As far as Amazon S3 is concerned, we can define a Cost Profile for that type of instances representing the cost variability. This is compulsory because the S3 service is charged on the base of different price ranges, depending on the allocated capacity. EBS, instead, provides volumes with standard file systems, so an EBS Instance is a realization of the File system Storage. Finally, Amazon EC2 provides a set of EC2 Instances, each of which is a realization of a Compute Cloud Resource. EC2 Instances are characterized by different EC2 Prices which are essentially Costs from the CPIM. Within EC2 it is possible to specify EC2 Auto Scaling Groups which are sets of homogeneous EC2 Instances and can be referred to the Resource Pools defined within the CPIM. Besides, EC2 Scaling Policies can be defined on these EC2 Auto Scaling Groups in order to set the rules controlling the scaling activities. An EC2 Scaling Policy derives from a generic Scaling Policy of the CPIM. For an EC2 instance it is possible to specify the Location in order to control reliability and delays. Figure 7 exemplifies the modeling of an EC2 Micro Instance, showing also the relation with the SubRegion and Region of the CPIM. Amazon instances do not provide any permanent local storage, so they usually use an external EBS Volume. Figure 7. AWS CPSM - EC2 Micro Instance Details (yellow: CPIM classes, cyan: CPSM classes) Within EC2, it is possible to define Virtual Areas (EC2 Micro Availability Zone) within sub-regions and to associate EC2 instances to them. The Figure shows also other features of EC2, such as the possibility to define Resource Pools (EC2 Micro Auto Scaling Group) composed by EC2 instances with the same configurations. It is also possible to associate to these pools Allocation Profiles (EC2 Micro Allocation Profile) which specify how many instances of a given type are allocated in a given time period. At the time of writing, Amazon provides 17 different instance types. Figure 8 shows the partial CPSM associated to EC2 (only a few EC2 instance types are represented and details about CPU and memory are omitted for simplicity). Public Final Version 1.0, dated 30/9/

16 Figure 8. AWS CPSM - EC2 (yellow: CPIM classes, cyan: CPSM classes) Figure 9 and Figure 10 show an overview of the CPSM representations of DynamoDB and RDS (only few RDS instance types are represented). Considering the RDS, it is a PaaS Cloud Service composed of one or more RDS Instances, each of which represents a Relational DB, which in turn is a Database Cloud Resource. The diagram in Figure 9 shows also some realizations of an RDS Instance, such as the RDS Micro DB Instance, the RDS Small DB Instance and the RDS Large DB Instance. An RDS Instance is composed by a Compute instance executing the RDBMS (MicroDBInstance, SmallDBInstance, LargeDBInstance) and a Cloud Storage providing the needed storage capacity (RDS_Storage). Public Final version 1.0, dated 30/9/

17 Figure 9. AWS CPSM - DynamoDB and RDS (yellow: CPIM classes, cyan: CPSM classes) Public Final Version 1.0, dated 30/9/

18 Figure 10. AWS CPSM - RDS Instance (yellow: CPIM classes, cyan: CPSM classes) For what concerns storage services, S3 and EBS are composed of S3 Instances and EBS Instances respectively (see Figure 11). Considering that S3 provides storage with a flat file system, an S3 Instance is a realization of a Blob Storage, which, in turn, is a Cloud Storage and then a Cloud Resource. Public Final version 1.0, dated 30/9/

19 Figure 11. AWS CPSM - EBS and S3 Overview (yellow: CPIM classes, cyan: CPSM classes) These resource models are particularly relevant for the analysis of non-functional characteristics as well as to help the cloud application developer and the cloud application provider in designing, optimizing and deploying a multi-cloud system. Indeed, they provide a description of the resources available and the relationship between them. 4 MODACloudML Models In this section we detail the various MODACloudML models. We introduce their metamodels and exemplify them with the OFBiz use case. 4.1 The Cloud-enabled Computation Independent Models We present in this section the main concept of the CCIMs, for an exhaustive description of the abstract syntax please refer to Appendix A. Figure 12 introduces the legend of the UML diagrams presented in this section. The orange classes represent MODACloudML metaclasses whilst the blue classes represent metaclasses imported from UML. Figure 12. Legend of the UML diagrams presented in this section Public Final Version 1.0, dated 30/9/

20 At the CIM level, we describe an application as a set of high level services following a Service Oriented Architecture (SOA) [6]. SOA is an architectural style for building enterprise solutions based on business services. The application is presented as a set of business-aligned reusable services (represented by the Service meta-class) that can be combined into high level business processes and solutions within the context of an enterprise. Figure 13. CCIM overview As depicted in Figure 13, a CCIM is composed of three main concepts: a set of services, an orchestration and a set of usage models. A service is composed by a service description (textual and requirements based), a set of provided and required interfaces, the definition of the data exchanged with other services and an implementation (of the provided interfaces and exchanged data). An orchestration defines the interactions between services. It should contain behavioural and structural models defining how services cooperate. A usage model defines the interaction with the external environment (typically the users of the application) with the services. The CCIM metamodel relies on the package structure described in Figure 14. The CCIM package is divided into seven sub-packages: Business Requirements, Service Definition, Data Model, Service Orchestration, Usage Model and Service Implementation. Public Final version 1.0, dated 30/9/

21 Figure 14. Package structure of the CCIM metamodel In the next subsections we detail the concepts involved in these packages Business Requirements The Business Requirements package is based on the requirements metamodel of the Analyst Module provided by Modelio. The rationale for this is to reuse in MODAClouds the existing support to requirements traceability analysis and document generation provided by Modelio. As depicted in Figure 15, this metamodel contains the following concepts: Business Requirements, Requirement Containers, and Business Requirements which can be associated to the model elements that implement them. Public Final Version 1.0, dated 30/9/

22 Figure 15. Business requirements overview A Business Requirement describes a functional requirement to be fulfilled by the application and may belong to a Business Requirement Container. A Business Requirement Container defines a hierarchy that breaks down the requirement model. It may contain other business requirement containers or business requirements as depicted by the owner association. Business Requirements are grouped into containers and implemented by elements in the MODACloudML Model as depicted by the implemented association. Both containers and elements contain a textual description. A Business Requirement Element is an abstract entity in a model describing the composition relation between Business Requirement Containers and other Business Requirement Elements. It textually describes a requirement or a requirement container in a model. Figure 16 illustrates a Business Requirements Container called "Accounting Requirements". It should contain the subset of requirements of the OFBiz application that are related to its accounting subsystem. Figure 16. Requirement diagram example This requirement container includes a business requirement stating that the system should allow comments to be added to budget specifications. The link between the inheritance relationship between the "Budget" and the CommentedElement entities and the "Budgets have comments" requirement states that this relationship satisfies the requirement. Public Final version 1.0, dated 30/9/

23 4.1.2 QoS Requirements For more details on the QoS requirements metamodel at the CCIM level, please refer to D2.2 [12] Service Definition A service definition (see Figure 17) is based on UML Components to define the top-level components of an application and the interfaces they require or provide. Figure 17. Service definition overview In the context of cloud-based applications, we define a service as a particular software system that can be published, located and invoked across the internet. Services are usually exposed as a Web service, but other publishing methods and protocols are acceptable. These pieces of information are part of the CPIM and CPSM models. A Service is considered as a black box who exposes public interfaces and that can be associated with a set of functional and non-functional requirements. A Service Description contains a high-level description of the features offered by the service. It also contains a list of functional and non-functional requirements to be implemented by the service. The Service Implementation class associated to a service describes the Public Final Version 1.0, dated 30/9/

24 implementation of the interfaces provided by this service. The requirement to be implemented by the service is described in the Requirement abstract class. The Exchanged Data class aggregates the specification of the data exchanged through the provided and required interfaces of a Service. These types may be detailed in the data model within the Service Implementation. The Provided Interface class aggregates the interfaces provided by a Service whilst the Required Interface class aggregates the interfaces required by a service. Figure 18. Service definition example Figure 18 illustrates part of the OFBiz account service definition. It shows part of the definition of the "Billing" interface that provides the "createbillingaccount" operation. This operation allows one to create a billing account by passing a timestamp from which this account will be valid. The bottom of the diagram illustrates the definition of the "Timestamp" data type. This data type is used in the definition of the Billing interface and therefore users of this service should be made aware of it Service Orchestration In a SOA, services can be combined into high level business processes which can be reconfigured easily according to the needs of the company. Besides modelling the business processes implemented by the CCIM services, this part of MODACloudML also captures dependencies between Services. Figure 19 presents our metamodel of service orchestrations. Public Final version 1.0, dated 30/9/

25 Figure 19. Service orchestration overview The Orchestration class represents the way the services in a CCIM model collaborate. It contains a static view of the connections between services and a set of business processes that describes the dynamic interactions between services. The Static View class aggregates the connectors between the services in a CCIM. The data and service connectors describe the correspondence link between the provided and required interfaces and the exchanged data from the point of view of both services. A data connector connects exchanged data types from a service to exchanged data types from another. A service connector connects a provided interface from a service to a required interface from another. The Business Processes that describe the dynamic interactions between services are represented as UML Activity diagrams contained by the business process class. Public Final Version 1.0, dated 30/9/

26 Figure 20. Example static view of orchestration Figure 20 depicts the static view of the OFBiz CCIM Model. The Product and Manufacturing services communicate by means of the "InventoryItemEntityManagement" interface which is provided by the former and required by the later. The "InventoryItem" class represents the return type of the "findbyid" operation of the shared interface. Because of this, it appears in the exchanged data part of both service descriptions. Public Final version 1.0, dated 30/9/

27 Figure 21. Business process example The Activity Diagram presented in Figure 21 shows the dynamic view of the orchestration of the Manufacturing and the "Accounting" services. It describes that the "Manufacturing" service prepares a request that is then handled by the Accounting service Usage Model A Usage Model specifies the way users are expected to exploit the functionality of the software to be implemented. It specifies which operations offered by the services can be invoked by the users. Additionally, it specifies the order and frequency/probability of these events. Figure 22 exemplifies such models in the context of the OFBiz example. It is basically a UML activity diagram whose actions represent the operations offered by the OFBiz CIM services. Each possible path is annotated with its probability, e.g. 20% of time users are creating new billing accounts, whilst 38% of the time they are executing other actions. Public Final Version 1.0, dated 30/9/

28 Figure 22. Example of usage model For more details on the metamodel of Usage Model at the QoS level, please refer to D Service Implementation This model is created from behaviours extracted from the services defined at the CCIM level. They are structured following the OMG recommendations relating to the organisation of a TOGAF architecture [7]. The implementation of a service is defined by means of models that describe the architecture of applications at different levels of abstraction together with a set of automatic and semi-automatic transformations allowing the transition from one level to another. The aim of this process is to produce an executable application thanks to some code generators. The purely architectural models are complemented by a data model which is basically a class diagram containing entities (classes), attributes (properties of an entity) and relations (associations) between Entities. Among the properties of entities, some are reported as identifiers of the entity when they allow one to identify uniquely its instances. Public Final version 1.0, dated 30/9/

29 Figure 23. Service implementation overview A service is implemented by a concrete data model (an entity-relationship model) and a description of the components (an ApplicationComponent) that implement the functionality of the service (see Figure 23). An ApplicationComponent represents one of the existing or target system s applications and can be specialized into: A ServiceApplication which represents an internal component of the application that offers services to other parts of the application. A SystemFederation which is the highest application level, containing all other application components. It assembles systems in order to federate them, as in the case of cooperation between different information systems in different enterprises A DatabaseComponent which represents a database or a repository. A SystemApplication which is an organized set of application components with autonomous functionalities. This often represents the enterprise s information system. A very large information system can be broken down into several (sub-)systems. A Service Application can itself be specialized as: Public Final Version 1.0, dated 30/9/

30 Entity components which focus on one or more key business entities of the system (for example, Client, Contract or Order). Their role is to provide access to information related to these entities, most often associated with a database. Typically, we find read, write and query operations. Entity components can also take on problems concerning the distribution and duplication of the associated repositories. Interaction components which manage the dialog between the system and external actors. In particular, they take care of managing graphical user interfaces and maintaining the user s session context. Intermediary applications or function components which play an intermediary role between process components and entity components, by handling certain business processing, validation or message adaptation. Process components which handle the automation of business processes: task sequencing, connections to services, event management. Utility components which provide transversal services, which are relatively independent of the enterprise s business, such as directories, messaging or electronic publishing. These components, which are generally stable, are often implemented by widely used, low-risk software packages Public components which are dedicated to services that can be accessed from outside the modelled system (e.g., B2B, partner relationships). A System application can be specialized as An application which is a form of component that designates an application in the traditional sense of the term. It is widely used to represent existing applications, for example to carry out application mapping. It allows applications to be designated as having been bought off-the-shelf, or as being ERPs or custom-developed applications. The Enterprise System class which represents an enterprise information system. Figure 24 illustrates the TOGAF notation adopted by Modelio for each kind of application component. It also introduces the notation for the connection between components. Public Final version 1.0, dated 30/9/

31 Figure 24. The TOGAF notation Based on this notation, the model presented in Figure 25 illustrates the architecture of the manufacturing service of OFBiz which involves the following components: "WebApp" is an interaction component that implements the user interface of the service; "BOM" is a process component that handles the requests related to the Bill of Materials; "Production Run" is a process component that handles the requests related to the production of products; "MRP" is a process component that handles the requests related to the MRP; "TechData" is a process component that handles the requests related to the technical related data; "EntityManagement" is an entity component that handles the data storage; Database is an off-the-shelf database software used to store data. Public Final Version 1.0, dated 30/9/

32 Figure 25. Service implementation example Data Model In this section, we provide a short overview of the data model and explain the importance of adopting the Entity Relationship (ER) approach as reference. The way it maps into the CPIM and CPSM data models is accurately presented in D4.4.1 section ER model is a conceptual model that has been adopted by technical and not technical users for describing data and relationships among them. The model supports the definition of data in terms of abstract concepts in a way that is independent of the logical model adopted to implement the data structures. As such, it is a good candidate for being our reference model at the CCIM level. The drawback of this model is that it does not provide any language for data manipulation, but we plan to introduce a language for it that will allow the user to express queries and other CRUD operations directly on it. The data model introduced in Figure 26 describes the entities manipulated by the application and their relationships at the implementation level. Entities in a data model are expected to implement the complex types appearing in the Exchanged Data part of the service definition. The present metamodel is based on the Modelio's Persistent Module metamodel to make sure MODAClouds can benefit of existing support for modelling conceptual and logical data models, automatic transformations from one to the other and vice-versa, and code generation. Public Final version 1.0, dated 30/9/

33 Figure 26 Data model overview The Data model class represents an entity-relationship model, so it contains a set of Entities, Relationships and Constraints. Constraints restrict the set of values allowed by the properties they are attached to. They take the form of textual description. Entities can be abstract or concrete and represent entities in an entity-relationship data model. They implement a type from the Exchanged Data. The parent association describes the inheritance parent of this entity. Note that multiple inheritances are not allowed. An Entity has a Role in the relationship it takes part. The PersistentProperty class represents a property of an entity that should persist in a database. An Identifier is a persistent attribute identifying uniquely an entity alone or along with other identifiers and a Persistent Attribute is a concrete persistent property. Figure 27 illustrates all meta-classes in the Data Model CCIM package. It has been inspired on the data model of the accounting application of OFBiz. Figure 27 Data model example (Budget) "CommentedElement", "Budget" and "BudgetType" are entities whilst "CommentedElement" is an abstract entity (name in italic). The arrow going from "Budget" to "CommentedElement" states that the former is the child of the later. Finally, "budgetid" and "budgettype" are identifiers while, "comments" is a string persistent attribute. The constraint attached to "comments" states that this attribute shall not be empty. Public Final Version 1.0, dated 30/9/

34 Figure 28 shows another more complex example extracted directly from the OFBiz documentation [3]. Figure 28 Data model example (Payment) The example highlights three entities, Payment, PaymentAttribute and PaymentApplication that are involved in three 1-to-many relationships that we named paymentattributerel, paymentapplicatonrel and topaymentapplicationrel. All these models from the CCIM level will be used by the MODAClouds IDE in order to generate parts of the models at the CPIM level. In the next section we present these models and the concepts involved. 4.2 The Cloud Provider-independent Models At the CPIM level we propose a new approach to describe the deployment, provisioning and data models of multi-cloud systems in a provider-agnostic way. Both the design alternatives and deployment model and the data model can be edited by the Functional Modeling Environment Design alternatives and deployment model CloudML is a new DSML developed in collaboration between the MODAClouds and PaaSage projects which is associated to the design alternative and deployment models and is a part of MODACloudML. CloudML is specified by a metamodel inspired by component-based approaches and follows the type-instance pattern [8]. This DSML is used by the IDE to describe design alternatives and deployment models of multi-cloud systems at the CPIM level. This initial version of the design alternatives and deployment models focuses on the IaaS level; the next iteration will consider both IaaS and PaaS concepts. Currently, two formats can be used for the tool s concrete syntax, namely the JavaScript Object Notation (JSON) and the XML Metadata Interchange (XMI) while another concrete syntax is provided by the MODAClouds IDE Type level Figure 29 presents the portion of the DSML metamodel that covers the types of the CPIM. A CPIM encompasses the topology of the nodes of the cloud infrastructure, the topology of the software artefacts to be deployed on these nodes, the bindings between software artefacts, and the bindings between artefacts and nodes. Hence, it consists of three main types of elements, namely the node types, the artefact types and the binding types. Public Final version 1.0, dated 30/9/

35 Figure 29. Type part of the DSML metamodel We illustrate in the rest of this section the main concepts of our metamodel by specifying the deployment and provisioning of OFBiz on two nodes where all the OFBiz components except the database are deployed on a single node and OFBiz is started in a demo mode. Listings 1-3 present some excerpts of the types specifying this deployment and provisioning. A node type represents a generic virtual machine (e.g., a virtual machine running GNU/Linux). This element can be parameterized by provisioning requirements (e.g., 2 cores <= compute <= 4 cores, 2 GiB <= memory <= 4 GiB, storage <= 10 GiB, location = Europe) as depicted in the SmallGNULinux node type defined in Listing 1. All these requirements are optional and do not have to be defined in the CPIM. ] "nodetypes" : [ { "id" : "SmallGNULinux", "os" : "GNULinux", "compute" : [2, 4], "memory" : [2048, 4096], "storage" : [10240], "location" : "eu", "sshkey" : "smallgnulinux", "securitygroup" : "ofbiz", "groupname" : "smalllinux", "privatekey" : "YOUR KEY", } Listing 1 - An example of a node type from a CPIM in JSON format and using the MODACloudML IDE The definition of a type of node can be achieved by referring to the resources models presented in Section In particular, the concept of node can be mapped to the concept of Cloud Resource defined in the CPIM presented in Figure 4. Public Final Version 1.0, dated 30/9/

36 An artefact type represents a generic component of the system called an Application type (e.g., an instance of the OFBiz, or a MySQL database) to be deployed on a node, or an external service managed by an external party. It can be associated to Resources (e.g., binary files, configuration files, shell scripts), which can be annotated with commands to manage the deployment's life-cycle of the associated artefact (e.g., OFBiz from configure it, and run it). As depicted by the composed relationship in our metamodel, application types may be grouped together and reused in the form of composites. The definition of an artefact type might be partially derived from the CCIM models. In particular, the concept of Service as defined in the SOA CIM model presented in Figure 13. Cloud related concepts can be added by referring to the resources models. In particular, the concept of artefact can be mapped to the concepts of Cloud Platform and Cloud Software depending on the dependencies between the artefacts. An artefact type can expose two kinds of ports: servertype, which exposes features that can be provided by the artefact (e.g., the database exposes a port for remote access) and clienttype for required features (e.g., the OFBiz requires a MySQL database). A client port is optional if the required feature is not mandatory in order to run the artefact (e.g., in Listing 2 the "requires" section specifies mandatory client ports depicting that OFBiz requires a MySQL database). The visibility of a port can be remote or local. To each port can be associated resources specifying how to configure the artefact accordingly (e.g., configure the MySQL to listen on default port). The definition of a port type might be partially derived from the CCIM models since this concept can be mapped to the concept of Interface defined in the SOA CIM model presented in Figure 13. "artefacttypes" : [ { "name" : "ofbiz", "resource" : { "name" : "ofbizarchive", "retrievingcommand" : "wget -P ~ ; wget -P ~ wget -P ~ wget jar; ", { } }, "deployingcommand" : "sudo deploy_ofbiz.sh", "startcommand" : "sudo ofbiz.sh" }, "requires" : [{ "name" : "mysqlrequired", "isremote" : true, "portnumber" : "0", "isoptional" : false } ] "name" : "mysql", "resource" : { "name" : "mysql", "retrievingcommand" : "wget "deployingcommand" : "sudo install_mysql.sh" }, "provides" : [{ "name" : "mysqlport", "isremote" : true, "portnumber" : "0" } ] Public Final version 1.0, dated 30/9/

37 Listing 2- Examples of artefacts types from a CPIM in JSON format and using the MODACloudML IDE BindingTypes between artefacttypes bind together two porttypes with the same visibility. A local port has to be bound to another port from an artefact on the same node. Typically, a binding involving a mandatory client port is called a deployment dependency (e.g., the MySQL database has to be deployed before OFBiz since it is required by a mandatory client port) while others are called communication channels (e.g., a client can communicate with the database through its default port). Resources can be associated to each BindingType describing how to configure these artefact types in order to communicate with each other (e.g., the "clientresource" section in Listing 3 specifies how to configure OFBiz to communicate with the database by updating configuration parameters such as IP address in the OFBiz configuration file, the "serverresource" section specifies how to configure the MySQL database so that it accepts remote queries). The definition of a binding type might be partially derived from the CCIM models since this concept can be mapped to the concept of service connector defined in the service orchestration CIM metamodel presented in Figure 19. "bindingtypes" : [{ "name" : "mysql_requirement", "server" : "artefacttypes[mysql]/provided[mysqlport]", "client" : "artefacttypes[ofbiz]/required[mysqlrequired]", "clientresource" : { "name" : "client", "retrievingcommand" : "wget -P ~ wget -P ~ ", "configurationcommand" : "sudo bash configure_ofbiz.sh" }, "serverresource" : { "name" : "server", "retrievingcommand" : "wget wget "configurationcommand" : "sudo service mysql stop; sudo cp ~/my.cnf /etc/mysql/; sudo service mysql start; sudo mysql_ofbiz.sh" } } ], Listing 3 -An example of a binding type in JSON format Public Final Version 1.0, dated 30/9/

38 Instance level The portion of the DSML metamodel that covers the instances of the CPIM is similar to the one that covers the types. Hence, it also encompasses three main concepts, namely node instances, artefact instances, and binding instances. It is worth to note that these instances will constitute the template of provisioning and deployment. Figure 30. Instance part of the DSML metamodel Listings 4-6 present some excerpts of instances of the types described above. A node instance represents an instance of a virtual machine (e.g., a virtual machine running GNU/Linux called cloudml-ofbiz). The readonly constraint is associated to some of the concepts in the metamodel, it shows that, once instantiated, their value cannot change over the time. For instance, one cannot change the type of a node instance or the owner of a port. This can only be achieved by the creation of a new instance. "nodeinstances" : [ { "id" : " cloudml-ofbiz", "type" : "SmallGNULinux", ] },{ } "id" : " cloudml-ofbizdb", "type" : "SmallGNULinux", Listing 4 - An example of a node instance from the CPIM in JSON format and using the MODACloudML IDE Public Final version 1.0, dated 30/9/

39 An artefact instance represents an instance of a component of the application on a specific virtual machine (e.g., an instance of OFBiz and of the MySQL database deployed on the virtual machine above). "artefactinstances" : [{ "name" : "ofbiz", "type" : "artefacttypes[ofbiz]", "destination" : "nodeinstances[cloudml-ofbiz]", "required" : [{ "name" : "mysqlrequired1", "type" : "artefacttypes[ofbiz]/required[mysqlrequired]" } ] },{ "name" : "mysql1", "type" : "artefacttypes[mysql]", "destination" : "nodeinstances[cloudml-ofbizdb]", "provided" : [{ "name" : "mysqlprovided1", "type" : "artefacttypes[mysql]/provided[mysqlport]" } ]}], Listing 5 - An example of an artefact instance from the CPIM in JSON format and using the MODACloudML IDE A binding instance depicts an instance of binding between two artefact instances. The two instances linked together are then configured according to the commands described in the type of the binding. ] "bindinginstances" : [{ "name" : "mysql_requirement1", "type" : "bindingtypes[mysql_requirement]", "client" : "artefactinstances[ofbiz]/required[mysqlrequired1]", "server" : "artefactinstances[mysql1]/provided[mysqlprovided1]" } Listing 6 - An example of an artefact instance from the CPIM in JSON format As for the types, the definition of artefact, port and binding instance can be derived from the definition of the service definition and service orchestration CCIM models Constraints on the CPIM metamodel Using OCL constraints, we formalized the dependencies between types and instances as well as constraints which must hold at the instance level, to ensure that the deployment model makes sense. This set of constraints can be extended according to the concerns and constraints of the user. First, we defined in Listing 7 the two following constraints related to the node instance concept: (i) after the instantiation of a node type, a node instance is always empty (i.e., there is no artefact instance deployed on it), (ii) in order to bind an application to a node instance we need to check that a node with the id specified as the application's destination is already instantiated. -- A new node instance is always empty Public Final Version 1.0, dated 30/9/

40 context NodeType::instantiates(): Node post: result.applications->isempty() -- Check that application requires the type of environment provided -- by the given node, and that the resulting application instance -- conformed to its type context ApplicationType::setDestination(n: Node): Application pre: n.id = self.host post: result.definition = self post: result.owner.node = n Listing 7 OCL constraints on node instances As described in the previous section, an artefact instance may expose remote or local ports. A local port has to be bound to another local port on the same node while a remote port can only be bound to another remote port. This is ensured by the constraints defined in Listing Local and remote ports cannot be bound context Binding inv: self.server.isremote = self.client.isremote -- Check that all local dependencies are actually available on the host -- node context Application inv: self.required->select ( cp not cp.isoptional & not cp.isremote ) ->collect( cp cp.channel.server.owner ) ->select( at at.oclistypeof(applicationtype) ) ->forall( o o.host = self.host or not oclisdefined(o.host) ) Listing 8 OCL constraints on artefact instances Some constraints are directly related to the life-cycle of the nodes and artefacts composing a deployment model. Figure 31 and Figure 32 present their life-cycle: Figure 32. Life-cycle of a node Figure 31. Life-cycle of an artefact There are two main states in the life-cycle of a node: stopped and running. The transitions between these states may be triggered by the start or stop commands. Before the actual stop of a node, all the applications that Public Final version 1.0, dated 30/9/

41 are running on it, should be stopped first. The OCL constraints presented in Listing 9 formalize the pre- and post-conditions of these actions. context Node::start() pre: self.oclisinstate(stopped) post: self.oclisinstate(running) -- Check that all application running on the given node are stopped, -- consequently context Node::stop() pre: self.oclisinstate(running) post: self.applications->forall( a a.oclisinstate(stopped) ) post: self.oclisinstate(stopped) Listing 9 OCL constraints related to the life-cycle of a node Similarly, to switch an application in a started state, all its mandatory dependencies have to be in the started state as well as the node on which it is deployed. Moreover, to change the state of an application to stopped, all its clients with a mandatory dependency should also be in a stopped state. This constraint can be associated to the start and stop commands as follows (Listing 10): -- Check that all the mandatory servers (transitively) are in a running state context Application::start() -- Transitive closure of the servers def allservers(a: Application): Set(Application) = a.required->select ( c not c.isoptional ) ->collect( c c.channel.server.owner ) ->select ( a a.oclistypeof(application) ) ->collect( a allservers(a) ) ->flatten pre: oclisinstate(stopped) pre: allservers(self)->forall( s s.ocisinstate(running) ) pre: self.destination.ocisinstate(running) post: oclisinstate(running) -- Ensure that stopping a given application impact the state of all clients -- that requires it (as a mandatory server) context Application::stop() -- Transitive closure of all clients def allclients(a: Application): Set(Application) = self.provided ->collect( s s.channels.client ) ->select ( c not c.isoptional ) ->collect( c allclients(c.owner) )->flatten pre: self.oclisinstate(running) post: self.oclisinstate(stopped) post: self.allclients->forall( c oclisinstate(stopped) ) Listing 10 OCL constraints related to the life-cycle of an application Moreover, before being started, an application has to be deployed. An application can be in a deployed state only if all its mandatory dependencies are deployed and its destination node is running. -- Check that all the mandatory servers (transitively) are in a deployed state context Application::deploy Public Final Version 1.0, dated 30/9/

42 pre: oclisinstate(uninstalled) pre: allservers(self)->forall( s s.oclisinstate(deployed) ) pre: self.destination.ocisinstate(running) post: oclisinstate(deployed) Listing 11 OCL constraint related to the deployment of an application Data model While at the CCIM level we focus exclusively on the expressivity of the data model representation, at the CPIM level we start considering the specific models being typically offered by cloud providers, without referring to a particular one. The majority of available data storage software, either installed on a IaaS directly by the application developer or offered as PaaS by cloud providers, provide services that include distributed file system, NoSQL solutions, and blobs. For this reason, we select three models at the CPIM level that are suitable to represent these different cases. Of course, the models appear less expressive compared to the ER model we have chosen at the CCIM level but they can significantly enhance the ability of dealing with big and replicated data. They are: Graph Data Model (GDM): This data model allows the representation of complex relationships. Entities are defined as nodes of the graph and relationships among entities as edges. It is then semantically equivalent to the ER model under the restriction that relationships are binary (each edge in the graph can link only two nodes). GDM can be seen as the abstraction of a classical relational database or of a NoSQL graph database. Hierarchical Data Model (HDM): This data model is appropriate when one wants to describe data that have a tree-based data structure. It models a single type of relation that is represented by the arc connecting the parent and the child node. Nested sets are examples of data structures that can be easily represented with this data model. HDM is the abstraction that can represent a file system and a document-based NoSQL database. Its main advantage is that data following this model can be easily distributed through different data storages thus promising a good level of scalability and availability of information. Flat Data Model (FDM): With this term we refer to sets of tables that are not related with each other. This data model is useful for representing the concept of set; in fact, each table collects a set of items that are part of the same category. For instance, we can represent the collection of registered users, the set of items sold from a store, etc. By using FDM it is not possible to keep track of relationships among tables. FDM is the abstraction that can represent in very general terms the characteristics of any NoSQL database. From the QoS perspective, FDM allows for so called sharding, that is, distribution of data belonging to the same data on different data storage to enable the possibility of parallelization of query execution on large data sets. Starting from the ER model at the CCIM level it is possible to map data in any of the CPIM models we presented before. The transformation toward GDM preserves all characteristics of the original data description. The transformations toward FDM and HDM result in the fact that either information is replicated or it is lost in the final model. The examples below show these cases. Based on what we have discussed above, the selection of the proper CPIM model is then a trade-off between expressivity and QoS requirements. This decision can either be made by the application designer or it can be performed automatically by a transformation tool, assuming that the QoS requirements are expressed in an appropriate format. To show the characteristics of the three models, we refer to the OFBiz example shown in Figure 28. Figure 33 depicts the GDM model related to the example in Figure 28. The black circles represent the keys of each entity while the white ones group all other attributes. Relations are described as arcs in the graph, where their cardinality is explicitly indicated. Public Final version 1.0, dated 30/9/

43 Figure 33 OfBiz GDM example (Payment) In spite of the fact that Figure 33 depicts the data model in a readable way, we want to provide an XSD model that describes data model in a formal way. The XSD figure is shown in Figure 34. We want to conclude the model description by providing the XSD code related to the GDM in Code 1. Figure 34 GDM XSD datamodel <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="gdm"> Public Final Version 1.0, dated 30/9/

44 <xs:complextype> <xs:sequence> <xs:element ref="node" maxoccurs="unbounded"/> <xs:element ref="edge" maxoccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:name" use="required"/> </xs:complextype> </xs:element> <xs:element name="node"> <xs:complextype> <xs:sequence minoccurs="1"> <xs:element name="attribute" maxoccurs="unbounded"> <xs:complextype> <xs:attribute name="name" type="xs:id" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="id" type="xs:id" use="required"/> <xs:attribute name="name" type="xs:name" use="required"/> <xs:attribute name="key" type="xs:idrefs" use="required"/> </xs:complextype> </xs:element> <xs:element name="edge"> <xs:complextype> <xs:attribute name="id" type="xs:id" use="required"/> <xs:attribute name="name" type="xs:name" use="required"/> <xs:attribute name="node1" type="xs:idref" use="required"/> <xs:attribute name="node2" type="xs:idref" use="required"/> <xs:attribute name="constrain" type="xs:string"/> <xs:attribute name="node1mincard" type="xs:unsignedint" use="required"/> <xs:attribute name="node1maxcard" type="xs:positiveinteger"/> <xs:attribute name="node2mincard" type="xs:unsignedint" use="required"/> <xs:attribute name="node2maxcard" type="xs:positiveinteger"/> </xs:complextype> </xs:element> </xs:schema> Code 1 GDM XSD code Figure 35 depicts a possible representation of the example by adopting HDM. In this case, we have considered the Payment entity as the root of the tree. The existence of the two relationships between Payment and PaymentApplication results in the fact that this last entity appears twice in the resulting tree. Another possible HDM representation of the example is shown in Figure 36. In this case, not only Payment but also PaymentAttribute together with the relationship paymentattributerel are replicated. This concept is better explained in D Public Final version 1.0, dated 30/9/

45 Figure 35 OfBiz HDM 1 example (Payment) Figure 36 OfBiz HDM 2 example (Payment) Figure 37 depicts the XSD datamodel and the related code is shown in Code 2. Public Final Version 1.0, dated 30/9/

46 Figure 37 HDM XSD datamodel <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="hdm"> <xs:complextype> <xs:sequence minoccurs="0"> <xs:element ref="child"/> </xs:sequence> <xs:attribute name="id" type="xs:id" use="required"/> </xs:complextype> </xs:element> <xs:element name="relationship"> <xs:complextype> <xs:sequence minoccurs="0"> <xs:element name="attribute" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:attribute name="name" type="xs:id" use="required"/> </xs:complextype> </xs:element> <xs:element ref="child" maxoccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:name" use="required"/> </xs:complextype> </xs:element> <xs:element name="child"> <xs:complextype> <xs:sequence> <xs:element name="attribute" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:attribute name="name" type="xs:ncname" use="required"/> </xs:complextype> </xs:element> <xs:element ref="relationship" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> Public Final version 1.0, dated 30/9/

47 <xs:attribute name="id" type="xs:name" use="required"/> </xs:complextype> </xs:element> </xs:schema> Code 2 HDM XSD code Figure 38 shows the FDM model associated to the example. In this case, the model does not include the relationships among the entities. In fact, as the figure shows, each entity has been represented as a single table with the columns that store the attributes (each node can be viewed as a table that contains all the attributes of the node). In spite of the model does not represent completely the example in Figure 33, it has the potential to be highly scalable. Each table can be split over different nodes in the net. Since relationships are not represented, complex queries have to be manually executed by the user. Figure 38 OfBiz FDM example (Payment) We want to conclude this section adding the XSD figure (Figure 39) and the related code definition (Code 3). Figure 39 FDM XSD datamodel <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="fdm"> Public Final Version 1.0, dated 30/9/

48 <xs:complextype> <xs:sequence> <xs:element name="table" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="column" minoccurs="1" maxoccurs="unbounded"> <xs:complextype> <xs:attribute name="id" type="xs:id" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="id" type="xs:id" use="required"/> <xs:attribute name="name" type="xs:name" use="required"/> <xs:attribute name="key" type="xs:idrefs" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:name" use="required"/> </xs:complextype> </xs:element> </xs:schema> Code 3 FDM XSD code 4.3 The Cloud Provider-Specific Models At the CPSM level, the design alternatives and deployment models as well as the data models are refined to include the provider-specific concerns needed to deploy a multi-cloud system. Part of these models can be generated by semi-automatic transformations. This section details their metamodels and presents some example applied to OFBiz Design Alternatives and Deployment Model The design alternatives and deployment models at the CPSM level result in the enrichment of the corresponding models at the CPIM level with provider specific concepts. Since we focus in this initial version of the models at the IaaS level, this enrichment mainly affects the Node element of the instance part of the metamodel as shown in Figure 40. This enrichment consists in: (i) adding the actual data resulting from the resolution of the constraints defined in the node types (e.g., actual CPU, RAM, Disk, VM ), and (ii) adding data required for the deployment and management of the application that are provider specific and can be accessed only once the provisioned process achieved. Thanks to this enrichment, one may retrieve data about the actual resources available and provisioned and how they can be accessed. These data are particularly relevant during the process of configuration of applications and bindings. In order to achieve this enrichment, a first step consists of the specification of the provider on which the CPIM instances will be deployed (e.g., the virtual machine running GNU/Linux called cloudml-ofbiz will be provisioned on Amazon EC2). Each provider is identified by a name and annotated with credentials and the data required to access the provider API (e.g., address of the API endpoint) (see Listing 12). "providers" : [{ "name" : "aws-ec2", "credentials" : "./credentialsamazon" },{ "name" : "flexiant", "credentials" : "./credentialsflexiant", "properties" : [{ "name" : "endpoint", "value" : Public Final version 1.0, dated 30/9/

49 }], } ] Listing 12 - An example of providers from the CPSM in JSON format The definition of providers can be achieved by referring to the resources models presented in Section In particular, the concept of provider can be mapped to the concept of Cloud Provider defined in the CPIM presented in Figure 4. Figure 40. Instance part of the deployment model at the CPSM level As depicted in Listing 13, once the enrichment process achieved, a node instance at the CPSM level is enriched with metadata about its actual provisioning (e.g., an Amazon t1.micro instance in eu-west running the ami-7bccc80f image, 1 core, 613MB of RAM ) as well as about its runtime (e.g., the node is running, public and private addresses). { "id" : " cloudml-ofbiz", "status" : "running", "type" : "SmallGNULinux", "publicadress" : "xxx.xxx.xxx.xxx", "privateadress" : "xxx.xxx.xxx.xxx", "provider" : "aws-ec2", "location" : "eu-west-1", "CPU" : 1, "RAM" : 613, "disk" : 20, "vm" : "t1.micro", "provided-id" : "i-3ab26e77", "image" : "ami-7bccc80f" Public Final Version 1.0, dated 30/9/

50 } Listing 13 - An example of a node instance from the CPSM in JSON format This concept of node at the CPSM level can be mapped to concepts in the resource models at the CPSM level that can be thought as instance of a Cloud Resources at the CPIM level. For instance, details on Amazon micro instance as depicted in Listing 13 can be found in the CPSM presented in Figure 7. The application instances are also annotated with runtime information such as their status or their availability. The status metadata is directly related to the state of an artefact instance in its life-cycle Data model In the context of IaaS solution cloud providers do not offer specific support to data storage and it is assumed that the application operators install the data storage technology he/she prefers. As such, a CPSM data model is irrelevant. When considering the case of PaaSes, the current offerings by cloud providers include a variety of different data storage approaches. In this section we focus specifically on this case and provide data models suitable to address the requirements of the following families: RDM (Relational Data Model) family: this family includes all models referring to the classical relational model adopted to store data in relational database. HDM family: we have already presented the HDM model at the CPIM level (see Section 4.2.2). The CPSM HDM family includes all data models that are hierarchical. A cloud provider offers a model of this family when exposes services such as a distributed file system or a document-based NoSQL. FDM family: this family corresponds to the CPIM level FDM described in Section as an example, a blob service is based on such kind of data model. KVDM (Key-Value Data Model) family: this family of data models offers the concept of table, that is, a collection of rows that can be singularly accessed through a key. CDM (Column-based Data Model) family: this family of models offers, again, the concept of tables as a primary concept of this model and offers the possibility to access to columns and collections of columns in an optimized way. The data model families defined above are suitable to classify the data models offered by the variety of available data storage services offered by PaaS providers. Of course, the set of models we have defined continues to make sense even in a IaaS context provided that someone has added to the IaaS level a data storage tool installation. In D4.4.1 we proposed, in the Data Mapping section, the guideline to map the CPIM data models in some specific CPSM data model families. The guideline is useful to restrict the plethora of the possible CPSM data models to be used. Table 1 summarizes the mapping possibilities we have identified. CPIM CPSM RDM HDM FDM KVDM CDM GDM X X HDM FDM X X X Table 1 CPIM to CPSM mapping X In the following some examples of data storage-specific data models are defined and classified according to the set of families listed above KVDM Family SimpleDB is an example of key-value data storage offered by Amazon. The XSD (see Code 4) of its data model is defined in Figure 41. Each customeraccount represents the Amazon user account. The user can create Public Final version 1.0, dated 30/9/

51 different domains that can be viewed as tables. In fact, the domain is a collection of items (rows) with attributes (it is the column name) and values. Figure 41 SimpleDB data model <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="customeraccount"> <xs:complextype> <xs:sequence> <xs:element name="domain" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="items" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="attribute"> <xs:complextype> <xs:attribute name="name" type="xs:id" use="required"/> </xs:complextype> </xs:element> <xs:element name="values"/> </xs:sequence> <xs:attribute name="index" type="xs:positiveinteger" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:id" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:id" use="required"/> </xs:complextype> </xs:element> </xs:schema> Code 4 SimpleDB XSD code CDM Family HBase is a well known column-based data storage service offered by Hadoop. Its XSD is shown in Figure 42 and detailed in Code 5. The figure depicts a database as a collection of tables that are composed of a set of column families. The column family aggregates several columns under the same namespace. As we can see, the data are defined in terms of columns in spite of a collection of rows. Furthermore, HBase offers the versioning of cells (see the presence of ts attribute in the cell definition which stays for timestamp). Public Final Version 1.0, dated 30/9/

52 Figure 42 HBase datamodel <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="database"> <xs:complextype> <xs:sequence> <xs:element name="table" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="columnfamily" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="column" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="cell" minoccurs="0"> <xs:complextype> <xs:attribute name="ts" type="xs:long" use="required"/> <xs:attribute name="value" type="xs:anysimpletype" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="rowkey" type="xs:id" use="required"/> <xs:attribute name="name" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:id" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:id" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:id" use="required"/> </xs:complextype> </xs:element> </xs:schema> Code 5 Hase XSD code Public Final version 1.0, dated 30/9/

53 HDM Family Figure 43 describes the document-based model (close to MongoDB model). A database is defined as a set of Collection items. Each Collection assumes the meaning of database namespace. A collection is a set of Documents which collect values. The value definition permits to express simple value or aggregate values. The data structure follows the same logic of JSON data format. To complete the data model description, the XSD code is provided in Code 6. Figure 43 MongoDB datamodel <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="database"> <xs:complextype> <xs:sequence> <xs:element name="collection" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="document" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="value" type="valuetype" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:id" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:id" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:id" use="required"/> </xs:complextype> </xs:element> <xs:complextype name="valuetype"> <xs:choice> Public Final Version 1.0, dated 30/9/

54 <xs:element name="int" type="xs:int"/> <xs:element name="string" type="xs:string"/> <xs:element name="object"> <xs:complextype> <xs:sequence minoccurs="0" maxoccurs="unbounded"> <xs:element name="key"/> <xs:element name="value" type="valuetype"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="array"> <xs:complextype> <xs:sequence minoccurs="0" maxoccurs="unbounded"> <xs:element name="value" type="valuetype"/> </xs:sequence> </xs:complextype> </xs:element> </xs:choice> </xs:complextype> </xs:schema> Code 6 MongoDB XSD code 5 Conclusion and roadmap In this deliverable we presented the set of models defined within WP4 as well as models and patterns to ease their manipulation by using the MODACloudML IDE. We highlighted how they can be organized within the MODAClouds' three levels (CCIM-CPIM-CPSM) approach before introducing their metamodels and examplifying them on our OFBiz use case. For now, the cloud-related concepts introduced in the initial definition of these metamodels focused on the IaaS layer. In future works we will introduce PaaS concepts and integrate them within the existing metamodels. Some of the transformations from one model to another have already been implemented. 6 Bibliography [1] P. Mell and T. Grance, The NIST Definition of Cloud Computing, National Institute of Standards and Technology, Special Publication , September [2] "OFBiz general introduction". [Online]. Available: [3] "OFBiz documentation". [Online], Available: [4] OMG Model-Driven Architecture. [Online]. Available: [5] "Cloud patterns". [Online] [6] ERL, Thomas. "Service-oriented architecture: concepts, technology, and design", Prentice Hall PTR [7] "TOGAF", [Online]. Available: [8] C. Atkinson and T. Kühne, Rearchitecting the UML infrastructure, ACM Transactions on Modeling and Computer Simulation, vol. 12, no. 4, pp , [9] Elisabetta Di Nitto et al, MODACLOUDS architecture Initial version (D3.2.1) [10] Marcos Almeida et al, MODACloudML IDE Proof of concept (D4.3.1) [11] Giuliano Casale et al, MODACloudML QoS abstractions and prediction models specification Initial version (D5.2.1) [12] Aida Omerovic et al, Design language extensions for cost and benefit analysis (D2.2) [13] ASF, OFBiz Datamodel Book. [Online]. Available: download/attachments/ /ofbizdatamodelbookn 11x17n 4of4n pdf Public Final version 1.0, dated 30/9/