Dynamic provisioning in multi-tenant service clouds
Lakshmi Ramachandran, Nanjangud C. Narendra & Karthikeyan Ponnalagu
Service Oriented Computing and Applications ISSN 1863-2386 Volume 6 Number 4 SOCA (2012) 6:283-302 DOI 10.1007/s11761-012-0116-0
1 23
Your article is protected by copyright and all rights are held exclusively by Springer-Verlag London Limited. This e-offprint is for personal use only and shall not be self-archived in electronic repositories. If you wish to selfarchive your work, please use the accepted author’s version for posting to your own website or your institution’s repository. You may further deposit the accepted author’s version on a funder’s repository at a funder’s request, provided it is not made publicly available until 12 months after publication.
1 23
Author's personal copy SOCA (2012) 6:283–302 DOI 10.1007/s11761-012-0116-0
ORIGINAL RESEARCH PAPER
Dynamic provisioning in multi-tenant service clouds Lakshmi Ramachandran · Nanjangud C. Narendra · Karthikeyan Ponnalagu
Received: 20 July 2011 / Revised: 16 May 2012 / Accepted: 19 June 2012 / Published online: 31 July 2012 © Springer-Verlag London Limited 2012
Abstract Cloud-based systems promise an on-demand service provisioning system along with a “pay-as-you-use” policy. In the case of multi-tenant systems this would mean dynamic creation of a tenant by integrating existing cloudbased services on the fly. Presently, dynamic creation of a tenant is handled by building the required components from scratch. Although multi-tenant systems help providers save cost by allocating multiple tenants to the same instance of an application, they incur huge reconfiguration costs. Cost and time spent on these reconfiguration activities can be reduced by re-constructing tenants from existing tenant configurations supported by service providers. Multi-tenant cloudbased systems also lack the facility of allowing clients to specify their requirements. Giving clients the flexibility to specify requirements helps them avoid spending an excessive amount of time and effort looking through a list of services, many of which might not be relevant to them. Moreover, dynamic provisioning in the cloud requires an integrated solution across the technology stack (software, platform and infrastructure) combining functional, non-functional and resource allocation requirements. Existing research works in the area of web service matching, although numerous, still fall short, since they usually consider each requirement type
in isolation and cannot provide an integrated solution. To that end, in this paper we investigate the features needed for dynamic service provisioning on the cloud. We propose a novel User Interface-Tenant Selector-Customizer (UTC) model and approach, which enables cloud-based services to be systematically modeled and provisioned as variants of existing service tenants in the cloud. Our approach considers functional, non-functional and resource allocation requirements, which are explicitly specified by the client via the user interface component of the model. To the best of our knowledge, ours is the first such integrated approach. We illustrate our ideas using a realistic running example, and also present a proof-of-concept prototype built using IBM’s Rational Software Architect modeling tool. We also present experimental results demonstrating the applicability of our matching algorithm. Our results show significant reduction in matching time with the help of an elimination process that reduces the search space needed for performing matching.
Thanks to the following for their feedback: Munindar Singh, Marco Aiello, GR Gangadharan, Saurabh Sinha, Vinayaka Pandit, Sugata Ghosal and Debdoot Mukherjee.
1 Introduction
L. Ramachandran North Carolina State University, Raleigh, NC, USA e-mail:
[email protected] N. C. Narendra (B) · K. Ponnalagu IBM India Research Lab, Bangalore, India e-mail:
[email protected] K. Ponnalagu e-mail:
[email protected]
Keywords Service-oriented architecture · Service clouds · Cloud computing · Multi-tenant systems
One of the promises of the cloud-computing paradigm is an on-demand composition of services (software-as-a-Service (SaaS), platform-as-a-Service (PaaS) or infrastructure-as-aService (IaaS)) for clients [7,17]. Multi-tenant cloud-based systems allow multiple clients to work on the same instance of an application, be it software or database tables. Although they help providers save costs by avoiding deployment of dedicated applications, they incur considerable reconfiguration costs.
123
Author's personal copy 284
SOCA (2012) 6:283–302
(service) tenant capabilities in response to a client’s requirements. In contrast to traditional web service matching techniques (e.g., [1,4,5,18,21,26]) our technique encompasses the entire technology stack (SaaS, IaaS and PaaS) and considers functional, non-functional and resource allocation requirements together. An overview of our system’s operation can be found in Fig. 2. Some of the chief contributions of this paper include:
Fig. 1 Overall architecture of the User interface-Tenant selector-Customizer system
Reconfiguration in multi-tenant systems may involve activities such as configuring a tenant’s instances in order to make it appear custom-made for that particular client, handling constraints listed by a tenant in its service level agreement (SLA) or managing resources allocated across different tenants. However, there are times when the configuration a client is seeking can be re-constructed using configuration instances of existing tenants. If similar changes have been made by the provider for existing tenants, then re-doing them for a new tenant might prove to be wasteful. Currently, cloud-based systems are designed in a manner that requires a client to select and instantiate service tenants1 from a catalogue prepared by the provider. As a result clients spend excessive amounts of time and energy searching through a list of available services, resulting in a sub-optimal selection. In this paper we propose an overall system architecture called User Interface-Tenant Selector-Customizer (UTC), which is represented in Fig. 1. A more detailed representation of the UTC’s operation is depicted in Fig. 2. The user interface component depicted in Figs. 1 and 2, provides clients with the flexibility of explicitly stating their expected constraints and behavior. Client’s requirements are modeled using the Tenant Requirements Model (TRM), explained in Sect. 2.1. The tenant selector feature of our system ensures fast and efficient tenant creation by matching the client’s requirements with the provisioned tenants’ functionalities. Provisioned tenants’ features are represented with the help of a Tenant Provider Model (TPM). The customizer is an additional feature of the UTC system that helps improve the matching (if possible) created by the tenant selector. When a matching is found, the newly created tenant is added to the set of existing tenants provisioned by the service provider. The UTC is a complete tenant configuration matching system. We have identified features of a multi-tenant provisioning system that can fulfill the vision of serviceoriented architecture [15], viz., dynamic provisioning of 1
A detailed description of service tenants or service clouds is available at http://cloudscaling.com/blog/cloud-computing/cloud-futurespt-1-service-clouds.
123
– Models that help define tenant providers and clients. – An integrated algorithm for matching and dynamic resource allocation based on a tenant’s state (explained in Sect. 2.3). – A novel technique for eliminating redundant tenant functionalities that quickens the pace of the matching algorithm (explained in Sect. 4.1.2). – A unique feature that helps create a customized match for the client’s requirements (explained in Sect. 4.2). – An overall approach that considers software, platform as well as infrastructural requirements during matching. While our matching algorithm can be applied to any generic service matching problem as described in earlier research [1,4,5,18,21,26], being a combination of the aforementioned original contributions makes our approach specially suitable for the cloud, where the issues of matching speed and resource constraints predominate. Figure 3 contains a pictorial representation of the features of our system. This figure depicts the paucity of related work in solving the problem that our paper addresses, and serves to demonstrate the novelty of our integrated matching approach. The blue shapes in Fig. 3 represent new models and features our work has introduced and addressed, while the orange shapes represent an overlap between our work and existing work. The rest of our paper is organized as follows: Sect. 2 introduces the tenant models that aid tenant matching. Section 3 introduces the running example that we will be using to illustrate our approach. Our UTC model and matching algorithm are introduced and described in Sect. 4. In Sect. 5 we present a detailed illustration of our algorithm using the running example from Sect. 3. In Sect. 6 we present experimental evaluations of our matching algorithm, while Sect. 7 discusses the limitations of our approach. Sect. 8 discusses related work in the area of cloud service-provisioning. Section 9 concludes the paper with suggestions for future work.
2 Tenant models This section introduces models that are used to represent tenants and providers along with their different attributes and behaviors.
Author's personal copy SOCA (2012) 6:283–302
285
Fig. 2 Functioning of the User interface-Tenant selector-Customizer system
Fig. 3 Comparison of components of our solution with solutions that have been proposed in the area of cloud service-provisioning
2.1 Tenant requirements model (TRM) A Tenant Requirements Model (TRM) constitutes behavior, constraints and state information of a tenant. Tenant behavior, also referred to as tenant functionality, is used to represent
a tenant’s functional requirements and contains inputs and outputs. An example of a tenant behavior is {check account balance—IN: account number, OUT: balance} that fetches and displays an account holder’s balance with account number as the input and balance as the output.
123
Author's personal copy 286
SOCA (2012) 6:283–302
Fig. 5 Tenant-state information for a single tenant Fig. 4 Representation of tenant requirements and provider models
Tenant constraints help specify a tenant’s conditions. An example of a tenant constraint is “other tenants’ type = Banking”, where the tenant requires that it be hosted alongside banking tenants only. A tenant’s state indicates whether a tenant is active or paused at a certain point of time. More details on tenantstate information can be found in Sect. 2.3. 2.2 Tenant provider model (TPM) A Tenant Provider Model (TPM) contains tenant-active constraints and state information for all existing tenants hosted by the provider. Tenant-active constraints are those that indicate periods during which a tenant is active. An example of a tenant-active constraint is “tenant-active ≥ 06:00”, which states that a tenant would be active or available to its users only after 6AM. Figure 4 contains a representation of a TPM and a TRM. State information of tenants can be derived from their tenant-active constraints. The TPM handles dynamic resource allocation across different tenants by maintaining their state information. Resource allocation has been explained in more detail in Sect. 4.3. 2.3 Tenant-state information Tenant-state information identifies the state a tenant could be in at any point during its hosted period in a multi-tenant system. A tenant could be in one of these states: created, active or paused. Figure 5 shows the states in which a tenant can persist and the corresponding inter-state transitions. Initially, a tenant is in the created state. A tenant’s tenant-active constraint is compared with the current time to identify its present state. For example, the tenant-active constraint “tenant-active > 06:00 and tenant-active < 18:00”, implies that a tenant would be active from 6AM to 6PM only and during any other hour the tenant would be in the paused state.
123
A tenant’s state information is useful during resource allocation (explained in Sect. 4.3). If it is found to be active, it is allocated resources and then set in the active state. If the tenant is found to be inactive at a certain point, that is, its tenant-active constraints return a false for the current time, its resources are reclaimed and it is set to the paused state. 2.4 Tenant factors value Tenant factors include non-functional aspects of a tenant such as time to deploy, cost of deployment, resource requirement, past performance, extensibility and number of features. Tenant factors value of a tenant represents the combined effect of each of the above-mentioned factors. It provides a measure of a tenant’s efficiency and helps rank the set of provisioned tenants prior to their selection during the matching process. It can be represented using the function in Eq. 1. tenant factors value = f(t, c, r, p, e, n)
(1)
In our approach, these tenant factors are treated as nominal attributes. A tenant factor is rated on a scale of 1 to 5, where 1 is the least and 5 the highest value for that factor. For instance, in the case of a factor such as time to deploy, a 1 indicates that only a small time period would be required to deploy that tenant, whereas a 5 indicates that a lot of time would be required to deploy the tenant. The values of other factors are interpreted similarly. These values are different for different provisioned tenants and are determined by the provider depending on the tenant’s functioning in the past. Explaining how each tenant factor is calculated is beyond the scope of this paper. One of the ways in which the tenant factors value of a tenant can be calculated is shown in Eq. 2. This is a simple formula calculating the difference between the factors that are positively and negatively correlated with a tenant’s value. Factors such as performance ( p) and extensibility (e) are considered positive because they are indicative of a tenant’s quality. A tenant factor such as cost (c) is considered to be negative because an increase in its value implies that the
Author's personal copy SOCA (2012) 6:283–302
287
provider would have to spend more while provisioning the tenant. Similar is the case for factors such as time to deploy (t) and resource requirements (r ). In the case of number of features (n) a larger n for a tenant would mean more functionalities to be matched with, thus implying an increase in matching time for the service provider. According to this formula the higher the tenant factors value, the higher its chance of getting selected for an iteration of the tenant selector algorithm. tenant factors value = (p + e) – (t + c + r + n)
2. Withdraw Cash (T2 ) – Tenant factors—{t = 1, c = 2, p = 5, e = 4, r = 4, n = 5} ⇒ tenant factors value = −3 – Platform—Operating systems {Red Hat Linux}, Framework {J2EE} – Infrastructure—Database {MySQL}, Memory {5 GB}, Storage {2,500 GB} – Software 2.1 Verify account {userInfo, request}, {verificationInfo} 2.2 Check balance {userInfo, request}, {balanceInfo} 2.3 Dispense cash {userInfo, amount}, {cash} 2.4 Change balance {userInfo, amount}, {userInfo, changedBalance} 2.5 Log details. {userInfo, request},{userInfo}
(2)
It is to be noted that we have chosen a simplified formula as described in Eq. 2. More complicated formulae such as those described in [6] can also be considered; however, selecting the appropriate formula for calculating tenant factors values is a domain-specific decision to be made by the user and is outside the scope of this paper. 3 Running example For our running example we consider tenants from the banking domain with software, platform and infrastructural specifications. Software specifications pertain to the functional requirements of tenants, which are expressed in terms of their inputs and outputs. For example, “Tenant functionality’s name {Inputs} {Outputs}” is the format of a tenant functionality. Platform specifications include features such as operating systems and software framework and their values, and infrastructural specifications include features such as database type, memory, storage and their corresponding values. Tenant factors such as time to deploy, cost to deploy, past performance, extensibility and resource requirement are assigned values on a scale of 1 to 5 (as specified in Sect. 2.4) and the tenant factors value is calculated using Eq. 2. The following are tenants currently provisioned by the service provider.
3. Insurance claim (T3 ) – Tenant factors—{t = 1, c = 1, p = 5, e = 4, r = 5, n = 7} ⇒ tenant factors value = −5 – Platform—Operating systems {Red Hat Linux}, Framework {.Net Framework 2.0} – Infrastructure—Database {Oracle}, Memory {15 GB}, Storage {1,275 GB} – Software 3.1 Determine liability {userInfo, request}, {Information} 3.2 Potential Fraud Check {userInfo}, {Details} 3.3 Final Review {userInfo}, {Details} 3.4 Analyze and estimate loss {reviewDetails}, {analysisDetails} 3.5 Generate claim report {analysisDetails}, {reportInfo} 3.6 Receive payment {userInfo, paymentAmount}, {userInfo, successMessage} 3.7 Log details {userInfo, request}, {userInfo}
1. Generate Bank Statement (T1 ) – Tenant factors—{time to deploy (t) = 2, cost to deploy (c) = 2, past performance (p) = 5, extensibility (e) = 4, resource requirement (r) = 3, number of features (n) = 4} ⇒ tenant factors value = −2 – Platform—Operating System {Windows XP}, Framework {.Net Framework 1.1} – Infrastructure—Database {MySQL}, Memory {10GB}, Storage {1,000 GB} – Software 1.1 Verify account {userInfo,request}, {verificationInfo} 1.2 Get complete transaction details {userInfo}, {transact-Details} 1.3 Generate report {Details}, {reportInfo} 1.4 Log details {userInfo, request}, {userInfo}
Following are the functional requirements of a client. We assume that the client has not specified his non-functional requirements and expects the provider to help him with the same. Request traveler’s checks 4.1 4.2 4.3 4.4
Verify account {userInfo, request}, {verificationInfo} Check balance {userInfo, request}, {balanceInfo} Dispense checks {userInfo, amount}, {paymentMode} Change account balance {userInfo, amount}, {userInfo, changedBalance}
123
Author's personal copy 288
4.5 Receive payment {userInfo, paymentAmount}, {userInfo, successMessage} 4.6 Log details {userInfo, request}, {userInfo}.
4 Approach Before we present our approach, we first prove the NP completeness of the tenant selector problem (the proof of this theorem is provided in the “Appendix”). Theorem 1 The tenant selector problem, which aims to identify a combination of existing tenant functionalities from the same or different tenants that best match a client’s requirements, is NP-complete. 4.1 Tenant selector heuristic The NP completeness of the tenant selector algorithm has prompted us to develop a heuristic for the same. Our algorithm makes use of the knowledge of relationships among existing tenant functionalities (Sect. 4.1.2) while calculating the degree of match between client requirements and tenant functionalities (Sect. 4.1.1) and assigning client requirements suitable matches. This involves several iterations and each iteration involves comparison of the client’s requirements with a selected tenant’s functionalities. The algorithm terminates when (1) a match is found for every client requirement or (2) all of the existing tenant functionalities have been exhausted in search of suitable matches. A detailed, formal description of this algorithm has been provided in the “Appendix” of this paper. 4.1.1 Degree of match When the degree of match [4,21,25] between a client requirement and a tenant functionality is to be calculated, their inputs and outputs are compared to identify the best match for each input and output parameters of a client requirement. Degree of match can be one of exact match, instance of (plug-in), subsumption or disjoint and is determined in a way similar to that used by description logics to address such problems [14]. Matches are ordered according to their degree of similarity, that is, exact match > plug-in > subsume > disjoint. The best match between a client requirement and a tenant functionality is determined by taking a minimum of their input and output matches. For instance, if match between inputs was exact, whereas their outputs had a disjoint match, then the client requirement and tenant functionality would be a disjoint match (i.e., minimum{exact, disjoint}). We do this to ensure the use of a rigorous matching process.
123
SOCA (2012) 6:283–302
– Exact: A client requirement and tenant functionality have an exact match only if both have the same set of inputs and outputs. This match is represented by a numerical value of 3. – Plug-in: A plug-in match is one where inputs and/or outputs of a client requirement form a supertype of the inputs and/or outputs of a tenant functionality, respectively, that is, a tenant functionality’s input and/or output parameters can be plugged-in for a client requirement’s inputs and/or outputs respectively [4]. In our running example (Sect. 3), payment Mode of client requirement Dispense checks is a supertype of cash in tenant Withdraw Cash’s functionality Dispense cash. payment Mode can be one of {cash, checks, car d} and cash can be plugged-in for payment Mode. This match is represented by a numerical value of 2. – Subsume: In case of a subsume match, a tenant functionality’s inputs and/or outputs form a supertype of a client requirement’s inputs and/or outputs [4]. This match is represented by a numerical value of 1. – Disjoint: When a client requirement and a tenant functionality’s inputs and outputs do not have any kind of a relation, the pair is said to have a disjoint match. This match is represented by as numerical value of 0. 4.1.2 Identifying relationships between existing tenant configurations Relationships between existing tenants are maintained to help reduce running time of the matching algorithm by eliminating tenant configurations that appear to be redundant. We use (1) the existing tenant relationships information along with (2) the assignments made in an iteration of the tenant selector and (3) the concept of transitivity to surmise the degree of match between unmatched client requirements and existing functionalities. For example, consider that all functionalities of tenant t1 have a disjoint match with a client’s requirements (after an iteration of the matching algorithm), and some functionalities of tenants t2 and t3 have an exact match with those of t1 . In such a case we eliminate functionalities of t2 and t3 that have an exact match with functionalities of t1 , since the features of t2 and t3 that have an exact match with functionalities of t1 are likely to be disjoint with the client’s requirements (transitive relation). Similar techniques are applied to identify and eliminate redundant functionalities. Although the task of determining relationships between every pair of existing tenant functionality appears to be time intensive, it needs to be performed only once and can be stored and referred to when needed. As we will show later in the Evaluation (Sect. 6), this step helps eliminate redundant tenant functionalities and significantly improves the speed of our matching algorithm.
Author's personal copy SOCA (2012) 6:283–302
289
Fig. 6 Overview of the tenant selector algorithm
Degree of match between two existing tenant functionalities is calculated in a way similar to that used to calculate the degree of match between a client requirement and an existing functionality. Our approach assumes the existence of appropriate domain ontologies by which tenant functionalities can be formally modeled and evaluated [19]. Hence we do not delve into this any further, since this is outside our paper’s scope.
from future iterations. With the information on tenant functionality assignments that were made in this iteration and relationships between existing set of tenants (as described in Sect. 4.1.2), tenant functionalities that are likely to be redundant in future iterations are also eliminated. This algorithm terminates either when a match is found for every client requirement or when all existing tenants have been exhausted while searching for matches. 4.2 Customizer model and algorithm
4.1.3 Tenant selector algorithm This algorithm, depicted pictorially in Fig. 6 (a formal description is presented in Algorithms 1–3 in the “Appendix”), begins with the selection of an existing tenant, which has the highest tenant factors value as determined by Eq. 2 in Sect. 2.4. The selection process ensures that only the most efficient tenant in terms of factors such as time to deploy, cost of deployment, past performance, extensibility and resource requirements is selected for an iteration of the matching algorithm. For each iteration of this algorithm, degree of match (as described in Sect. 4.1.1) between the selected tenant’s functionalities and each of the client’s requirements is determined. Assignments are made for each client requirement with the tenant functionality that has produced the best match so far. Client requirements with exact matches are removed
A formal description of this algorithm is presented in Algorithms 4–6 in the “Appendix”. When a client requirement remains unmatched or has only a plug-in or subsume match with a tenant functionality, the customizer tries to look for a combination of tenant functionalities, which when taken together satisfies the client’s requirement with an exact match. Customization can be achieved by taking a conjunction of functionalities from across the same or different tenant(s). Consider that a match between a tenant functionality and a client’s requirement CR is not exact. Figure 7 displays the steps taken by the customizer to look for a set of tenants CZ that satisfies CR with an exact match. The order in which the customizer looks for a matching set of tenant functionalities is by beginning with the client requirement’s outputs and then progressing to its inputs. The algorithm
123
Author's personal copy 290
SOCA (2012) 6:283–302
Fig. 7 Overview of the customizer algorithm
Fig. 8 Overview of the dynamic resource allocator algorithm
looks for a tenant functionality TF such that TF’s output matches exactly with that of CR. If an exact match between their inputs is found, TF is added to the set CZ and the algorithm exits. If no match is found, TF is added to CZ and the algorithm looks for a TF whose output matches TF’s input. If found, TF is set as TF and the process continues till a TF whose input matches that of CR is found. After the completion of the algorithm set CZ will contain the tenant functionalities, which are combined to customize the client’s requirement, provided such a set of functionalities exist. CZ will be empty at the end of the algorithm if no such set exists.
123
4.3 Dynamic resource allocation using TRM and TPM The formal description of this algorithm is presented in Algorithms 7 and 8 in the “Appendix”. Resources refers to the computational resources required by the tenants and not the storage requirements and therefore can be allocated or de-allocated without the fear of losing any stored data. The TPM maintains a tenant’s tenant-active constraints, which helps it handle dynamic allocation of resources across active and paused tenants. TPM implements dynamic resource allocation by running the algorithm as an asynchronous process in the background. The dynamic resource
Author's personal copy SOCA (2012) 6:283–302
291
Fig. 9 Relationship information between platform and infrastructure features of all existing tenants
allocator makes the allocation of paused tenants’ resources to an active one. Figure 8 displays an overview of the working of the dynamic resource allocator. The dynamic resource allocation algorithm begins with the search for a tenant T , which has currently become active (due to it being selected by our matching algorithm) and is looking for resources. The algorithm then looks for a set of paused tenants TP whose active constraints do not intersect with those of tenant T and whose resource requirements sum up to be either equal to or greater than the resource requirement of T . If such a set of tenants TP is found, their resources are allocated to T . If no such TP is found, fresh resource allocations for T must be made by the provider. Please note that the resource requirements of a tenant is a upper-bound on the amount of resources it may need for computation and we are not suggesting that this value is constant. Also, our approach does not make exclusive resource allocations to a single tenant, but instead makes available to a tenant the amount of resources that it might need for computation from a pool of resources available at the time (depending on other paused or active tenants’ resources).
4.4 Matching platform and infrastructure requirements Although our system allows the client to state explicitly their functional and non-functional requirements, there are times when a client is unable to provide such information. We therefore propose a technique that helps create platform and infrastructural assignments for a new tenant, when the client is unable to provide said information. Figure 9 shows a taxonomy of platform and infrastructure features and their corresponding values for tenants T1 , T2 and T3 from the section on Running Example (Sect. 3). Since functionalities that match a client’s requirements can come from multiple existing tenants with different
specifications, platform and infrastructural matching for a new tenant can be determined by combining values for features such as operating systems, software frameworks, memory requirement from across all matched tenants. Combining can be defined as the process of identifying the largest representative of a platform or infrastructural feature based on the values (for these features) from the matched set of existing tenants. Different platform and infrastructural features have different types of values and hence the way in which they are combined would be different. For instance, operating systems feature has a version associated with it, whereas memory requirement has a numerical value.
– For features with numeric values, a max of values from across matched tenants could be taken as a suitable representative. For example (from Fig. 9), if two of the client’s requirements match with functionalities from tenants T1 and T3 , then their memory requirement would be max(10 GB, 15 GB) = 15 GB. – For features such as operating systems or software frameworks, with non-numeric values, relationships can be established across their different versions or upgrades. A latest version of the operating system or framework that is backward compatible (i.e., which also works with older versions) is selected. Consider that two of the client’s requirements match with functionalities from tenants T1 and T3 and that a suitable framework is to be selected .Net framework 2.0, which is a newer (and backward compatible) version when compared to .Net framework 1.0 is selected for the client. Please note that the values listed for memory and storage requirements in this example are intended to be upperbounds for these requirements and we are not suggesting that a tenant’s memory and storage requirements are constant values.
123
Author's personal copy 292
SOCA (2012) 6:283–302
Table 1 Relations between existing set of tenants
T1 Generate Bank Statement T2 Withdraw Cash
T3 Insurence Claim
1.1 1.2 1.3 1.4
2.1 2.2 2.3 2.4 2.5
3.1 3.2 3.3 3.4 3.5 3.6 3.7
3
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
2
0
0
0
0
0
3
0
0
0
0
0
0
3
1
0
0
0
0
0
0
2.2
0
0
0
0
0
0
0
2.3
0
0
0
0
0
0
0
0
0
0
0
0
0
3
T1 Generate 1.1 – Bank 1.2 Statement 1.3 1.4
0
T2 Withdraw Cash
2.1 Same as [T1 , T2 ]
–
T3 Insurance Claim
3.1 Same as [T1 , T3 ]
2.4 Same as [T2 , T3 ]
–
3.2 3.3 3.4 3.5 3.6
4.5 Complexity of algorithms Complexity of the tenant selector algorithm (Tenant Selector (matching) Algorithm in the “Appendix”) calculated with the inclusion of several tasks such as searching and matching inputs and outputs is roughly O(n 7 ). However, the most time-consuming tasks of this algorithm are as follows: calculating relationships between existing tenants and their functionalities (GenRelBetExistTen Algorithm in the “Appendix”), and iterating through the existing set of tenants and functionalities to determine matching (CalculateDegreeOfMatch Algorithm in the “Appendix”), which have a running time of O(n 4 ). Thus, complexity of the tenant selector algorithm in terms of its most timeconsuming tasks is O(n 4 ). It is also important to note that determining relations between existing set of tenants is a one-time activity only, and this information helps decrease search time as has been illustrated in the Evaluation section (Sect. 6). The running time of the customizer algorithm is also O(n 4 ), where first the output of the client requirement that needs customization is compared with the output of every existing tenant’s functionality (Customizer Algorithm in the “Appendix”) followed by a set of input–output matches (InputOutputMatch Algorithm) with every existing tenant’s functionalities. Finally, the dynamic resource allocation algorithm involves the identification of an active tenant and a corresponding set of paused tenants, whose resources when taken together satisfies the active tenant’s resource requirements. Running time of the dynamic resource allocation algorithm
123
is O(n 2 ) (DynamicAllocationOfResources Algorithm). 5 Illustration using running example We now illustrate our matching algorithm on our running example introduced in Sect. 3. Table 1 displays the relation between the functionalities of existing set of tenants—Generate Bank Statement (T1 ), Withdraw Cash (T2 ) and Insurance Claim (T3 ). Each tenant’s functionalities is compared with tenant functionalities from each of the other existing tenants. Each cell in the matrix contains a matrix displaying the degree of match between functionalities of the compared tenants. The inner matrix contains functionalities represented along the rows and columns, while the outer matrix has tenants represented along their rows and columns. The numbers represent degree of match values between tenant functionalities as specified in Sect. 4.1.1. 5.1 Tenant selection and matching This section describes the different iterations of the tenant selector matching algorithm. 5.1.1 Iteration 1 with T1 —Generate Bank Statement In the first iteration T1 is selected for comparison with the client’s requirements. T1 ’s tenant factors value is specified in Sect. 3 as −2 and is the highest when compared to those of tenants T2 and T3 (−3 and −5 respectively). Matching is performed between client’s requirements and T1 ’s function-
Author's personal copy SOCA (2012) 6:283–302
293
Table 2 Matches between client requirements and functionalities of the Generate Bank Statement tenant
Table 3 Matches between remaining client requirements and functionalities of Withdraw Cash tenant
T1 Generate Bank Statement
Client-Request Traveler’s Checks
T2 Withdraw Cash
1.1
1.2
1.3
1.4
4.1
3
0
0
0
4.2
0
0
0
0
4.3
0
0
0
0
4.4
0
0
0
0
4.5
0
0
0
0
4.6
0
0
0
3
Client-Request Traveler’s Checks
2.2
2.3
2.4
4.2
3
0
0
4.3
0
2
0
4.4
0
0
3
4.5
0
0
0
Table 4 Matches between remaining client requirements and functionalities of Insurance claim tenant T3 Insurence Claim
alities and result is shown in Table 2. The italicized values indicate matches found for client requirements with tenant functionalities. The new client’s requirements are listed along the rows while T1 ’s functionalities are listed along the columns. Requirements 4.1 and 4.6 are assigned functionalities 1.1 and 1.4, respectively, from T1 , since there exists an exact match between them. In Table 1 we see that tenant functionality 2.1 has an exact match with 1.1 and functionalities 2.5 and 3.7 have an exact match with 1.4. Since 1.1 and 1.4 have disjoint matches with the other (unassigned) client requirements (4.2 to 4.5), therefore tenant functionalities 2.1, 2.5 and 3.7 are also likely to have disjoint matches with the unassigned client requirements (by transitivity). Hence functionalities 2.1, 2.5 and 3.7 can be eliminated from future iterations. Similarly, functionality 3.5 of T3 has a plug-in match with functionality 1.3 from T1 (Table 1). Since 1.3 has a disjoint match with the other (unassigned) client requirements (Table 2) and a plug-in match is very near to an exact match, 3.5 is also likely to be disjoint with the client requirements. Therefore, we eliminate functionality 3.5 to avoid redundant matching. 5.1.2 Iteration 2 with T2 —Withdraw Cash T2 is selected to perform the second iteration of the algorithm (tenant factors value −3 > −5 for T3 from example in Sect. 3). The result of this iteration is shown in Table 3. Note that the table contains only the unassigned client requirements and T2 ’s functionalities that have not been eliminated in the previous iteration. Client requirements 4.2 and 4.4 have an exact match with functionalities 2.2 and 2.4, respectively, and assignments are made. Requirement 4.3 has a plug-in match with 2.3 (since payment Mode in the client requirement 4.3 is a supertype of cash in tenant functionality 2.3). None of the tenant functionalities are eliminated as none of the assigned functionalities have an exact match with functionalities from other tenants, and neither do the unassigned functionalities.
3.1 Client-Request Traveler’s Checks
3.2
3.3
3.4
3.6
4.3
0
0
0
0
0
4.5
0
0
0
0
3
5.1.3 Iteration 3 with T3 —Insurance Claim Iteration 3 is performed for client requirements 4.3 and 4.5. Although 4.3 has a plug-in match with functionality 2.3, it is retained in iteration 3 to check whether there exists a tenant functionality with which it has a better (exact) match. The result of iteration 3 is shown in Table 4. Table 4 contains the unassigned client requirements along the rows and T3 ’s functionalities that have not been eliminated in earlier iterations along the columns. 4.5 is matched to tenant functionality 3.6. However, no exact match is found for requirement 4.3. 5.2 Customizing using an alternate tenant, if any Customizer tries to identify a combination of tenant functionalities that can satisfy client requirement 4.3 (Dispense checks) with a match that is better than plug-in. Let us assume that the provider supported a fourth tenant that allows—Cash withdrawal and conversion of cash into another payment mode (e.g. checks) with the following functionalities: 5.1 Check balance {userInfo, request}, {balanceInformation} 5.2 Dispense cash {userInfo, amount}, {cash} 5.3 Cash conversion {cash}, {paymentMode} Functionalities 5.2 and 5.3 of the above tenant can be combined to satisfy 4.3 with an exact match. Requirement 4.3’s inputs and outputs are {userInfo, amount} and {paymentMode}, respectively. Tenant functionality 5.2’s output matches 5.3’s input. Therefore, the two functionalities when combined together form a chain {userInfo, amount} →
123
Author's personal copy 294
{cash} → {paymentMode}, where the output of Dispense cash feeds into the input of functionality Cash conversion and together they satisfy (with an exact match) the client requirement Dispense checks. 5.3 Platform and infrastructure matching Let us assume that the client has only provided information on its functional requirements but not its platform or infrastructural requirements. This section illustrates how platform and infrastructural assignments are made after matching software functionalities. From the above three iterations we find that the client’s functional requirements are matched with functionalities from tenants T1 , T2 and T3 . In order to identify the platform and infrastructural specifications for the client we identify the representative of each platform and infrastructure feature. This can be identified from tenant feature values in Fig. 9. – Operating systems—{Windows XP, Red Hat Linux}— Both operating systems are selected since no version-type relationship can be established between them and different client requirements might have different operating systems requirements. – Framework—{J2EE, .Net Framework 2.0}—Off the two versions .Net Framework 2.0 and .Net Framework 1.0 for tenants T1 and T3 , .Net Framework 2.0 is selected, since it is backward compatible. J2EE is selected to satisfy the client requirement that matches T2 ’s functionalities. – Database—{ MySQL, Oracle}—MySQL is selected to satisfy client requirements that match with T1 and T2 ’s functionalities and Oracle is selected to satisfy requirements that match T3 ’s functionalities. – Memory—{15 GB}—Taking max of the numeric memory values for tenants T1 , T2 and T3 . – Storage—{2,500 GB}—Similar to the previous case.
6 Evaluation We constructed a prototype, using IBM’s Rational Software Architect, which implements our matching algorithm.2 We conducted experiments on our prototype by simulating a set of realistic tenants in the banking domain.3 A client seeking a tenant to request for traveler’s checks is selected to perform the matching with an existing set of tenants. The number of existing tenants compared with for each 2 A demo video of the prototype’s functioning is accessible via http:// www4.ncsu.edu/~lramach/Prototype/Prototype.html. 3 In http://www4.ncsu.edu/~lramach/XMLfilesWeb.html we list the provisioned tenants (specified using SAWSDL [24]), client requirements and a view of a banking ontology that was used for our experiments.
123
SOCA (2012) 6:283–302
run of the prototype is increased from 1 (containing four functionalities) to 20 (containing 98 functionalities). For a banking application, there are only so many functionalities that can be taken into consideration. Hence, for purposes of illustration, only 20 tenants with as many as 98 functionalities were considered for this study. The client’s requirements are matched with functionalities from across all existing tenants. We strongly believe that the results from our study can be extended to applications with a larger number of tenants and that this approach would prove quite useful in other domains with a larger number of functionalities. Our experiments demonstrate the following: D1 Given relationships between tenants, the system would end up searching a consistently smaller set of tenant functionalities during the matching phase. D2 A reduction in the number of redundant tenant functionalities would result in a significant reduction in the running time of the matching algorithm. D3 Elimination of redundant tenant functionalities does not affect the number of exact, plug-in or subsume matches found. 6.1 Decrease in number of tenant functionalities chosen for matching The chart in Fig. 10 shows the number of tenant functionalities the client’s requirements are compared with for each run of the algorithm. Fewer tenant functionalities are matched with when redundant ones are eliminated (blue line) than when none of the functionalities were eliminated (red line). Redundant functionalities can be eliminated from comparison with the help of relationship information between existing tenants. Figure 11 depicts the number of tenant functionalities that were considered for matching with the client’s requirements from each of the existing tenants. Each point along the xaxis represents a single tenant. For each tenant on the x-axis, the first bar shows the number of functionalities that were selected for comparison when redundant functionalities were not eliminated and the second bar shows the number matched with when redundant functionalities were eliminated. Fewer number of functionalities were selected from every tenant when redundant functionalities were eliminated. Therefore, the results in Figs. 10 and 11 demonstrate claim D1. 6.2 Decrease in running time of the matching process Our experiments compare the time taken by the matching algorithm for each run of the algorithm with differing numbers of existing tenants. The x-axis lists the different runs of the algorithm and the y-axis represents the time taken to complete the matching process. We compare the
Author's personal copy SOCA (2012) 6:283–302
295
Fig. 10 Difference in the number of tenant functionalities a client’s requirements would have to be compared with when redundant tenant functionalities were (blue line) or were not (red line) eliminated. The X -axis represents the different runs of the tenant selector algorithm with differing number of existing tenants (color figure online)
Fig. 11 Number of tenant functionalities selected (from each of the tenants listed along the X -axis) for matching with the client’s requirements. The first bar represents the number of functionalities selected
for matching when redundant tenant features were not eliminated and the second bar represents the number matched with when
time taken when redundant tenant functionalities were not eliminated with the time taken when they were eliminated. Figure 12 shows that the time taken by the matching algorithm when redundant tenant functionalities are eliminated is up to 59 % lower than the time taken when the redundant tenant functionalities were not eliminated. Figure 12 also shows that the running time of the algorithm without redundant tenant functionalities grows much more slowly than the running time with redundant tenant functionalities. Chart in Fig. 13 shows the time spent in matching the client’s requirements with each of the 20 different existing tenants’ functionalities. We notice significant differences in the time taken for matching when redundant tenant functionalities were/not eliminated. The calculated time includes the time taken for matching along with other postprocessing steps, which includes the time taken to eliminate redundant functionalities. Thus, in spite of the pre- or
post-processing steps the amount of time taken to carry out matching when redundant functionalities are eliminated appears to be lesser than the time taken for matching without elimination. Charts in Figs. 12 and 13 show that the identification of relationships between existing tenant functionalities and the subsequent elimination of redundant functionalities results in a decrease in matching time. This demonstrates claim D2. 6.3 Eliminating redundant tenant functionalities does not affect overall degree of match The chart in Fig. 14 depicts the number of matches found for the client’s requirements. The chart shows that elimination of redundant functionalities does not affect the number of matches found for the client’s requirements and that the number of matches found with elimination is just as good as
123
Author's personal copy 296
SOCA (2012) 6:283–302
Fig. 12 Performance of the tenant selector matching algorithm for the different runs of the algorithm with and without redundant tenant functionalities
Fig. 13 Time taken to match client requirements with functionalities of tenants (listed along the X -axis) with and without redundant functionalities
the number found when matching is done without elimination. This demonstrates claim D3. 6.4 Time taken to calculate relations between existing tenant functionalities The chart in Fig. 15 depicts the time taken to calculate relationships between existing tenants. X -axis of the chart represents each run of the prototype (with differing numbers of existing tenants), while the Y -axis represents the amount of time taken to perform matching in milliseconds. The chart shows that when there is only one existing tenant (first run of the algorithm) the time taken is 0 ms. Time taken by our algorithm to identify relations between existing set of tenants increases steeply with an increase in the number of tenants. However, this is a one-time activity only and it helps eliminate redundant functionalities.
123
Therefore, we see that the identification of relations between existing tenants, although an intensive one-time activity, results in a significant reduction in the number of tenant functionalities that a client’s requirements are matched with, and hence a reduction in the run time of the algorithm.
7 Limitations One of the limitations of our evaluation is the limited number of tenants and tenant functionalities chosen for the evaluation. However, our motivation for the evaluation was twofold. First, we wanted to select tenants and functionalities in a single domain, viz., banking. Second, we selected tenants so that they had some overlap in terms of their tenant functionalities, which would mimic the real world. Since there are only a certain number of unique functionalities in
Author's personal copy SOCA (2012) 6:283–302
297
Fig. 14 Number of exact, plug-in or subsume matches found when matching was done with and without redundant tenant functionalities
Fig. 15 Time taken to calculate relations between existing tenants’ functionalities
every domain, it is difficult to synthesize a large number of different tenants for our experiments. Hence we limited ourselves to 20 tenants. However, it is to be noted that these 20 tenants did provide a total of 98 different functionalities, which we believe to be of reasonable size. We acknowledge the fact that this might not be a good replication of cases in the real world that use thousands of tenants, but we plan to address this in our future work. We plan on testing the system with a larger number of tenant functionalities from across different domains and study its performance. During the identification of platform and infrastructural requirements for a new client, the provider uses the maximum of the values from tenants that have provided functionality for the new client. Since the new client is unaware of the memory or storage requirements, we make a best-guess assignment, but what works for the existing tenants may not always work for the new client. This is one of the limitations of the system. We must therefore incorporate some kind of a learning mechanism with the help of which the system can automatically learn and adjust the new client’s memory and storage requirements based on its usage.
Another limitation of our system is that it does not factor in the number of users the new client is likely to have. This is because the client may not be aware of the number of users of the system at the time of tenant creation. However, we do plan on including this as a feature in our system in the future. 8 Related work In this section we expand on Fig. 3 and discuss the literature in the area of cloud-service provisioning that helped us identify the lack of a suitable dynamic tenant-provisioning model, as well as some others that provided motivation for our approach. Tenant Model Variability: Mietzner et al. [20] discuss development of a variability model (internal and external) to guide the customization process. All new requirements appear to be treated as variation points by their technique. Our technique, however, tries to identify a tenant that is closest to the current requirements and only the similarities between the closest tenant and the new requirements are considered.
123
Author's personal copy 298
Their work does not introduce a common tenant structure, and neither does their technique model the differing client and provider perspectives. Our technique, however, defines the tenant requirements and provider models and introduces the concept of tenant-context or tenant-state. The technique in [20] also does not model tenant-state information. Sam et al. [23] suggest a new structure for web services that includes structural and constraint subsystems. The structural subsystem includes context and input/output information. Unlike our technique where the context refers to state information, context in [23] refers to a service functionality. Their work also does not include non-functional service requirements such as availability, resource requirements, security requirements, etc. Since their constraint subsystem is based on the inputs and outputs in the structural subsystem, their technique cannot handle non-functional constraints, which our system can. According to [23], the customization step primarily involves handling type conflicts that might occur between the input/output types across services having similar contexts. Our customization technique, on the other hand, involves identifying a combination of tenant functionalities that satisfy a client’s requirement. Groher et al. [13] have proposed a product-line variability model using the concept of model-driven software development and aspect-oriented development. They propose a tool that handles new requirements by implementing positive and negative variations (adding or deleting features/modules) and customizing product line software. However, their method does not propose a common tenant structure to handle interactions between tenants. Tenant Provider Model: Arnold et al. [3] present an extendable model-driven development technique to identify SOA deployment patterns. However, the technique does not elaborate on how units are selected to be added to the topology (during automatic pattern realization). The technique only models the deployer’s (provider) perspectives but not the client’s perspectives. Their technique also does not model state information of deployed services so as to be able to handle dynamic re-allocation of resources. Konstantinou et al. [16] propose a simplified technique of composing and deploying distributed virtual software services. The technique is based on the deployer’s (provider) perspective (as in [3]), with configurations handling primarily non-functional and deployment-related information. Matching functional and non-functional requirements: Our matching algorithm is inspired by the original matching algorithm presented in [21] and subsequently enhanced in [4,5]. The original idea from [21] defined the three degrees of match that we have used in our paper: exact, plug-in, subsume and fail (no match). That algorithm gives more importance to the outputs, driven by the reasoning that requesters
123
SOCA (2012) 6:283–302
are more interested in providers that produce an exact match in the outputs than those that have an exact match in the inputs. The enhancement from [4] proposed an algorithm that tries to identify a maximum degree of match between a query (input/output) and an advertisement. The minimum of all the degrees of match would represent the overall degree of match between the advertisement and the query. A further enhancement in [5] extended [4] based on the inputs and outputs of web services to include preconditions and effects. Our matching algorithm therefore utilizes and enhances the matching techniques from [4,5,21]. Shvaiko and Euzenat [25] define a matching element as a 5-tuple, which includes a unique identifier, two entities that are to be matched, confidence measure of this matching and the type of relationship of the matching. They define three matching dimensions: inputs, outputs and characteristics of the matching process (which can either be approximate or be exact). They present a survey of matching techniques, such as string-based, constraint-based, linguistic, graph-based and taxonomy-based. Our matching algorithm is primarily taxonomy-based, since we assume the existence of an initial ontology of terms. Research works on grid service composition [8,11,12,22, 28–30] have extended Web service matching algorithms such as those described earlier and applied them to grid-computing environments. However, our approach is more comprehensive, since it encompasses all layers of the cloud-computing stack, and also considers functional and non-functional requirements together.
9 Conclusions and future work In this paper we have investigated the crucial issue of dynamic, service-tenant provisioning in cloud-based systems, and we have presented an integrated algorithm for matching tenant functionalities with a client’s requirements. Our algorithm contains several key features specifically suited to cloud-based systems, viz., integrated functional and non-functional requirement matching at SaaS, PaaS and IaaS levels; dynamic resource allocation using state information; and elimination of redundant tenant functionalities in order to prune the search space. In particular, we have shown that redundant functionality elimination renders a significantly faster matching algorithm, thereby making it usable in practice. We have also demonstrated the performance of our algorithm on an example in the banking domain using a prototype built on IBM’s Rational Software Architect tool. Future work would involve enhancing our algorithm, with emphasis on more efficient dynamic resource allocation as in [2,27] (i.e., only allocating the resources needed by the tenant rather than an upper bound as in our paper currently), and testing it on larger case studies and real-life cloud-based
Author's personal copy SOCA (2012) 6:283–302
299
systems, from across several domains. We will also investigate enhancing our algorithm by incorporating formal verification approaches as described in [10].
Appendix Proof of Theorem 1 We prove NP-completeness of the tenant selector problem by drawing parallels between the objective of this problem and that of the Knapsack problem, a wellknown NP-complete problem [9]. The tenant selector problem can be described as follows: Given a set of tenants, each with a time taken to match its functionalities with the client’s requirements and a degree of match with each of the client’s requirements, does there exist a set of tenant functionalities whose time taken to complete the matching process is less than some integer C and whose net degree of match is greater than some integer D?. According to the Knapsack problem: Given a set of objects, each with a weight and a worth and integers K and W , does there exist a set of objects whose cumulative weight is less than K and net worth greater than W ?. Let B = {m f 1 , m f 2 . . . m f n } be the set of all functionalities selected for matching. Let t (m f 1 ), t (m f 2 ), . . . t (m f n ) be the time taken to match each of these functionalities with the client’s requirements and d(m f 1 ), d(m f 2 ), . . . d(m f n ) be the degree of match values of the matched functionalities. Constraints of the tenant selector problem are as follows: t (m f 1 ) + t (m f 2 ) + · · · t (m f n ) ≤ C
(A.1)
d(m f 1 ) + d(m f 2 ) + · · · d(m f n ) ≥ D
(A.2)
Let O = {o1 , o2 . . . o p } be the set of objects in the knapsack and wt (o1 ), wt (o2 ), . . . wt (o p ) be their weights and w(o1 ), w(o2 ), . . . w(o p ) be their worth. Constraints of the knapsack problem are as follows: wt (o1 ) + wt (o2 ) + · · · wt (o p ) ≤ K
(A.3)
w(o1 ) + w(o2 ) + · · · w(o p ) ≥ W
(A.4)
Constraints A.1 and A.2 of the tenant selector problem are analogous to constraints A.3 and A.4 of the knapsack problem, that is, constraints A.1 and A.3 aim at decreasing the time taken by the number of tenants that are matched with the client’s requirements and weight of objects in the knapsack, respectively, and constraints A.2 and A.4, both aim at increasing the degree of match of tenant functionalities and the net worth of objects in the knapsack, respectively. Thus, the tenant selector problem is derivable from the knapsack problem and is therefore NP-complete.
Algorithm 1 Tenant Selector(matching) Algorithm 1: Description: Algorithm for identification of a suitable matching for a new client’s requirements from an existing set of tenant functionalities. 2: Input: new client’s requirements and existing set of tenants 3: Output: matching tenant functionality for every client requirement 4: 5: newTenant - contains new client’s requirements 6: existingTenants - list of existing tenants 7: finalMatches - contains list of tenant functionalities that match each of the client’s requirements. 8: 9: //Generate relations between existing tenants 10: ExistingTenantMatrix = GenRelBetExistTen (existingTenants) 11: 12: //Identifying matches for the client’s requirements 13: i = 0 14: while i < number of existingTenants do 15: for every tenant t in existingTenants do 16: //t’s tenant factor value is calculated using the formula 17: t.tenantFactorValue = (t.pastPerformance + t.extensibility) - (t.timeToDeploy + t.costToDeploy + t.resourceRequirement + t.numberOfFeatures) 18: if t.tenantFactorValue > SelectedTenant .tenantFactorValue then 19: SelectedTenant = t 20: //SelectedTenant contains the existing tenant that has been selected for matching in an iteration. 21: end if 22: end for 23: 24: //Calculates degree of match between each of the client’s requirements and every functionality of the selected tenant 25: MatchMatrix = CalculateDegreeOfMatch (newTenant, SelectedTenant) 26: //Rows of the MatchMatrix contain the client’s requirements, while the columns contains the SelectedTenant’s functionalities, with each cell containing the degree of match value between the client’s requirement and SelectedTenant’s functionality. 27: 28: //Looking for the best match for each new requirement 29: for each client requirement R in MatchMatrix do 30: if an EXACT, PLUG-IN or SUBSUME match is found then 31: Add tenant functionality information (column of MatchMatrix), name of the SelectedTenant and degree of match to finalMatches. 32: Client requirement R and matched tenant functionality will be eliminated from future iterations 33: end if 34: end for 35: 36: Eliminate redundant tenant functionalities from other existing tenants based on assignments that were made 37: i++ 38: end while 39: //Checking if any of the client requirements with non-EXACT matches can be customized 40: for every client requirement e in finalMatches do 41: if e is empty OR e’s degree of match is PLUG-IN or SUBSUME then 42: if customizer() = null then 43: Update matches after customization is completed 44: Details of the matched functionalities are added to e 45: end if 46: end if 47: end for 48: //finalMatches contains the final list of matched tenant functionalities for each of the client requirements
123
Author's personal copy 300
SOCA (2012) 6:283–302
Algorithm 2 GenRelBetExistTen Algorithm
Algorithm 4 Customizer Algorithm
1: Description: Algorithm generates relationships between functionalities of existing tenants, for every pair of existing tenant. 2: Input: Existing set of tenants 3: Output: Matrix containing relations between existing set of tenants. 4: 5: existingTenants - contains list of existing tenants 6: relationMatrix - contains relationships between functionalities for every pair of existing tenants. 7: 8: for every tenant T1 in existingTenants do 9: for every tenant T2 in existingTenants & T1 = T2 do 10: for every feature F1 in T1 do 11: for every feature G 1 in T2 do 12: //Compare inputs and outputs of functionalities F1 and G 1 and set the minimum of the input and output matches as the degree of match between the two functionalities. 13: match1 = Compare F1 .inputs with G 1 .inputs 14: match2 = Compare F1 .outputs with G 1 .outputs 15: relationMatrix[T1 ][T2 ][F1 ][G 1 ] = min(match1, match2) 16: end for 17: end for 18: end for 19: end for 20: return relationMatrix
1: Description: Algorithm performs customization for client features that have a partial (plug-in or subsume) match or no match with tenant functionalities. 2: Input: Client feature that has only a partial or no match. 3: Output: Customized matching set of tenant functionalities that provide a better degree of match 4: 5: ClientFeature - contains client’s feature that needs to be customized 6: existingTenants - contains list of existing tenants 7: CombineMatches - contains a list of tenants, which are combined to satisfy the ClientFeature 8: 9: for every tenant T in existingTenants do 10: for every feature F in T do 11: //Checking if the client feature’s outputs matched the existing tenant feature’s outputs 12: if PerformMatching(F.outputs, ClientFeature .outputs) == TRUE then 13: Add F to CombineMatches 14: //Looking for an input to output match between tenant’s feature F and outputs of any one tenant feature’s outputs 15: if InputOutputMatch(F, CombineMatches, ClientFeature) == TRUE then 16: //CombineMatches contains the set of matches for the client’s feature 17: if CombineMatches = null then 18: return CombineMatches 19: end if 20: //Else the process is repeated for a different tenant functionality F in tenant T 21: end if 22: end if 23: end for 24: end for 25: //Cannot customize client feature 26: return null
Algorithm 3 CalculateDegreeOfMatch Algorithm 1: Description:Algorithm generates relationships between client requirements and functionalities of the selected tenant. 2: Input: newTenant - client requirements and SelectedTenant - functionalities of the selected tenant. 3: Output: Matrix containing relations between client and selected tenant. 4: 5: newTenant - contains list of client requirements 6: SelectedTenant - contains list of functionalities of the selected tenant 7: relMatrix contains relationships between the client’s requirements and functionalities of the selected tenant. 8: 9: for every feature F1 in newTenant do 10: for every feature G 1 in SelectedTenant do 11: //Compare inputs and outputs of functionalities F1 and G 1 and set the minimum of the input and output matches as the degree of match between the two functionalities. 12: match1 = Compare F1 .inputs with G 1 .inputs 13: match2 = Compare F1 .outputs with G 1 .outputs 14: relMatrix[F1 ][G 1 ] = min(match1, match2) 15: end for 16: end for 17: return relMatrix
123
Algorithm 5 PerformMatching Algorithm 1: Description: Trying to identify if inputs and outputs across two tenants have an EXACT unique match. 2: Input: Attributes pertaining to input or output parameters of tenant and client features that need to be compared 3: Output: TRUE if the they have an EXACT match else FALSE 4: 5: //Checks for attribute matches between inputs, outputs or inputs and outputs of the two features 6: if EXACT match is found between each of the inputs and outputs then 7: return TRUE 8: else 9: return FALSE 10: end if
Author's personal copy SOCA (2012) 6:283–302
301
Algorithm 6 InputOutputMatch Algorithm
Algorithm 8 lookForPaused Algorithm
1: Description: Checks if there exists a tenant functionality from among existing set of tenants whose output matches the input of a functionality 2: Input: Tenant feature (TF) looking for a functionality whose outputs match its inputs, the list of matches CombineMatches found so far and client’s feature (ClientFeature) that needs to be customized. 3: Output: Set of matches found 4: 5: existingTenants - contains list of existing tenants 6: TF - input tenant functionality looking for a functionality whose outputs match its inputs 7: ClientFeature - contains client feature that needs to be customized 8: flag - contains TRUE if the customization is complete, else FALSE 9: 10: for every tenant T in existingTenants do 11: for every feature F in T do 12: //Comparing TF’s inputs to F’s outputs 13: if PerformMatching(TF.inputs, F.outputs) == TRUE then 14: Add F to CombineMatches 15: Set F as TF to continue looking for other functionalities in the chain 16: Set TF = F 17: //Inputs of F are matched with the client requirement’s inputs to check if the chain of match is complete 18: if PerformMatching(F.inputs, ClientFeature .inputs) == TRUE then 19: Update CombineMatches 20: return TRUE 21: end if 22: end if 23: end for 24: end for 25: return FALSE
1: Description: Algorithm looks for paused tenants. 2: Input: Set of tenants currently provisioned by the provider and the active tenant. 3: Output: Set of paused tenants that satisfy the client’s resource requirement or null, if no such set exists. 4: 5: existingTenants - contains list of existing tenants 6: T - active tenant, which needs resources 7: pausedTenants - list of paused set of tenants whose resources can be reallocated to the currently active tenant 8: resource - contains the cumulative resources of the paused tenants that are identified and is initialized to 0. 9: 10: for every tenant t in the existing set of tenants do 11: if t is in the paused state then 12: Add t to list pausedTenants 13: resource = resource + t.resource 14: //If the cumulative resources of paused tenants exceed T’s resource requirement, then return the set of paused tenants. 15: if resource > T.resource then 16: return pausedTenants 17: else 18: continue 19: end if 20: end if 21: end for 22: return null
Algorithm 7 DynamicAllocationOfResources Algorithm 1: Description: Algorithm performs dynamic allocation of resources across tenants 2: Input: Set of tenants currently provisioned by the provider 3: Output: Allocation of paused tenants’ resources to an active tenant 4: 5: existingTenants - contains list of existing tenants 6: pausedTenants - list of paused set of tenants whose resources can be reallocated to the currently active tenant 7: 8: for every tenant T in the existing set of tenants do 9: if T is in the active state then 10: pausedTenants = lookForPaused( existingTenants, T) 11: if pausedTenants = null then 12: Make allocation of pausedTenants’ resources to T 13: T’s state is set to ACTIVE 14: else 15: Make other allocation for resources 16: end if 17: end if 18: end for
References 1. Agarwal V, Dasgupta K, Karnik NM, Kumar A, Kundu A, Mittal S, Srivastava B (2005) A service creation environment based on end to end composition of web services. In: WWW, pp 128–137 2. Aoun R, Doumith EA, Gagnaire M (2010) Resource provisioning for enriched services in cloud environment. In: CloudCom, pp 296–303 3. Arnold W, Eilam T, Kalantar MH, Alexander V (2007) Konstantinou, and Alexander Totok. Pattern based soa deployment. In: ICSOC, pp 1–12 4. Bellur U, Kulkarni R (2007) Improved matchmaking algorithm for semantic web services based on bipartite graph matching. In: ICWS, pp 86–93 5. Bellur U, Vadodaria H (2008) On extending semantic matchmaking to include preconditions and effects. In: ICWS, pp 120–128 6. Cardoso J, Sheth AP, Miller JA, Arnold J, Kochut K (2004) Quality of service for workflows and web service processes. J Web Sem 1(3): 281–308 7. Cloud Computing Use Cases, accessed 19th August 2010. http:// groups.google.com/group/cloud-computing-use-cases?pli=1 8. Chao K-M,Younas M, Griffiths N, Awan I, Anane R, Tsai C-F (2004) Analysis of grid service composition with bpel4ws. In: AINA (1), pp 284–289 9. Cormen TH, Leiserson CE, Rivest RL, Stein C (2001) Introduction to Algorithms, Second Edition. The MIT Press and McGraw-Hill Book Company 10. Deutsch A, Vianu V (2008) Wave: automatic verification of datadriven web services. IEEE Data Eng Bull 31(3):35–39 11. Ezenwoye O, Sadjadi SM, Cary A, Robinson M (2007) Grid service composition in bpel for scientific applications. In: OTM workshops, pp 1304–1312
123
Author's personal copy 302 12. Glatard T, Montagnat J, Pennec X (2006) Efficient services composition for grid-enabled data-intensive applications. In: HPDC, pp 333–334 13. Groher I, Voelter M (2007) Expressing feature-based variability in structural models. In: SPLC ’07: proceedings of the workshop on managing variability for software product lines 14. Horrocks I (2008) Ontologies and the semantic web. Commun ACM 51(12):58–67 15. Huhns MN, Singh MP (2005) Service-oriented computing: key concepts and principles. IEEE Internet Comput 9(1):75–81 16. Konstantinou AV, Eilam T, Kalantar M, Totok AA, Arnold W, Snible E (2009) An architecture for virtual solution composition and deployment in infrastructure clouds. In: VTDC ’09: Proceedings of the 3rd international workshop on virtualization technologies in distributed computing. ACM, New York, NY, USA, pp 9–18 17. Lenk A, Klems M, Jens N, Tai S, Sandholm T (2009) What’s inside the cloud? an architectural map of the cloud landscape. In: ICSE cloud 09: first international workshop on software engineering challenges for cloud computing, pp 23–31 18. Li L, Horrocks I (2003) A software framework for matchmaking based on semantic web technology. In: WWW 2003. ACM, New York, NY, USA, pp 331–339 19. Maedche A, Staab S (2004) Ontology learning. In: Handbook on ontologies, pp 173–190 20. Mietzner R, Metzger A, Leymann F, Pohl K (2009) Variability modeling to support customization and deployment of multi-tenant-aware software as a service applications. In: PESOS ’09: proceedings of the 2009 ICSE workshop on Principles of engineering service oriented systems. IEEE Computer Society, Washington, DC, USA, pp 18–25
123
SOCA (2012) 6:283–302 21. Paolucci M, Kawamura T, Payne TR, Sycara KP (2002) Semantic matching of web services capabilities. In: International semantic web conference, pp 333–347 22. Pautasso C (2005) Jopera: an agile environment for web service composition with visual unit testing and refactoring. In: VL/HCC, pp 311–313 23. Sam Y, Boucelma O, Hacid M-S (2006) Web services customization: a composition-based approach. In: ICWE ’06: proceedings of the 6th international conference on web engineering. ACM, New York, NY, USA, pp 25–31 24. Sheth AP, Gomadam K, Ranabahu A (2008) Semantics enhanced services: Meteor-s, sawsdl and sa-rest. IEEE Data Eng Bull 31(3):8–12 25. ShvaikoPavel Euzenat J (2005) A survey of schema-based matching approaches. J Data Semant IV 146(171):146–171 26. Vaculín R, Neruda R, Sycara KP (2008) Towards extending service discovery with automated composition capabilities. In: ECOWS, pp 3–12 27. Vaquero LM, Rodero-Merino L, Buyya R (2011) Dynamically scaling applications in the cloud. Comput Commun Rev 41(1):45– 52 28. Venugopal S, Buyya R, Winton LJA (2006) grid service broker for scheduling e-science applications on global data grids. Concurr Comput Pract Exp 18(6):685–699 29. Jia Y, Venugopal S, Buyya R (2006) A market-oriented grid directory service for publication and discovery of grid service providers and their services. J Supercomput 36(1):17–31 30. Jing Z, Guosun Z (2009) A mechanism for grid service composition behavior specification and verification. Future Gener Comput Syst 25:378–383
