Keywords: Software Product Line (SPL), Model Driven Engineering (MDE), ontologies.
SALOON is a framework for the configuration and the deployment of highly variable and heterogeneous distributed systems. SALOON can be used in many different application domains such as cloud computing, cyber-physical systems, networked environments. SALOON combines ontologies (or domain models), Software Product Line Engineering (SPLE) and Model Driven Engineering (MDE) in order to enable the description and configuration of heterogeneous distributed systems.
Figure 1 provides an overview of the SALOON Platform when used to deal with the Cloud. In particular, SALOON enables the description of Cloud environment variability, i.e., commonalities and variabilities, as feature models extended with cardinalities, attributes and constraints over them. One feature model is used to describe one Cloud environment, there is thus one software product line per Cloud environment. The functionality provided by Cloud environments are reified and gathered into a Cloud Knowledge Model, mapped to each cloud feature model to automate the feature selection process. Domain Architects (DOM) define these Feature and Cloud Knowledge models. SALOON also supports the configuration analysis of the feature models, including complex constraints over attributes and cardinalities, as well as the derivation of the related software products as configuration files and scripts, both processes being automated. Finally, to help in the selection of a suitable Cloud, it is possible to estimate the cost for a given feature model configuration via a dedicated cost estimation engine, which is based on a Cloud pricing model related to the feature models.
Figure 1 also depicts the different phases required to configure Cloud environments. Configuring a Cloud environment using SALOON relies on several phases. First, the Developer (DEV) or final user specifies her/his requirements using the Cloud Knowledge Model ①. Then, features and attributes of each feature model are selected regarding the mapping between this Cloud model and the feature models ②. Each feature model Configuration is then checked ③ and given as input, if valid, to the Cost Estimation engine to help the user making her/his choice ④. Finally, the Derivation tool yields the related configuration files and/or deployment scripts ⑤, executed by the developer ⑥.
The following video shows how SALOON automatically reasons about user’s requirements defined in the Cloud Knowledge Model and derives the related software assets. These assets are configuration files and the related bash script, executed for the environment to be properly set up. SALOON is used to deploy a Java application on Heroku.
When looking at other development languages, this configuration and deployment process can be more complex and error-prone. Here are a few examples of the required configuration files regarding the language the application to deploy has been developed with:
Although required whatever the language used, the Procfile is different for each configuration. Moreover, regarding the build.sbt files, a blank line must be placed between each configuration line for it to be properly handled by Heroku. All those little details can be the cause of a configuration error and therefore lead to the inability to deploy the application. These files can be automatically generated and filled with SALOON regarding the user requirements. The following video shows the cloud configuration and deployment using SALOON of 3 applications written in different languages:
SALOON defines two main metamodels: (i) a Feature metamodel to deal with subsystem descriptions and (ii) a Domain Knowledge metamodel that provides a unified view of functionality of the distributed system. Figures below show both metamodels as well as one example of each one regarding the Cloud.
Figure 3. The Heroku Feature Model.
The Heroku example showed in Figure 3 depicts the use of an Attribute Constraint between two attributes, dynoSize and dynoMemorySize, describing the fact that if the Dyno is selected with its size setted to “1X”, then it provides 512 MB of memory (the value is actually hidden by the EMF editor, since the dynoMemorSize is held by the Dyno feature. In the constraint, the “To Value” is a reference to a feature attribute). In the example, one can also see other kinds of constraints and different features that are part of the Heroku feature model.
Figure 5 depicts an excerpt of the Cloud Knowledge Model, which is an instance of the Domain Knowledge Model depicted by Figure 4. One can see some Technical Elements, that are usually related to functional requirements, for example which database or application server support is required. It also depicts the Memory concept that is a Quantifiable Element, i.e., whose one can define the required quantity in the related unit (here 4 GB of memory). All of these concepts can be selected by the SALOON user.
Below we list the different publications related to SALOON. We also include some deliverables from the PaaSage project, which uses SALOON for Cloud environment modeling and selection.
Cloud Environment Selection and Configuration: A Software Product Lines-Based Approach. Clément Quinton. Ph.D. thesis.
SALOON: A Platform for Selecting and Configuring Cloud Environments. Clément Quinton, Daniel Romero and Laurence Duchien. In Software: Practice and Experience, 46:55-78, 2016.
Consistency Checking for the Evolution of Cardinality-based Feature Models. Clément Quinton, Andreas Pleuss, Daniel Le Berre, Laurence Duchien and Goetz Botterweck. In Proceedings of the 18th International Software Product Line Conference, SPLC’14. Florence, Italy, 15-19 Septembre 2014.
Automated Selection and Configuration of Cloud Environments Using Software Product Lines Principles. Clément Quinton, Daniel Romero and Laurence Duchien. In Proceedings of the 7th IEEE International Conference on Cloud Computing, CLOUD’14. Anchorage, Alaska (USA), 27-02 June/July 2014.
Cardinality-Based Feature Models With Constraints: A Pragmatic Approach. Clément Quinton, Daniel Romero and Laurence Duchien. In Proceedings of the 17th International Software Product Line Conference, SPLC’13. Tokyo, Japan, 26-30 August 2013.
D2.1.2 – CloudML Implementation Documentation – First version. Alessandro Rossini, Nikolay Nikolov, Daniel Romero, Jörg Domaschka, Kiriakos Kritikos, Tom Kirkham, and Arnor Solberg. April, 2014.
D3.1.1 – Upperware Prototype. Amil Bsila, Nicolas Ferry, Geir Horn, Tom Kirkham, Maciej Malawski, Nikos Parlavantzas, Christian Pérez, Jonathan Rouzaud-Cornabas, Daniel Romero, Alessandro Rossini, Arnor Solberg, and Hui Song. March, 2014.
D2.1.1 – CloudML Guide and Assessment Report. Alessandro Rossini, Arnor Solberg, Daniel Romero, Jörg Domaschka, Kostas Magoutis, Nicolas Ferry, Tom Kirkham. Research Report, 2013.