Automatic, multi- grained elasticity- provisioning for the Cloud Application Description Tool V1 Deliverable no.: 2.1 Date: 29-07- 2013 CELAR is funded by the European Commission DG- INFSO Seventh Framework Programmed, Contract no.: 317790
Table of Contents 1 Introduction... 8 1.1 Purpose of this document... 9 1.2 Document Structure... 9 2 State of the Art in Cloud Application Description... 10 2.1 Proprietary Cloud Application Management Platforms... 10 2.2 Generic Cloud Application Management Platforms... 11 2.3 Application Description Specifications... 12 3 Application Description Tool... 14 3.1 Actors... 14 3.2 Use Cases... 16 3.3 Functional Requirements... 17 3.4 Non-functional Requirements... 18 4 Design Concepts... 19 4.1 Application Structure... 19 4.2 Application Description... 20 4.2.1 Elasticity Requirements/Capabilities Specification... 20 4.2.2 Deployment Artifacts Specification... 21 4.2.3 Data/Load Hints Specification... 21 4.3 Create Application Description... 22 4.3.1 Creating a new CELAR project... 22 4.3.2 Creating a new Application Description... 23 4.3.2.1 Application Description Wizard... 23 4.3.2.2 Graphical Editor... 25 4.3.2.3 Palette... 25 4.3.2.4 Canvas... 28 4.3.2.5 Properties View... 29 5 Towards the Implementation of the CELAR Application Description Tool... 33 5.1 c-eclipse Architecture... 33 5.1.1 c- Eclipse Core... 34 5.1.2 Authentication Mechanism... 35 5.1.3 UI components... 35 5.2 Application Description Tool Development... 35 5.2.1 Eclipse Modeling Framework... 35 5.2.2 Graphiti... 35 5.3 Graphiti Architecture... 36 6 GitHub Repository... 38 7 Conclusions... 39 References... 40 2 / 41
List of Figures Figure 1: CELAR System Architecture... 8 Figure 2: Application Description Tool Workflow... 15 Figure 3: Abstract Application Composition Model... 20 Figure 4: CELAR Project... 22 Figure 5: New Application Description Wizard... 24 Figure 6: Graphical Editor... 25 Figure 7: Palette... 26 Figure 8: Canvas... 28 Figure 9: Application Properties View... 29 Figure 10: Application Component Properties View... 30 Figure 11: Composite Application Component Properties View... 31 Figure 12: Relationship Properties View... 32 Figure 13: c- Eclipse Architecture... 34 Figure 14: Graphiti Architecture [Graphiti Intro]... 36 3 / 41
List of Tables Table 1: Use Cases... 16 4 / 41
List of Abbreviations IaaS PaaS TOSCA SYBL VM XML GUI DB EMF GEF GMF Infrastructure as a Service Platform as a Service Topology and Orchestration Specification for Cloud Applications Simple Yet Beautiful Language Virtual Machine Extensible Markup Language Graphical User Interface Database Eclipse Modeling Framework Graphical Editing Framework Graphical Modeling Framework 5 / 41
Deliverable Title Filename Author(s) Date Application Description Tool V1 CELAR_d2.1_finalrelease.docx Nicholas Loulloudes, Stalo Sofokleous, Demetris Trihinas, George Pallis, Marios D. Dikaiakos 29.07.2013 Start of the project: 1.10.2012 Duration: 36 Months Project coordinator organisation: ATHENA RESEARCH AND INNOVATION CENTER IN INFORMATION COMMUNICATION & KNOWLEDGE TECHNOLOGIES (ATHENA) Deliverable title: Deliverable no.: Application Description Tool V1 2.1 Due date of deliverable: Actual submission date: 31 July 2013 29 July 2013 Dissemination Level X PU Public PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services) Deliverable status version control Version Date Author 1.0 29 July, 2013 Nicholas Loulloudes, Stalo Sofokleous, Demetris Trihinas, George Pallis, Marios D. Dikaiakos 0.4 26 July, 2013 Nicholas Loulloudes, Stalo Sofokleous, Demetris Trihinas, George Pallis, Marios D. Dikaiakos 0.3 9 July, 2013 Nicholas Loulloudes, Stalo Sofokleous, Demetris Trihinas, George Pallis, Marios D. Dikaiakos 0.2 3 July, 2013 Nicholas Loulloudes, Stalo Sofokleous 0.1 30 June, 2013 Nicholas Loulloudes, Stalo Sofokleous 6 / 41
Abstract The aim of this document is to present the development lifecycle of the first version of the Application Description Tool. The purpose and functionalities of the tool, together with the implementation approach used are described in detail. Furthermore, a study of the State of the Art in software frameworks, unified environments and related standards that facilitate the description of cloud application features is performed. Keywords Application Description Tool, Eclipse, c- Eclipse, TOSCA, Submission, Cloud Computing, Graphiti 7 / 41
1 Introduction The CELAR project aims at developing an integrated and complete system that will provide automatic, multi- grained resource allocation for Cloud applications, resulting thereby to the commitment of just enough computing and storage resources. In turn, these innovative capabilities will result in the optimal use of the infrastructure and minimization of administrative costs from the Cloud provider and end- user perspectives, respectively. This elastic resource adaptation will be provided through intelligent decision- making processes that exploit multi- layer information sources dedicated to the application requirements, runtime demand and performance. The CELAR System architecture, introduced and described extensively in Deliverable 1.1 [D1.1] (depicted in Figure 1), is comprised of three main parts: (i) the Application Management Platform, (ii) Cloud Information and Performance Monitor, and (iii) Elasticity Platform. The focus of WP2, is the development of the complete Application Management Platform that will not only function as the interface of end- users with the system, but will serve as that information source through which application features and requirements will be made available to the resource provisioning and decision- making components. The Application Management Platform, called c-eclipse, contains the necessary graphical tools that will ultimately enable users to describe the application topology and model elasticity requirements in a high- level manner, submit the application to the underlying platform for deployment and execution, and finally monitor its complete life cycle. As the name suggests, c- Eclipse will be implemented on top of the reliable Eclipse platform [Eclipse], and will follow its plug- in based architecture. Application Management Platform Application Description Application Submission Information System Cloud Information and Performance Monitor Interceptor Monitoring System Multi- level Metrics Evaluation SaaS / Pass IaaS Physic al Layer Custom Applications Services VM VM Custom App 1 HBase Cassandra Cluster VM VM Custom App 2 Hive VM Hadoop Custom App 3 Other VS Storage VS Elasticity Platform Application Orchestration Resource Provisioner Cloud Orchestration Application Profiler Decision Module CELAR Manager CELAR DataBase Cloud Provider Figure 1: CELAR System Architecture 8 / 41
c- Eclipse takes advantage of the Eclipse GUI that thousands of users around the world are accustomed to and utilize extensively on a daily basis. The intuitive and user- friendly GUI, through which CELAR users will interact with the system, will be able to minimize any complexity regarding the process of application description, submission and monitoring. The aim is to provide a powerful and extensible toolset that will facilitate all user interactions with the system. This will result in a low- entry barrier for end- users who are new to Cloud technologies, while simultaneously improve the workflow efficiency of experienced users. Moreover, by integrating c- Eclipse to the Eclipse eco- system the CELAR project targets to: (i) achieve its long- term sustainability through a strong international user and developer backed community and (ii) increase the project visibility and improve its rate of adoption. 1.1 Purpose of this document The aim of this document is to present the first version (v1.0) of the Application Description Tool and the advancements performed until month 10 that will ultimately lead towards the provision of the complete c- Eclipse Application Framework. Specifically, this document will present the initial version of the c- Eclipse core architecture and the development of the Application Description Tool on top of the Eclipse architecture. The functional and non- functional requirements are defined, and all necessary internal modules are described. 1.2 Document Structure The rest of the document is structured as follows: Section 2 presents the State of the Art in software frameworks, unified environments and related standards that facilitate the description of cloud application features and requirements. Section 3, presents the concepts of the Application Description Tool, in accordance with actors, the use- cases driven by these actors and the respective functional and non- functional requirements. Section 4 focuses on the design concepts of the Application Description tool along with screen shots that provide a look and feel of the UI. Section 5, documents all the implementation specific details of the c- Eclipse Framework and the Application Description tool. The last section concludes the deliverable and outlines the future work. 9 / 41
2 State of the Art in Cloud Application Description Cloud environments, in contrast to traditional high- performance distributed computing environments such as the Grid, are inherently dynamic and empowering. The capability to provision computing, storage and networking resources enables Cloud users to deploy virtualized resources on- demand, in order to meet the workload of their applications. In addition, access and control to the full software stack, from the operating system upwards, allows users to customize the execution environment to better suit the functional requirements of application. However, these impose a level of complexity and additional effort from the user perspective, required to properly configure ( contextualize ) and deploy a specific application [Keahey 2008]. Inevitably, this additional effort is both, time consuming and error prone, if we consider that certain applications require the deployment of a large number of virtualized instances, which often have complex inter- dependencies. Furthermore, by including resource elasticity in the equation, where virtualized instances need to be deployed or re- configured adaptively ( re- contextualization ) based either on the current workload or various governance policies, introduces further overhead and new challenges [Marshall 2012]. It is evident therefore that there is a need for powerful tools that facilitate the automatic provisioning, configuration, deployment and management of applications in a systematic manner. This chapter presents the state- of- art in such Application Management platforms and Application Description specifications. 2.1 Proprietary Cloud Application Management Platforms VMware s vcloud Suite [VCloud] provides a complete integrated solution that enables service provisioning for organizations that wish to deploy their own private or hybrid Cloud infrastructures, using VMware s proprietary virtualization technologies (i.e. VMware vsphere). The suite provides all the necessary functionality both, for IT teams to build and deploy complete and agile Cloud infrastructures, and also for end- users that require rapid access to virtualized resources so as to deploy and manage their own Cloud workloads. The vfabric Application Director [VFabric] is among the products offered in the vcloud suite, and provides the necessary tooling for simplifying the process where application architects/developers/users assemble, provision, deploy and manage Cloud applications. vfabric Application Director employs a canvas with drag- and- drop capabilities through which any of the aforementioned actors can create complete application topologies/blueprints. Via a catalog service, architects can accelerate the process of designing their application by choosing available logical templates (i.e. base or customized O/S images), middleware services (i.e. Web or Database server) and application components that sit on top of middleware services (i.e. WAR files). Moreover, vfabric allows the specification of execution plans (series of scripts) for unattended installation and configuration of various software components of the application. Along similar lines, Oracle s Virtual Assembly Builder [OVAB] tool allows the description of the complete topology of a multi- tier application. Even further, it allows a user to capture the individual components that comprise the specific application environment, into self- contained VM templates (appliances). The templates themselves expose properties associated with each application component (e.g. Web server ports, endpoints for data input/output all described in metadata files), thus allowing wiring 10 / 41
among them as building blocks of a complete application. Once these appliances are assembled with the aid of a drag- and- drop visual interface (client- side), they are passed to a deployment server who is responsible to instantiate them on Oracle s Exalogic Elastic Cloud infrastructure. OVAB is geared towards optimizing applications from the Oracle product family, however a generic framework is provided for any kind of application. In contrast to vfabric and OVAB, c- Eclipse aims at providing a non- proprietary application framework through which interested parties will be able to describe their generic application topology and subsequently submit it to one or more private or public Cloud providers for deployment. It will sport a similar unified working environment, on the client- side, in which all Cloud application- related tasks can be efficiently and effectively executed through the help of various sub- components. Among those sub- components, key is the Application description editor that will feature a drag- and- drop, catalog- to- canvas, functionality in order to capture the application topology in a seamless and intuitive manner. 2.2 Generic Cloud Application Management Platforms The Agility Platform by ServiceMesh [ServiceMesh] enables the automatic deployment and management of Cloud applications/services across private, public and hybrid Cloud providers through a fully integrated offering. The core platform provides the necessary mechanisms that allow the management, governance and orchestration of Cloud applications in a consolidated manner. Specifically, the core platform has a broad range of capabilities including among other, (i) a dedicated engine for the creation and enforcement of a large number and complex governance, compliance and security policies ranging from user permissions to financial constraints, (ii) a comprehensive security model that enables federated identity management across the network, virtual instances and data, (iii) an orchestration engine for deploying complex cloud workload across heterogeneous public/private Cloud providers, including Amazon, VMware, Windows Azure, Rackspace, etc. In addition to the above core capabilities, the Agility Platform includes a number of web- based versatile product modules that collectively provide end- to- end lifecycle management of Cloud workloads. Key among them is the Designer module that provides a graphical workbench, enabling the rapid description from simple stack to complex multi- tier application blueprints and topologies. Similar in concept with the vfabric Application Director, ServiceMesh s Designer graphical environment provides the necessary tooling in the form of a drag- and- drop editor for designing and assembling complex workloads specification of application configuration controls, auto- scaling rules, governance and security controls, as well as various operating utilities. Similar to the concept of the Information System [D1.1 Section 3.3.1.4] that will be made available at a later stage via the c- Eclipse framework, the Designer includes a library for publishing re- usable base images, packages, customization templates, scripts, blueprints and policies in order to accelerate the design and deployment process of Cloud applications. Likewise, Wrangler [Juve 2012] provides a system for automatic deployment and monitoring of distributed applications with complex dependencies on different Cloud infrastructures. Through a dedicated XML language, users can describe an application deployment; characteristics of the virtual resources to be provisioned (CPU, memory, disk), specific virtual machine images, plugin parameters, authentication credentials; and consequently send it to a web service that uptakes the role of the 11 / 41
coordinator. Upon reception of the description, the coordinator provisions nodes at the Cloud provider, collects deployment logs and acts as a broker for application configuration. Each virtual instance includes one or more plugins (i.e. user- specified scripts) that define the services and functionality to be implemented by the node upon deployment. Nevertheless, the dedicated XML language utilized in Wrangler, limits the portability of application deployments to those compliant providers that are able to understand its semantics. To avoid this provider lock- in and promote portability, c- Eclipse capitalizes and depends on the use open- source standards (see Section 2.3 below). Dell s Multi-Cloud Manager (formerly known as Enstratius) [Enstratius] provides Cloud automation, security and governance for enterprises. Following Software as a Service (SaaS) model, it facilitates the deployment, monitoring and elasticity of applications across leading public, private and hybrid Cloud infrastructures establishing thereby independence (avoid lock- in) from Cloud providers. The system provides a web- based, unified solution that establishes a management environment for enterprise applications running on multiple Cloud infrastructures. SlipStream [SlipStream] by SixSq, is also a multi- cloud coordinated provisioning engine, provided as a Platform as a Service (PaaS). It provides a multi- machine provisioning system for defining and executing deployments based on cloud provider agnostic recipes. From within a unified web- based service, application users have the capability to deploy different parts of their application on separate Cloud providers to accommodate various resilience and redundancy of even running cost requirements. Slipstream uses connector architecture to communicate to a number of open- source (i.e. OpenStack) and proprietary (i.e. Amazon AWS) IaaS providers. 2.3 Application Description Specifications The Topology and Orchestration Specification for Cloud Applications (TOSCA) [TOSCA] proposed by the Organization for the Advancement of Structured Information Standards (OASIS) aims at standardizing and enhancing the portability of Cloud Application and services that run on complex software and hardware infrastructures. Specifically, it provides the necessary service level abstractions that enable the interoperable description of Cloud applications/service, the relationships between various components, and subsequently the operational behavior of these components (i.e. deploy, install, run, shutdown, etc.), while at the same time being agnostic of the Cloud provider and its underlying hardware technology. Ultimately, the goal of TOSCA is to avoid lock- in of application users/developers to a specific Cloud provider, thereby supporting portable deployment to compliant providers and easy migration of existing application to the Cloud. To summarize, c- Eclipse aims to provide a generic Application Framework through which architects/developers/users will be able to define, customize and monitor the provisioning and deployment cycles of their elastic Cloud applications. c- Eclipse capitalizes its success as a generic Cloud Application Framework on two key factors: (i) the utilization of the open-source Eclipse environment as the underlying development platform, and (ii) the adoption of the open-source, non-proprietary, TOSCA specification as the de- facto language for describing the provision, deployment and re- contextualization of elastic applications across different Cloud infrastructures. On one hand, the underlying Eclipse platform will guarantee the availability of an integrated workbench with the necessary toolset via which application developers will be able to describe the features and dependencies of their Cloud applications in an 12 / 41
intuitive graphical manner. Furthermore, since Eclipse is considered as one of the most widely adopted integrated development environments (IDE s) with extended support for several programming languages, it can potentially serve as a unified environment where Cloud applications are developed and then are seamlessly handed to c- Eclipse modules for deployment. On the other hand, the TOSCA specification will assure the interoperable description of applications/services, the relationships between their various components, and subsequently the operational behavior of these components, across different and heterogeneous Cloud infrastructures. 13 / 41
3 Application Description Tool The c- Eclipse application framework consists of several modules, as shown in Figure 1, one of which is the Application Description Tool. The purpose of the Application Description Tool is to enable the description of the structure, elasticity requirements and other behavioral features of the application to be run over a Cloud platform. This information is required for: The Resource Provisioner [D3.1 Section 4.2.1] to deploy the application on the selected Cloud platform The Decision Module [D5.1 Section 4] to find the initial best deployment for the described application, and decide how and when the application should be elastically scaled during its lifetime This chapter presents the use cases for the Application Description Tool, similar to the use cases presented in the CELAR Deliverable D1.1 [D1.1 Section 2.3.2]. The first section presents the different actors that interact with the Application Description Tool to provide information to it, or retrieve information from it. The second section focuses on the use cases of the tool explaining how the defined actors interact with the Application Description Tool. The chapter closes with a description of the functional and non- functional requirements for the Application Description Tool. 3.1 Actors The Application Description Tool requires input from the Application User in order to facilitate the process of application deployment and the decision- making process. In general, the Application Description Tool will provide an intuitive graphical user interface (GUI) that will enable the Application User to describe its application in an efficient way. Consequently, the graphical application description will be translated into an XML specification, an extension of the TOSCA specification enriched with elasticity requirements and capabilities. The XML application description will be forwarded via the Application Submission Tool [D1.1 Section 3.3.1.3] to the CELAR Manager [D1.1 Section 3.3.2.4] of the underlying CELAR System, see Figure 2. To this extent, the Application Description Tool interacts with the c- Eclipse Application Submission Tool and with two external entities, the Application User and the CELAR Manager. Application User The Application User [D1.1 Section 2.3.1] is a person that is knowledgeable about an application to be submitted for execution to the CELAR platform. His goal is to describe, deploy and monitor an application using CELAR. The Application User is a generalization of the Application Owner and the Application Expert/Developer: Application Owner: The Application Owner is a user responsible to define high- level application requirements, such as cost and performance policies that govern the elastic decisions made by the CELAR platform. The Application User can define or update the optimization criteria under which elastic actions will be taken. Application Expert/Developer: The Application Expert is a person aware of the application s structure, execution environment and history, etc. The Application Expert can provide CELAR with low- level elasticity requirements and behavioral details for the application components that constitute the application description. 14 / 41
CELAR Manager The CELAR Manager interacts with the Application Description Tool providing it with information stored in the CELAR DataBase [D1.1 Section 3.3.2.3] about the services offered by the Cloud providers, such as VM images and elasticity actions, and the services offered by the CELAR System, such as monitoring probes. Application Submission Tool The Application Description Tool translates the graphical application description given by the Application User into the extended TOSCA specification and passes it to the Application Submission Tool. The Application Submission Tool enriches the description with deployment and orchestration information, and sends it to the CELAR Manager which in turn forwards the description to the interested parties, the Resource Provisioner and the Decision Module. Figure 2: Application Description Tool Workflow 15 / 41
3.2 Use Cases The following table gives an overview of the Application Description Tool Use Cases: Table 1: Use Cases Use Case Name Actor Description 1 Get Cloud provider CELAR Manager The Application Description Tool Information request information about the resources offered by the Cloud providers, such as VM images and 2 Get CELAR System Information 3 Describe Application Structure/Topology 4 Describe High- Level Elasticity Requirements 5 Set Optimization Policy 6 Describe Low- Level Elasticity Requirements 7 Describe Elasticity Capabilities CELAR Manager Application Expert/Developer elasticity actions. The Application Description Tool request information about the resources offered by the CELAR System, such as available monitoring probes. Structural description of the application provides information to the platform about the application's topology (number and types of application components and the relationships between them). Application Owner Define the high- level cost and performance application requirements. Application Owner Set the application s optimization policy; is used by the CELAR Decision Module to optimize the application's metrics that are more important to the Application User. Application Expert/Developer Application Expert/Developer 8 Describe Data/Load Application Expert/Developer 9 Describe Monitoring Probes Application Expert/Developer Define the complex/low- level elasticity requirements in order to provide information about the application's elastic behavior towards elasticity actions. Define the actions that can be enforced to the application components in order to achieve elastic behavior e.g. scaling actions and reconfiguration actions. Provide data and load hints that are going to be used by CELAR and help the Profiler predict the application's behavior under different amount of skew, read/write/update schemes, load, etc. Define the application metrics to be monitored during application 16 / 41
10 Set Deployment Parameters 11 Forward Application Description Application Expert/Developer Application Submission Tool deployment/execution. Set deployment details (e.g. VM images, deployment scripts) in order to be used by CELAR to initialize the configuration of application components and orchestrate them in the physical level. The Application Description Tool translates the graphical application description given by the Application User into the extended TOSCA specification and then passes it to the Application, Submission Tool. 3.3 Functional Requirements The following section presents the functional requirements of the Application Description Tool that derive from the previous use cases along with the general CELAR use cases as described in the Deliverable 1.1 [D1.1]: Application Description Creation Application Users should be able to provide, via a graphical interface, meaningful information about the application to be deployed and elastically managed by CELAR. In order to assist CELAR and accommodate the general application case, a minimum set of hints relating to the structure of the application, its dependencies, sample elasticity requirements/capabilities and load/data usage are expected to be provided. Furthermore, Application Users must select the appropriate VM image for each application component. The user will be able to pick one of the base VM images available from the Cloud provider. Alternatively, he can use custom machine images built and configured over base images. Building and configuring custom image snapshots is a job aided by automated tools such as veewee [Veewee], BoxGrinder [BoxGrinder] and SlipStream s New Machine Image feature [StratusLab]. Application Description Translation The Application Description Tool should be able to translate the graphical application description given by an Application User into a specification that can be parsed and processed by the CELAR Manager and/or other CELAR modules. The specification that will be used for this purpose is the TOSCA specification that must be extended to include elasticity requirements and capabilities in addition to the topology and other information provided by TOSCA. The translation process should be done automatically without any Application User intervention. Customizable Application Description Application Users might want to run their application on another Cloud provider, because that provider became cheaper. Or they can choose to re- deploy their application on the same provider but with different structure details in case users demands have changed. To this extent, Application Users should be able to adjust their application descriptions in various ways; for example, an Application User should be able to change 17 / 41
the structure of an application, add/remove application components and relationships, or change the VMs or monitoring probes for their application components. They should also be able to change the elasticity requirements and capabilities governing their application behavior, and to dynamically alter the important metrics that will be reported to them. 3.4 Non- functional Requirements The following section presents the non- functional requirements resulting from the above functional requirements of the Application Description Tool: Abstraction The CELAR System will be implemented by a number of different Cloud providers. In order to achieve this, the Application Description Tool must offer a high level of abstraction regarding the application description process. This means that Application Users must be able to describe their applications in a very generic way, so that an application description can be submitted for deployment to any Cloud provider offering CELAR. Robustness The Application Description Tool shall be able to cope with unexpected situations, like incomplete or erroneous input data. Since the Application Description Tool provides important information to other CELAR modules, it is a responsibility of the tool to ensure the correctness and completeness of this information. Thus, incomplete or erroneous application descriptions will be considered when designing the Application Description Tool, and appropriate error messages will be prompt to the Application User until the provided application description is complete and unambiguous. Wide Applicability To ensure a wider usage of the CELAR System after the end of the project by different organizations and environments, it is necessary to develop a system that is portable, easy to deploy and maintain, intuitive to use and extend. To this extent, open standards and platform independent languages, libraries and tools, should be utilized for the development of the Application Description Tool. User- friendliness The Application Description Tool is the CELAR s interface that allows Application Users to interact with the CELAR System. Thus, it is very important to ensure that the Application Description Tool is designed in a user- friendly and user- intuitive manner: Application Users should not be forced to input information unknown to them, and the tool should provide useful hints that will assist Application Users throughout the application description process. 18 / 41
4 Design Concepts The aim of the Application Description Tool is to enable users to describe first the elasticity requirements of their application which is to be executed over a Cloud platform, together with any scaling/reconfiguration actions that should be applied to the application in order to meet these requirements. Secondly, the Application User should be able to describe the deployment artifacts required for the application s deployment. Moreover, Application Users must be able to register the performance metrics of importance for their application so that they will be able to monitor these metrics during application s execution. This chapter presents the main concepts for describing a Cloud application using the c- Eclipse Application Description Tool. This chapter presents the main aspects of the application description process. The concept of the application structure is given first, followed by an explanation of the core application description elements. These elements are the elasticity requirements and capabilities, the deployment artifacts and the data/load hints. The rest of the chapter guides the reader throughout the process of describing an application using the c- Eclipse Application Description Tool. 4.1 Application Structure In order to describe an application in a way that is meaningful to all CELAR modules, a common composition- based model for describing the application s structure has been defined. This model is described in detail in Deliverable 5.1[D5.1 Section 4.1.1] and is generic enough, mapping different application types, while still complying with the proposed representations by different standardizing institutions such as TOSCA. The abstract application composition model is used by the Resource Provisioner to initially deploy the application and by the Decision Module for building a current application model considering application structure and system- level information like how components of the application communicate at runtime or what is the type of relationship between application components. As shown in Figure 3, a Cloud application is decomposed into smaller- subparts and consists of component, relationship, composite component, and cloud application. A component represents any kind of module or unit encapsulating functionality or data. This view is generic enough to facilitate the modeling of different types of applications and systems (i.e. web services, software package and web resource), each with different views on the units or modules the application is composed of. A group of components together with the relationships between them can be modeled as a composite component, a cloud application being composed of one or more complex components. The composite component is not physically represented at runtime; it is only a representational concept helping with the cloud application control. 19 / 41
Figure 3: Abstract Application Composition Model 4.2 Application Description The first step in describing an application is to define the application structure, or topology, following the abstract application composition- based model presented in Section 4.1. Then all the information required for the application description must be structured according to the application model, depending on which part of the application the information is connected to. Thus, there are 3 levels at which application- related information can be connected to: Application Level: Information about the entire Cloud application. Component Level: Information about a single application component. Composite Component Level: Information about a group of application components, or a composite application component. Once the application structure is defined, the elasticity requirements, elasticity capabilities, deployment artifacts and other application behavioral characteristics, such as data and load hints, must be specified for each one of the 3 levels described above: 4.2.1 Elasticity Requirements/Capabilities Specification The purpose of the elasticity requirements, as explained in [D5.1 Section 4.1.2], varies from controlling costs to achieving higher quality or even specifying demands on the relation between cost, resources and quality. An Application User can either specify just the elasticity requirements that must be met by the application deployment, or he can also specify detailed elasticity capabilities. The elasticity capabilities for an application include the elasticity actions (scaling/reconfiguration actions) and the application level at which they must be applied for elastically adapting the application at runtime based on the specified elasticity requirements [D5.1 Section 4.2.1.2]. Some examples of elasticity requirements depending on the elasticity type are presented below: Cost-related elasticity requirements: An Application Owner may specify that when the total cost is higher than 800 Euro for a number of clients, there should be a scale- in action for keeping costs within acceptable limits. 20 / 41
Quality-related elasticity requirements: An Application User may need to monitor different quality parameters, which should be within acceptable limits. For instance, an Application Owner can specify a response time requirement depending on the number of users currently accessing the provided software. An Application Developer could specify that the result from a data analytics algorithm must reach a certain data accuracy under a cost requirement, without caring how many resources should be used for executing the code of that algorithm. There will be a predefined list of elasticity requirements supported by CELAR from which an Application User can choose. The chosen elasticity requirements with all the related information, such as thresholds and elasticity actions, will be translated by the Decision Module into SYBL, [D5.1 Section 4.3.1]. The Decision Module will use SYBL to decide when a requirement is triggered and which elasticity action is the most appropriate each time. 4.2.2 Deployment Artifacts Specification For each component in the application structure, the required artifacts for materializing an instance of the component and for supporting that instance s execution lifetime must be specified. The VM image is the core deployment artifact for an application component. Apart from the VM image, the Application User can specify a set of deployment scripts containing bootstrapping and configuration commands. Another type of deployment artifacts are the necessary custom- made executable files required for the materialization of a specific application component s instance. The deployment artifacts, VM images, deployment scripts and other application- specific executables are created outside the c- Eclipse and published in a repository which can be accessed by the Resource Provisioner using the Application User s credentials. These artifacts can then be imported to the Application Description Tool and they can be specified in an application description by references that point to the location from where the artifacts can be retrieved. The same happens with the scaling/reconfiguration action scripts specified in the elasticity capabilities [Section 4.2.1]. 4.2.3 Data/Load Hints Specification The Application User can give data/load hints about each application component in the application structure. This information is useful to the Application Profiler [D3.1 Section 4.2.3] for allowing the monitoring and measurement of the application s behavior over representative resource provisioning and load scenarios. This way, CELAR will form a clear model of the elasticity, cost and performance properties on a per application component basis. Collected information will form the basis of the learning knowledge required by the Decision Module in order to avoid forcing wrong elasticity actions caused by lack of application knowledge. Furthermore, the load hints given by the Application User will assist the Profiler in generating the application load that will stress out the deployed application configurations. Different load types, e.g. read only, write only, read/write etc. can be given by the Application User. There will be a predefined list of data and load hints from which the Application User will be able to choose the most appropriate. If the expected load is not known or it cannot be estimated, the Profiler will create a number of representative (or random) loads in order to identify the application s behavior on a per component basis. At any case, the Profiler using a generic load generator module will produce the required load needed to test each deployment. 21 / 41
4.3 Create Application Description This section describes how to use the c- Eclipse Application Description Tool to get a Cloud application ready to be submitted to CELAR for deployment. A new CELAR Project must be created first, where all the application related details will be stored, and then the application description must be created. 4.3.1 Creating a new CELAR project A CELAR project provides a placeholder for an Application User to organize any files and scripts that are required for the description of a particular application. Therefore, there is a 1- to- 1 relationship between a CELAR project and a Cloud application. An Application User can create a new CELAR Project by filling in the New -> CELAR Project wizard. As shown in Figure 4, a CELAR project in c- Eclipse consists of the following folders: Figure 4: CELAR Project Application Descriptions: Contains the Application Users descriptions of a particular application. More than one description can be created for an application. For instance, the Application User might want to deploy a particular application on different VMs and/or with different elasticity requirements and capabilities, thus requiring a different description for each respective deployment scenario. Application Submissions: Contains details about the past and current submissions of an application. The details include the date/time of the submission, the cloud provider on which the application was submitted for deployment, the Application User who submitted the application and the summarized monitoring data about parameters chosen by the Application User like total cost, average response time etc. Each submission refers to a single application description. 22 / 41
Artifacts: Contains the artifacts required for the deployment and operation of the application. These artifacts must be available in a repository, which is public or can be accessed using Application User s credentials (see Section 5.1.2), so that they can be located by the Resource Provisioner based on the referenced URL that was provided. Since all the artifacts are referenced in the application description by URLs, it is not necessary to have the actual artifacts in the project s folder; we just give the option to the Application User to have all the artifacts related to an application in one place. The Artifacts folder consists of 4 subfolders, Applications, Virtual Machine Images, Reconfiguration Scripts and Deployment Scripts: Applications: Contains the custom executable files of the application that is to be deployed on the Cloud, such as the.jar files, or it contains just the references to these files. Virtual Machine Images: Contains files with the IDs of the Application User s custom VM images. The Application User can use automated tools, to pre- create an image by picking up a base image and installing his custom application and/or other software dependencies, and then creating a snapshot image that can be uploaded to a Cloud provider. Then, the Cloud provider will give an ID to the custom image. This ID can be used for the deployment of the application. Reconfiguration Scripts: Contains scaling/reconfiguration action scripts, or just references to these scripts, in which the Application User has defined elasticity actions for elastically managing his application in a customized way. Deployment Scripts: Contains custom scripts, or just references to these scripts, that will be executed on an application component at boot phase. For example the Application User can write a script for configuring a database or installing additional software dependencies. Monitoring: Contains the monitoring configuration file(s). These files will be automatically generated by the Application Submission Tool and will be used to communicate with the CELAR Monitoring System [D1.1 Section 3.3.3.1] and to configure the monitoring visualization tool based on the Application User s needs in order to display graphs and metrics that are of his concern. 4.3.2 Creating a new Application Description An Application User can initiate the Application Description process through a dedicated wizard, called the New Application Description Wizard. The wizard can be triggered through a right- click on the CELAR project and invoking the respective action: New -> Application Description. The wizard provides a quick and automated way of defining the application details that are of CELAR s interest regarding the application as a whole. After completing the wizard, the Application User can utilize the Graphical Editor for specifying the structure and other details of the application topology. 4.3.2.1 Application Description Wizard The New Application Description Wizard is used by the Application User to specify the application- level elasticity requirements, together with the optimization policy, as shown in Figure 5. 23 / 41
Figure 5: New Application Description Wizard Optimization Policy: The Application Optimization policy can be specified in the CELAR Application Description Wizard. The optimization policy describes the application metric that the Application User wants to see improved the most. For example, an optimization policy might combine multiple types of elasticity requirements into one single policy, such as Minimum cost and Maximum Performance. The Application User can choose an optimization policy from a predefined list of policies supported by CELAR, but he can also update the policy at a later stage of the application description, or at the submission phase. Global Elasticity Requirements: The Application User can add multiple application level elasticity requirements, or global elasticity requirements, by choosing each requirement from predefined list of elasticity requirements. After selecting the type for a global elasticity requirement, he will be asked to specify its value too. For example an Application User can choose the elasticity requirement maximum cost and specify a value for this requirement. 24 / 41
4.3.2.2 Graphical Editor Once the new Application Description wizard is finished, the Graphical Editor of the Application Description Tool opens for the Application User to complete the application description. The Graphical Editor is composed of 3 parts, as shown in Figure 6: (i) the Canvas on which the application topology is drawn, (ii) the Palette from which the Application User can drag application topology components and drop them on the Canvas, and (iii) the Properties View where the Application User can manipulate the properties of the entire application, the properties of the individual and composite application components and the relationships properties. Figure 6: Graphical Editor 4.3.2.3 Palette The graphical editor retrieves information from the CELAR DataBase [D3.1 Section 4.2.4] regarding the resources offered by the Cloud providers that implement CELAR on their platforms and to which the Application User has been previously subscribed (see Section 5.1.2). In order to achieve this, the Application User must have already been subscribed to the Cloud providers and provide his credentials to CELAR. Then, the resources offered by the Cloud providers, to which the Application User is subscribed, will be presented among others to the Application User via the Palette and can be used in the application description. The elements in the Palette are organized into different categories, as shown in Figure 7 and explained below: 25 / 41
Figure 7: Palette Application Component/Group: The Application User can drag and drop an Application Component to the canvas to represent any kind of application module or unit encapsulating functionality or data. Otherwise, the Application User can choose a Group component in which to place more than one application components, in order to form a composite application component as described in Section 4.1. Connections: The Application User can drag a relationship from the palette to connect two application components. There are two types of relationships in the Palette, the unidirectional and the bidirectional relatioship. A relationship denotes that an application component interacts with another component. For example, a web service 26 / 41
component interacts with the database component by sending data to it and retrieving data from it, so a bidirectional relationship should connect these two components. Base Images: The Application User can select a base VM image available from the Cloud providers that he is subscribed to (see Section 5.1.2). Otherwise the Application User can select a Generic image and specify the preferred operating system, version etc. and then the CELAR System will find the most appropriate image for the application component using an appropriate Cloud connector (e.g. jclouds [jclouds]). Custom Images: The Application User can use automated tools, to pre- create a custom image by picking up a base image and installing his custom application and/or other software dependencies, and then create a snapshot image that can be used for automated deployment. This snapshot image can be uploaded to a Cloud provider to which the Application User is subscribed, so that the image ID given by the Cloud provider can be used in the application description. The custom images that the Application User has uploaded to the Cloud providers will be presented in the Palette under the Custom Images category. User Applications: The Application User can attach to an application component references to the executable files of the application that is to be deployed on the Cloud, for example references to the locations where the.jar files of a custom Java application are published. If the Application User imports his custom application files, or just the references to these files, in the CELAR project under the Applications folder, then the custom applications will be presented in the Palette under the User Applications category. Software Dependencies: This category includes the software that might be required for a User s application to be executed. Some commonly used software, such as Java, Cassandra etc., will be presented in the Palette under this category. If the desired software is not presented under the Software Dependencies category, the Application User can choose the Generic software dependency from the Palette and rename it accordingly. The presence of the software dependencies in the application description is helpful for the Application User to know what software is installed on each component, and it might also be helpful in case the CELAR System will try to find the most appropriate image for the application component. Elasticity Actions: The Application User can attach to an application component a scaling/reconfiguration action offered by the available Cloud providers, or he can choose the Generic action from the Palette and attach to it a reference of a custom elasticity action from the Reconfiguration Actions folder in the Project Explorer, thus defining a specialized elasticity action for the component. Monitor Probes: The Application User can attach a monitoring probe to an application component if he wants to monitor a specific parameter for that component. A list of the monitoring probes provided by the CELAR System will be presented in the Palette. 27 / 41
4.3.2.4 Canvas The Canvas of the Application Description Tool s Graphical Editor is used for drawing the Application Topology, as shown in Figure 8. Figure 8: Canvas The Application User can use the Canvas to: Add/Delete Application Component: The Application User can add an application component to the application topology by dragging the component from the Palette and dropping it to the Canvas. An application component can be removed by selecting the component and pressing the Delete button. When a component is deleted, all the relationships connected to the component are also removed. Add/Delete Composite Application Component: The Application User can add a composite application component to the application topology by dragging the Group component from the Palette and dropping it to the Canvas. Application components can then be added to the composite component by dragging and dropping them inside the Group component. A composite component can be removed by selecting the component and pressing the Delete button. When a composite component is deleted, all the components and relationships inside the composite component are also removed. Move Application Component: The Application User can move an application component around the Canvas. All the relationships connected to the component are also moved together with the component. The same happens with composite components. Add/Delete Relationship: The Application User can add a relationship by dragging the relationship from the Palette and dropping it on the source application component and then pulling it to the destination component. A relationship between two components can be removed by selected the relationship and pressing the Delete button. The same happens with composite components. 28 / 41
Add/Delete Artifact: The Application User can add an artifact (VM images, application scripts, monitoring probes) to an application component by dragging the artifact from the Palette and dropping it on the application component. An artifact can be removed from a component by selecting the artifact and pressing the Delete button. 4.3.2.5 Properties View The Application User can use the Properties View of the Graphical Editor to add or edit information about the application topology. The Properties View provides different properties for the entire application, the application components, the composite application components and the relationships. Application Properties View Figure 9 shows how the Application Properties View looks like. The application properties included in this view are described below: Application Name: The name of the application that is being described. It is inserted through the new Application Description wizard, and it can be updated using the Application Properties View. Optimization Policy: The application metrics that the Application User wants to see improved the most. It can be inserted through the new Application Description wizard, or later using the Application Properties View. Elasticity Requirements: The elasticity requirements that apply to the entire application (see Section 4.2). They can be inserted through the new Application Description wizard, or later using the Application Properties View Data/Load Hints: The data and load hints that apply to the entire application (see Section 4.2). They can only be specified using the Application Properties View. Monitoring Probes: The metrics about the application as a whole that the Application User wants to monitor throughout application s lifetime. They can be dragged and dropped from the Palette to the Canvas, and edited later using the Application Properties View. Elasticity Actions: The elasticity actions that the Application User wants to be applied to the application as a whole in order to achieve elastic behavior. They can be dragged and dropped from the Palette to the Canvas, and edited later using the Application Properties View Figure 9: Application Properties View 29 / 41
Application Component Properties View Figure 10 shows how the Application Component Properties View looks like. The application components properties included in this view are described below: Application Component Name: The name of the selected application component. It can be inserted graphically by double clicking on the application component or using the Application Component Properties View. VM Image: The virtual machine image for the selected application component. It can be dragged and dropped from the Palette on the application component and viewed in the Application Component Properties View. VM Flavor: The size of the required virtual machine for the selected application component. It can be chosen from a drop down list in the Application Component Properties View. Min/Max Instances: The minimum and maximum number of instances for an application component. They can be inserted using the Application Component Properties View. The default values are 1/1. Elasticity Requirements: The elasticity requirements that apply to the selected application component (see Section 4.2). They can be inserted using the Application Component Properties View. Data/Load Hints: The data and load hints that apply to the selected application component (see Section 4.2). They can be inserted using the Application Component Properties View. Monitoring Probes: The metrics about the selected application component that the Application User wants to monitor throughout application s lifetime. They can be dragged and dropped from the Palette on the application component and edited later in the Application Component Properties View. Elasticity Actions: The elasticity actions that the Application User wants to be applied to the selected application component in order to achieve elastic behavior. They can be dragged and dropped from the Palette on the application component and edited later in the Application Component Properties View. Input/Output: The output parameters that the application component exposes to other components and the input parameters that must be fulfilled by other components output parameters. The Application User will have to specify which parameter fulfills each one of the application component s input parameters at the submission phase. By specifying the input/output parameters for each application component, we provide a simple synchronization mechanism to control the order in which the different components are brought up. Figure 10: Application Component Properties View 30 / 41
Composite Application Component View Figure 11 shows how the Composite Application Component Properties View looks like. The composite application components properties included in this view are described below: Elasticity Requirements: The elasticity requirements that apply to the selected composite application component (see Section 4.2). They can be inserted using the Composite Application Component Properties View. Data/Load Hints: The data and load hints that apply to the selected composite application component (see Section 4.2). They can be inserted using the Composite Application Component Properties View. Network Interface: The network interface required for connecting the components included in the selected composite application component. It can be inserted using the Composite Application Component Properties View. Monitoring Probes: The metrics about the selected composite application component that the Application User wants to monitor throughout application s lifetime. They can be dragged and dropped from the Palette on the composite application component and edited later in the Composite Application Component Properties View. Elasticity Actions: The elasticity actions that the Application User wants to be applied to the selected composite application component in order to achieve elastic behavior. They can be dragged and dropped from the Palette on the composite application component and edited later in the Composite Application Component Properties View. Figure 11: Composite Application Component Properties View Relationship Properties View Figure 12 shows how the Relationship Properties View looks like. The relationship properties included in this view are described below: Relationship Name: The name of the selected relationship. A default name is given and it can be edited using the Relationship Properties View. Relation Type: The type of the selected relationship, for example master- slave, peer- peer, and producer- consumer relationship. It can be chosen from a drop down list in the Relationship Properties View. Network Interfaces: The network interface required for connecting the two related application components. It can be inserted using the Relationship Properties View. 31 / 41
Figure 12: Relationship Properties View 32 / 41
5 Towards the Implementation of the CELAR Application Description Tool This chapter presents the overall c- Eclipse architecture, thus giving an overview of how the Application Description Tool is associated to the other c- Eclipse modules. Then the frameworks used for the development of the Application Description Tool are described. 5.1 c- Eclipse Architecture As mentioned earlier, the c- Eclipse Framework is built on top of the reliable Eclipse Platform and follows its plug- in based software architecture. It takes advantage of the Eclipse GUI that thousands of users around the world are accustomed to and utilize extensively on a daily basis. This intuitive graphical GUI through which users will interact with any Cloud Infrastructure, as well as the consistent modus operandi, will be able to minimize any complexity regarding the process of application description, submission and monitoring. In turn, this will result in a low- entry barrier for Application Users who are new to the Cloud, while simultaneously improve the workflow efficiency of experienced users. The c- Eclipse framework will be platform independent, running on any platform, which is supported by Eclipse (Windows, Linux, Sun Solaris, Mac OS X and others). By utilizing graphical libraries such as SWT, the Eclipse GUI is not only platform independent but always has the look and feel of a native application. Furthermore, the availability of high quality tooling such as the Eclipse Modelling and Communication frameworks as well as the vast supplementary resources (documentation, tutorials, examples, etc.) eases the work of the development team and enables us to focus on the delivery of a high quality end product. Importantly, thanks to the Eclipse modular architecture that adheres to the OSGi [OSGI] framework, the c- Eclipse functionality and GUI can be easily extended and customized to support either new Cloud related technologies or additional requirements. Finally, by integrating c- Eclipse to the Eclipse eco- system, the consortium will be able to: i) guarantee its long- term sustainability through a strong international user and developer- backed community, and ii) increase the CELAR project visibility and thereby further improve its rate of adoption. Before getting into the implementation specifics of the Application Description Tool, we present an overview of the complete c- Eclipse Framework architecture (Figure 13) and its dependencies. 33 / 41
Figure 13: c-eclipse Architecture The c- Eclipse Framework, as shown in Figure 13, consists of four (4) UI components, the c- Eclipse core and the User Authentication mechanism. Specifically: 5.1.1 c- Eclipse Core The c- Eclipse core contains those abstractions required for the creation of the application description/submission files and for interacting with the CELAR Manager. One of the key functionalities of the core, which has been so far implemented, is the provision of a unified placeholder (The CELAR Project presented in Section 4) for storing any resources that are related to the above Cloud- related tasks. Specifically, it provides a mechanism for accessing and managing both local elements, i.e. local files and folders, as well as remote resources. A significant part of this key functionality and the associated source code has been inherited and re- used from the g- Eclipse FP7 project [geclipse], however it has been customized for Cloud environments. The g- Eclipse project provided an integrated framework over Eclipse, to facilitate and ease access to Grid infrastructures. The g- Eclipse source- code is under the Eclipse Public License (EPL), thereby fragments of the code can be freely re- used and modified provided that the resulting source code Is made publicly available [EPL FAQ], a requirement that adheres to the principles of the CELAR project; that is that all resulting source code will be made publicly available. 34 / 41
5.1.2 Authentication Mechanism Before an Application User can describe and submit his application to the Cloud, the User must subscribe to the Cloud provider to which his application is going to be deployed on. The Application User will then provide his subscription credentials to c- Eclipse in order to query Cloud provider for capabilities, submit or monitor an application deployment, or to retrieve information from the CELAR DataBase about his current and previous deployments. 5.1.3 UI components Application Description Tool: This tool interacts with the Application User who gives a description of the application that is to be deployed on the Cloud. The application description is translated into a formal XML specification that is passed to the Application Submission Tool. Application Submission Tool: This tool enriches the application description with deployment information given by the Application User. The complete application description is then passed to the CELAR Manager who must parse it and propagate it to the interested modules, which are the Resource Provisioner and the Decision Module. Monitoring Visualization Tool: This tool receives monitoring data from the CELAR DataBase about resource related metrics (CPU, memory usage, etc.) and specified application performance metrics and presents them graphically to the Application User. In this way, the Application User is able to observe his application during its lifetime and intervene, if required, by configuring his deployment. Information Tool: The Information Tool will provide an interface for Application Users to inspect their current and previous deployments. Users will also be able to utilize the Information Tool to compare different IaaS providers as well as search for offered resources per IaaS. 5.2 Application Description Tool Development The Application Description Tool is part of the CELAR perspective. Specifically, the CELAR perspective is a visual container for a set of user- interface parts (wizards and editors) that are specific to the tasks that will be performed primarily by the Application Users. Consequently, these parts exist wholly within the CELAR perspective and are not shared with other perspectives. This section describes the development tools used for building the Application Description Tool on top of the Eclipse Platform. 5.2.1 Eclipse Modeling Framework The EMF project [EMF] is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XML, such as the TOSCA specification, EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command- based editing of the model. The Application Description Tool uses the EMF modeling framework to produce the Java classes for the extended XML TOSCA specification. Thus, the Application Description Tool is able to translate the graphical application description given by the Application User into a formal XML specification that is useful to other CELAR modules. 5.2.2 Graphiti Eclipse offers two popular frameworks useful for building graphical editors for Domain Models. These are the Eclipse Modeling Framework (EMF) which provides the 35 / 41
basis for modeling (Section 5.1.2), and the Graphical Editing Framework (GEF) which supports programming graphical editors. GEF is fairly complex and it needs a notable amount of work to get used to the framework. Therefore, SAP built a framework, named Graphiti, which hides GEF's complexities from the developer and bridges EMF and GEF to ease and speed up the development of graphical editors. The Graphiti programming model is very easy to understand and can be supported by any platform, by hiding platform specific technologies such as GEF and Draw2d. Graphiti [Graphiti], [Graphiti Intro] was donated by SAP to the Eclipse community in 2009, and it is an alternative to the Graphical Modeling Framework (GMF). Graphiti is now an Eclipse- based graphics framework that enables rapid development of state- of- the- art diagram editors for domain models. It is self- contained, unlike GMF which is GEF depended, and it has a standardized and homogeneous look and feel defined by SAP usability experts. Graphiti is evolving around the Eclipse Modeling Framework (EMF) and offers graphical representations and editing possibilities for EMF objects. To this extent, the Application Description Tool uses the Graphiti infrastructure to build the graphical editor through which the Application User can efficiently describe the structure and features of an application. 5.3 Graphiti Architecture The Graphiti s architecture is depicted in Figure 14. The user of a Graphiti based tool communicates with the tool via the screen, mouse and keyboard. An Interaction Component will receive users requests such as drag- and- drop, resize, or delete, but the actual processing of these requests is done by the Diagram Type Agent. The Rendering Engine, on the other hand, is responsible to display the current diagram on the screen. Thus, the Rendering Engine together with the Interaction Component form the Graphiti s framework components. Figure 14: Graphiti Architecture [Graphiti Intro] 36 / 41
Diagram Type Agent The main task of the Diagram Type Agent s is to modify the model data. On the one side we have the Pictogram Model which is made available by Graphiti, and on the other side we have the domain specific model which comes from the developer. These models are explained below. Domain Model The Domain Model contains the data which has to be visualized graphically. In our case the domain model is the extended XML TOSCA specification. We make our model available in EMF so that it can be easily processed by Graphiti. The data of the Domain Models in Graphiti are called Business Objects. Thus, the Business Objects related to the Application Description Tool are the application topology, application components, relationships, artifacts etc. Pictogram Model The Pictogram Model contains the complete information required for graphically representing a diagram. This way allows a diagram to be represented without the presence of the Domain Data. For this purpose, a partially redundant storage of data is required, which is present both in the Pictogram Model and in the Domain Model. When the Domain Model is updated, the Graphiti knows that the Pictogram Model is out of sync, and uses the so- called Update Features to update the already existing Pictogram Model and therefore the existing diagram. The metamodel of the Pictogram Model is made available by Graphiti. Link Model The Domain Model must be somehow connected to the Pictogram Model. This is the objective of the Graphiti s Link Model. The Link Model is responsible for connecting data from the Domain Model and data from the Pictogram Model. This approach enables the actions that happen in the graphical editor, such as a deletion of a graphical object, to affect the associated object of the Domain Model by making the necessary changes. 37 / 41
6 GitHub Repository You can find the implementation code for the Application Description Tool under https://github.com/celar/c- Eclipse/tree/master/app- description 38 / 41
7 Conclusions In this document we have provided a detailed description of the Application Description Tool. We have studied the state of the art in the field of Cloud application description frameworks and related standards. We have given a detailed analysis of the Application Description Tool s design concepts, the actors interacting with the tool and the respective use cases, together with the functional and non- functional requirements arising from these use cases. The first version of the tool is presented using screenshots complemented with detailed explanations. Finally we have presented the implementation of the Application Description Tool describing the frameworks used and procedures followed during the development of the tool. The following versions of the Application Description Tool will be presented in Deliverables 2.2 and 2.3 39 / 41
References [BoxGrinder] BoxGrinder, http://boxgrinder.org/ [D1.1] User Requirements and System Architecture V1, Deliverable, CELAR Project, https://wiki.celarcloud.eu/doku.php?id=celar_project:deliverables:deliverables_1.x:d 1.1 [D3.1] Architecture Definition of the Elasticity Provisioning Platform, Deliverable, CELAR Project, https://wiki.celarcloud.eu/doku.php?id=celar_project:deliverables:deliverables_3.x:d 3.1 [D5.1] Decision Process for On- demand Elasticity Report, Deliverable, CELAR Project, https://wiki.celarcloud.eu/doku.php?id=celar_project:deliverables:deliverables_5.x:d 5.1 [Eclipse] The Eclipse Framework, http://www.eclipse.org [EMF]: Eclipse Modeling Framework Project, http://www.eclipse.org/modeling/emf/ [Enstratius] Multi- Cloud Manager (formerly Enstratius), http://www.enstratius.com/ [EPL] Eclipse Public Licence Version 1.0, http://www.eclipse.org/org/documents/epl- v10.html [EPL FAQ] Eclipse Public Licence Frequently Asked Questions, http://www.eclipse.org/legal/eplfaq.php [Flexiant] Flexiant Cloud Orchestrator, http://www.flexiant.com/flexiant- cloud- orchestrator [g- Eclipse] g- Eclipse - Tools for Grid and Cloud Computing, http://www.eclipse.org/geclipse [GEF] Graphical Editing Framework, http://www.eclipse.org/gef/ [Graphiti] Graphiti a Graphical Tooling Infrastructure, http://www.eclipse.org/graphiti/ [Graphiti Intro] Development of High- Quality Graphical Model Editors and Viewers, http://help.eclipse.org/kepler/index.jsp?nav=%2f24 [jclouds] JClouds, http://jclouds.incubator.apache.org/ [Juve 2012] Gideon Juve and Ewa Deelman, Automatic Application Deployment in Infrastructure Clouds, IEEE 3 rd International Conference on Cloud Computing Technology and Science (CloudCom), pp 658-556, Athens, Greece, November 2011. 40 / 41
[Keahey 2008] Katarzyna Keahey and Tim Freeman, Contextualization: Providing One- Click Virtual Clusters, IEEE 4 th International Conference on escience (escience 08), pp 301-308, Indianapolis, USA, December 2008. [Marshall 2012] Paul Marshall, Henry Tufo, Kate Keahey, David LaBissoniere and Matthew Woitaszek, Architecting a Large- scale Elastic Environment Recontextualization and Adaptive Cloud Services for Scientific Computing, In Proceedings of the 7 th International Conference on Software Paradigm Trends (ICSOFT 12), pp 409-418, Rome, Italy, July 2012. [OSGI]: OSGi Alliance, http://www.osgi.org [OVAB]: Oracle Virtual Assembly Builder, http://www.oracle.com/technetwork/middleware/ovab/overview/index.html [ServiceMesh] ServiceMesh Agility Platform, http://www.servicemesh.com/agility- platform [SlipStream] SlipStream, http://sixsq.com/products/slipstream [StratusLab] Slipstream- StratusLab, https://slipstream.stratuslab.eu/ [TOSCA] Topology and Orchestration Specification for Cloud Applications (TOSCA), https://www.oasis- open.org/committees/tosca/ [VCloud] VMware vcloud Suite, http://www.vmware.com/products/datacenter- virtualization/vcloud- suite/overview.html [Veewee] Veewee, https://github.com/jedi4ever/veewee [VFabric] VMware vfabric Application Director, http://www.vmware.com/products/application- platform/vfabric- application- director/overview.html 41 / 41