Autonomic Management for Availability And Performance in SaaS Model

Autonomic Management for Availability And Performance in SaaS Model Nadir K.Salih, Tianyi Zang School of Computer Science and Engineering, Harbin Institute of Technology, Harbin, Heilongjiang, China

Abstract - SaaS application gave many aspects of the business management. For that it became available and using in many domains. It will be needed to realize customer’s requirements from design to runtime. In this paper we have described the service availability for business process to perform the necessity of this kind of application. Depending on our SaaS model in three levels of the management we applied dynamic analysis by PRISM for availability and performance requirement. We followed the probability description because it the best way to define QoS requirements. It help us to use Markov chain which it described transition can occur from any state to other state and represented a simple or a compound event. For explain our research work we have taken the online booking as a running example. The result is we have adapted the SaaS online booking system by detecting or predicting violation in availability and performance requirements. Finally we present a conclusion and future work. Keywords: SaaS application, availability, Markov chain, probability

1

Introduction

In this paper we have showed the benefits of the autonomic management for our new model in SaaS application. Exactly we have defined the proportion of time for the system is functional and working to represented by availability in our model levels. We started at first by describing probability of the availability in the user level when the customer requires services from tenant level. It clearly obtained some scenarios for user activities will have an effect on the system availability. In the same description we introduced availability in the tenant level and the provider level. And the important thing is the availability of the services introduced from our SaaS model depends on availability of the resources. Secondly we used formal language probabilistic computation tree logic (PCTL), and continuous stochastic logic (CSL) which they have defined QoS requirements obviously. With the quality evaluation Markov chain we described discrete and continuous states of our model [1]. All processes have explained and verification models by used online booking example. We have summarized our contributions of this paper as follow:
A novelty in availability requirement for our three levels in SaaS model.
The hierarchy of availability in our model, availability

of the provider level means availability of the services, availability of the services level depends on availability of the resources level.
Used formal language is probabilistic computation tree logic (PCTL) and continuous stochastic logic (CSL) which they defined QoS requirements obviously.
Quality evaluation model by DTMCs, CTMCs
Approximation of availability and performance metrics it has adapted SaaS application and shows what the user and the tenant expecting from the system.
Empirical evaluation by using PRISM as a model checker. It made dynamic analysis for detecting or predicting violation of the SaaS application requirements. We organized this paper by beginning with the description for availability of the SaaS model in section 2. In section 3 we defined the formal definition of QoS requirement. By the sequence we introduced the type of the quality evolution model in section 4. In section 5 we have described running example for verification model. We made the empirical evaluation for availability and performance requirements in section 6. In section 7 we mentioned the related work. Finally, we present the conclusion and point to future work.

2

Availability of SaaS Model

Availability of the user level depends on availability of the tenant level and availability of tenant level depends on availability of the provider level. Therefore, a detailed of the availability and analysis for this architecture can be carried out to support design architectural decisions. Different variants of this architecture can be modeling and comparing with respect to the availability objectives to be fulfilled. For example the hierarchy of the availability requirement it depicted in figure 1. As we have described new model for the SaaS application in our last research. Here we extended it to manage availability and performance requirements. First of all we show the availability of three levels user, tenant, and provider as follow:

2.1

Availability Model in User Level

We have taken online booking hotel as example. The user level can access through web start with browse, booking, payment, and exit. We can describe many scenarios for user level by different probabilities as appeared in figure 2

2.2

Availability Model in Tenant Level

We look in tenant or travel agencies level through the web of monitoring customer’s booking activity as depict in figure 3. Travel agency it can divide the period of booking in a normal season or low season this mean resources availability in low season will be high. Pij it shows the probabilities between states of process in travel agencies level.

Fig 1 Availability of SaaS Model Fig 3 Availability Model in Tenant Level Probability variable from travel agency to travel agency depend on the services introduce and resources availability. Availability model in this level is very important to serve many users in fewer resources to minimize the costing. Fig 2 Availability Model in User Level Here in user level just the customer want to receive services from online booking hotel system. But in this level the user can do some processes without benefit travel agencies like just browse and searching without booking. This will effect to the resources availability for other they want to book. That can be appeared in scenarios in table 1 below: show different type of users by their probabilities in every scenario.

