Modeling multi-tenancy at the data layer of cloud applications has been proposed in MDE based modeling languages. Most of these languages aim to automate the provisioning and deployment of cloud services. A few languages are geared towards portability and interoperability of cloud applications across di↵erent cloud prov- iders, and migration of existing applications to the cloud by generating deployment specification models. In general, modeling languages have been implemented as extensions for general propose modeling languages, or as independent DSLs.
2.3.1
Unified Modeling Language Extensions
CAML [15] has been proposed as an extension for Unified Modeling Language (UML) to express cloud-based deployments directly in UML models. Using this extension, a deployment topology is described in terms of CAML Library. Then, the deploy- ment topology is refined by applying a dedicatedCAML Profile to map deployments with cloud provider specific o↵erings. CAML Library uses common cloud modeling concepts that capture computing services (e.g., operating system, web server, ap- plication container), cloud storage options, and cloud services (e.g., load balancer, queue). CAML Profile comprises services from GAE and AWS. In CAML, di↵erent cloud storage options (i.e., block storage, blob storage, relational databases, and key-value storage) with consistency kinds (i.e., strict or eventual) are captured in
CAML Library.
Another UML profile [49] has been designed for modeling multi-cloud applica- tions. Cloud artifacts are introduced in the profile to represent application com- ponents that can be deployed in a cloud platform. During the application model- ing process, each cloud artifact requires a cloud-agnostic service type. The profile also allows to represent non-functional requirements for application components in terms ofproperty, operator,and value. The model is later refined to represent cloud provider specific service instances, and processed by a model transformation engine to generate deployment plan with all cloud-related information. Using this UML profile, the data layer can be represented as a cloud artifact with a cloud storage option (i.e.,file storage, relational storage, and NoSQL storage) assigned as a service
type.
2.3.2
Domain-Specific Languages
An XML-based modeling language [8] has been provided by TOSCA to define application components and their relationships. Similarly, Cloud Modeling Lan- guage (CloudML)-Stiftelsen for Industriell og Teknisk Forskning (SINTEF) [14] has been proposed as a standalone DSL in the PaaSage8 project to express deploy- ment specification of application components. In both approaches, the data layer of an application can be described as a separate component with database properties. Specifically, TOSCA XML enables to specify a database engine, a virtual machine to deploy the database, and an operating system that runs on the virtual machine. In contrast, CloudML-SINTEF captures other database properties such as a database engine, a data structure type associated with the database engine, and consistency of the storage type.
Furthermore, CloudML-SINTEF has been evolved in Model-Driven Approach for Clouds (MODA-Clouds) 9 project to allow describing a data architecture associated with the applications data layer. The data architecture is expressed in terms of an Entity Relationship (ER) diagram and refined by a meta-model that specifies functional and non-functional data properties. Then, the data architecture is refined by cloud storage types (i.e., distributed file system, NoSQL databases, and blob storage) o↵ered by cloud providers in a cloud provider independent way. Later, the data architecture can be further refined by cloud provider-specific data structures to generate data definition scripts.
Cloudify DSL 10 is also based on TOSCA to describe an application with its resources (e.g., infrastructure, middleware, application code, scripts, tool configu- ration, metrics, and logs). The application descriptions are stored as blueprints in Yet Another Markup Language (YAML) documents. In addition to database re- lated properties, CloudifyDSL allows to specify life cycle operations (e.g.,configure, create, start and stop) in a generic manner. Similarly, using Zephyrus [34] the data layer can be specified as an application component with quality constraints (e.g.,
maximum number of components, minimum number of replicas).
Another XML-based modeling language, CloudML-Universidade Federal de Per- nambuco (UFPE) [47], allows to describe the data layer in terms of cloud resources and services with their requirements. Stratus Modeling Language (StratusML) [51] also captures an application structure as a composition of cloud services. In StratusML, a developer can specify a storage group that will be used to persist application’s data
8http://www.paasage.eu 9http://www.modaclouds.eu
and describe di↵erent data partitioning strategies. The similar approaches are also supported by Holmes [57] and Blueprint [99]. Though the latter approach enables expressing service-based applications from a combination of di↵erent services from di↵erent cloud service models (i.e., IaaS, PaaS, and SaaS). Thus, an application can be hosted by a combination of di↵erent cloud storage types from di↵erent cloud providers.
Move to Clouds for Composite Applications (MOCCA) [79] and CloudDSL [119] have been proposed to create deployment models to support migration of existing application to the cloud. MOCCA [79] provides a way to re-architect application components into groups of components where each group can be provisioned sepa- rately by di↵erent cloud providers. Whilst, CloudDSL [119] uses a common cloud vocabulary, for describing cloud IaaS services, to model an application architecture as an interconnection of cloud services. In both approaches, cloud storages are cap- tured as services with storage related configurations such as region to deploy the storage, storage type and security rules to access the storage.
Almost all of the proposed modeling languages allow to capture di↵erent cloud storage services to generate deployment configurations. This certainly helps to au- tomate deployment of application components to the cloud. However, none of the approaches explicitly enable to model a multi-tenant data architecture, or to pro- duce source code from it. In addition, partitioning and implementation peculiarities of di↵erent cloud storage types have not been considered.