MODACloudML development Initial version

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "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/

MODACloudML development Final version

MODACloudML development Final version Grant Agreement N FP7-318484 Title: Authors: Editor: Reviewers: Identifier: Nature: MODACloudML development Final version Antonin Abhervé (Softeam), Marcos Almeida (Softeam), Danilo Ardagna (Polimi), Franck

More information

Dana Petcu (IeAT), Nicolas Ferry (SINTEF), Marco Miglierina (POLIMI), Alexander Gunka (BOC), Florin Picioroaga (SIEMENS), Marcos Almeida (Softeam)

Dana Petcu (IeAT), Nicolas Ferry (SINTEF), Marco Miglierina (POLIMI), Alexander Gunka (BOC), Florin Picioroaga (SIEMENS), Marcos Almeida (Softeam) Grant Agreement N FP7-318484 Title: Authors: Editor: Reviewers: Identifier: Nature: Report on best practices Initial version Dana Petcu (IeAT), Nicolas Ferry (SINTEF), Marco Miglierina (POLIMI), Alexander

More information

Reuse and Migration of Legacy Systems to Interoperable Cloud Services

Reuse and Migration of Legacy Systems to Interoperable Cloud Services Reuse and Migration of Legacy Systems to Interoperable Cloud Services REMICS Consortium, Arne Berre 07 June 2011 - Timisoara 1 Project facts REMICS is a STREP accepted in the Objective 1.2 of FP7 Call

More information

Enterprise Architecture: Practical Guide to Logical Architecture

Enterprise Architecture: Practical Guide to Logical Architecture Objecteering Practical Guides Enterprise Architecture: Practical Guide to Logical Architecture Author: Version: 1.0 Copyright: Softeam Softeam Consulting Team Supervised by Philippe Desfray Softeam 21

More information

CloudML@ARTIST: Overview

CloudML@ARTIST: Overview CloudML@ARTIST: Overview In the context of the ARTIST project, and following the analysis on the state of the art documented in the public ARTIST Deliverable D7.2, it was decided to base our modelling

More information

Introduction to Service Oriented Architectures (SOA)

Introduction to Service Oriented Architectures (SOA) Introduction to Service Oriented Architectures (SOA) Responsible Institutions: ETHZ (Concept) ETHZ (Overall) ETHZ (Revision) http://www.eu-orchestra.org - Version from: 26.10.2007 1 Content 1. Introduction

More information

Model Driven Interoperability through Semantic Annotations using SoaML and ODM

Model Driven Interoperability through Semantic Annotations using SoaML and ODM Model Driven Interoperability through Semantic Annotations using SoaML and ODM JiuCheng Xu*, ZhaoYang Bai*, Arne J.Berre*, Odd Christer Brovig** *SINTEF, Pb. 124 Blindern, NO-0314 Oslo, Norway (e-mail:

More information

Overcoming the Cloud heterogeneity: from uniform interfaces and abstract models to multi cloud platforms

Overcoming the Cloud heterogeneity: from uniform interfaces and abstract models to multi cloud platforms Overcoming the Cloud heterogeneity: from uniform interfaces and abstract models to multi cloud platforms Dana Petcu http://web.info.uvt.ro/~petcu, petcu@info.uvt.ro West University of Timisoara & Institute

More information

SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS

SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) VERSION 2.1 SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS 1 TABLE OF CONTENTS INTRODUCTION... 3 About The Service-Oriented Modeling Framework

More information

Service-Oriented Architectures

Service-Oriented Architectures Architectures Computing & 2009-11-06 Architectures Computing & SERVICE-ORIENTED COMPUTING (SOC) A new computing paradigm revolving around the concept of software as a service Assumes that entire systems

More information

ASCETiC Whitepaper. Motivation. ASCETiC Toolbox Business Goals. Approach

ASCETiC Whitepaper. Motivation. ASCETiC Toolbox Business Goals. Approach ASCETiC Whitepaper Motivation The increased usage of ICT, together with growing energy costs and the need to reduce greenhouse gases emissions call for energy-efficient technologies that decrease the overall

More information

Meta-Model specification V2 D602.012

Meta-Model specification V2 D602.012 PROPRIETARY RIGHTS STATEMENT THIS DOCUMENT CONTAINS INFORMATION, WHICH IS PROPRIETARY TO THE CRYSTAL CONSORTIUM. NEITHER THIS DOCUMENT NOR THE INFORMATION CONTAINED HEREIN SHALL BE USED, DUPLICATED OR

More information

