A Pattern for Enabling Multitenancy in Legacy Application

Flavio Corradini, Francesco De Angelis, Andrea Polini and Samuele Sabbatini

University of Camerino, via del Bastione 2, Camerino, Italy

Keywords:

Multi-tenancy, Cloud Migration, Cloud Pattern.

Abstract:

Multitenancy is one the new property of cloud computing paradigm that change the way of develop software.

This concept consists in the aggregation of different tenant in one single istance in contrast with the classic

single-tenant concept. The aim of multitenancy is the reduction of costs, the hardware needed is less than

single-tenant application, and also the mantainance of the system is less expensive. On the other hand, appli-

cations need an high conﬁguration level in order to satisfy the requirements of each tenant. In this paper is

presented a pattern that enable legacy applications to handle a multitenancy database. After the presentation

of the different approach that implements multitenancy at database system, it is proposed the pattern that aims

to interact with this kind of database managing the different customization of different tenant at database level.

1 INTRODUCTION

The concept of cloud computing is exploding dur-

ing last year. Although the concept of utility com-

puting was introduced about ﬁfty years ago (Parkhill,

1966), it began to be a commercial need only in the

early 2000s. The fact that this new paradigm is driven

by commercial aspects and not from a real scientiﬁc

study has led to the creation of different deﬁnitions

(Vaquero et al., 2008) depending on the commercial

context. NIST (Mell and Grance, 2011) provides the

most used deﬁnition of cloud. They deﬁnes the cloud

model as a composition of ﬁve essential characteris-

tics, three service models, and four deployment mod-

els. The concept is totally revolutionary in software

development as foundries have been in the hardware

industry (Armbrust et al., 2009). One of the main

challenges is the ability to migrate legacy applica-

tion developed with previous methodologies into a

new environment and making them cloud compliant.

This challenge is due to the fact that legacy applica-

tion have been implemented with previous methods

without taking into considerations concepts unknown

until the advent of cloud (i.e. elasticity, scalability and

multi-tenancy).

This work focuses its attention on multi-tenancy

concept, in particular on how to adapt legacy appli-

cation that already exists in order to take advantage

from this new concept. The multi-tenancy, within the

software architecture community, is usually referred

to as the ability to serve multiple client organizations

through one instance of a software product and it can

be seen as an high level architectural pattern in which

a single instance of a software product is hosted on

the software vendor’s infrastructure, and multiple cus-

tomers access the same instance (Bezemer and Zaid-

man, 2010b).

Before going in deep with the multi-tenancy, it is

important to underline the difference between multi-

tenant and multi-user applications. In a multi-user

application we assume that all users are using the

same application with limited conﬁguration options.

In a multi-tenant application, we assume that each

tenant has the possibility to conﬁgure the application

heavily. This results in the situation that, although

tenants are using the same building blocks in their

conﬁguration, the appearance or work ﬂow of the

application may be completely different for two

tenants (Bezemer and Zaidman, 2010a). In order

to understand the meaning of multi-tenancy, it can

be used the deﬁnition formulated in (Kabbedijk

et al., 2015) after an evaluation through a Systematic

Literature Review. They analysed the deﬁnition of

43 different resources extrapolating a deﬁnition using

the most common word founded. The result of this

process is this deﬁnition:

Multi-tenancy is a property of a system where

multiple customers, so-called tenants, transparently

share the system’s resources, such as services,

applications, databases, or hardware, with the aim of

lowering costs, while still being able to exclusively

conﬁgure the system to the needs of the tenant.

Corradini, F., Angelis, F., Polini, A. and Sabbatini, S.

A Pattern for Enabling Multitenancy in Legacy Application.

In Proceedings of the 6th International Conference on Cloud Computing and Services Science (CLOSER 2016) - Volume 2, pages 257-264

ISBN: 978-989-758-182-3

257

Multi-tenancy concept involves the entire soft-

ware stack of applications. In this regard, it is nec-

essary to modify the entire stack to adapt legacy ap-

plications to the new model, focusing the attention on

the database and application levels. There are sev-

eral advantages related to multi-tenancy. Here are the

principal ones:

• The possibility to share hardware resources, en-

abling cost reductions (Wang et al., 2008);

• A high degree of conﬁgurability, enabling each

customer to create his own look-and-feel and

workﬂow within the application (Jansen et al.,

2010);

