Home
Welcome to the cloudml wiki!
Before you start with CloudML, please have a look at the CloudML metamodel. It is the main API to use when interacting with CloudML.
CloudML allows developers to model the provisioning and deployment of a multi-cloud application at two levels of abstraction: (i) the Cloud Provider-Independent Model (CPIM), which specifies the provisioning and deployment of a multi-cloud application in a cloud provider-agnostic way ; (ii) the Cloud Provider-Specific Model (CPSM), which refines the CPIM and specifies the provisioning and deployment of a multi-cloud application in a cloud provider-specific way. This two-level approach is agnostic to any development paradigm and technology, meaning that the application developers can design and implement their applications based on their preferred paradigms and technologies.
CloudML is also inspired by component-based approaches in order to facilitate separation of concerns and reusability. In this respect, deployment models can be regarded as assemblies of components exposing ports, and bindings between these ports. To this end, CloudML implements the type-instance pattern. The figure below presents the main concepts of the type part of the metamodel. The POJO implementation of this metamodel is available here.
In the following, we provide a description of the most important classes and corresponding properties in the metamodel.
A CloudMLModel consists of CloudMLElements (these classes have been omitted from the previous Figure to increase the readability). A CloudMLElement can be associated to Property and Resources. A Resource represents an artefact (e.g., scripts, binaries, configuration files, etc.) adopted to manage the deployment life-cycle (e.g., download, configure, install, start, and stop). The three main types of CloudMLElements are Component, Relationship, and ExecutionBinding.
A Component represents a reusable type of component. A Component can be an ExternalComponent managed and provided as a service by a Provider (e.g., a Beanstalk container), or an InternalComponent managed and deployed by CloudML (e.g., a Servlet container).
A VM is a type of ExternalComponent and represents a reusable type of virtual machine (e.g., a virtual machine running Linux)
A Port represents an interface of a component. A Port can be a ProvidedPort, meaning that it supplies a feature provided by the component (e.g., the servlet provides a REST interface), or a RequiredPort, meaning that it consumes a feature (e.g., a servlet requires another servlet offering a REST interface). Only internal components can have a RequiredPort since this requires to be fully managed by CloudML. The property isMandatory represents that the internal component depends on this feature. The property isLocal represents that the component requesting the feature and the component providing the feature have to be deployed on the same external component.
An ExecutionPlatform port represents another type of interface of a component. An ExecutionPlatform can be a ProvidedExecutionPlatform, meaning that a component supplies an execution environment (e.g., the servlet container has to be executed on a VM running Linux), or a RequiredExecutionPlatform, meaning that an internal component requires an execution platform in order to be executed.
A Relationship represents a reusable type of relationship between ports of two internal components. A relationship can be associated to resources specifying how to configure the components in order to communicate with each other.
An ExecutionBinding represents a reusable type of binding between a required and a provided execution platform port. Resources can be associated to Execution Binding specifying how to configure the execution platform and the component to be deployed on it.
You can build CloudML by using:
mvn clean install
In order to use CloudML as a library by including in your path the jar file called: 'cloudml-library.jar' that has been generated in the 'facade\target' folder. If you plan to deploy your applications on AWS EC2 you should also include the ec2 driver: 'aws-ec2-1.7.2.jar'
You can use CloudML as a service by starting the jar file called: 'cloudml-WebSocket.jar' that has been generated in the 'ui\websocket\target' folder. This jar file should be placed together with the 'lib' folder that has also been generated in 'ui\websocket\target'. The command to start the service is the following:
java -jar cloudml-WebSocket.jar
Finally you can use CloudML has a command line tool by starting the jar file called: 'cloudml-shell.jar' that has been generated in the 'ui\shell\target' folder. This jar file should be placed together with the 'lib' folder that has also been generated in 'ui\websocket\target'. The command to start the service is the following:
java -jar cloudml-shell.jar -i
For the credentials description, please refer to the provider definition [the JSON codec] (https://github.com/SINTEF-9012/cloudml/tree/master/codecs/json).
The CloudML log file is available at the following directory: "C:\Users<your username>" on windows or "/home/yourusername" on Linux.
CloudML provides 3 ways of accessing its API in order to instantiate models:
- Programatically, as a library via [the Java API] (https://github.com/SINTEF-9012/cloudml/tree/master/facade). This API is not yet fully implemented and we envision to provide [the following commands] (https://github.com/SINTEF-9012/cloudml/wiki/API).
- From a JSON file via [the JSON codec] (https://github.com/SINTEF-9012/cloudml/tree/master/codecs/json).
- From an Ecore/XMI file via the XMI codec, which you can create in an Eclipse editor.
In addition, CloudML offers a DOT codecs, which generates a DOT file that can be used to visualize the topology of a deployment model. The list of codecs is available here
The enactment of CloudML models i.e. the actual deployment of services in the CloudML is realized by the CloudML engine. This engine can be accessed programatically via:
- a Facade,
- a Shell,
- a websocket interface.
TODO: elaborate more