Variability Modeling to Support Customization and Deployment of MultiTenant-Aware Software as a Service Applications * Ralph Mietzner Univ. of Stuttgart, 70569 Stuttgart, Germany
[email protected]
Andreas Metzger Univ. of Duisburg-Essen, 45117 Essen, Germany andreas.metzger@ sse.uni-due.de
Klaus Pohl Univ. of DuisburgEssen, 45117 Essen, Germany
[email protected]
application (or parts thereof) to as many customers, called tenants, as possible [4,6,19]. As a consequence, Software as a Service applications must be multitenant aware. Multi-tenant aware means that the software must appear to each tenant as if he was the sole tenant of the application (e.g., keeping confidential data private), while allowing multiple tenants to use the same instance of the application (in order to achieve economy of scale). Multi-tenant aware applications thus allow providers to provision the hardware and software stack for the application once and run multiple customers on that very same infrastructure. The functionality and quality that individual tenants require from a software application can differ. As a consequence, SaaS providers are faced with two goals, which need to be balanced. Firstly, in order to attract enough customers, they need to cater for the varying requirements of potential tenants by providing the tenant-specific adaptation and deployment of the SaaS application. Secondly, they need to make sure that the variants of their SaaS application retain enough commonalities to exploit the economies of scale. This paper shows that variability modeling and management techniques (successfully employed in software product line engineering [2,16]) provide good means to support the handling of variability in serviceoriented SaaS applications. Key to the proposed approach is to define and exploit so called explicit variability models, which relate the variation of the SaaS applications in terms of SaaS customer requirements to the variation allowed by deployment and realization alternatives. Based on this model, the SaaS providers are supported in their decision about which variants to offer. Additionally, based on information about which tenants have already been deployed (i.e., information
Abstract More and more companies are offering their software by following the Software as a Service (SaaS) model. The promise of the SaaS model is to exploit economies of scale on the provider side by hosting multiple customers (or tenants) on the same hardware and software infrastructure. However, to attract a significant number of tenants, SaaS applications have to be customizable to fulfill the varying functional and quality requirements of individual tenants. In this paper, we describe how variability modeling techniques from software product line engineering can support SaaS providers in managing the variability of SaaS applications and their requirements. Specifically, we propose using explicit variability models to systematically derive customization and deployment information for individual SaaS tenants. We also demonstrate how variability models could be used to systematically consider information about already deployed SaaS applications for efficiently deploying SaaS applications for new tenants. We illustrate our approach by a running example for a meeting planning application.
1. Motivation Software as a Service (SaaS) has emerged as a promising new delivery model for software applications. Instead of installing software applications on the premises of a customer, the software applications are maintained and run by a SaaS provider. In contrast to earlier attempts of application service provisioning [18], the SaaS delivery model is focused on exploiting economies of scale by offering the same instance of an *
Frank Leymann Univ. of Stuttgart, 70569 Stuttgart, Germany
[email protected]
The research leading to these results has received funding from the European Community’s Seventh Framework Programme FP7/2007-2013 under grant agreement 215483 (S-Cube).
PESOS’09, May 18-19, 2009, Vancouver, Canada 978-1-4244-3716-0/09/$25.00 © 2009 IEEE
18
ICSE’09 Workshop
about the binding of variability), this paper demonstrates how deployment scripts to provision new tenants can be generated. Additional benefits of the approach include support for users in deciding on the options to be chosen, reasoning on unused variants and support for de-provisioning of tenants. Of course, offering “pre-planned” variability for a service-based SaaS application, in general restricts the flexibility enabled through the open world assumption of serviceoriented computing. However, managing the complexity of “unlimited” flexibility is still an open issue. Thus, our approach provides a balance between offering (enough) flexibility and managing that flexibility. The remainder of the paper is structured as follows. Section 2 discusses deployment and multi-tenancy support for SaaS applications, focusing on the need for customization and how to realize it. Section 3 discusses related work in the field. Section 4 presents a running example to illustrate our approach. Section 5 introduces our variability modeling approach for SaaS deployment. Where Section 6 shows how the variability model can be used for supporting SaaS customization, Section 7 shows how (automated) deployment is enabled by the variability models. Section 8 details further benefits of the presented approach.
require an application to be highly available and are therefore willing to pay a higher price for the usage. Other tenants are not so much interested in highavailability but care more about a lower price. With traditional software this is often reflected in products that are offered in different packages. One package offers the basic application features for free, and another package offers the same features but allows the application to be installed, for instance, in a cluster to guarantee a higher degree of quality of services.
2.2. Realizing Customizable SaaS Applications The service oriented architecture (SOA [10]) is well-suited as an architectural style for realizing SaaS applications [4,6,14] as it offers a flexible way for building new composite applications out of existing building blocks (i.e., services). By composing an application out of existing services, customization and adaptation of the software can be done on the level of individual services and the composition of such services. Additionally, service orientation allows tenants to customize individual parts (services) of an application by exchanging them for their own implementation of the service (interface). Therefore, service orientation allows a SaaS application to be composed of two types of services: services that are deployed in multi-tenancy mode (i.e., shared by several tenants), as well as services that are deployed in a single-tenancy mode. This allows a higher degree of customization as opposed to monolithic SaaS applications that are fully deployed in a multi-tenancy mode and configurable via metadata. Therefore, SaaS providers such as Salesforce.com are offering platforms (such as Salesforce’s Force.com AppExchange platform 1 ) that allow tenants to create and deploy their own extensions to the application. These extensions can be either tenant-specific or can be multi-tenant aware and reused by other tenants. Based on the need for customer-specific adaptation, a SaaS application (or parts thereof) can be realized and deployed using three basic patterns [4,12,13]. These patterns are: • Single instance: This pattern denotes that all tenants use the same instance of the SaaS application (or parts thereof), i.e., the instance is shared between all SaaS applications (commonality). As explained above, by same instance we mean that the same workflow using the same code on the same infrastructure is used by several tenants. • Single configurable instance: In this pattern, all tenants use the same instance of the SaaS applica-
2. Background 2.1. Need for Customization To exploit economies of scale, SaaS providers must be successful in attracting a significant number of tenants for their SaaS applications. Obviously, the functionality and quality that individual customers require from a software application can differ. As a consequence, SaaS providers need to cater for the varying requirements of a broad spectrum of potential tenants. This implies that SaaS applications allow tenantspecific configuration and customization. Salesforce.com, a popular SaaS CRM application, for example, allows users to customize the data-fields used in the application as well as adding and modifying workflows. This is done via so-called “configuration metadata” that is specific on a per-tenant level. Such tenant-specific adaptations of a SaaS application affect all layers of the application. From functional requirements such as design and texts in the graphical user interface (also called “branding”), over customized business processes to database schemas. Tenants do not only have differing requirements with respect to functional properties of the SaaS application, they can also require different quality of service properties (such as privacy or performance). Some tenants
1
19
http://www.salesforce.com/appexchange/
tion (or parts thereof). However the instance is configurable on a per-tenant basis. This means that whenever the SaaS application is invoked by the tenant, the instance is adapted during run-time (typically through configuration metadata, e.g., configuration files or configuration entries in a database). This means that there is variability in the SaaS applications. • Multiple instances: In this pattern, each tenant uses a different instance of a service. This allows for the most flexible adaptation to the customer requirements, but also requires separate code to be deployed for each tenant. In case all parts of the SaaS application and the necessary hardware are deployed using this pattern, this is similar to the ASP model with all its disadvantages. Like in the previous patter, this means variability. The two single instance patterns correspond to the idea of a multi-tenant aware application as they serve multiple tenants from the same instance of a software implementation. Therefore, the (parts of) the application that can be deployed in this manner must be developed with multi-tenancy in mind.
variability issues of SaaS applications. In [6] the authors present a framework to deal with the issues of native multi-tenancy for SaaS applications. In [4,6] the challenges of SaaS applications for application vendors and providers are discussed, taking into account the need for customization of SaaS applications. Our approach extends the above approaches as it explicitly takes into account variability and combines the work from the software product line community with the work of the SaaS community.
4. Running Example To demonstrate our approach, we will use the running example of a SaaS provider, who offers MeetR, an application that is used to run a decision process among several individuals to find a date for a meeting. The MeetR application is realized as a service-oriented application using Web services. The application consists of the following components: • an e-mail Web service, which can be invoked to send out e-mails; • a WS-BPEL 2 workflow that reflects the decision process and calls the e-mail Web service; • a graphical user interface (in the form of several Web pages) that gathers user input and displays the results of the decision process. The functional variability of the MeetR example SaaS application is as follows: The Saas provider allows tenants to customize the GUI of MeetR by uploading their own companyspecific logo and also by entering a new title for the application. Tenants can customize the business process by choosing from one of the two pre-defined workflows “short” and “long”: Following the “short” workflow, the MeetR application will accept a proposal for a set of meeting dates from the meeting organizer, based on which the organizer receives an e-mail from MeetR. The meeting organizer can then forward this e-mail to all possible attendants. The e-mail contains a link to a Web page that allows the possible attendants to state on which dates they are available. Once the meeting organizer has determined that enough people have registered, the organizer can fix the actual meeting date by selecting one of the proposed dates. Based on that, the organizer will then receive an e-mail that again can be forwarded to all attendants. Following the “long” workflow, the MeetR application will accept a proposal for a set of meeting dates together with a list of e-mail addresses for possible
3. Related Work Variability Management: Several authors have proposed using variability modeling techniques from software product line engineering in the context of service-based systems. In [3] the authors address the problem that variability of business processes and services is not explicitly modeled, which hinders implementing adaptive service-based systems. They extend the XML schemas of service description languages in order to cater for variability. In [3] the authors propose to exploit variability and goal modeling techniques to deal with changes in service-based systems. In [7] the authors describe an approach to document and handle variability in Web services, while [9] focus on variability in BPEL. Although these approaches propose explicitly documenting variability, they do not cater for the specific problems faced in the SaaS context (e.g., multi-tenancy). Deployment and Multi-Tenancy Support: In [1] the authors discuss architectural issues and requirements for the distribution, configuration and deployment of Web services. They describe an architecture for a software distribution environment to deploy Web service based applications. In [8] a framework for the provisioning of applications and related infrastructure using workflows is presented. These approaches, however do not explicitly deal with the multi-tenancy and
2
20
Web Service business process execution language [13]
attendants. The MeetR application then sends an email to each of the possible attendants, which contains link to a Web page on which the attendants can mark their available dates. When all possible attendants have marked their available dates, the MeetR application automatically sends an e-mail to the meeting organizer with a link to the Web page that contains a summary of all available dates. The meeting organizer can now choose one of the dates and an e-mail with this date is sent to all attendants by MeetR. When selecting the “long” workflow, tenants can also opt to include additional functionality, namely the storage of e-mail addresses so that these addresses do not have to be re-entered when the next meeting is organized. In case a tenant opts for this variant, an additional Web service, which stores and retrieves the addresses from a database, is used. To ensure multitenancy, the database must be designed in a way that the e-mail addresses of different tenants are separated, such that one tenant cannot access the e-mail addresses of another tenant. There exist several ways to achieve this [4], one way would be to annotate every record in the database with the tenant ID and adapt the queries accordingly. Another way would be to store the data of each tenant in a separate database. From a SaaS provider point of view, using a single shared database in multi-tenant mode is beneficial, since only one database must be set up, secured, backupped and maintained. Tenants however might have company regulations, for example, that prevent storing e-mail addresses in shared databases. Therefore, further variability is introduced allowing tenants to choose whether they want to store the e-mails in a separate database or in a shared database. The application is offered in two availability modes: High availability and no-guaranteed availability. In case high availability is needed a tenant is served from a cluster, otherwise he is served from a standard nonclustered environment.
customers of a SaaS application might want their application to show their respective company logo. • Realization-driven Variability: Alternatives for realizing the SaaS application introduce a further level of variation, which needs to be understood. As an example, the “send e-mail” feature of a SaaS application could be realized as a single instance on a single infrastructure, which is shared between all tenants or separately deployed for each tenant. In addition, the binding of the SaaS variability (i.e., the choice of the desired variants and the respective configuration of the SaaS application) is not only dependent on choices made by a tenant, but also on the choices made by the tenants that have been deployed so far. Knowing which parts of the application have already been deployed supports minimizing operation costs, as existing parts may be reused for additional tenants. For example, if a customer requires high availability (customer-driven variability) the highavailable workflow engine will be deployed. Now, if the same SaaS application is deployed for a second tenant, it might be more economical to use the highavailable engine as well instead of deploying the standard workflow engine in addition (although this is not explicitly required by the customer). Therefore, in SaaS scenarios, the binding of variability is not always done before an application is deployed but also during the deployment of an application. To model the variability of SaaS applications as well as the binding of it, we propose exploiting techniques from software product line engineering. The product line community has achieved significant progress in explicitly modeling the variability of product lines [2,16]. In software product line engineering, two types of variability can be distinguished and documented in variability models: external variability and internal variability [16]: • In simple terms, external variability is the variability that is communicated to the customer of the product line. In the SaaS context, the customerdriven variability nicely matches with this notion of external variability. • In contrast to external variability, internal variability is only visible to the developers of the product line. As such, this kind of variability clearly correlates with the realization-driven variability of a SaaS application. Consequently, we will follow this distinction when constructing the SaaS variability models, and are thereby able to reason on these models in order to support the decision process for realizing, customizing and deploying SaaS applications.
5. Variability Modeling for SaaS Our key idea to address the problem of managing variability in SaaS applications is to explicitly model the variability of SaaS applications. The variability of SaaS applications can be driven by several sources: • Customer-driven Variability: Different customers have different requirements to the application. These differences in requirements require that the SaaS applications are configurable to cater for the varying requirements. As an example, the different
21
must be adapted on a per-tenant base. In case a tenant requires data to be not shared, and opts for e-mails to be stored, a separate database must be set up for this tenant upon deployment and the e-mail service must be configured to use this database for this tenant. If the application needs to be highly available the tenant must be deployed in a cluster. These dependencies are reflected by «requires» dependencies in the OVM model in Figure 1.
5.1. The OVM Language For defining the variability we use the OVM (Orthogonal Variability Model) described in [16, 11]). In contrast to approaches which document variability within existing models, the OVM provides a separate view on variability. The benefits of this separate view are – besides others – that the variability models are smaller in complexity/size (only variability and not the commonalities are documented) and that communicating variability to the stakeholders is simplified (e.g., only the variability model and not design models etc. must be understood by the customers). The OVM provides the following key concepts for modeling variability: In an OVM, a variation point (VP) documents a variable item. A variant documents the possible instances of a variable item and is thus related to a VP. Both VPs and variants can be either optional or mandatory (shown graphically by solid resp. dashed lines). A mandatory VP must always be bound, i.e., variants of that VP must always be chosen. An optional VP does not have to be bound. Mandatory variants must be chosen whenever their VP is bound. Optional variants can, but do not have to be chosen. Optional variants can be aggregated to into an alternative choice. The variants that can be chosen from an alternative choice are constrained by the cardinality given as min..max. Further constraints between variants, between VPs and between variants and VPs can be defined graphically: An exclude constraint specifies a mutual exclusion; e.g., if a variant excludes an optional VP, the VP may not be bound whenever the variant is chosen, and vice versa. A requires constraint specifies an implication; i.e. if one variant is chose, another variant has to be chosen as well.
VP
Workflow
VP
VP
VP
Logo
Data Separation
Title
1..1
1..1 V
V
V
Short
Guaranteed
Not guaranteed
V
Long
VP
«requires» Availability VP
1..1
Store E-Mails
V
Standard V
V
High availability External Variability
Yes
Internal Variability
«requires»
VP
DB Pattern 1..1 V
V
Single Instance Multiple Instances
VP
«requires»
Environment 1..1 V
Non-Clustered
«requires» V
Clustered
Fig. 1. Variability model showing the customer-driven (external) and the realizationdriven (internal) variability in OVM notation
5.2. Running Example Figure 1 depicts the variability model for our running example. Here, external variability is the choice of a logo (VP Logo) and a title for the application (VP Title), as well as the choice of one of two predefined workflows (VP Workflow). In the case that the “long” workflow has been chosen, the tenant can also decide whether he wants to store e-mail addresses for future use (VP Store E-Mails). Additionally, the tenant can choose one of several non-functional properties: If the data is shared or not (VP Data Separation), and if the application needs to be highly-available or not (VP Availability). Depending on the choice of one of the workflows (“short” / “long”), the GUI must be configured differently to submit data to the right workflow and to display different results. Therefore, configuration files
6. Customization using Variability Model Once the variability of SaaS applications has been modeled, those variability models can be used for further support throughout the SaaS application customization and deployment lifecycle.
6.1. Guiding Users through Customization In order to customize a SaaS application, the tenants need to decide which variants should become part of their SaaS application. Thus, those tenants need to be presented with the potential configuration options in order to bind the variability of the SaaS application. In
22
the product line engineering community, several approaches have been presented to realize such a customization support. For the specifics of SaaS applications, we have described in [11] how to generate so-called customization flows out of variability information. These customization flows are workflows (expressed in BPEL) used to guide tenants through the customization of a SaaS application. After the customization all customer-driven variability is bound.
to the single instance services, the resources for the single configurable instance services must be reserved. In addition to that, the configuration data must be deployed. For services in multiple instances mode, the appropriate infrastructure must be provisioned. Additionally, a new instance of the service must be installed on that infrastructure.
7. Deployment Support based on the Variability Model
By annotating the explicit variability model with deployment information the deployment infrastructure can derive which steps to take to deploy all possible configurations of the SaaS application. Therefore we annotate each variant in the variability model with the necessary deployment actions to deploy this variant. Together with the information about the binding of the variation points the planning component of the deployment infrastructure can now generate a deployment script that contains all necessary deployment actions corresponding to the bound variants. A suitable language to describe and execute such deployment scripts on a high level is for example WS-BPEL as shown in [8, 13, 17]. The deployment infrastructure then executes the generated deployment script to deploy the tenant.
7.2. Annotation of the Variability Model with Deployment Information
After the binding of the customer-driven variability of a SaaS application by a tenant, the necessary deployment actions must be taken so that the application can be used by the new tenant.
7.1. Binding of Open Variation Points During Deployment of Services The deployment actions to be taken by the provisioning infrastructure depend on the binding of the realization-driven variability which in turn depends on the customer-driven variability and the information about already bound variability, i.e. deployed SaaS application. Therefore to bind the realization-driven variability the provisioning infrastructure must consider the customer-driven variability as well as the binding information about the parts of the application that have been deployed for other tenants. The internal variation points that are not bound because of dependencies to variants that have been chosen by the binding of the customer-driven variability must be bound by the provisioning infrastructure. For each open variation point the provisioning infrastructure is aware of the possible variants because it knows the variability model. It must now choose the variant that is the cheapest one for the provider. This can be done by annotating individual variants with a cost parameter and using optimization algorithms to find the least expensive variant combination for all open variation points. These algorithms are however out of the scope of this paper. The deployment actions the provisioning infrastructure needs to take does not only depend on the status but also on the multi-tenancy mode in which services are used for a particular tenant. For services that are be used in a single instance mode, the infrastructure must make sure that enough resources are available to run the new tenant on the instance of the service that is already deployed. Similar
7.3. Running Example Table 1 shows three possible configurations for the example application. The table shows the bound alternatives for each variation point (the title and logo ones are omitted for brevity), given a particular configuration (“-“ denotes that no alternative has been bound for a variation point and “*” denotes that the variation point will be bound during deployment time). Config 1 and config 2 are the same, since every variation point is bound with the same variant. Variation Point
Config 1
Config 2
Config 3
Workflow Data Separation Store E-Mails
short
short
long
-
-
important
-
-
Yes
DB Pattern
-
-
multiple instances
Availability
standard
standard
high availability
Environment
*
*
clustered
Table 1. Possible configurations for the sample application The deployment component for new tenants of the MeetR application must provision the necessary re-
23
sources to run the e-mail service and the graphical user interface for the new tenant. The e-mail service and graphical user interface are standard components of the application that are reused in “single instance” and “single configurable instance” mode for all tenants. Therefore, after reserving the necessary resources to accommodate the new tenant on these services, only the configuration data for the GUI needs to provisioned. For config 1 and config 2 (see Table 1) the deployment component must then reserve the necessary resources to run the “short” process models for the new tenant. Since both configurations do not require high-availability, the application can be deployed on the least expensive environment. However, as the “*” denotes in Table 1, the decision whether the application is deployed in the standard environment or in the high-available environment is left open to the deployment infrastructure. Let us assume that first config 1 is deployed and the workflow “short” is already deployed on a BPEL engine in the standard environment. Upon deployment of config 2, this standard BPEL engine cannot support additional users so that a new BPEL engine in the standard environment needs to be provisioned to run the instances of process model short for tenant 2. However, a BPEL engine in the high-available environment is also available that can accommodate the load that will be generated by tenant 2. Therefore, the resources for the “short” BPEL process are reserved on this engine as this is cheaper than provisioning a new standard BPEL engine. As shown, we have postponed the binding of internal variability to the deployment or even the runtime in this case. The result of this behavior is that two tenants that bind all external variability points in a similar way can end up with two different solutions, as one solution for example is deployed on the highly available environment while the other one is deployed on the normal environment. The deployment flow for tenant 3 (config 3) must provision resources for the DB service as this tenant chose to store e-mail addresses in the database. Additionally, the service must also be deployed in multiple instances mode, as privacy is important to that tenant. As the tenant also selected the option of guaranteed high availability, the workflow “long” is deployed on a BPEL engine that is configured for high availability. Now a situation could arise where tenant 3 would require the resources on the high available engine that are occupied by tenant 2. In this case provisioning a new high-availability engine would cost more than provisioning a new standard BPEL engine. Therefore, tenant 2 should be moved from the high-availability engine to the standard one.
7.4. Undeployment and Transfer Scripts Once a tenant decides to unsubscribe from an application it must be undeployed from the system. This might be as simple as removing a line in a configuration database and marking the resources used by that tenant as free. However, in case a tenant has used services that are deployed in multiple-instance mode, these services must be undeployed. Nevertheless, it is important to know which combination of both, functionality and environment has been used by a tenant to perform the necessary steps to undeploy said tenant. Similar to the provisioning scripts mentioned above, the steps of deprovisioning scripts can be annotated to the individual variants thus allowing for an automated generation of deprovisioning scripts out of the bound variability model for a tenant. In addition to provisioning and de-provisioning scripts, “tenant transfer” scripts can be generated that describe how a tenant is transferred from one configuration to another. These scripts can be annotated to two variants of a variation point that exclude each other.
7.5. Prototype Implementation We have implemented a prototype that demonstrates the above concepts. The prototype is based on the Apache Tuscany 3 service component architecture (SCA) runtime. The prototype allows annotating SCA application packages with variability expressed in the variability descriptor format [12, 14]. This variability information is then used to generate customization workflows out that guide users through the customization of the application. The prototype uses a registry that captures information about already deployed parts of the SaaS application. The provisioning infrastructure then queries this registry to decide whether a service needs to be deployed or not or if it is sufficient to deploy configuration data. The prototype also allows plugging in different algorithms that are used to determine which infrastructure resources across different infrastructure providers can be used to deploy the application. We are currently investigating how the distribution of the application services over different infrastructure resources can be optimized, however this is out of scope for this paper.
8. Further Benefits of the Approach We have shown in [12] how to generate customization flows out of an explicit variability model and have 3
24
http://tuscany.apache.org/
3.
shown above how the explicit variability model can be exploited by the provisioning infrastructure for resource-efficient provisioning of new tenants. Some other usage scenarios are detailed below.
4. 5.
8.1. Optimizing the Offered Variability The documentation of external variability can be used to reason on the customization choices the tenants make. These choices include the binding of individual variation points; e.g., which workflow engine has been chosen in our running example. In more elaborate scenarios, more complex information such as popular combinations of variation points can be derived. For example, it could be observed that all customers that require high availability also require databases that are not shared. By capturing and mining configuration options that tenants have chosen in the past, SaaS providers can optimize the variability that is offered by their SaaS applications (thereby reducing the complexity in developing, maintaining and testing those applications). Based on this information, a provider can, for example decide to remove variants that are only relevant for a very small amount of users (as offering these variants does not pay off in the long run).
6.
7. 8. 9.
10. 11.
9. Conclusion and Outlook 12.
We presented how variability modeling techniques, well known from software product line engineering, can be used to model variability in Software as a Service (SaaS) applications. We have applied the concepts of external and internal variability from software product line engineering to the problem of customization and deployment support for SaaS applications and have demonstrated the benefits of our approach by means of an illustrative example. In our future work, we plan to investigate how to associate the variability model with cost functions so that a service provider can determine the cost of creating, maintaining and managing a variant and can evaluate whether it makes sense, economically, to keep a variant or whether to remove it.
13.
14.
15. 16. 17.
References 1. 2.
18.
R. Anzböck, S. Dustdar, H. Gall,“Software Configuration, Distribution and Deployment of Web-Services” In Proc. of SEKE 2002 J. Bayer, S. Gerard, Ø. Haugen, J. Mansell, B. MøllerPedersen, J. Oldevik, P. Tessier, J.-P. Thibault, and T.Widen. “Consolidated Product Line Variability Modeling”, Software Product Lines . Springer, 2006.
19.
25
S. H. Chang and S. D. Kim, “A Variability Modeling Method for Adaptable Services in Service-Oriented Computing,” in Proc. of SPLC ’07 F. Chong, G. Carraro “Architecture Strategies for Catching the Long Tail” , MSDN Library, 2006 R. Clotet, D. Dhungana, X. Franch, P. Grünbacher, L. Lopez, J. Marco, and N. Seyff, “Dealing with Changes in Service-Oriented Computing Through Integrated Goal and Variability Modelling,” in Proc. of VaMoS 2008. C. J.Guo, W. Sun, Y. Huang, Z. H. Wang, B. Gao, “A Framework for Native Multi-Tenancy Application Development and Management.” In Proceedings of CEC/EEE 2007 J. Jiang, A. Ruokonen, T. Systa, "Pattern-based Variability Management in Web Service Development," ECOWS'05, 2005 A. Keller, R. Badonnel, “Automating the Provisioning of Application Services with the BPEL4WS Workflow Language.” In Proceedings of DSOM 2004 M. Koning, C. Sun, M. Sinnema and P. Avgeriou. “VxBPEL: Supporting variability for Web services in BPEL”. Information and Software Technology. Volume 51, Issue 2, February 2009 D. Krafzig, K. Banke, D. Slama, “Enterprise SOA: Service-Oriented Architecture Best Practices.” Prentice Hall Ptr, 2004. A. Metzger, P. Heymans, K. Pohl, P.-Y. Schobbens G. Saval: “Disambiguating the Documentation of Variability in Software Product Lines: A Separation of Concerns, Formalization and Automated Analysis.” In Proceedings of RE 2007 R. Mietzner, F. Leymann, “Generation of BPEL Customization Processes for SaaS Applications from Variability Descriptors.” In Proc. of SCC 2008 R. Mietzner, F. Leymann, “Towards Provisioning the Cloud: On the Usage of Multi-Granularity Flows and Services to Realize a Unified Provisioning Infrastructure for SaaS Applications”. In Proc. of SERVICES 2008 R. Mietzner, F. Leymann, M. Papazoglou, “Defining Composite Configurable SaaS Application Packages Using SCA, Variability Descriptors and Multi-Tenancy Patterns.” In Proc. ICIW 2008 OASIS WS-BPEL Technical Committee, http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsbpel K. Pohl, G. Böckle, and F. van der Linden. “Software Product Line Engineering: Foundations, Principles and Techniques”. Springer, 2005. T. Scheibler, R. Mietzner, F. Leymann, “EAI as a Service – Combining the Power of Executable EAI Patterns and SaaS”. In Proc. EDOC 2008, L. Tao.: “Shifting Paradigms with the Application Service Provider Model”, COMPUTER vol. 34 Is.10, 2001 M. Turner, D. Budgen, P. Brereton, “Turning Software into a Service”, COMPUTER vol. 36 Is. 10, 2003