• A shared application and database instance, en-

abling easier maintenance (Kwok et al., 2008).

The aim of the study is to propose a pattern that

can enables applications to manage a multi-tenancy

database. Despite the management of a relational

database has been deﬁned by several studies, the ap-

plication adaptation to this new data management

model is still in process. This research is related

to the Open City Platform project (OCP project,

SCN

00467) founded by the Italian Ministry (Minis-

tero dell’Istruzione, dell’Universitae della Ricerca) in

the Smart Cities and Communities and Social Innova-

tion initiative (OCP Consortium, 2015). This project

aims to migrate the applications used by some Pub-

lic Administration in an private cloud infrastructure.

In this context, this pattern helps companies that are

working in the migration of their application in the

OCP Cloud Platform.

This paper is structured as follows: Section 2

presents some related works. Section 3 shows the

approach that can be used to create a multi-tenancy

database. Section 4 proposes a pattern that could en-

able multi-tenancy in legacy application. Moreover,

in that section it is presented the survey that validate

the pattern proposed. Section 5 focuses on conclusion

and future works.

2 RELATED WORK

This research is part of Italian national project that

aims to migrate legacy application in a cloud plat-

form. The aim of this project is very close to other

two European project: ARTIST(Artist Consortium,

2015) and REMICS (Remics, 2015). ARTIST and

REMICS are two projects very closed to the aim of

the research herein. These projects are funded by the

European Community, and they focus their aim on

migration using Model Driven Engineering (Object

Management Group, 2015b ). Both projects aim to

develop different tools of different part of the migra-

tion. REMICS ended in the 2013 and it focused the

attention on the recovery, migration, validation and

supervising processes of the migration itself. How-

ever this project did not cover challenges such as elas-

ticity, multi-tenancy and other non-functional proper-

ties. ARTIST focuses on migrating legacy software

written in Java and C. The project is still open and it

tries to support the migration in every aspect.

This paper focuses its attention on multi-tenancy.

This property is very important with the advent of the

cloud computing. Several researches are working in

the direction of deﬁning an approach to develop cloud

native applications or adapt legacy applications in or-

der to enable multi-tenancy. Bezemer et. al (Bezemer

and Zaidman, 2010a) propose an architectural pattern

that aims to enable multi-tenancy in single-tenant ap-

plication. In order to solve the problem, the solution

proposes three additional layers to be included in the

application. The ﬁrst layer is the Authentication layer

that is used to manage different tenants. The second

one is the Conﬁguration layer that is used to highly

conﬁgure applications. The last layer regards the in-

terface between the application and database layer

that help to adapt the query. The validation of this

approach is proposed in (Bezemer et al., 2010) where

the authors validated it with an Industrial Experience

Report. This works is very close to our work but they

offer an high level point of view that aim to cover all

the aspects of the multi-tenancy.

In (Kang et al., 2011) Kang et al. propose a con-

ceptual architecture of a SaaS platform that enables

the execution of conﬁgurable and multi-tenant SaaS

application. The platform allows to conﬁgure ﬁve as-

pects of SaaS software ( User Interface, Data Model,

Organizational Structure, Workﬂow, Business Logic).

In addition, meta-data driven architecture is applied

for providing multi-tenancy of SaaS application.

Another important work in multi-tenancy is (Mi-

etzner et al., 2009). In that work, it was described

how multi-tenancy can be achieved introducing and

evaluating a set of patterns that can be used to design,

develop and deploy process-aware service-oriented

SaaS applications.

The study of Kabbedijk et. al (Kabbedijk and

Jansen, 2011) is very closed to our. The research pro-

pose a set three of patterns that introduces variability

concept in multi-tenant Software as a Service solu-

tions. The proposed pattern are used to customize the

application depending on the tenants. The patterns

aim to customize data views, create dynamic menus

and implements custom module before or after a data

updating.

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

258

3 MULTI-TENANCY DATABASE

With cloud advent, NoSQL databases have acquired

an increased importance as they are more agile than

classical relational database (Sakr et al., 2011) (Chen

and Zhang, 2014). The use of NoSQL database is not

always the best choice, above all if the application al-

ready exists. In this case, the entire database migra-

tion would be very long and expensive. Considering

that the focus of this work is to adapt legacy applica-

tions to cloud, various approaches will be presented

to managing multi-tenancy database elaborated by

(Chong et al., 2006) and used in several works to