WHITE PAPER DATA GOVERNANCE ENTERPRISE MODEL MANAGEMENT

WHITE PAPER DATA GOVERNANCE ENTERPRISE MODEL MANAGEMENT WHITE PAPER DATA GOVERNANCE ENTERPRISE MODEL MANAGEMENT CONTENTS 1. THE NEED FOR DATA GOVERNANCE... 2 2. DATA GOVERNANCE... 2 2.1. Definition... 2 2.2. Responsibilities... 3 3. ACTIVITIES... 6 4. THE

More information

A Software Development Platform for SOA

A Software Development Platform for SOA A Software Development Platform for SOA Peter Eeles Executive IT Architect Rational Brand Architect for UK, Ireland and South Africa peter.eeles@uk.ibm.com 2004 IBM Corporation Agenda IBM Software Group

More information

Overview. Stakes. Context. Model-Based Development of Safety-Critical Systems

Overview. Stakes. Context. Model-Based Development of Safety-Critical Systems 1 2 Model-Based Development of -Critical Systems Miguel A. de Miguel 5/6,, 2006 modeling Stakes 3 Context 4 To increase the industrial competitiveness in the domain of software systems To face the growing

More information

Model Driven and Service Oriented Enterprise Integration---The Method, Framework and Platform

Model Driven and Service Oriented Enterprise Integration---The Method, Framework and Platform Driven and Oriented Integration---The Method, Framework and Platform Shuangxi Huang, Yushun Fan Department of Automation, Tsinghua University, 100084 Beijing, P.R. China {huangsx, fanyus}@tsinghua.edu.cn

More information

Improving Agility of Cloud Ecosystems with MODAClouds Introduction and objectives for the second year

Improving Agility of Cloud Ecosystems with MODAClouds Introduction and objectives for the second year Improving Agility of Cloud Ecosystems with MODAClouds Introduction and objectives for the second year Elisabetta Di Nitto Politecnico di Milano elisabetta.dinitto@polimi.it MODAClouds () 2 MODAClouds objectives

More information

IaaS Federation. Contrail project. IaaS Federation! Objectives and Challenges! & SLA management in Federations 5/23/11

IaaS Federation. Contrail project. IaaS Federation! Objectives and Challenges! & SLA management in Federations 5/23/11 Cloud Computing (IV) s and SPD Course 19-20/05/2011 Massimo Coppola IaaS! Objectives and Challenges! & management in s Adapted from two presentations! by Massimo Coppola (CNR) and Lorenzo Blasi (HP) Italy)!

More information

Revel8or: Model Driven Capacity Planning Tool Suite

Revel8or: Model Driven Capacity Planning Tool Suite Revel8or: Model Driven Capacity Planning Tool Suite Liming Zhu 1,2, Yan Liu 1,2, Ngoc Bao Bui 1,2,Ian Gorton 3 1 Empirical Software Engineering Program, National ICT Australia Ltd. 2 School of Computer

More information

DESIGN OF A PLATFORM OF VIRTUAL SERVICE CONTAINERS FOR SERVICE ORIENTED CLOUD COMPUTING. Carlos de Alfonso Andrés García Vicente Hernández

DESIGN OF A PLATFORM OF VIRTUAL SERVICE CONTAINERS FOR SERVICE ORIENTED CLOUD COMPUTING. Carlos de Alfonso Andrés García Vicente Hernández DESIGN OF A PLATFORM OF VIRTUAL SERVICE CONTAINERS FOR SERVICE ORIENTED CLOUD COMPUTING Carlos de Alfonso Andrés García Vicente Hernández 2 INDEX Introduction Our approach Platform design Storage Security

More information

< IMPACT > START ACCELERATE IMPACT

< IMPACT > START ACCELERATE IMPACT START ACCELERATE IMPACT IMPACT project has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement n 632828 START ACCELERATE IMPACT WEBINAR #2 Technology

More information

Service-Oriented Architecture and Software Engineering

Service-Oriented Architecture and Software Engineering -Oriented Architecture and Software Engineering T-86.5165 Seminar on Enterprise Information Systems (2008) 1.4.2008 Characteristics of SOA The software resources in a SOA are represented as services based

More information

Applying 4+1 View Architecture with UML 2. White Paper

Applying 4+1 View Architecture with UML 2. White Paper Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was

More information

Reference Model for Cloud Applications CONSIDERATIONS FOR SW VENDORS BUILDING A SAAS SOLUTION

