=Paper=
{{Paper
|id=Vol-1706/paper8
|storemode=property
|title=Evolving Multi-Tenant SaaS Cloud Applications Using Model-Driven Engineering
|pdfUrl=https://ceur-ws.org/Vol-1706/paper8.pdf
|volume=Vol-1706
|authors=Assylbek Jumagaliyev,Jon Whittle,Yehia Elkhatib
|dblpUrl=https://dblp.org/rec/conf/models/JumagaliyevWE16
}}
==Evolving Multi-Tenant SaaS Cloud Applications Using Model-Driven Engineering==
https://ceur-ws.org/Vol-1706/paper8.pdf
Evolving Multi-Tenant SaaS Cloud Applications Using
Model-Driven Engineering
Assylbek Jumagaliyev Jon Whittle Yehia Elkhatib
School of Computing and School of Computing and School of Computing and
Communications Communications Communications
Lancaster University Lancaster University Lancaster University
United Kingdom United Kingdom United Kingdom
a.jumagaliyev@lancaster.ac.uk j.n.whittle@lancaster.ac.uk y.elkhatib@lancaster.ac.uk
ABSTRACT
Cloud computing promotes multi-tenancy for efficient resource
utilization by sharing hardware and software infrastructure among
multiple clients. M ulti-tenant applications running on a cloud
infrastructure are provided to clients as Software-as-a-Service
(SaaS) over the network. Despite its benefits, multi-tenancy
introduces additional challenges, such as partitioning,
extensibility, and customizability during the application
development. Over time, after the application deployment, new
requirements of clients and changes in business environment
result application evolution. As the application evolves, its Figure 1. Multi-tenancy patterns
complexity also increases. In multi-tenancy, evolution demanded application and database. Tenants may also want to extend or
by individual clients should not affect availability, security , and customize a business process workflow to cater for their specific
performance of the application for other clients. Thus, the multi- needs. However, extensions and customizations of individual
tenancy concerns add more complexity by causing variability in tenants should not affect the use of the application by other
design decisions. M anaging this complexity requires adequate tenants. Thus, partitioning, extensibility, and customizability
approaches and tools. In this paper, we propose modeling challenges emerge during the application development.
techniques from software product lines (SPL) and model-driven
Over time, applications evolve because of changes in tenant
engineering (M DE) to manage variability and support evolution of requirements or new tenant requirements [6]. The evolution may
multi-tenant applications and their requirements. Specifically, imply changes in the application structure. Usually, cloud
SPL was applied to define technological and conceptual applications consist of several layers (e.g., presentation layer, data
variabilities during the application design, where M DE was
logic layer, and business logic layer) and changes in any layer
suggested to manage these variabilities. We also present a process
may entail changes in other layers. M oreover, multi-tenancy
of how M DE can address evolution of multi-tenant applications requires the following architectural considerations to be
using variability models. addressed. First, the application layers must be multi-tenant aware
to ensure tenant isolation. Second, the application must allow per
Keywords
tenant customization. Finally, each layer must scale independently
Evolution; multi-tenancy; variability; cloud computing; cloud
application; software product lines; model-driven engineering of each other.
Cloud providers offer various technologies and tools for cloud
1. INTRODUCTION application development. Nevertheless, multi-tenancy concerns
Cloud computing provides on-demand, scalable, and flexible cause additional variability challenges in design decisions such as
computing resources to develop and deploy cloud applications [1]. different multi-tenant data architectures, partitioning schemas and
Applications deployed on cloud are provided to clients as services design patterns. The variability represents different available
over the Internet and are known as SaaS. As mentioned in [2], one options to implement a certain functionality and it should be
key attribute of SaaS is multi-tenant efficiency, which enables considered in the whole lifecycle of multi-tenant applications to
economies of scale and efficient resource utilization by sharing a meet tenant requirements, and to leverage resource pooling and
cloud infrastructure across multiple clients (i.e., tenants). A tenant scalability of the cloud.
is an organization or company with its end users that uses SaaS Variability can be efficiently managed using SPL techniques.
application. M ainly, SPL engineering focuses on the development of software
As illustrated in Figure 1, there are generally two multi-tenancy products from reusable core assets [7]. In SPL, software systems
patterns [3]: multiple instances multi-tenancy and single instance share common functionality, but each software system has some
multi-tenancy. In the former, each tenant has a dedicated variable functionality [5].
application instance on a shared hardware, operating system, or M odeling the variability can also help to efficiently evolve
middleware. In the latter, tenants are served by a single applications. During the application development a set of
application instance that runs on shared hardware and software variability models can be chosen for a given cloud deployment.
infrastructure. We explore and address challenges that relate to the When the application evolves, it is possible to evolve the
latter multi-tenancy pattern where tenants require isolation in corresponding code by selecting another set of options from the
60
variability model. For example, a multi-tenant data architecture 2.2 Evolution
can be modeled in different ways: 1) single database shared by all Evolution is an inevitable p rocess in any software system [6] and
tenants, 2) a separate database for each tenant, or 3) multiple multi-tenant applications are no exception. There are several
database instances where each instance serves a group of tenants. reasons that trigger application evolution, such as fixing bugs,
Initially, the developers might select a single database for all changes in business environment, improving security and
tenants. However, the security requirements of tenants may reliability, changes in tenant requirements, or new tenant
require a more isolated approach that cannot be provided in a requirements. Applications should respond to such changes to
single database instance. Therefore, the developer selects another maintain tenant satisfaction. In application level multi-tenancy,
multi-tenant architecture and the application evolves to multiple changes must be adapted at runtime without affecting availability,
database instances. security, and performance of an application for other tenants. A
The main contribution of our ongoing research is exploring key problem is implementing and managing required changes in
combination of SPL and M DE techniques for managing applications [6].
variability in design decisions and evolving multi-tenant cloud
applications. Others have advocated the integration of SPL and 2.3 SPL
M DE for managing variability in multi-tenant cloud applications. SPL is a software engineering approach that focuses on the
For example, in [10], Orthogonal Variability M odel (OVM ) and development of software products from reusable core assets [7]. It
Service Oriented M odeling Language (SoaM L) were used to promotes feature modeling to analyze and identify the
model variability and customizability in cloud applications. While commonality and variability in applications [5]. Features are
in [4], a framework was proposed to model customizable multi- specific characteristics of an application and are classified in
tenant cloud applications and to support their evolution. However, terms of capabilities, domain technologies, and implementation
these approaches address application variability, customizability, techniques [7]. Capabilities represent functional and non-
and limited evolution scenarios, such as onboarding new tenants, functional characteristics that are provided by an application to
removing tenants, and tenant customizations. In our approach, we clients. Domain technologies describe how to implement features
use SPL to identify technological and conceptual variability prior regarding an underlying domain, where implementation
to application implementation, where M DE concepts are applied techniques comprise commonly used generic approaches in the
to manage variability. Subsequently, variability models may development. Features are also grouped as mandatory, optional,
efficiently support evolution of applications and their alternative and at-least-one-of (OR). Common features are
requirements. M oreover, we illustrate our approach by a multi- mandatory features, while variability features may be optional,
tenant application example. alternative or at-least-one-of. Optional features can be selected or
neglected, only one feature must be selected from alternative
The reminder of the paper is structured as follows. Section 2
features, and one or more features can be selected from at-least-
describes variability in multi-tenant applications and their
evolution. It also describes SPL and discusses related work in the one-of features.
field. Section 3 explains our approach for addressing variability 2.4 Related work
and evolution challenges in multi-tenant applications. Section 4 Several authors have proposed using SPL or M DE techniques for
presents a case study to motivate and illustrate our work. Finally, managing variability in cloud applications to address multi-
Section 5 concludes the presented approach. tenancy concerns. M oreover, there are some tools and frameworks
for deploying, provisioning or supporting portability of cloud
2. BACKGROUND applications. However, none combined the strength of these two
In this section, we briefly explain variability in multi-tenant
paradigms to address the multi-tenancy challenges, design
applications and their evolution. We also describe SPL and give
an overview of related work. decision variability challenges and evolution complexity.
2.4.1 MDE and SPLs
2.1 Variability M ietzner et al. [8] proposed variability management in multi-
Variability emerges in all levels of cloud applications. Abu-M atar tenant SaaS applications and their requirements using explicit
et al. [4] categorized the variability into the following levels: variability models of SPL. Initially, the customer-driven
application variability, business process variability, platform variability and realization-driven variability were modeled using
variability, provisioning variability, deployment variability and Orthogonal Variability M odel (OVM ). Then, the model was used
provider variability. Through this paper, we consider application to support customizability in applications. The authors also
variability and business process variability. supported efficient SaaS applications deployment for new tenants
In application variability, different tenants may have different based on the information about already deployed SaaS
functional and non-functional requirements in addition to the core applications. Nevertheless, this approach addresses the application
application. In business process variability, tenants may have variability and does not support evolution.
varying business workflows. Therefore, the application must Service line engineering (SLE) [9] (i.e., combination of service-
enable configuration and customization to meet tenant’s goals and oriented development and SPL) was introduced for customizable
requirements. In [8], variability is separated as customer-driven multi-tenant SaaS application development. SLE uses feature
variability and realization-driven variability. The customer-driven modeling to address engineering complexity and manage
variability comprises tenant requirements. We can classify variability caused by application-level multi-tenancy. The main
application and business process variability as customer-driven departure from SPL is that customizations are applied to a single
variability. The realization-driven variability represents different application instance that is shared across multiple tenants. The
implementation options derived by customer-driven variability. In author emphasized that SLE also supports application evolution.
this paper, we use design decision variability as realization-driven
Kumara et al. [11] described an approach for realizing service-
variability.
based multi-tenant applications. This approach is also feature-
61
oriented as SLE and it supports evolution by enabling runtime
sharing and tenant-specific variations using Dynamic SPLs.
CloudM L [12], CAM L [13], and CloudDSL [14] are examples of
modeling languages for cloud applications that exploited M DE
techniques. CloudM L automates provisioning for cloud
applications that run on multiple clouds. CloudDSL supports
portability of applications by describing cloud platform entities,
whereas CAM L supports deployment and enables migration of
existing applications to cloud. However, none of these modeling
languages addresses multi-tenancy in design decisions or
evolution of applications.
2.4.2 Combining MDE and SPLs
Shahin [10] integrated SPL and M DE to model variability for
customizable SaaS applications. In this approach, SoaM L was
extended to model variability in all layers of Service Oriented
Architecture (SOA). OVM from SPL was exploited to model
variability as separate models. These separate models were used
to generate a customization model for SaaS applications.
Cavalcante et al. [15] applied feature modeling to manage
commonality and variability in cloud applications. In addition,
they modeled costs regarding the use of cloud resources to Figure 2. Multi-tenant application development and
minimize expenditure. They also used UM L class diagram for evolution with MATA
features to identify dependencies.
conflicts and dependencies of models are checked. Finally, source
Abu-M atar et al. [4] described a framework for modeling service-
code specific to a particular cloud platform is generated.
oriented customizable multi-tenant cloud applications. They
exploited SPL for managing variability in services from multiple Figure 2 also describes application evolution which may require
views (i.e., service-oriented views and cloud views). They also models re-selection, adding new features, or a combination of
applied M DE for modeling multi-tenant aware application both. In the case of model re-selection, developers pick
artifacts. In [17], the framework was complemented to support appropriate features from the models of variant features. When
some evolution scenarios such as onboarding new tenants and evolution demands adding new features, developers identify
removing tenants. In our approach, we address multi-tenancy whether new features are common or variable. The new common
concerns by modeling variability in design decisions that emerges features affect the existing core UM L model, whereas for each
during the architecting process. Thus, developer can use variable feature a corresponding model of variant feature is
variability models for further support throughout the whole created. There might be cases when all new features are common
lifecycle of multi-tenant cloud applications. or variable. In the former, only the core UM L model is updated.
While in the latter, new models are added to the models of feature
3. OUR APPROACH variants and it requires models re-selection. Then, developers
We consider an integration of feature modeling concepts and generate a composed UM L model and source code.
M DE techniques to address the design decision variability and
evolution complexity in multi-tenant cloud applications. Our 4. CASE STUDY
approach is based on the work of Jayaraman et al. [16]. The main To explore our approach, we present a Surveys service [2] case
idea of this approach is maintaining feature separation and study by M icrosoft. Surveys is a multi-tenant SaaS application for
detection of structural dependencies and conflicts between creating and managing online surveys. Tenants can create, publish
features during analysis and design modeling. Features or groups surveys, and analyze results. Three different actors interact with
of features are modeled using UM L, and a model composition the application: the application provider administrator, the tenant
language, M ATA (M odeling Aspects using a Transformation administrator, and the survey respondent. The application
Approach), detects relationships and conflicts. However, this provider administrator manages all tenants and their surveys,
approach requires additional work to support cloud application whereas the tenant administrator manages its own surveys and
development and multi-tenancy. survey results, and the survey respondent completes surveys.
Figure 2 illustrates modeling multi-tenant applications that Although multiple tenants use the same application instance with
consists of the following steps. Initially, common and variable core functionalities and user interface layouts, each tenant can
functional and non-functional features with dependencies are view and edit its own data. In addition, the application allows
captured using feature modeling. This helps to define available tenants to apply user interface customization by uploading their
implementation options for the design decisions. Next, common corporate logo, adding tenant name, welcome text, and contact
features are used to model the core of the application using an details. Besides, tenants can customize the business process by
UM L composition language. Each variant feature is modeled in choosing a standard or premium subscription type. With standard
the M ATA language with dependencies to the core UM L model subscription, tenants can publish a limited number of surveys and
and relations to other features. This allows features to be modeled cannot export their survey results. Premium subscription tenants
independently of each other and enables reuse of models. Further, can create and publish any number of surveys, export survey
a composed UM L model is generated from the core UM L model results for further analysis, and their requests are prioritized by the
and selected models from models of variant features. At this stage, application.
62
Figure 3. The feature model of the S urveys application.
4.1 Applying our Approach increases, a more isolated approach must be selected from
As a first step, we constructed a feature model to define variability models to meet user requirements. With the M ATA
commonalities and potential variabilities in the application. An language multi-tenant data architectures are modeled separately
excerpt of the feature model is illustrated in Figure 3. As with their dependencies to the core model and can be easily
mentioned in Section 2.3, features were identified and categorized reused. Hence, developers can select any other multi-tenant data
into three layers. The capability layer comprises the functional architecture model at any time during the application evolution.
and non-functional features that are available for tenants. The
domain technology layer describes the way of implementing 4.2 Evolution Scenarios
Over the application lifetime, the functionality and quality of
features from the capability layer, and the implementation
service offered by the application must increase to meet tenants’
technique layer represents generic techniques to implement
requirements. In this section, we consider some evolution
features on a cloud infrastructure. Further, the features were
classified as mandatory, optional, alternative features, and at- scenarios that affect design decisions in the application structure.
least-one-of (OR). The mandatory features are common features When architecting the application structure, we decided to use a
that represent core components of the application that will alw ay s single database instance shared by all tenants. However, over time
be present in any evolution of the cloud application. Whereas the the number of tenants increases. Therefore, the number of
optional, alternative and at-least-one-of features are variable concurrent end users and amounts of data stored by each tenant
features that describe different possible implementations. Once increase as well. M oreover, some tenants may require a separate
the common and variable features are defined, the process (as database due to privacy requirements. These scenarios require a
defined in Figure 2) would come up with a core UM L model from more isolated data storage approach and entail model re-selection
the common features and models of variant features from the from models of variant features. Thus, developers select either a
variable features. As a next step, a composed UM L model from single database instance for each tenant or multiple database
the core UM L model and selected models of variant features instances for multiple tenants from the available data architecture
would be generated. models (as depicted in Figure 3).
Figure 3 shows that various options were modeled in the domain For maintaining a session state while creating a new survey, we
technologies and implementation techniques for realizing certain suggest JavaScript/AJAX technologies. This approach is simple,
features. These variability models are used to support evolution. easy to maintain, scalable, and secure compare to other available
For example, the application uses a single database instance implementation techniques under the M aintaining Session State
shared by all tenants. However, as the number of users per tenant feature. However, it relies on client-side JavaScript that makes it
the least robust solution among available techniques. In the future,
63
to improve robustness and effectiveness, developers must decide [7] K. Lee, et al., “Concepts and guidelines of feature modeling
between default in in-memory session state provider and cache for product line software engineering”, Proceedings of the
session. This scenario also requires model re-selection from 7th Conference on Software Reuse: M ethods, Techniques,
existing models of variant features. and Tools, pp. 62–77, 2002.
Another typical scenario is adding new features. For example, [8] R. M ietzner, et al., “Variability modeling to support
tenants may want to perform comp lex analysis on survey results. customization and deployment of multi-tenant-aware
Currently, the application stores survey answers in blob storage. Software as a Service applications", Proceedings of the 2009
To provide the new feature, an SQL database (from different ICSE Workshop on Principles of Engineering Service
models under Storage Type) is the best solution for applying Oriented Systems, pp. 18-25, 2009
complex queries and join query. When adding a new feature, [9] S. Walraven, et al., “Efficient Customization of M ulti-tenant
developers must identify whether the new feature is common or
Software-as-a-Service Applications with Service Lines”,
specific to certain clients. If the feature is common, the core UM L
Journal of Systems and Software, Vol. 91, pp. 48-62, 2014.
model will be updated. If the feature is variable, the core UM L
model will remain the same and a model of variant feature for this [10] A. Shahin, A “Variability M odeling for Customizable SaaS
variable feature will be generated. At this point, the M ATA Applications”, International Journal of Computer Science
language detects relations and dependencies of the new feature to and Information Technology, 6(5), pp. 39-49, 2014.
other features. The SQL Database also needs partitioning to [11] I. Kumara, et al., “Sharing with a difference: Realizing
support multi-tenancy. Thus, the developers must select one of the service-based SaaS applications with run-time sharing and
different partitioning models for SQL databases. M oreover, a new variation in dynamic software product lines”, IEEE
interface must be implemented to view and analyze survey data. Conference on Services Computing, pp. 567–574, 2013
5. CONCLUSION [12] A. Bergmayr, et al., “The Evolution of CloudM L and its
In this paper, we have proposed an integrated SPL and M DE M anifestations”, Proceeding of the 3rd Workshop on
modeling approach to address design decision variability and CloudM DE, 2015
evolution concerns in multi-tenant SaaS cloud applications. We [13] A. Bergmayr, et al., “UM L-Based Cloud Application
have applied feature modeling concepts to identify variability in M odeling with Libraries, Profiles and Templates”,
implementation. The M ATA language has been suggested to Proceedings of the 2nd Workshop on CloudM DE, 2014.
manage variability, and to support customization and evolution. [14] G. S. Silva, et al., “Cloud DSL: A Language for Supporting
Thus, the proposed approach allows features to be modeled CloudPortability by Describing Cloud Entities”, Proceedings
independently. Furthermore, conflicts in the application structure
of the 2nd Workshop on CloudM DE, 2014.
and dependencies between models are detected. However, it
requires improvements to enable cloud application development [15] E. Cavalcante, et al., “Exploiting Software Product Lines to
and multi-tenancy. Develop Cloud Computing Applications,” the 16th Software
Product Line Conference, 2012.
In our future work, we plan to enhance our approach by making
the M ATA language applicable for multi-tenant SaaS cloud [16] P. Jayaraman, et al., “M odel Composition in Product Lines
applications and by developing a model to code transformation and Feature Interaction Detection Using Critical Pair
prototype to transform composed models to source code. A case Analysis”, Conference on M odel Driven Engineering
study will be carried out to illustrate and evaluate the Languages and Systems, 2007
implemented tool. M oreover, we will compare our approach with [17] F. M ohamed, et al., “SaaS Dynamic Evolution Based on
other tools to identify benefits and drawbacks. M odel-Driven Software Product Lines”, Proceedings of the
IEEE 6th Conference on Cloud Computing Technology and
6. REFERENCES Science, 2014
[1] P. M ell, et al., “The NIST Definition of Cloud Computing”,
National Institute of Standards and Technology, Special
Publication 800-145, Bethesda, M aryland, 2011
[2] D. Betts, et al., “Developing M ulti-Tenant Applications for
the Cloud on Windows Azure”, M icrosoft Patterns and
Practices, 2013
[3] J. Guo, et al., “A framework for native multi-tenancy
application development and management”, Proceedings of
the 9th IEEE Conference on E-Commerce Technology and
the 4th IEEE Conference on Enterprise Computing, E-
Commerce and E-Services, pp. 551–558, 2007.
[4] M . Abu-M atar, et al., “Towards Software Product Lines
Based Cloud Architectures”, Proceedings of the IEEE
Conference on Cloud Engineering, 2014
[5] H. Gomaa, “Designing Software Product Lines with UM L:
From Use Cases to Pattern-Based Software Architectures”,
Addison-Wesley Professional, 2004
[6] I. Sommerville, “Software Engineering”, Pearson, 2010
64