better deﬁne the concept of multi-tenancy database

level. The description of these approaches is proposed

through the use of key attributes for a well-designed

Saas application (scalability, multi-tenant efﬁciency

and conﬁguration) as presented in (Chong and Car-

raro, 2006). The approaches proposed are:

• Separated DataBase;

• Shared DataBase, separated schema;

• Shared DataBase, shared schema.

3.1 Separated Database

In this ﬁrst approach, each tenant has its own database

and its set of data that remains logically isolated from

data of all the other tenants (See Fig. 1). In this case,

in the provisioning process new standard database is

created for the new tenant. Each database can be ac-

cessed through meta-data services. The database can

be modiﬁed by the tenant in order to satisfy its needs.

The possible modiﬁcations are related both to the user

interface and the program logic and the tenant can po-

tentially create new ﬁelds, new queries, new tables

and relationships.

The advantage of this approach relies on the fact

that the database can be modiﬁed by the tenant so it

offers the maximum freedom of extension. Moreover,

in some speciﬁc case such as sensitive data manage-

ment ( i.e. medical or banking data management) this

approach is appropriate due to the strong data iso-

lation requirements. The disadvantages of this ap-

proach is related to the fact that it leads to support

only a limited number of database for each server

and consequence the cost of the infrastructure will be

higher.

3.2 Shared Database, Separate Schema

In the second approach a single database is shared

by all tenants (see Fig.2). In this database a pre-set

of customs ﬁelds that tenants can assign and use are

Figure 1: Architecture of ”Separated Database” approach.

present in addition to the standard set fo ﬁelds. Each

customer can choose what to use these ﬁelds for, and

how data will be collected for them.

The custom ﬁelds can be typed or untyped. The

ﬁrst one enable the customer to use any available

built-in type checking and veriﬁcation functions that

the application and database provide to validate the

data. In the case of untyped ﬁeld, the customer can

use them to store any type of data (the customer can

optionally provide its own validation logic, to prevent

users from accidentally entering invalid data).

Shared database allows a single database engine

to support a larger number of customers before par-

titioning becomes necessary rather than isolated ap-

proach. This leads to a lower cost of providing ser-

vice. The disadvantage related to this approach refers

to the extensibility of the data model that is limited to

the number of provided custom ﬁeld.

Figure 2: Architecture of ”Shared Database, Separate

Schema” approach.

3.3 Shared Database, Shared Schema

A single shared database is building in the third ap-

proach (see Fig. 3). In this case customers can ex-

tend the data model arbitrarily, storing custom data as

namevalue pairs in a separate table. A unique record-

ID is assigned to each customer record (including cus-

tom data). The unique ID matches one or more rows

in a separate extension table. For each row in this ta-

ble, a name-valuepair is stored. The name-valuepairs

can be created without any limitation (in number and

type) by customers.

When the application retrieves a customer record,

it performs a lookup in the custom data table, selects

all rows corresponding to the customer ID, and re-

turns them to be treated as ordinary data ﬁeld. In the

custom data table, data cannot be typed, because the

ﬁeld may contain data in many different forms for dif-

ferent customers. To solve this, a third column can

A Pattern for Enabling Multitenancy in Legacy Application

259

optionally hold a data type identiﬁer, so that the data

can be cast to the appropriate data type once it is re-

trieved.

This approach makes the data model arbitrarily

extensible, while retaining the cost beneﬁts of using

a shared database. But, the added level of complex-

ity for database functions (such as searching, index-

ing, querying, and updating records) can be consid-

ered one disadvantage of this approach. If customers

requires considerable degree of ﬂexibility in extend-

ing the default data model without the requirement of

data isolation. This will be the best approach.

It is important to consider that every time an ex-

tensively approach for data model is developed, any

extension implemented by a customer will require a

corresponding extension to the business logic (so that

the application can use the custom data), as well as an

extension to the presentation logic (so that users have

a way to enter the custom data as input and receive it

as output).

Figure 3: Architecture of ”Shared Database, shared

Schema” approach.

4 ENABLE MULTI-TENANCY IN

LEGACY APPLICATION

In this section we propose the pattern that we imple-

mented. The methodology used to describe the pat-

tern is described in Figure 4. In the context of OCP

project, various organizations have been facing the

problem of migration starting from an assessment to

evaluate the compatibility of an application with the