Reference Model for Cloud Applications CONSIDERATIONS FOR SW VENDORS BUILDING A SAAS SOLUTION October 2013 Daitan White Paper Reference Model for Cloud Applications CONSIDERATIONS FOR SW VENDORS BUILDING A SAAS SOLUTION Highly Reliable Software Development Services http://www.daitangroup.com Cloud

More information

Software Architecture Document

Software Architecture Document Software Architecture Document Natural Language Processing Cell Version 1.0 Natural Language Processing Cell Software Architecture Document Version 1.0 1 1. Table of Contents 1. Table of Contents... 2

More information

A Monitored Student Testing Application Using Cloud Computing

A Monitored Student Testing Application Using Cloud Computing A Monitored Student Testing Application Using Cloud Computing R. Mullapudi and G. Hsieh Department of Computer Science, Norfolk State University, Norfolk, Virginia, USA r.mullapudi@spartans.nsu.edu, ghsieh@nsu.edu

More information

An Extensible Application Topology Definition and Annotation Framework

An Extensible Application Topology Definition and Annotation Framework Institute of Architecture of Application Systems University of Stuttgart Universitätsstraße 38 D 70569 Stuttgart Diploma Thesis Nr. 3504 An Extensible Application Topology Definition and Annotation Framework

More information

MODAClouds. An FP7 Integrated Project

MODAClouds. An FP7 Integrated Project MODAClouds An FP7 Integrated Project MODAClouds the consortium FP7 Integrated Project (n. 318484) Duration: Oct. 1 st, 2012 Sept 30 th, 2015 28 July, 2014 e-infrastructure Services for Society 2 MODAClouds

More information

CLEVER: a CLoud-Enabled Virtual EnviRonment

CLEVER: a CLoud-Enabled Virtual EnviRonment CLEVER: a CLoud-Enabled Virtual EnviRonment Francesco Tusa Maurizio Paone Massimo Villari Antonio Puliafito {ftusa,mpaone,mvillari,apuliafito}@unime.it Università degli Studi di Messina, Dipartimento di

More information

Foundations of Model-Driven Software Engineering

Foundations of Model-Driven Software Engineering Model-Driven Software Engineering Foundations of Model-Driven Software Engineering Dr. Jochen Küster (jku@zurich.ibm.com) Contents Introduction to Models and Modeling Concepts of Model-Driven Software

More information

Winery A Modeling Tool for TOSCA-based Cloud Applications

Winery A Modeling Tool for TOSCA-based Cloud Applications Institute of Architecture of Application Systems Winery A Modeling Tool for TOSCA-based Cloud Applications Oliver Kopp 1,2, Tobias Binz 2, Uwe Breitenbücher 2, and Frank Leymann 2 1 IPVS, 2 IAAS, University

More information

The Service, The Cloud & The Method: The Connection Points

The Service, The Cloud & The Method: The Connection Points The Service, The Cloud & The Method: The Connection Points Thomas Erl SOA Systems Inc. Prentice Hall Service-Oriented Computing Series Started in 2003 Text Books are an Official Part of the SOACP Curriculum

More information

CHAPTER 8 CLOUD COMPUTING

CHAPTER 8 CLOUD COMPUTING CHAPTER 8 CLOUD COMPUTING SE 458 SERVICE ORIENTED ARCHITECTURE Assist. Prof. Dr. Volkan TUNALI Faculty of Engineering and Natural Sciences / Maltepe University Topics 2 Cloud Computing Essential Characteristics

More information

MODAClouds, Underpinning the Leap to DevOps Movement on Cloud Environments

MODAClouds, Underpinning the Leap to DevOps Movement on Cloud Environments MODAClouds, Underpinning the Leap to DevOps Movement on Cloud Environments Executive Summary Today, most organizations face high market pressure, and their supporting IT departments are struggling to accelerate

More information

Collaborative Open Market to Place Objects at your Service

Collaborative Open Market to Place Objects at your Service Collaborative Open Market to Place Objects at your Service D6.4.1 Marketplace integration First version Project Acronym COMPOSE Project Title Project Number 317862 Work Package WP6 Open marketplace Lead

More information

Aneka Dynamic Provisioning

Aneka Dynamic Provisioning MANJRASOFT PTY LTD Aneka Aneka 2.0 Manjrasoft 10/22/2010 This document describes the dynamic provisioning features implemented in Aneka and how it is possible to leverage dynamic resources for scaling

More information

A Quick Introduction to SOA