2.3

Availability Model in Provider Level

The provider level need availability model to manage all travel agencies. Begin from monitoring all events of travel agencies that serve all customers. And modification information of travel agencies by adds new agencies or deletes any redundancy data for them. After that the system in this level can show the costing or payment of the services provide from provider to travel agencies.

Table 1 User Level Scenarios Scenarios Start-browse-end Start-browse-browse-end Start-browse-search-end Start-browse-search-booking-end Start-browse-search-bookingcancelling-end Start-browse-search-bookingpayment-end Start-browse-search-booking-searchpayment-end Start-browse-search-booking-searchcancelling-end

type1 10% 20% 15% 20% 60%

type2 6% 10% 15% 40% 50%

type3 2% 12% 15% 20% 30%

20%

50%

70%

30%

45%

65%

40%

20%

10%

For example in scenario 1 (start-browse-end) the probability of user type 1 is 10 percent, user type 2 is 6 percent, and user type 3 is 2 percent. The user type has big value of the probability that can more effect in availability. In other scenario (Start-browse-search-booking-search-payment-end) this completes the booking service and gave good income by user type 3 for travel agency.

Fig 4 Availability Model in Provider Level By this description in provider level we showed the availability model for services that can be introduce in this level. We represented this availability by probabilities between states inside the model as depicted in figure 4.

2.4

Availability Model in Service Level

Availability model for service level can depend on web server, application server, and data base server that will be interact between any level of our model. Any service in figure 5 it has need to availability of web server at first to browse the service and the next probability for application server availability to process the functionality of service

is able to express both steady-state and transient properties by means of the S and ρ operators, respectively. The syntax of CSL is recursively defined as follows:

￢

Φ::= true |a| Φ⋀ Φ| Φ |  |  (Ψ) Ψ::= X  Φ| Φ   Φ

Fig 5 Availability Model in Service Level Then it need to availability of database server to modify and save data. In the last it need to the web server again to show the result or the request of the demand.

3

Formal Definition of QoS Requirements

The estimation of the QoS requirements [2] is very important for optimization SaaS application in our model. We used two formal languages are probabilistic computation tree logic (PCTL) and continuous stochastic logic (CSL), which they defined QoS requirements obviously. PCTL is defined by the following syntax:

￢

Φ::= true |a| Φ⋀ Φ| Φ |  (Ψ) Ψ::= X Φ | Φ   Φ Where p ∈ [0, 1], ∈ {, ≥}, t ∈ N ∪{∞}, and a represents an atomic proposition. The temporal operator X is called next and U is called until. Formula generated from Φ is referred to as state formula and they can be evaluated to either true or false in every single state. While the formula generated from Ψ are named path formula and their truth is to be evaluated for each execution path. PCTL can naturally represent availability-related properties for a DTMC model of the application. For example, we may easily express constraints that must be satisfied concerning the probability of reaching absorbing failure or success states from a given initial state. These properties belong to the general class of reachability properties. Reachability properties are expressed as  ( Φ) which expresses the fact that the probability of reaching any state satisfying Φ has to be in the interval defined by constraint  . In most cases, Φ just corresponds to the atomic proposition that is true only in an absorbing state of the DTMC. In the case of a failure state, the probability bound is expressed as ≤ x , where x represents the upper bound for the failure probability; for a success state it would be instead expressed as ≥ x , where x is the lower bound for success. PCTL is an expressive language through which more complex properties than plain reachability may be expressed. Such properties would be typically domaindependent, and their definition is delegated to system designers. We have considered the continuous stochastic logic to state properties on CTMC models. For CTMC there are two main types of properties relevant for analysis: steady-state properties where the system is considered when equilibrium has been reached. And it is the transient properties where the system is considered at specific time points or intervals. CSL