cloud platform (F. Corradini et al., 2015).

Some problems emerged during the evaluation of

this assessment. Among the most common prob-

lems that the various applications had to face, it

emerged the management of multi-tenancy database

that legacy (and single tenant) applications were not

able to handle. For this reason, it was decided to de-

velop a pattern that would help various developers in

migrating their applications. Pattern validation was

done through the use of questionnaires which were

then proposed to the same developer and to other in-

dustry experts. Depending on the results of the ques-

tionnaire, the necessary changes to the pattern were

carried out until the questionnaires proposed a satis-

factory result. In this case we needed two interaction

to validate the pattern. In the ﬁrst interaction, we fo-

cusing our attention on the feedback while the second

one was used to reﬁne the pattern.

Figure 4: Methodology of pattern deﬁnition.

4.1 Pattern

In the previous section, we presented various ap-

proaches that literature offers at database manage-

ment level. In order to enable multi-tenancy in

legacy application, database adaptation needs several

changes. These changes impact the behaviour of the

higher levels. In legacy application the logic layer re-

ceives standard data depending on the structure of the

tenant. Indeed, multi-tenancy applications data can

vary for each tenant as explained before. In this sec-

tion, we will present a pattern to be applied in an exist-

ing legacy application to enable the logic layer to ma-

nipulate data from multi-tenancy database. The con-

cept of pattern was adopted in software engineering

from the book of the ”Gang of four” (Gamma et al.,

1994). This concept relates to provide a solution to

a recurring problem with a generic scheme applica-

ble in all contexts. The following information will be

used for pattern description:

• The name of the pattern;

• The context of the problem;

• The description of the problem;

• The solution of the problem introduced by:

1. A class diagram expressed in UML (Object

Management Group, 2015a );

2. An explanation of the solution.

• The consequence of the application of the pattern.

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

260

4.1.1 Name

Customizable application for data handling.

4.1.2 Context

The concept of multi tenancy introduced with the ad-

vent of cloud has changed the implementation design

of applications. With this pattern, we would adapt

legacy applications to make them able to manage a

multi-tenancy database composed of heterogeneous

data among different tenants.

4.1.3 Problem

The multi-tenancy has led to new patterns of database

design. Although it is now possible to use a single

instance to multiple tenants, hardly the standard so-

lution is suitable for all of them. This involves the

management of different information within the same

instance. This problem affects both the database and

application level. At database level, where it is possi-

ble to manage multiple heterogeneous data sources in

a single instance, the application must be able to han-

dle different results (different data type or number of

arguments) according to the tenant making the query

to the database. So, the purpose of this pattern is to

make the software adaptable to the tenant needs giv-

ing the possibility to change / add / remove ﬁelds in

standard components of the application.

4.1.4 Solution

This pattern has to be applied to each component of

the application that has to be adapted to enable it

to manage heterogeneous information. The Compo-

nent class is the generic class that already exists in

the application, with all its attributes and methods al-

ready deﬁned. The rest are new classes that do not

modify the existing code. DataConﬁgurationMan-

agement class is the class of access to this pattern and

it has to manage the properties present in the Com-

ponent class. This class is able to access the generic

class through the use of ”addProperty”, ”deleteProp-

erty” and ”modifyProperty” functions and it enables

to modify the various parameters within the class.

Three methods corresponding to the methods of

the class DataConﬁgurationManagementare added to

the existing class. The management of the property

is done by the class DynamicProperty. This class is

used to manage all changes to the component and it is

used to deﬁne whether the property has been changed,

added or deleted from the component. The class Dy-

namicPropertyValue saves the value of the data and

make it accessible to the component. The class Dat-

aComponent regards the interface of the component

with the layer database.

Figure 5: Class Diagram of the pattern that helps to manage

different conﬁguration of multi-tenancy db.

4.1.5 Consequences

As mentioned in the previous sections, the impact of

the patterns in the existing architecture is low. The

pattern integrates itself with the existing code without

being invasive and this minimizes changes in what is

already done. The Component class is the only exist-

ing class and it does not require any changes with the

exception of the three methods that have to be added.

Depending on the implementation of the class Com-

ponent it is possible to implement the pattern using a

derived class or to add these methods directly in the

class without changing the existing code. In this way,

the pattern appears to be context-independentand this

makes it applicable every time it is needed.

In addition to the deployment aspect, the pattern