A Quick Introduction to SOA Software Engineering Competence Center TUTORIAL A Quick Introduction to SOA Mahmoud Mohamed AbdAllah Senior R&D Engineer-SECC mmabdallah@itida.gov.eg Waseim Hashem Mahjoub Senior R&D Engineer-SECC Copyright

More information

Guiding Principles for Modeling and Designing Reusable Services

Guiding Principles for Modeling and Designing Reusable Services Guiding Principles for Modeling and Designing Reusable Services Max Dolgicer Managing Director International Systems Group, Inc. mdolgicer@isg-inc.com http://www.isg-inc.com Agenda The changing notion

More information

Overview of Cloud Computing (ENCS 691K Chapter 1)

Overview of Cloud Computing (ENCS 691K Chapter 1) Overview of Cloud Computing (ENCS 691K Chapter 1) Roch Glitho, PhD Associate Professor and Canada Research Chair My URL - http://users.encs.concordia.ca/~glitho/ Overview of Cloud Computing Towards a definition

More information

Aneka: A Software Platform for.net-based Cloud Computing

Aneka: A Software Platform for.net-based Cloud Computing Aneka: A Software Platform for.net-based Cloud Computing Christian VECCHIOLA a, Xingchen CHU a,b, and Rajkumar BUYYA a,b,1 a Grid Computing and Distributed Systems (GRIDS) Laboratory Department of Computer

More information

MDE Opportunities in Multi-Tenant Cloud Applications

MDE Opportunities in Multi-Tenant Cloud Applications MDE Opportunities in Multi-Tenant Cloud Applications Mohammad Abu Matar 1 and Jon Whittle 2 1 Etisalat British Telecom Innovation Center Khalifa University of Science, Technology and Research Abu Dhabi,

More information

Seamless adaptive multi-cloud management of service-based applications

Seamless adaptive multi-cloud management of service-based applications Seamless adaptive multi-cloud management of service-based applications Open solution brings Interoperability & Portability to PaaS The future of Cloud computing: Elasticity, Legacy Support, Interoperability

More information

Architecture. Reda Bendraou reda.bendraou{{@}}lip6.fr http://pagesperso-systeme.lip6.fr/reda.bendraou/

Architecture. Reda Bendraou reda.bendraou{{@}}lip6.fr http://pagesperso-systeme.lip6.fr/reda.bendraou/ Architecture Reda Bendraou reda.bendraou{{@}}lip6.fr http://pagesperso-systeme.lip6.fr/reda.bendraou/ Some slides were adapted from L. Osterweil, B. Meyer, and P. Müller material Reda Bendraou LI386-S1

More information

CiteSeer x in the Cloud

CiteSeer x in the Cloud Published in the 2nd USENIX Workshop on Hot Topics in Cloud Computing 2010 CiteSeer x in the Cloud Pradeep B. Teregowda Pennsylvania State University C. Lee Giles Pennsylvania State University Bhuvan Urgaonkar

More information

SLA BASED SERVICE BROKERING IN INTERCLOUD ENVIRONMENTS

SLA BASED SERVICE BROKERING IN INTERCLOUD ENVIRONMENTS SLA BASED SERVICE BROKERING IN INTERCLOUD ENVIRONMENTS Foued Jrad, Jie Tao and Achim Streit Steinbuch Centre for Computing, Karlsruhe Institute of Technology, Karlsruhe, Germany {foued.jrad, jie.tao, achim.streit}@kit.edu

More information

TOSCA Interoperability Demonstration

TOSCA Interoperability Demonstration Topology and Orchestration Specification for Cloud Applications (TOSCA) Standard TOSCA Interoperability Demonstration Participating Companies: Join the TOSCA Technical Committee www.oasis-open.org, join@oasis-open.org

More information

MDE Adoption in Industry: Challenges and Success Criteria

MDE Adoption in Industry: Challenges and Success Criteria MDE Adoption in Industry: Challenges and Success Criteria Parastoo Mohagheghi 1, Miguel A. Fernandez 2, Juan A. Martell 2, Mathias Fritzsche 3 and Wasif Gilani 3 1 SINTEF, P.O.Box 124-Blindern, N-0314

More information

Planning, Provisioning and Deploying Enterprise Clouds with Oracle Enterprise Manager 12c Kevin Patterson, Principal Sales Consultant, Enterprise

Planning, Provisioning and Deploying Enterprise Clouds with Oracle Enterprise Manager 12c Kevin Patterson, Principal Sales Consultant, Enterprise Planning, Provisioning and Deploying Enterprise Clouds with Oracle Enterprise Manager 12c Kevin Patterson, Principal Sales Consultant, Enterprise Manager Oracle NIST Definition of Cloud Computing Cloud