Where p ∈ [0, 1], t ∈ R≥0 ∪ {∞}, ∈ {, ≥}, and a represents an atomic proposition. The semantics of Boolean operators is the same defined for PTCL. As well as the possibility it defines derived operators, both boolean and temporal. To address the semantics of S and, let us first introduce the notation π@t, which denotes the state in which the execution described by trace π is at time t. As before, π[i] denotes the i-th state the execution passed through, thus π@t  = π[i] with i =mini {t ≤ ∑  }.

4

Quality Evaluation Model

The uses of models extend beyond the initial design of an application support both the evolution of the software architecture. And it is devises suitable for reconfiguration strategies in dynamic contexts. To model complex interactions between components, use other kinds of models like Markov chains or more generally state space models. Many examples of dependencies among system components have been observed in practice and captured by Markov models. State-space based model which states represent various conditions of the system. Transitions between states indicate occurrences of events. State can keep track of number in functioning resources of each type, states of recovery for each failed resource, number of tasks of each type waiting at each resource, and allocation of resources to tasks. A transition can occur from any state to any other state and can represent a simple or a compound event. For that we looked in the Markov chain has two types in discrete and continuous time:

4.1

Discrete SaaS User-Tenant-Provider Model

State-transition systems augmented with probabilities formalizing path-based on properties of Discrete SaaS UserTenant-Provider Model (DSUTP) model [3]. We turn to the problem of constructing a discrete time Markov chain with a given initial distribution, α, and transition matrix, P. More explicitly, for the discrete set S = {1, 2, . . . } (the finite state space is handled similarly), we assume the existence of: (i) An initial distribution α = {αk} giving the associated probabilities for the random variable X0. That is, for k ∈ S, αk = P{X0 = k}……………..(1) (ii) Transition probabilities, pij , giving the desired probability of transitioning from state i ∈ S to state j ∈ S: pij = P{Xn+1 = j | Xn = i}…....(2) Note that we will require that α is a probability vector in that αk ≥ 0 for each k and ∑∈  =1 We further require that for all i ∈ S∑∈  =1.

We simply says that the chain will transition somewhere from state i (including the possibility that the chain transitions back to state i). The problem is to now construct a discrete time Markov chain for a given choice of α and {pij} using more elementary building blocks: uniform random variables. Implicit in the construction is a natural simulation method.

4.2

Continuous SaaS User-Tenant-Provider Model

A Continuous SaaS User-Tenant-Provider Model (CSUTP) is characterized by state changes that can occur at any arbitrary time the Index space is continuous and the state space is discrete valued [4]. A CSUTP can be completely described by: Initial state probability vector for X (t0):  = ! , ! = 0,1,2, … … ………….….(3) Transition probability functions (over an interval):

 ',  =  = |' = ( , )*+ 0 , ' ,  -./ (,  = 0,1,2 … 1, () ( = 

 ,  = 0 -./ , ∑∈5  6 ',  = 0 *12+3(42 1 7 (; ,0 , ' , …………………………….....(4) A CSUTP is said to be irreducible if every state can be reached from every other state, with a non-zero probability. A state is said to be absorbing if no other state can be reached from it with non-zero probability. Notion of transient, recurrent non-null, recurrent null are the same as in a DSUTP. There is no notion of periodicity in a CSUTP.

R4: The probability P4 of the service monitor event failure from provider web site P4=0. 05. R5: The probability P5 the service demand of booking during high season will drop if it take more than 5 second, P5 more than or equal 0.5. R6: The probability P6 the service request of booking during high season will drop if it take more than 10 second, P6 more than or equal 0.8. R7: The probability P7 the service request of monitor event from provider to tenants will drop if it take less than 7 second, P7 more than or equal 0.4. SaaS application administrators require suitable availability in QoS requirements [5]. Approximation of metrics [6] that will adapt SaaS application and what the user and tenant expecting from system will help administrators. The availability services of our three levels model it has depicted in figure 6 by DSUTP model.