has non-functional advantages. First of all, the pat-

tern can increase the deployment process of the devel-

oper and it can guarantee the correctness of the sys-

tem. Another advantage of the pattern is to standard-

ize the applications. In this way a cloud provider can

increase the Quality of Services of their hosted appli-

cation implementing a service that properly manage

the pattern.

4.2 Pattern Utilization Example

In this example, we present the utilization of the pat-

tern in order to explain better how it works. First of

all, we present the process to add a new property. The

steps are showed in Fig. 6 and it can be summarize in

these steps:

A Pattern for Enabling Multitenancy in Legacy Application

261

1. The administrator of the system sends a request

of adding property to DataConﬁgurationManage-

ment class;

2. The DataConﬁgurationManagement Class calls

the component that has to be modiﬁed;

3. The Component creates a DynamicProperty to

handle the request of new property using the

method addProperty;

4. The DynamicProporty class creates Dynam-

icPropertyValue class that will be used by Com-

ponent class to logically store data.

5. The Component uses the DataComponent to store

the changes in the DB.

The process of modiﬁed and remove standard

property is the same as showed for creating new prop-

erty. The only changes regards the method called

in the step 3. To modify an already existing prop-

erty, it is used the method modifyProperty. Indeed,

deleteProperty is used in order to logically delete

property.

The behaviour of the application at execution time

does not change. A user, with permissions to access

at the component, uses in addition to it all the Dy-

namicPropertyValue of its speciﬁc tenant ( by check-

ing the tenantID ﬁeld of the DynamicProperty class).

The class DataComponent is used to get information

from the database or to store modiﬁcation occurred at

application level.

Figure 6: Sequence diagram of new property creation pro-

cess.

4.3 Validation

The research method used for the validation of the

pattern is a survey. The instrument used to collect

data is a questionnaire. Questionnaires are consid-

ered less time-consuming than interview surveys. The

questionnaire was submitted by using Google Form

and written in Italian, as all the evaluators are native

Italian speakers. The questionnaire consists of a se-

ries of closed questions and one open-ended question

to provide suggestions to improve the pattern. The

questionnaire was proposed to everyone involved in

the OCP project with a good technical basis to address

the evaluation. The following job functions were se-

lected in order to have a correct evaluation: architect,

software development manager or technical manager.

A total of 8 experts were involved in the evaluation.

The questionnaire consists of 4 different parts:

• Introduction of the questionnaire to explain the

context of use of the pattern

• Presentation of the pattern with diagram and de-

scription

• Closed-questions

• One open question for criticisms and hints

4.3.1 Questions

In this section we explain the questions used to eval-

uate the pattern. In the questionnaire eight different

characteristics that are needed in a multi-tenancy en-

vironment are evaluated. For every characteristic the

experts has to assign a score from 1 to 5 depending

on the level of satisﬁability. The score is expressed

in the following terms: 1: poor; 2: below average;

3: average; 4: good; 5: excellent. In the Invasive-

ness and Complexity the score is reverse where score

of 1 means excellent and score of 5 means poor. The

characteristics taken into account regards both cloud

environment and aspects related to the reference ap-

plication. At the end of the questionnaire there is an

open-ended question that is used for some consider-

ations of the experts. The characteristics taken into

account in the questionnaire are:

1. Signiﬁcance: Level of importance of the pattern.

How useful is to apply it in order to enable multi-

tenancy.

2. Invasiveness: Degree of impact of the pattern in

the existing code. More invasive is the pattern and

greater are the difﬁculties to implements in differ-

ent contexts.

3. Effectiveness: Evaluation of the pattern in rela-

tion to the initial troubleshooting. This parameter

indicates the degree of solution of the identiﬁed

problem.

4. Completeness: Evaluation of the pattern in rela-

tion to the aspects taken into account. Highlight if

the pattern covers all possible usage scenarios.

5. Complexity: Degree of complexity of implemen-

tation of the pattern and degree of efﬁciency to

which the software product can be made available

for use.

6. Portability: Degree of efﬁciency for the pattern

to be transferred from one environment to another.

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

262

7. Scalability: Degree of reliability of the pattern

when the workload changes. Adaptability of the

pattern to work with multiple instances.

8. Security: Degree to which the pattern ensures

that data are accessible only those authorized to

have access.

4.3.2 Results

In this section we describe the results of the last eval-