More information

cloud SOA www.cloud4soa.eu Research Guide

cloud SOA www.cloud4soa.eu Research Guide cloud SOA A Cloud interoperability framework and platform for user-centric, semantically-enhanced, service-oriented application design, deployment and distributed execution Research Guide www.cloud4soa.eu

More information

CHAPTER 2 MODELLING FOR DISTRIBUTED NETWORK SYSTEMS: THE CLIENT- SERVER MODEL

CHAPTER 2 MODELLING FOR DISTRIBUTED NETWORK SYSTEMS: THE CLIENT- SERVER MODEL CHAPTER 2 MODELLING FOR DISTRIBUTED NETWORK SYSTEMS: THE CLIENT- SERVER MODEL This chapter is to introduce the client-server model and its role in the development of distributed network systems. The chapter

More information

zen Platform technical white paper

zen Platform technical white paper zen Platform technical white paper The zen Platform as Strategic Business Platform The increasing use of application servers as standard paradigm for the development of business critical applications meant

More information

Service Oriented Architectures

Service Oriented Architectures 8 Service Oriented Architectures Gustavo Alonso Computer Science Department Swiss Federal Institute of Technology (ETHZ) alonso@inf.ethz.ch http://www.iks.inf.ethz.ch/ The context for SOA A bit of history

More information

SeaClouds Project D6.2 - Case Study test-beds and key features mapping

SeaClouds Project D6.2 - Case Study test-beds and key features mapping SeaClouds Project D6.2 - Case Study test-beds and key features mapping Project Acronym Project Title Call identifier Grant agreement no. 610531 Start Date 1 st October 2013 Ending Date 31 st March 2016

More information

AppStack Technology Overview Model-Driven Application Management for the Cloud

AppStack Technology Overview Model-Driven Application Management for the Cloud AppStack Technology Overview Model-Driven Application Management for the Cloud Accelerating Application Time-to-Market The last several years have seen a rapid adoption for public and private cloud infrastructure

More information

Business-Driven Software Engineering Lecture 3 Foundations of Processes

Business-Driven Software Engineering Lecture 3 Foundations of Processes Business-Driven Software Engineering Lecture 3 Foundations of Processes Jochen Küster jku@zurich.ibm.com Agenda Introduction and Background Process Modeling Foundations Activities and Process Models Summary

More information

WebRatio 5: An Eclipse-based CASE tool for engineering Web applications

WebRatio 5: An Eclipse-based CASE tool for engineering Web applications WebRatio 5: An Eclipse-based CASE tool for engineering Web applications Roberto Acerbis 1, Aldo Bongio 1, Marco Brambilla 2, Stefano Butti 1 1 WebModels S.r.l. Piazzale Gerbetto, 6. I22100 Como, Italy

More information

CLOUD CLOUT WITH OPEN APIS WHAT YOU SHOULD ASK OF YOUR CLOUD PROVIDER

CLOUD CLOUT WITH OPEN APIS WHAT YOU SHOULD ASK OF YOUR CLOUD PROVIDER CLOUD CLOUT WITH OPEN APIS WHAT YOU SHOULD ASK OF YOUR CLOUD PROVIDER STRATEGIC WHITE PAPER As cloud services become increasingly popular, more questions arise about the capabilities of cloud solutions.

More information

Cloud computing - Architecting in the cloud

Cloud computing - Architecting in the cloud Cloud computing - Architecting in the cloud anna.ruokonen@tut.fi 1 Outline Cloud computing What is? Levels of cloud computing: IaaS, PaaS, SaaS Moving to the cloud? Architecting in the cloud Best practices

More information

C2C: An Automated Deployment Framework for Distributed Applications on Multi-Clouds

C2C: An Automated Deployment Framework for Distributed Applications on Multi-Clouds C2C: An Automated Deployment Framework for Distributed Applications on Multi-Clouds Flora Karniavoura, Antonis Papaioannou, and Kostas Magoutis Institute of Computer Science (ICS) Foundation for Research

More information

Building the European Biodiversity. Observation Network (EU BON)

Building the European Biodiversity. Observation Network (EU BON) Enterprise Application Integration Building the European Biodiversity through Service-Oriented Architecture Observation Network (EU BON) EU BON Project Building the European Biodiversity Network Presentation

More information

1 What is Cloud Computing?... 2 2 Cloud Infrastructures... 2 2.1 OpenStack... 2 2.2 Amazon EC2... 4 3 CAMF... 5 3.1 Cloud Application Management