5 Running Example for Verification SaaS Model From our activity diagram in previous research we have described the workflow representing online booking system to customer. We have defined SaaS application in three management levels. We have taken samples of the services for every level. For example provider level has: (1) modify travel level data, (2) monitor events, and (3) reporting, for tenant level has: (1) check user form, (2) modify tariff, and (3) customer reporting, and user level has: (1) available booking, (2) cancelling booking, and (3) searching. The costing or payment process for this system classified in two types: first payment from customer to travel agencies for giving services like booking. Second payment from travel agencies to provider for prepares resources and data management for them. In our system need to monitor the availability of the services, there are some properties will be very important like failure rate (FR) of services, the costing(C) of the services, execution time (ET) inter-arrival rate (µ), and maximum request of services (λ). From property we can define some requirements for suitable availability and performance metrics for our model: R1: The probability P1 of the service booking failure from user web site P1=0.13 R2: The probability P2 of the service cancelling failure from user web site P2=0.14 R3: The probability P3 of the service modify tariff failure from tenant web site P3=0.01.

Fig 6 Online Booking DSUTP Model Requirements R1–R4 can be translated in PCTL as follows: 9.;< = = 4 = 22> The probability of eventually reaching state 22 booking failure, which corresponds to the successful completion of the session (see Fig. 6) is greater than or equal 0.13 9.;? = = 4 = 21> The probability of eventually reaching state 21 cancelling failure, which corresponds to the successful completion of the session (see Fig. 6) is greater than or equal 0.14 9.; = = 4 = 23> The probability of eventually reaching state 23 modify tariff failure, which corresponds to the successful completion of the session (see Fig. 6) is greater than or equal 0.01 9.A = = 4 = 24> The probability of eventually reaching state 24 monitor event failure, which corresponds to the successful completion of the session (see Fig. 6) is greater than or equal 0.05 Performance requirement for our model in three levels it can realize the continuity of SaaS system activity. We have defined the state rate in a time for three levels in our running example see table 2. To show these continuous states and their requests we have depicted CSUTP model in figure 7.

1 2 3 4 5 6 7 8 9 10 11 12

Table 2 State Rate in A time State rate(λ) Value req\sec Login-cancel 10 Login-booking 15 Cancel process 20 Generate cancel 5 Booking process 30 Generate booking 8 Login-travel agency 5 Receive job 10 Done job 5 Login-provider 3 Monitor event 5 Modification by provider 20