uation of the questionnaire(Tab. 1). For each param-

eter, it is shows the average and the variance of the

questionnaire. The average parameter is used to cal-

culate if the result is acceptable, the variance is used

to determine if there is an high dispersion of the score

in the speciﬁc parameter. The ﬁnal results of the ques-

tionnaire are shown as follows:

• Signiﬁcance: The result of this parameter is fun-

damental because it is used to evaluate if the pat-

tern is useful to enable multi-tenancy in the appli-

cation. A value of 3.8 indicates that the introduc-

tion of this pattern is useful for that aim.

• Invasiveness: The average of this parameter is

good but the variance is too high. This score in-

dicates a different behaviour depending on the ap-

plication.

• Effectiveness: The result is quite sufﬁcient. The

average of the results are quite good but a variance

of 0.84 indicates a problem in some type of appli-

cations. We will monitor this parameter when we

apply the pattern in other application.

• Completeness: This results is better than the Ef-

fectiveness. Even if the average is the same, in

this parameter we have a low level of variance in-

dicating same results from different applications.

• Complexity: It is the worst results of the eval-

uation regarding both average and variance. As

in the invasiveness, the results is a consequence

of the heterogeneous applications that are taken

into account from different experts. The variance

in this characteristics indicates a dispersion of the

results without a signiﬁcant majority of a value.

• Portability: It is one of the worse results of the

evaluation. The average score is sufﬁcient but it

has a quite high variance that indicates some ”be-

low average” results.

• Scalability: This characteristic is important in

cloud and in a multi-tenancy environment. A

component can have an elastic workload and it

can be duplicated. The scores of this characteris-

tic is good with a low level of variance, this means

that the pattern can handle multiple component in-

stances without problem.

• Security: It is one of the most important param-

eter of that pattern. Indeed, it is fundamental that

each tenant can access only to their data. The re-

sult of this parameter is good with a low variance.

Regarding the ﬁrst evaluation step, the developers

gave some important feedback that help us to improve

the pattern. The ﬁrst critic regards the permission of

the instance of DynamicProperty. To avoid this prob-

lem, we add the attribute tenantID who stores the ten-

ant with the permission to access and uses its own

speciﬁc instance. The second annotation of the devel-

opers regards the management of modiﬁed or deleted

standard properties. In this context, we decided to use

an enumerator in DynamicProperty class that helps

to choose dynamic properties instead of the standard

ones during the execution of the component.

Table 1: Results of the pattern evaluation.

Parameter Average δ

Signiﬁcance 3.8 0.98

Invasiveness 2.3 1.13

Effectiveness 3.6 0.84

Completeness 3.6 0.27

Complexity 3.1 1.27

Portability 3.5 0.86

Scalability 3.7 0.21

Security 3.9 0.7

5 CONCLUSIONS

In this paper we presented our work about building

a pattern to implement in legacy applications in or-

der to enable the accessing multi-tenancy databases.

The pattern is proposed as part of the OCP project. It

helps developers to modify the code of the application

faster and ensure that the applications involved in the

project have the same programming logic. However,

the pattern is independentof context and therefore can

be implemented in any type of application considered

that it is independent from the technology. Next step

of this work is to extend the pattern to other applica-

tion involved in OCP in order to have more feedback

and reﬁne, if necessary, the pattern. The realization

of this pattern was part of a larger effort that leads to

the realization of other patterns that solve problems

encountered in the valuation of the assessment. The

problems are related to the development of applica-

A Pattern for Enabling Multitenancy in Legacy Application

263

tions that enable a high level of conﬁguration in par-

ticular we will focus the attention in these aspects:

Role Conﬁguration; Workﬂow Conﬁguration; Busi-

ness Rule Conﬁguration; Report Conﬁguration; Ac-

tion Process Conﬁguration. The ﬁnal results of this

works will be a list of pattern that can be used by the

organization involved in OCP project ﬁrst of all but

also all the organization that want migrate legacy ap-

plication to the cloud.

REFERENCES

Armbrust, M., Fox, O., Grifﬁth, R., Joseph, A. D., Katz,

Y., Konwinski, A., Lee, G., Patterson, D., Rabkin, A.,

Stoica, I., etal. (2009). M.: Above the clouds: a berke-

ley view of cloud computing.

ARTIST Consortium (2015). Artist project.

http://www.artist-project.eu/.