1 What is Cloud Computing?... 2 2 Cloud Infrastructures... 2 2.1 OpenStack... 2 2.2 Amazon EC2... 4 3 CAMF... 5 3.1 Cloud Application Management 1 What is Cloud Computing?... 2 2 Cloud Infrastructures... 2 2.1 OpenStack... 2 2.2 Amazon EC2... 4 3 CAMF... 5 3.1 Cloud Application Management Frameworks... 5 3.2 CAMF Framework for Eclipse... 5 3.2.1

More information

White Paper: Cloud for Service Providers

White Paper: Cloud for Service Providers White Paper: Cloud for Service Providers September 2011 Cloud for Service Providers This paper describes the architectural outline of an infrastructure as a Service (IaaS) cloud that Zimory built for an

More information

4 SCS Deployment Infrastructure on Cloud Infrastructures

4 SCS Deployment Infrastructure on Cloud Infrastructures 4 SCS Deployment Infrastructure on Cloud Infrastructures We defined the deployment process as a set of inter-related activities to make a piece of software ready to use. To get an overview of what this

More information

UIMA and WebContent: Complementary Frameworks for Building Semantic Web Applications

UIMA and WebContent: Complementary Frameworks for Building Semantic Web Applications UIMA and WebContent: Complementary Frameworks for Building Semantic Web Applications Gaël de Chalendar CEA LIST F-92265 Fontenay aux Roses Gael.de-Chalendar@cea.fr 1 Introduction The main data sources

More information

Where We Are. References. Cloud Computing. Levels of Service. Cloud Computing History. Introduction to Data Management CSE 344

Where We Are. References. Cloud Computing. Levels of Service. Cloud Computing History. Introduction to Data Management CSE 344 Where We Are Introduction to Data Management CSE 344 Lecture 25: DBMS-as-a-service and NoSQL We learned quite a bit about data management see course calendar Three topics left: DBMS-as-a-service and NoSQL

More information

Service Oriented Architecture 1 COMPILED BY BJ

Service Oriented Architecture 1 COMPILED BY BJ Service Oriented Architecture 1 COMPILED BY BJ CHAPTER 9 Service Oriented architecture(soa) Defining SOA. Business value of SOA SOA characteristics. Concept of a service, Enterprise Service Bus (ESB) SOA

More information

Customer Bank Account Management System Technical Specification Document

Customer Bank Account Management System Technical Specification Document Customer Bank Account Management System Technical Specification Document Technical Specification Document Page 1 of 15 Table of Contents Contents 1 Introduction 3 2 Design Overview 4 3 Topology Diagram.6

More information

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Version 9 2 SOA-2 Overview Ok, now we understand the Web Service technology, but how about Service Oriented Architectures? A guiding analogy Terminology excursion Service,

More information

Architecting for the cloud designing for scalability in cloud-based applications

Architecting for the cloud designing for scalability in cloud-based applications An AppDynamics Business White Paper Architecting for the cloud designing for scalability in cloud-based applications The biggest difference between cloud-based applications and the applications running

More information

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Charlie Abela Department of Artificial Intelligence charlie.abela@um.edu.mt Last Lecture Web Ontology Language Problems? CSA 3210 Service Oriented Architecture 2 Lecture Outline

More information

Getting Started with Service- Oriented Architecture (SOA) Terminology

Getting Started with Service- Oriented Architecture (SOA) Terminology Getting Started with - Oriented Architecture (SOA) Terminology Grace Lewis September 2010 -Oriented Architecture (SOA) is a way of designing, developing, deploying, and managing systems it is neither a

More information

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements

More information

D. SERVICE ORIENTED ARCHITECTURE PRINCIPLES

D. SERVICE ORIENTED ARCHITECTURE PRINCIPLES D. SERVICE ORIENTED ARCHITECTURE PRINCIPLES 1. Principles of serviceorientation 2. Service exchange lifecycle 3. Service composition 4. Evolution of SOA 212 D.1 Principles of service-orientation 213 HISTORICAL

More information

SysML Modelling Language explained

SysML Modelling Language explained Date: 7 th October 2010 Author: Guillaume FINANCE, Objet Direct Analyst & Consultant UML, the standard modelling language used in the field of software engineering, has been tailored to define a modelling

More information

SCADE System 17.0. Technical Data Sheet. System Requirements Analysis. Technical Data Sheet SCADE System 17.0 1