Fig 7 Online Booking CSUTP Model Performance requirements have been mapped into the following CSL formula (notice that the notion of time here is continuous and not discrete in time steps. 9.A = = A 4 = 11> The probability of eventually to reach state 11 (generate booking) within 5 s is greater than or equal 0. 5 9.C = = ; 4 = 12> The probability of eventually to reach state 12 (request booking done) within 10 s is greater than or equal 0. 8 9.? = = D 4 = 5> The probability of eventually to reach state 13 (request of monitor event report) less than 0.5 s is greater than or equal 0.4

6 Empirical Evaluation We have adapted the SaaS application automatically identified by detecting a validation of requirement for our model in three levels. The possible verification of requirements can be achieved by using model checking techniques. We used DSUTP model and connected with environment which can effect in SaaS availability may be change over a time. The requirements from R1 to R4 are depicted by DSUTP for analysis availability requirements and represented the failure of services. By CSUTP model we have defined R5 to R7 for analysis performance requirements [7].

6.1

Availability Requirement

We used PRISM as model checker to dynamic analysis temporal logic formula for all possible value. For availability we have an assign to configurable SaaS parameters by depict

the probability variation of the requirements failure to consider into valid and invalid range. From figure 6 we have supposed some failures for three levels of our model. Here we used PRISM coding to DSUTP model failure of online booking system services see the listing 1. Table 3 The Pseudo-code of DSUTP for R1 to R4 A pseudo-code of DSUTP for R1 to R4 dtmc module failure 1 // local state 2 s: [1..24] init 1; 3 // state failure 4 d: [21..24] init 21; 5 [ ] s=1->0.01:(s'=2)+0.39: (s'=3)+0.3: (s'=4) + 0.3:(s' =5) ; 6 [ ] s=2 -> 0.86 : (s' =6) + 0.14 : (s' =21) & (d' =21) ; 7 [ ] s=3 -> 0.87 : (s' =7) + 0.13 : (s' =22) & (d' =22) ; 8 [ ] s=4 -> 1 : (s' =8); 9 [ ] s=5 -> 0.95 : (s' =9) + 0.05 : (s' =24) & (d' =24) ; 10 [ ] s=6 -> 1 : (s' =10); 11 [ ] s=7 -> 1 : (s' =11); 12 [ ] s=8 -> 1 : (s' =12); 13 [ ] s=9 -> 1 : (s' =16); 14 [ ] s=10 -> 1 : (s' =13); 15 [ ] s=11 -> 1 : (s' =14); 16 [ ] s=12 -> 1 : (s' =15); 17 [ ] s=13 -> 1 : (s' =17); 18 [ ] s=14 -> 1 : (s' =18); 19 [ ] s=15 -> 0.99 : (s' =19) +0.01 : (s' =23) & (d' =23) ; 20 [ ] s=16 -> (s' =16); 21 [ ] s=17 -> (s' =17); 22 [ ] s=18 -> 1 : (s' =20); 23 [ ] s=19 -> (s' =19); 24 [ ] s=20 -> (s' =20); 25 [ ] s=21 -> 1 : (s' =21); 25 [ ] s=22 -> 1 : (s' =22); 27 [ ] s=23 -> 1 : (s' =23); 28 [ ] s=24 -> 1 : (s' =24); Endmodule Experimental results about our method we used the probabilistic model checker PRISM on the example to verify the satisfaction of the previous properties, we got the following probabilities: • “Probability of cancelling failure is equal to 0.0014” • “Probability of booking failure for a user is equal to 0.0507” • “Probability of tariff failure for travel agencies equal to 0.003” • “Probability of monitor event failure for provider level equal to 0.015” We supposed input from outside environment to our model that has modeling different services. Two services from user level cancelling failure and booking failure. The output of PRISM indicated to validation of input because the probability 0.0014, 0.0507 for cancelling failure, and booking failure respectively inside the range of requirements (cancelling failure from user web site P2=0.14, booking failure from user web site P1=0.13). In the tenant level the probability of tariff failure is 0.01 no violated in model

checker because it 0.003. And so for provider level the failure of monitor event for travel agencies activities is 0.05 more than the output of PRISM 0.015 it is valid value. The output of this analysis is in figure 8 bellow.

Fig 8 Analysis of Availability Requirements Model checker help online SaaS application to detect the violation that will lead to failure it look like prognostics strategies [8] to what will happen. And we understand the effect of services failure for availability of application. Definitely we increased availability of the SaaS application to be functional and working.

6.2

28 [] s=13 -> 5.5 : (s'=9) ; 29 endmodule Again by means of PRISM, we get the following probabilities: • “Probability that demand of booking during high season will drop if it take more than 5 second, P5=1. ” • “Probability P6 the request of booking during high season will drop if it take more than 10 second, P6=1” • “Probability the request of monitor event from provider to tenants will drop if it take less than 7 second, P7=1” We observed that PRISM output not satisfies the requirements under the stated assumptions on the behavior of the environment because it violated the value input for system control. Can see figure 9 analysis the different probability services request for the model levels drop generatebooking, drop requesbooking, and drop monitorevent for user level, tenant level and provider level respectively.

Performance Requirements

Here we used PRISM coding to CSUTP model of the online booking system services for performance requirement [9]. See the listing 2. Table 5 The Pseudo-code of CSUTP for R5 to R7 A pseudo-code of CSUTP for R5 to R7 ctmc module GCbooking 1 // local state 2 s : [1..11] init 1; 3 // value of the drop 4 d :[10.. 11] init 10; 5 [] s=1 -> 15 : (s'=3) ; 6 [] s=3 -> 30 : (s'=7) ; 7 [] s=7 -> 8 : (s'=11) &(d' =11); 8 [] s=11 -> 3.5 : (s'=7) ; 9 endmodule 10 module Gdonebooking 11 // local state 12 s : [1..12] init 1; 13 value of the drop 14 d :[11.. 12] init 11; 15 [] s=1 -> 5 : (s'=4) ; 16 [] s=4 -> 10 : (s'=8) ; 17 [] s=8 -> 2.3 : (s'=4) + 5 : (s'=12) & (d' =12) ; 18 [] s=12 -> 3.5 : (s'=8) ; 19 endmodule 20 module Gdonereportevent 21 //local state 22 s : [1..13] init 1; 23 // value of the drop 24 d: [12..13] init 12; 25 [] s=1 -> 3 : (s'=5) ; 26 [] s=5 -> 5 : (s'=9) ; 27 [] s=9 -> 4.2 : (s'=5) + 20 : (s'=13) & (d' =13) ;

Fig 9 Analysis of Performance Requirements Continuous detection of this violation will increase the SaaS system performance and define the range of time request for every level service of our model. In addition we can predict for what will happen for any service level. This analysis depend on monitoring specification of system environment and it choices for plan state [10].

7 Related Work The SaaS application is hot research in recent years in [11] they Configurable business process, and isolation database to Leverage SMEs. Researchers in [12] they innovated multi-layered customization framework to Manage the variability of SaaS applications and tenants-specific requirements. Ontology is used to derive customization and deployment information for tenants cross layers. In [13] authors they used Context-oriented Programming to achieves a higher customization flexibility by single-version application code base. In [14] they Identified requirements for such a runtime architecture addressing the individual interests of all involved stakeholders. SaaS reference architecture must support at design time as well as at runtime. They Selfoptimize the runtime environment according to a tenant’s configuration. Authors in [15] they designed Three architectural patterns that support variability in multi-tenant SaaS environments. In [16] they depicted the design space and represent the common and variant parts of SaaS architectures. Feature model enhances the understanding of SaaS systems, and supports the architect in designing the

SaaS application architectures. The research in [17] it defined architecture by SaaS application layers for flow customization business process. Integration requirements and roadmap between SaaS application and on-premise applications are introduced in [18] by frame work architecture in SBM services. In [19] they designed Systematic approach and corresponding tool support for guiding the design of SaaS application architectures. Selected features are related to design decisions and a SaaS application architecture design is derived. They separated data servers for Tenants, separated application server, and one distribution server. They implemented architecture in [20] to define a SaaS application as an organization-based service composition and helps SaaS vendors, tenants in modeling and managing their applications. All researches didn’t take autonomic management for SaaS application.

8

Conclusions

This paper has explained the way for autonomic management of QoS requirements for SaaS application. We have described the availability of SaaS application because it is a big issue in business process. To grantee the system continuous working we used the probability modeling. That it has gave our model high power in dynamic analysis for QoS requirements. By PRISM we have insured the model checker can give indicator of violation of requirements to detect and predict for what will happen. The future work will be following the autonomic management of the SaaS application for other QoS requirements in our new model.

9

Acknowledgement

This work has been developed with the support under the project with number: 2012AA02A604, 863 Program key projects in China: The Technology and the System Development for Smart Acquirement of Personal Healthcare Information. And so the Key Project of NSF in China: Methodology of Value-oriented Software Services: Theory, Method and Application with number: 61033005.

10 References [1] N. Poggi , T. Moreno , J. L. Berral , R. Gavaldà , J. Torres. Selfadaptive utility-based web session management. Elsevier, 2008, pp. 1712–1721. [2] N. Pogg, T. Moreno, J. L. Berral, R. Gavald, Jordi Torres. Web Customer Modeling for Automated Session Prioritization on High Traffic Sites. Springer-Verlag Berlin Heidelberg, 2007, pp. 450–454. [3] N.Tcholtchev, A. Betkowska Cavalcante, R. Chaparadza. Scalable Markov Chain based Algorithm for Fault-Isolation in Autonomic Networks. Communications Society subject matter experts for publication, IEEE, 2010. [4] R. Calinescu , M. Kwiatkowska. Using Quantitative Analysis to Implement Autonomic IT Systems.IEEE, 2009, pp.100-110. [5] R. Ashok Kumar, K. Hareesh, K. Ganesan, D. H. Manjaiah. Maximizing the Availability and Reliability of Videos in VoD System Using Markov Chain. International Conference on Communication Theory, Reliability, and Quality of Service. IEEE, 2009, pp. 15-19.

[6] G. Casale, N. Mi, L. Cherkasova, E. Smirni. Dealing with Burstiness in Multi-Tier Applications: Models and Their Parameterization. IEEE Transactions oN Software Engineering, vol. 38, no 5. 2012, pp.1040-1053. [7] A. Shrestha, L.Xing Y. Dai. Decision Diagram Based Methods and Complexity Analysis for Multi-State Systems. IEEE Transactions ON reliability, vol 59, no. 1, 2010, pp. 145-161. [8] B. Sun, S. Zeng, R.Kang, M. G. Pecht. Benefits and Challenges of System Prognostics, IEEE Transactions on Reliability, vol. 61, NO. 2, 2012, pp. 323-335. [9] D. Krishnamurthy, J. Rolia, M. Xu. WAM—The Weighted Average Method for Predicting the Performance of Systems with Bursts of Customer Sessions, IEEE Transactions ON Software Engineering, vol. 37, no. 5,2011, pp.718-735. [10] M. S. Bouguerra, D. Trystram, F. ric Wagner. Brief Contributions: Complexity Analysis of Checkpoint Scheduling with Variable Costs. IEEE Transactions on Computers, vol. 62, no. 6, 2013.pp 1269-1275. [11] Irene S. Harris, Z. Ahmed. An Open Multi-Tenant Architecture to Leverage SMEs. European Journal of Scientific Research. Vol.65 No.4, pp. 601-610, 2011. [12] W.Tek Tsai, Q. Shao, W. Li. OIC: Ontology-based Intelligent Customization Framework for SaaS. International Conference on Service-Oriented Computing and Applications (SOCA) IEEE,2010. [13] E. Truyen, N. Cardozo,S. Walraven, J. Vallejos, Bainomugisha, S. Gunther, T. Hondt, W. Joosen. Context-oriented Programming for Customizable SaaS Applications. Proceedings of the 27th Annual Symposium on Applied Computing ACM, 2011, pp. 418-425. [14] Julia Schroeter, Sebastian Cech, Sebastian Götz, Claas Wilke, Uwe Aßmann. Towards Modeling a Variable Architecture for MultiTenant SaaS-Applications. Sixth International Workshop on Variability Modeling of Software-Intensive Systems.ACM, 2012. [15] Jaap Kabbedijk, Slinger Jansen. Variability in Multi-tenant Environments: Architectural Design Patterns from Industry, Springer, 2011. [16] K. Öztürk, B. Tekinerdogan, Feature Modeling of Software as a Service Domain to Support Application Architecture Design. International Conference on Software Engineering Advances. IARIA, 2011. [17] Ralph Mietzner, Frank Leymann. Generation of BPEL Customization Processes for SaaS Applications from Variability Descriptors, International Conference on Services Computing.IEEE, 2008. [18] A. J. Elmore, S. Das, D. Agrawal, A. El Abbadi. Towards an Elastic and Autonomic Multitenant Database. ACM, 2011. [19] B. Tekinerdogan, K. Ö., A.Doğru, Modeling and Reasoning about Design Alternatives of Software as a Service Architectures. Ninth Working IEEE/IFIP Conference on Software Architecture.IEEE,2011. [20] D. Concha, J. Espadas, D. Romero, A. Molina. The e-HUB evolution: From a Custom Software Architecture to a Software-as-aService implementation. Elsevier,2010, pp 145–151.