MULTICLAPP allows applications to be constructed in three stages: cloud ap- plications are modeled in the first stage, the applications’ functional behaviour is coded in the second stage, and specific cloud compliant artefacts are generated through an automated procedure in the third stage. An overview of the frame- work’s development process is provided in [7]; the second and third development stages are detailed in [4].
During the application modeling stage, the UML profile presented in this paper is used to model multicloud applications. These models are then pro- cessed by a Model Transformation Engine that allows artefacts to be assigned to specific cloud platforms. The model transformations generate software projects composed of class skeletons and a XML-coded deployment plan that contains all cloud-related information. This allows the source code to be independent from any cloud platform and makes it easier for developers to code the application’s functional behaviour without having to be familiarized with the peculiarities of any cloud.
Applications that have been fully coded and for which a deployment plan has been generated are processed by a Source Transformation Engine, which generates each of the cloud artefacts identified in the deployment plan [8].
Each artefact complies with the specifications of its assigned platform. It con- tains automatically generated adapters that allow it to interoperate with its dependant artefacts and with the cloud specific services that it requires. Once they are generated, the artefacts can be deployed in their cloud platforms.
5
Modeling a Multicloud Application
The MULTICLAPP framework described in this paper has been used in some of the projects carried out by Gloin to model and develop applications hosted in multicloud environments. In this section an excerpt of a cloud application model designed for one of those projects is presented in order to illustrate how the profile described in Section 3 was applied.
The project from which the application model has been taken consisted of a data quality project that was developed in the scope of the author rigths business. Its goal consisted on analysing large heterogeneous data sets in order to produce statistics and metadata about the analysed information. The numerous data sources that had to be analysed, the high volume of information that they contained, and the large number of use cases that had to be implemented, were factors that greatly increased the complexity of the project. Multiple components had to be constructed and integrated with one another, preferably using cloud environments to deploy the software in order to benefit from its low start-up costs and its high potential for scalability.
Each of the project’s stakeholders imposed their own requirements regarding the platform and location in which certain components had to be executed, such that components had to be distributed across different platforms. Furthermore, building software that was decoupled from the cloud was a critical factor since some of the software components of the project had to be replicated in different platforms for performance reasons.
Figure 2 presents an excerpt of a model where the profile presented in Sec- tion 3 was applied to two interdependent software components developed in the project: an administration panel that provides a centralized interface from which to monitor and control the remaining components, and a data processing mod- ule that generates statistics and metadata that is sent out to other components. The data processing module is also responsible of authenticating and validating incoming requests from the administration panel; this is done through a security management module that validates the permissions of each user. Furthermore, the data processing module also provides the administration panel with moni- toring information about its execution.
The QoS requirements of each of these components also differed from one another. Whilst the administration panel was not subject to any particular non- functional requirements, legal restrictions enforced the data processing compo- nent to be physically deployed in Spain since it managed sensible data that included the users’ roles and permissions. An additional non-functional require- ment of the data processing component was that it required a storage space greater than 1GB in order for its security management module to save all user related information.
Fig. 2.Cloud application model excerpt
These requirements led to the decision of splitting the application into two direferent artefacts, containing the administration panel on one hand, and the data processor and security manager on the other. All elements assigned to
AdministrationArtefact could potentially be deployed in a specific cloud which
has been illustrated asCloud A, and those assigned toProcessorArtefact could potentially be assigned to a different one, illustrated asCloud B. In this case the architect assignedAdministrationArtefact to Amazon’s EC2 platform where other administration components were also hosted. On the other handProcesso-
rArtefact was assigned to a private OpenNebula1instance in which a MongoDB
database was installed; such configuration satisfied the data processor’s storage and geographic deployment restrictions.