SCADE System 17.0. Technical Data Sheet. System Requirements Analysis. Technical Data Sheet SCADE System 17.0 1 SCADE System 17.0 SCADE System is the product line of the ANSYS Embedded software family of products and solutions that empowers users with a systems design environment for use on systems with high dependability

More information

Taming the Complexity of Big Data Multi-Cloud Applications with Models

Taming the Complexity of Big Data Multi-Cloud Applications with Models Taming the Complexity of Big Data Multi-Cloud Applications with Models Marcos Aurélio Almeida da Silva 1, Andrey Sadovykh 1, Alessandra Bagnato 1, Etienne Brosse 1 1 R&D Department, SOFTEAM, 9 Parc Ariane,

More information

SOA and Cloud in practice - An Example Case Study

SOA and Cloud in practice - An Example Case Study SOA and Cloud in practice - An Example Case Study 2 nd RECOCAPE Event "Emerging Software Technologies: Trends & Challenges Nov. 14 th 2012 ITIDA, Smart Village, Giza, Egypt Agenda What is SOA? What is

More information

Safe Automotive software architecture (SAFE) WP3 Deliverable D3.6.b: Safety Code Generator Specification

Safe Automotive software architecture (SAFE) WP3 Deliverable D3.6.b: Safety Code Generator Specification Contract number: ITEA2 10039 Safe Automotive software architecture (SAFE) ITEA Roadmap application domains: Major: Services, Systems & Software Creation Minor: Society ITEA Roadmap technology categories:

More information

Cloud Computing. Adam Barker

Cloud Computing. Adam Barker Cloud Computing Adam Barker 1 Overview Introduction to Cloud computing Enabling technologies Different types of cloud: IaaS, PaaS and SaaS Cloud terminology Interacting with a cloud: management consoles

More information

Data Integration Checklist

Data Integration Checklist The need for data integration tools exists in every company, small to large. Whether it is extracting data that exists in spreadsheets, packaged applications, databases, sensor networks or social media

More information

Amit Sheth & Ajith Ranabahu, 2010. Presented by Mohammad Hossein Danesh

Amit Sheth & Ajith Ranabahu, 2010. Presented by Mohammad Hossein Danesh Amit Sheth & Ajith Ranabahu, 2010 Presented by Mohammad Hossein Danesh 1 Agenda Introduction to Cloud Computing Research Motivation Semantic Modeling Can Help Use of DSLs Solution Conclusion 2 3 Motivation

More information

IaaS Cloud Architectures: Virtualized Data Centers to Federated Cloud Infrastructures

IaaS Cloud Architectures: Virtualized Data Centers to Federated Cloud Infrastructures IaaS Cloud Architectures: Virtualized Data Centers to Federated Cloud Infrastructures Dr. Sanjay P. Ahuja, Ph.D. 2010-14 FIS Distinguished Professor of Computer Science School of Computing, UNF Introduction

More information

Georgiana Macariu, Dana Petcu, CiprianCraciun, Silviu Panica, Marian Neagul eaustria Research Institute Timisoara, Romania

Georgiana Macariu, Dana Petcu, CiprianCraciun, Silviu Panica, Marian Neagul eaustria Research Institute Timisoara, Romania Open source API and platform for heterogeneous Cloud computing environments Georgiana Macariu, Dana Petcu, CiprianCraciun, Silviu Panica, Marian Neagul eaustria Research Institute Timisoara, Romania Problem

More information

Analysis of existing Cloud technologies and Cloud modelling concepts and prototype requirements

Analysis of existing Cloud technologies and Cloud modelling concepts and prototype requirements Grant Agreement N FP7-318484 Title: Authors: Editor: Reviewers: Analysis of existing Cloud technologies and Cloud modelling concepts and prototype requirements Nicolas Ferry (SINTEF), Arnor Solberg (SINTEF),

More information

EnergySync and AquaSys. Technology and Architecture

EnergySync and AquaSys. Technology and Architecture EnergySync and AquaSys Technology and Architecture EnergySync and AquaSys modules Enterprise Inventory Enterprise Assets Enterprise Financials Enterprise Billing Service oriented architecture platform

More information

Cloud Models and Platforms

Cloud Models and Platforms Cloud Models and Platforms Dr. Sanjay P. Ahuja, Ph.D. 2010-14 FIS Distinguished Professor of Computer Science School of Computing, UNF A Working Definition of Cloud Computing Cloud computing is a model

More information

Cloud Computing & Service Oriented Architecture An Overview