Bezemer, C. and Zaidman, A. (2010a). Challenges

of reengineering into multi-tenant saas applications.

Technical report, Delft University of Technology,

Software Engineering Research Group.

Bezemer, C.-P. and Zaidman, A. (2010b). Multi-tenant saas

applications: maintenance dream or nightmare? In

Proceedings of the Joint ERCIM Workshop on Soft-

ware Evolution (EVOL) and International Workshop

on Principles of Software Evolution (IWPSE), pages

88–92. ACM.

Bezemer, C.-P., Zaidman, A., Platzbeecker, B., Hurkmans,

T., and Hart, A. (2010). Enabling multi-tenancy:

An industrial experience report. In Software Main-

tenance (ICSM), 2010 IEEE International Conference

on, pages 1–8. IEEE.

Chen, C. P. and Zhang, C.-Y. (2014). Data-intensive appli-

cations, challenges, techniques and technologies: A

survey on big data. Information Sciences, 275:314–

347.

Chong, F. and Carraro, G. (2006). Architecture strategies

for catching the long tail. MSDN Library, Microsoft

Corporation, pages 9–10.

Chong, F., Carraro, G., and Wolter, R. (2006). Multi-tenant

data architecture. MSDN Library, Microsoft Corpora-

tion, pages 14–30.

Corradini, F., Sabbatini, S., De Angelis, F., Polini, A.

(2015). Cloud readiness assessment of legacy appli-

cation. In In 5th International Conference on Cloud

Computing and Services Science (CLOSER 2015).

Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1994).

Design patterns: elements of reusable object-oriented

software. Pearson Education.

Jansen, S., Houben, G.-J., and Brinkkemper, S. (2010).

Customization realization in multi-tenant web ap-

plications: Case studies from the library sector.

Springer.

Kabbedijk, J., Bezemer, C.-P., Jansen, S., and Zaidman, A.

(2015). Deﬁning multi-tenancy: A systematic map-

ping study on the academic and the industrial perspec-

tive. Journal of Systems and Software, 100:139–148.

Kabbedijk, J. and Jansen, S. (2011). Variability in multi-

tenant environments: architectural design patterns

from industry. In Advances in conceptual modeling.

recent developments and new directions, pages 151–

160. Springer.

Kang, S., Kang, S., and Hur, S. (2011). A design of the

conceptual architecture for a multitenant saas applica-

tion platform. In Computers, Networks, Systems and

Industrial Engineering (CNSI), 2011 First ACIS/JNU

International Conference on, pages 462–467. IEEE.

Kwok, T., Nguyen, T., and Lam, L. (2008). A software as

a service with multi-tenancy support for an electronic

contract management application. In Services Com-

puting, 2008. SCC’08. IEEE International Conference

on, volume 2, pages 179–186. IEEE.

Mell, P. and Grance, T. (2011). The nist deﬁnition of cloud

computing.

Mietzner, R., Unger, T., Titze, R., and Leymann, F.

(2009). Combining different multi-tenancy pat-

terns in service-oriented applications. In Enterprise

Distributed Object Computing Conference, 2009.

EDOC’09. IEEE International, pages 131–140. IEEE.

Object Management Group (2015a). UML,

http://www.uml.org/.

Object Management Group (2015b). Model Driven Archi-

tecture. http://www.omg.org/mda/.

OCP Consortium (2015). Open city platform project.

http://www.opencityplatform.eu/.

Parkhill, D. F. (1966). Challenge of the computer utility.

REMICS Consortium (2015). Remics project.

http://www.remics.eu/.

Sakr, S., Liu, A., Batista, D. M., and Alomari, M. (2011).

A survey of large scale data management approaches

in cloud environments. Communications Surveys &

Tutorials, IEEE, 13(3):311–336.

Vaquero, L. M., Rodero-Merino, L., Caceres, J., and Lind-

ner, M. (2008). A break in the clouds: towards a cloud

deﬁnition. ACM SIGCOMM Computer Communica-

tion Review, 39(1):50–55.

Wang, Z. H., Guo, C. J., Gao, B., Sun, W., Zhang, Z., and

An, W. H. (2008). A study and performance evalu-

ation of the multi-tenant data tier design patterns for

service oriented computing. In e-Business Engineer-

ing, 2008. ICEBE’08. IEEE International Conference

on, pages 94–101. IEEE.

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

264