Cloud Computing & Service Oriented Architecture An Overview Cloud Computing & Service Oriented Architecture An Overview Sumantra Sarkar Georgia State University Robinson College of Business November 29 & 30, 2010 MBA 8125 Fall 2010 Agenda Cloud Computing Definition

More information

Model Driven Performance Simulation of Cloud Provisioned Hadoop MapReduce Applications

Model Driven Performance Simulation of Cloud Provisioned Hadoop MapReduce Applications Model Driven Performance Simulation of Cloud Provisioned Hadoop MapReduce Applications Hanieh Alipour, Yan Liu Concordia University Montreal.Canada h_alipou@encs.concordia.ca; yan.liu@concordia.ca Abdelwahab

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2008 Vol. 7, No. 8, November-December 2008 From The Business Motivation Model (BMM)

More information

A Collection of Patterns for Cloud Types, Cloud Service Models, and Cloud-based Application Architectures

A Collection of Patterns for Cloud Types, Cloud Service Models, and Cloud-based Application Architectures Universität Stuttgart Fakultät Informatik, Elektrotechnik und Informationstechnik A Collection of Patterns for Cloud Types, Cloud Service Models, and Cloud-based Application Architectures Christoph Fehling

More information

Setting Up an AS4 System

Setting Up an AS4 System INT0697_150625 Setting up an AS4 system V1r0 1 Setting Up an AS4 System 2 Version 1r0 ENTSOG AISBL; Av. de Cortenbergh 100, 1000-Brussels; Tel: +32 2 894 5100; Fax: +32 2 894 5101; info@entsog.eu, www.entsog.eu,

More information

SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) SERVICE-ORIENTED LOGICAL DESIGN MODEL LANGUAGE SPECIFICATIONS

SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) SERVICE-ORIENTED LOGICAL DESIGN MODEL LANGUAGE SPECIFICATIONS SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) VERSION 2.1 SERVICE-ORIENTED LOGICAL DESIGN MODEL LANGUAGE SPECIFICATIONS 1 TABLE OF CONTENTS INTRODUCTION... 3 About The -Oriented Modeling Framework (SOMF)...

More information

UPDATING RM-ODP BY INTEGRATION OF SOA AND CLOUD COMPUTING

UPDATING RM-ODP BY INTEGRATION OF SOA AND CLOUD COMPUTING UPDATING RM-ODP BY INTEGRATION OF SOA AND CLOUD COMPUTING MOSTAFA JEBBAR, OTHMAN BENAMMAR and ABDERRAHIM SEKKAKI Department of Mathematics and Computer Science University Hassan II, Aïn Chock, Faculty

More information

Bridge Development and Operations for faster delivery of applications

Bridge Development and Operations for faster delivery of applications Technical white paper Bridge Development and Operations for faster delivery of applications HP Continuous Delivery Automation software Table of contents Application lifecycle in the current business scenario

More information

D3.3.1: Sematic tagging and open data publication tools

D3.3.1: Sematic tagging and open data publication tools COMPETITIVINESS AND INNOVATION FRAMEWORK PROGRAMME CIP-ICT-PSP-2013-7 Pilot Type B WP3 Service platform integration and deployment in cloud infrastructure D3.3.1: Sematic tagging and open data publication

More information

Applying MDA in Developing Intermediary Service for Data Retrieval

Applying MDA in Developing Intermediary Service for Data Retrieval Applying MDA in Developing Intermediary Service for Data Retrieval Danijela Boberić Krstićev University of Novi Sad Faculty of Sciences Trg Dositeja Obradovića 4, Novi Sad Serbia +381214852873 dboberic@uns.ac.rs

More information

A Marketplace Broker for Platform-as-a-Service Portability

A Marketplace Broker for Platform-as-a-Service Portability Seamless Adaptive Multi-cloud Management of Service-based Applications Workshop at ESOCC 14, Manchester, UK A Marketplace Broker for Platform-as-a-Service Portability Bholanathsingh Surajbali and Adrian

More information

HP OpenStack & Automation

HP OpenStack & Automation HP OpenStack & Automation Where we are heading Thomas Goh Cloud Computing Cloud Computing Cloud computing is a model for enabling ubiquitous network access to a shared pool of configurable computing resources.

More information

Amazon Web Services Primer. William Strickland COP 6938 Fall 2012 University of Central Florida

Amazon Web Services Primer. William Strickland COP 6938 Fall 2012 University of Central Florida Amazon Web Services Primer William Strickland COP 6938 Fall 2012 University of Central Florida AWS Overview Amazon Web Services (AWS) is a collection of varying remote computing provided by Amazon.com.

More information