Extension of a SCA Editor and Deployment-Strategies for Software as a Service Applications

Transcription

1 Institut fur Architektur von Anwendungssystemen Universität Stuttgart Universitätsstraße Stuttgart Diplomarbeit Nr Extension of a SCA Editor and Deployment-Strategies for Software as a Service Applications Tobias Arnold Course of Study: Softwaretechnik Examiner: Supervisor: Prof. Dr. Frank Leymann Dipl.-Inf. Ralph Mietzner Commenced: August 7, 2008 Completed: February 6, 2009 CR-Classification: C.2.4, D.1.7, D.2.11, D.2.13

2

3 Contents 1. Introduction Task Description Structure of this Document Delivered Software Basics Software as a Service Levels of SaaS Configuration on the Level of Services Multi-Tenancy Patterns Roles in the SaaS Business Model Service Oriented Architecture Service Component Architecture Component Implementation Services References Interface Binding Property Composite Wires Include Domain Contribution Extension model SCA Definitions Policy Framework Specification Variability Descriptors Multi-Granularity Flows SaaS Application Packages Evolution of a Package I

4 Contents Template Solution Modeling Restrictions Wiring Single Configurable Instance Components Configuration of non-xml based Implementation Files Customization of Implementation Files that are used for several Components Customization of the Multi-Tenancy Pattern Modeling of Wires Deployment Strategies Challenges for the Deployment Process General Deployment Strategies Preparation Deployment Deployment on a SCA Engine Preparation Fixed and Tenant Specific Package Separation via Composite Implementation Separation via Include Handling of other SCA Elements Handling of Implementation Files Prototype Architecture Overview Editor Requirements Utilized Technologies Eclipse Modeling Framework Graphical Modeling Framework Modifications Ecore Model Changing the Pattern Visual Representation of the Multi-Tenancy Patterns Package Deployer Requirements Utilized Technologies Apache Tuscany Apache Tomcat and Apache Axis Web Tools Platform II

5 Contents Arrangements for the Implementation Import and Export Statements Composite Model Modifications File Repository Interface Implementation Details Create Solution Delete Solution Deploy Solution Undeploy Solution Start Stop Restrictions Domain Manager Launcher Distributed Nodes Scenario Components Store Catalog CurrencyConverter ShoppingCart DiscountCalculator StoreOwnerMailer Preparations for the Customization Process Customization by the Shop Owners Deployment Conclustion and Outlook What Level is It Propositions for Future Work A. Bibliography i B. List of Figures iii C. Listings v D. List of Tables vi E. Web Interface of the Package Deployer vii III

6 Contents E.1. Repository Status View vii E.2. Deployment View vii E.3. Nodes View vii F. Test Client for the Package Deployer x G. Composite File of the Scenario Application xii H. Implementation Mapping File of the Scenario Application xv IV

7 1. Introduction Today Software as a Service is said to have a major impact on software industry. It changes the way people build, sell, buy and use Software. In the Software as a Service delivery model the software is no longer purchased by customers and hosted by themselves. But it is run on the IT infrastructure of a hosting company. To use a SaaS application, customers have to subscribe for it and unlike in traditional software, they loose all rights when they unsubscribe from a service. Since the organizational structures of companies are quite different, there is also the need for tailor-made customer configurations. Certainly the SaaS delivery model offers several economical advantages. For example less money has to be spent for the customers infrastructure. Another advantage would be, that the problems with hardware is moved to the service provider and it is easier to calculate the overall budget for IT services. Due to the fact, that only one application can serve many customers, it also becomes profitable to sell a software to smaller companies. Considering this fact, several vendors are building proprietary platforms where more and more applications are hosted in the SaaS business model. A famous example is salesforce.com. Though, a drawback of this approach is that the applications offered by different application providers can not easily be reused on the platforms of different SaaS hosting providers. To master this problem, in [20], there is a solution proposed by the IAAS of the University of Stuttgart. The idea is to use the Service Component Architecture framework to create composite configurable SaaS application packages. These packages define a common format in which SaaS applications can be delivered. Based on this, there are three roles in a typical SaaS scenario introduced. The customer who wants to fulfill a certain task and therefore, subscribes to a SaaS application. The provider who offers the software and the vendors who are responsible for the development of an application. Certainly these different roles must not implicitly be assigned to different companies. But customers would have the possibility to outsource the hosting activities or the development of an application. To cover the need for the configuration of the SaaS application packages, in [20], different phases in the evolution of an application package are introduced. Before a package is configured it is labeled as an application template. After the configuration process it is called a solution package. 1

8 1 Introduction This diploma thesis is based on the paper [20] which was released in early In this paper the method to use the service component architecture to create SaaS application packages was firstly introduced. In this thesis the theoretical approach of building these packages is advanced and enriched by practical execution Task Description The first task of this thesis is to extend an existing SCA-Editor. It has to support the annotation of services by multi-tenancy patterns. As a result there is the possibility to model SaaS application package templates like mentioned in the introduction. In the next, these packages have to be transformed into solution packages. To achieve this, they are customized via the help of variability descriptors. This customization process is part of another diploma thesis but will be mentioned to support the comprehension of the whole picture. In the second part, strategies for the deployment of the solution packages have to be analyzed. Therefore, a strategy is developed which allows the deployment of SaaS solution packages on different platforms. To evaluate the approach, a tool has to be created which exemplary enables the automatic deployment on a SCA engine. To adapt a solution package for a SCA runtime, the ideas from [20] are used. The packages are divided into two different packages, namely a tenant specific and fixed package. Whereas the tenant specific package contains all services which can only be used by the specific tenant, the fixed package contains the services which can be shared among several tenants. As a result, the deployment tool needs to provide the deployment process along with the separation into a tenant specific and fixed package. Having the methods to create and deploy SaaS packages, a complete prototype for a SaaS system can be created. Task Summary Extension of an existing SCA-Editor to support multi-tenancy patterns Development of deployment strategies for SaaS solution packages Creation of a tool, that allows the deployment of SaaS solution packages on a SCA engine Support for the creation of a prototype for a complete SaaS system 2

9 1 Introduction 1.2. Structure of this Document Chapter two covers the background information needed for the comprehension of this thesis. At first some fundamental basics about the SaaS business model are described. This includes a description of different levels of SaaS applications, along with the introduction of multi-tenancy patterns. These patterns can be used in a SaaS approach that is based on the level of services. Furthermore the Service Component Architecture and the technology of variability descriptors is presented in detail. Both are crucial for the SaaS packages created in this thesis. Chapter three introduces the packages which represent the base for all further work. The assembly of the packages, as well as significant restrictions, are presented. Chapter four starts with the challenges that have to be managed for the deployment of the packages. Afterwards a strategy that allows their deployment on any platform is presented. This approach is used to develop a concrete method that enables the deployment on a SCA runtime. In chapter five the prototype is introduced. It allows to create the packages and their deployment. For the realization, several parts of software were created. The section describes the extended editor that can be used to create the packages. Furthermore the package deployer that manages their deployment and execution is introduced. For every part of software, the utilized technologies and implementation details are stated. In chapter six the functionality of the prototype is explained by the use of a sample application. In the scenario three customers use the prototype to setup a simple online store. The document ends with a conclusion and an outlook on future analysis, what can be done to improve the approach presented in this thesis Delivered Software Besides this paper, the task of this diploma thesis is the creation of several parts of software. These are delivered on the attached DVD. The content of the DVD is described by a readme file in its root folder. In this section the different applications are listed. Extended Editor A SCA editor is extended to allow the annotation of components by multi-tenancy patterns. As a basis, the SCA editor from the eclipse STP (SOA Tools Platform) project is used. The editor is provided as a plugin for eclipse and in a standalone version. 3

10 1 Introduction Package Deployer The package deployer allows to create solution packages which can be deployed on the SCA runtime apache tuscany. Furthermore it allows to execute tuscany nodes which, in this case, permit to run an application package. The package deployer is implemented as a Web service using apache tomcat and axis. It is distributed as a WAR (Web Application Archive) file. To store the application packages, the package deployer uses a file system repository. This repository is contained on the DVD. Domain Manager Launcher The domain manager launcher allows to launch a tuscany domain manager. The launcher is also implemented as a Web service and distributed as a WAR file. External Node Launcher Like the package deployer, the external node launcher allows to start tuscany nodes. This enables the distribution of the application packages over several host PCs. As the other Web services, the external node launcher is distributed as a WAR file. 4

11 2. Basics 2.1. Software as a Service In [14] the authors try to describe Software as a Service by one expressive sentence. They explain it as Software deployed as a hosted service and accessed over the internet. But this explanation is valid for many applications today. Especially for all attractions offered by the Web 2.0 world and web sites in general. So this definition seems to be too general and a more specific description has to be introduced. To achieve this, in [14], different levels of SaaS applications are introduced (see 2.1.1). In the most mature level a SaaS application has to be configurable, multi tenant aware, and scalable. For a better categorization of the Software as a Service applications, in [14], two categories are introduced. Line of business services are stated which are offered to enterprises and organizations of all sizes to support their business processes. On the other hand customer oriented services, that are offered to the general public, are mentioned. Such public services are often offered at no costs, but are subsidized by advertising. Examples are web mail offers or online communities. Application packages suggested in this thesis better fit for business services, since many companies need to configure an application to adopt their business processes. Therefore, complex configurations for a customer may be necessary. Despite of that, packages can also be used to create customer oriented services. Such applications get more and more adoptable today. There are many economical changes which come along with the introduction of a Software as a Service application. The ownership of the software shifts from the customer to an external provider. So the customer is only allowed to use the software during the period he subscribed for it. Thus the responsibility for the technology required to host an application is shifted, too. The provider must ensure that the service is available according to the service level agreements he defined with the customer. The possibility for a provider to offer the same applications to many customers without the need for a whole new infrastructure certainly provides cost-savings. Savings can be achieved for example through less hardware needs and decreases in labor-cost for maintenance, needed on the side of the customer. The big advantage of this cost reduction is that the software is affordable for smaller 5

12 2 Basics companies. In [14], these companies are described as the long tail of businesses (see Figure 2.1). So through economy of scale, Software as a Service applications get also profitable for the service providers. Furthermore new customers can be added at very low costs, if the provider facilitates a way to subscribe for a service without labor intervention on the part of the software vendor. Figure 2.1.: The Long Tail of Businesses [14] Levels of SaaS To specify the wide definition of Software as a Service, the SaaS application maturity can be expressed using a model with four distinct levels [14]. The levels go from old applications that were enriched by a HTML front end, which may fit the broad definition of SaaS, to well designed, scalable, multi-tenant-efficient and configurable applications. In the following these four levels are presented. To achieve comparability the levels are described using four different attributes: the ability to configure an application how many instances of an application can be created what needs to be done when an application changes scalability considerations Figure 2.2 illustrates the different levels of SaaS applications. 6

13 2 Basics Figure 2.2.: The different Levels of SaaS Applications [14] Level 1: Ad Hoc/Customs In level 1 every tenant has its own application instance. Different configurations are applied by the modification of the implementation of a specific tenant. So a separate application is deployed for every customer, but on the infrastructure of a provider. Configuration Instances Changes Scalability Each customer has its own customized version of the application. The instance for a customer is independent of any other instance. The implementation has to be changed separately for every customer. The instances can be distributed over several hosts. One instance can be scaled by moving it to a more powerful machine. Table 2.1.: Level 1 of SaaS Applications Level 2: Configurable In level 2 a separate instance is created for every customer. But unlike in level 1, the instance is created from the same code base. So it is easier to change the application. 7

14 2 Basics Configuration Instances Changes Scalability All instances use the same code implementation, providing detailed configuration options. There is an instance for every customer. Changes to the code base can be easily provided to all of the vendors customers at once. The instances can be distributed over several hosts. One instance can be scaled by moving it to a more powerful machine. Table 2.2.: Level 2 of SaaS Applications Level 3: Configurable, Multi-Tenant-Efficient In Level 3, there is one instance which can be configured for the different customers. The applications of this level can only support a restricted number of customers. Otherwise performance problems would occur. Configuration Instances Changes Scalability There is one instance with support for configurable metadata and security policies. There is only one instance of the application. This eliminates the need to provide server space for as many instances as the vendor has customers. The implementation of the only instance has to be changed. The application is only scalable by moving it to a more powerful server. Table 2.3.: Level 3 of SaaS Applications Level 4: Load-balanced farm of identical Instances In level 4 several instances of the same configurable application can be created. This allows to support a significant amount of customers. 8

15 2 Basics Configuration Instances Changes Scalability There is support for configurable metadata and security policies. There are several instances of the same application. There is only one code base for every instance. Therefore, only one implementation has to be changed. There is support for an arbitrarily large number of customers. This is because the number of servers and instances on the back end can be increased or decreased as necessary to match the demand. Table 2.4.: Level 4 of SaaS Applications In [14] it is also stated, that not every application can be described by exactly one level only. In fact the different levels can be seen as a continuum between isolated data and code on one hand and shared data and code on the other Configuration on the Level of Services In the SaaS model described above, it is possible to configure an instance of the whole application. But in some situations it may be helpful to allow the configuration on a finer grained level. For example some customers may only need to configure parts of an application and may share other parts with other customers. Or an application may contain parts that are not configurable at all, such as external services. In this situation, different parts of the application can still be configurable. Today, according to a Service Oriented Architecture (SOA), most business applications will be realized by the orchestration of service components which make up the particular business functions. For such an application, it is obvious not to require the configuration of the whole application, but to allow the customization of the particular services and the way they are connected. In this model, in addition to the configuration of the functional aspects of an application, a tenant has the following options to modify an application: configure the wiring between the services add new services remove services modify the implementation of a service decide if a service can be shared with other tenants 9

16 2 Basics The SaaS model used in this diploma thesis, allows the configuration on the level of services Multi-Tenancy Patterns Based on the possibility to configure the services which make up an application, three multi-tenancy patterns can be introduced. These patterns describe, to what extent a service can be configured by a tenant. The patterns were firstly stated in [20]. Single Instance Multi-Tenant Single instance multi tenant services are shared amongst multiple tenants. They are neither configurable nor the implementation can be modified on a per tenant basis. Single Configurable Instance Multi-Tenant There is only one instance of the service. So as for a single instance service, the same implementation is used for all tenants. Therefore, tenants can configure the service according to their needs but they cannot choose to modify the implementation. Multiple Instances Multi-Tenant There is a separate instance for every tenant. This allows the tenants to configure a service and to modify its implementation. Some tenants may even choose to replace the whole implementation by their own one Roles in the SaaS Business Model As stated in the introduction, in [20] three roles within the SaaS business model are introduced. These roles are described in the following. Application Vendor The application vendor is responsible for the development of the application. Today many SaaS vendors also act as an application provider. This is due to a missing common platform that allows applications to be easily hosted by different providers. Application Provider The application provider hosts an application. He provides the infrastructure and the manpower to maintain it. Another task of the provider is to allow customers to subscribe for an application and to configure it. 10

17 2 Basics Customer The customer subscribes for an application for the period he needs to use it. He also configures the application for his needs. In this thesis the customer sometimes is called the tenant of an application. Both terms are interchangeable Service Oriented Architecture SOA is an architectural style, which relies on the use of services. A service is a welldefined self-contained function. For communication purposes services provide endpoints, where messages are received and send to. Furthermore, every service can conform to a certain set of non-functional requirements (security, transactions, etc.). Since the services are self-contained, the communication in a Service Oriented Architecture is called loosely coupled. For example services can be added or replaced without the need to change any other artifacts within the architecture. Because the Service Oriented Architecture is only an abstract architectural concept, it can be realized by different approaches. The technology most likely to be used is the technology of Web services. In a Service Oriented Architecture the interfaces of the services need to be described by a common language. For the Web service technology the XML based language WSDL [26] (Web Service Description Language) is used. A common way for the combination of Web services is provided by WS-BPEL [17]. With the help of BPEL (Business Process Execution Language) business processes can be modeled and described. By the invocation of services within a process, a combination of Web services results. Furthermore a BPEL process itself is provided by a Web service. In this thesis both Web services and BPEL are used for the realization of the prototype Service Component Architecture An essential characteristic of SOA is the ability to assemble new and existing services. This allows the generation of new applications that may consist of different technologies. The Service Component Architecture [18] (SCA) defines a service based model for design, assembly and deployment of services. Therefore, SCA allows to create applications which comply to the SOA architectural style. The SCA programming model is language neutral and can be easily extended. Another benefit of SCA is that it allows to separate infrastructure concerns from business logic, which allows developers to focus on business logic. This is achieved by defining methods to declaratively apply policies to service invocations. 11

18 2 Basics To separate the interaction between services from their implementation, SCA defines the notion of a component. Every SCA application is build up from one or more components. Some components could be Java classes others might be written in C++ or might be defined using BPEL. Components are combined into a larger structure called composite. A SCA composite is described in a.composite file. This file uses an XML-based format called Service Component Definition Language (SCDL) to describe the components within a SCA composite and the interactions between them. The most outer boundary for all SCA mechanisms is defined by a SCA domain. It represents a runtime configuration that allows to run all components described by the composites in the domain. Today the most established SCA engine is apache tuscany. But there are several other projects, such as Fabric3 [1] or SCOrWare [2], which both, are open source projects like tuscany. In the following section all elements of the SCA assembly are described in detail. This is important, because most of the elements are essential for the comprehension of this thesis. All descriptions refer to version 1.0 of the SCA specification, which is cited in this thesis. Figure 2.3 shows a SCA composite, containing most of the artifacts described in this section. This thesis uses the same illustration, like it is used in the specification of SCA. Figure 2.3.: SCA Overview [18] 12

19 2 Basics Component Components represent the basic elements of business functions which are combined into complete business solutions. They consist of an implementation that can be configured by properties. For communication purposed, components provide services which can be consumed by other components. The assembly of implementation, services and references is referred to as component type. To constrain the development, a constraining type can be defined. A component is identified by its unique name attribute. Important sub elements zero or one implementation zero or more services zero or more references zero or more properties Implementation There is a wide range of available component implementations in SCA. For example components can be implemented in Java, BPEL or C++. Also special frameworks or runtime environments like JEE can be used. As a special form, composites are accepted as a component implementation (see 2.3.8). The composition of services, references and properties, which can be used by the implementation, is referred to as component type. This component type is calculated in two steps. In step one an introspection of the implementation takes place. In Java for example annotations can be used to denote, where the services, references or properties are utilized in the implementation. In the second step the implementations are handled, for which only a partial or no introspection is possible. To complete the required information, a component type file is used. This file maps the elements which are defined by the component to the proper elements of the implementation. The information provided in the component type file has to match the information which was allocated in the implementation Services Services offer the business functions provided by an interface. Therefore, services can have bindings, which describe the mechanism, how the service can be reached. If no bindings are specified, then the bindings can be specified by the implementation. Bindings 13

20 2 Basics specified by a service element override those, which were specified by the implementation. Every service has a name attribute that has to match the service name, specified by the implementation. Important sub elements zero or one interface one or more bindings References References define the parts of a component where services are consumed. Like the service element, references can have bindings, which describe the mechanism, how particular SCA services can be reached. If no bindings are specified in the description, the bindings can be specified by the implementation. References also define zero or more targets by stating the URIs (Uniform Resource Identifier) of the services in question. The amount of targets is constrained by a multiplicity attribute. Again, if no targets are declared, they can be specified by the implementation. Important sub elements zero or one interface one or more bindings Interface Interfaces define one or more business functions. These functions are provided by services and are used by references. A service offers the business function of exactly one interface to be used by other components. Each interface defines one or more service operations. Each operation has zero or one request message and zero or one response message. SCA in the version 1.0 supports the following interface types: Java interfaces, WSDL 1.1 port types and WSDL 2.0 interfaces. Other interface types can be added via the extensibility system (see ). Interfaces can be declared remoteable to be available for other processes of the operating system or clients running on different machines. Interfaces can be bidirectional by defining an optional callback interface. Or Interfaces can be conversational by defining a sequence of operations. The different interface characteristics are no subject of this thesis because they are not fundamental for the comprehension. 14

21 2 Basics Binding Bindings define the method used for the communication between services and references. References use bindings to describe the access mechanism to call a service. Services use bindings to describe the mechanism, clients have to use to call the service. Examples for binding types are: SCA binding, Web service, etc. More bindings types can be supported through the extensibility mechanism (see ). A special form of binding is defined by the SCA-binding, which can be used for communication within a SCA domain (see ). It is important to understand how the URI for a binding is composed. There are two types of URI schemes: hierarchical and non-hierarchical. Hierarchical URIs are composed by the combination of the following parts: Base System URI / Component URI / Service Binding URI The SCA domain defines a base URI for every hierarchical URI scheme, on which it intends to provide services. The component URI is assigned by the URI attribute of a component. If no component URI is specified, the component name is used. The service binding URI is specified by the URI attribute of the binding element. If no Uri attribute is stated, the binding name serves as URI. Both component URI and service binding URI can also be defined absolutely, to overwrite the URIs specified by the domain or component. Example of a hierarchical URI: If a non hierarchical URI scheme (like mailto:) is used, the URI attribute of a binding can be used to define the complete URI for a binding Property Properties allow the configuration of an implementation with externally set data values. Properties can either have simple (string, integer, etc.) or complex types. Complex types are defined in a separate property type element. Additionally properties can be multi or single valued. The default value can either be set by the implementation or by a default value element. If no default value is set and a must-supply attribute is set, a value for the property must be specified. 15

22 2 Basics Composite Composites are used to assemble SCA elements into logical groups. They build the basic unit of composition within a SCA domain. A SCA composite contains a set of components, services, references and wires that interconnect them. Composites also contain properties which can be used to configure components. A composite is identified by its name attribute. Services and references of a composite are called composite service and composite reference. Services and references of a composite cannot be self-containing. They are provided by some service or reference of a component through promotion. Thereby, the composite service or reference can overwrite configurations made by the promoted component, such as bindings. Even when overwritten on composite level, the configurations of a component keep in effect for direct usage by other components within the composite. Composites can also serve as a component implementation for other composites. Therefore, they must comply to a completeness contract: Composites used as component implementation must have at least one service or reference which is provided by some complete component. Important sub elements zero or more components zero or more services zero or more references zero or more properties zero or more wires Wires SCA wires connect source component references to target component services. One way to define a wire is by configuring a reference of a component using its target attribute. Multiple target services are valid when the reference multiplicity allows it. An alternative way to define a wire is by the use of a wire element. This method is useful when the separation of the wiring form the elements that are connected is reasonable. A wire specified via a wire element is equivalent to a wire specified via the target attribute of a reference. 16

23 2 Basics Include The include element allows to include one composite into another. The semantic is, that the content of the included composite is inlined into the outer composite through textual inclusion. There is no need for the included composite to be complete Domain A SCA domain represents a complete runtime configuration, potentially distributed over a series of interconnected runtime nodes. The domain represents the boundary for all SCA mechanisms. Therefore, connections outside the domain must use binding specific mechanisms for addressing services. The domain has a virtual domain level composite that includes all composites which make up the domain. The inclusion is accomplished in terms of the include element (see ). The size of a domain can be highly variable. It typically represents an area of business functions controlled by a single organization (e.g. account department). The composite also has a set of installed contributions which contain the artifacts necessary to run its components. Certainly the domain provides the possibility to modify the set of contributions and the domain level composite Contribution A SCA Domain may require a large number of different artifacts to work with. These are provided through contributions. The main artifacts of a contribution include implementation files and interface definition files. Both may be object code such as Java class files or XML files such as BPEL or WSDL files. Furthermore any other resource such as image files can be part of a contribution Extension model The SCA assembly model can be extended to support new interface types, implementation types and binding types. A method for the extension of other elements or a way to add completely new elements is not available in version SCA Definitions Since some elements are generally useful not only for a specific composite or component, SCA provides a way to formulate domain wide definitions in a definitions file. For example extensions (see ) can be placed in such a file. 17

24 2 Basics Policy Framework Specification SCA also provides a policy framework to define non-functional requirements. Policies applied to services and references are called interaction policies. Policies attached to a component are called implementation policies. Whereas interaction policies affect the form of the interaction between services, implementation policies affect the way a component behaves to its runtime container. All policies in SCA are realized using WS- Policy [24]. A second approach are intents, which represent requirements at an abstract level, without having to define concrete policies. Intents allow to define QoS (Quality of Services) at an early stage of development. The policy framework is part of the complete picture, but there is no need to discuss details within this thesis Variability Descriptors The idea of variability description is a concept which was first used in product line engineering [21]. Within this, variability points are used to describe the needs of different customers or third party software. In respect to this variability, different versions of the software are implemented. For this thesis variability descriptors are needed in the context of SaaS applications. They are used to describe the parts which can be configured on a per tenant basis. A method how this can be achieved for any file within a SaaS application package is described in [16]. For the comprehension of this thesis a detailed description of this concept is not needed. Therefore, only the most important facts are mentioned. Requirements on a Variability Descriptor Variability points mark the parts where customization is needed and allowed. There is a method to constrain variability points. Dependencies between variability points can be described. The order in which variability points must be bound can be described. Variability Descriptors for XML based Files To locate a variability point in a file, there are so called locators in use. Depending on the type of a file, an appropriate locator has to be used. In [16] a locator for XML files that is based on XPath expressions is introduced. The different possible values of a variability point are called alternatives. Many different modes for alternatives exist. For example they can be explicitly defined (explicit 18

25 2 Basics alternative) or they can be defined by pointing to another part of the same or different document (expression alternative). Dependencies can be used to describe the relation between variability points. Furthermore enabling conditions describe which requirements must be met to choose a particular alternative. Figure 2.4 illustrates the annotation of XML based files with variability points. Figure 2.4.: Variability Descriptors [16] 2.5. Multi-Granularity Flows In this thesis the notion of a customization and a provisioning flow is used. Both are so called multi-granularity flows. A multi-granularity flow is a high level business process, which is used to orchestrate business services to realize a particular business goal [19]. Business services can be implemented in traditional programming languages or by a sub-process. To implement a process workflow execution languages such as BPEL can be used. The particular services represent single steps to complete a certain task. In this thesis provisioning flows support the deployment of SaaS application packages. The single steps of a customization flow are used to configure an application, file, etc. 19

26 2 Basics The customization flow is utilized by a user that makes the configuration decisions. For example such a flow can be used to fill the variability points in a variability descriptor [16]. 20

27 3. SaaS Application Packages As stated in the introduction, [20] describes how the Service Component Architecture can be used to create SaaS application packages. The first and most important point is to define, which element of the SCA assembly is used to describe an application package. In this thesis (see [20]), an application package equates to a SCA contribution. For being able to create multi-tenant aware packages, the components of all deployable composites of the contribution are annotated with the multi-tenancy patterns described in The ability to configure a package is provided by the use of variability descriptors. Variability points can be set in every XML based artifact of an application package. So variability points can be set to allow a tenant to configure the multi-tenancy pattern used for the deployment of a component, too. The following section describes how the packages are built and which constraints must be considered Evolution of a Package In [20] two stages in the evolution of a package are described. In the first stage a package is called application template. This package is provided by the application vendor. A template package is ready to be configured for a certain customer. After it is configured, the template turns into a solution. Below these two stages are described and illustrated in detail Template In the first stage an application package is called a template. For a template all components of all deployable composites must be annotated by a multi-tenancy pattern. Furthermore all necessary variability points must be set. But they are not yet filled with concrete values. 21

28 3 SaaS Application Packages Figure 3.1.: Template Package Solution A template, where all variability points are filled with concrete values, is called a solution. The solution is the final stage in the evolution of an application package. It is ready for the deployment by a provider. The following figure illustrates the evolution of a package, starting from a template, to a solution. Figure 3.2.: Solution Package 22

29 3 SaaS Application Packages 3.2. Modeling Restrictions Theoretically every SCA application can be transformed to a SaaS application package. What needs to be done, is to apply multi-tenancy patterns and to enable the ability to configure the application by the use of variability points. Though by taking a closer look, several restrictions occur. In this section the restrictions are enumerated and explained. First, not every component description or component implementation within an application package is allowed to be customized. This is due to the different multi-tenancy patterns. The following table shows, which artifacts are allowed to be configured depending on the multi-tenancy pattern of a component. Pattern Component Description Single Instance % % Multiple Instances D D Single Configurable Instance D % Implementation Table 3.1.: Restrictions on the Modification of Component Description and Implementation, dependent on the Multi-Tenancy Pattern Wiring Single instance components are only allowed to have references to other single instance components. This is due to the fact, that these components run without any tenant context. However single instance components can be forced by their implementation to call a context dependent component. Therefore, the context must be supplied together with the invocation of the single instance component. For some URI schemes it might not be possible to generate a tenant dependent URI. In these cases the URI must be specified per tenant by the use of a variability point. More details on the background of this is discussed in chapter Single Configurable Instance Components A single configurable instance component implies that there is only one instance of the component. Therefore, it is not allowed to modify the service element. This is due to the 23

30 3 SaaS Application Packages fact, that the service element is required to provide endpoints for all components that call this single instance. No new endpoints can be added or removed after the instance was created. The configurable parts of a single configurable instance component are: component references properties external configuration files which are used by the component implementation Configuration of non-xml based Implementation Files For every type of file format a separate mechanism, which allows to set variability points, has to be developed. For example Java class files do not allow to be the target of a variability point. For those files, it is impossible to customize the implementation directly. To manage this problem SCA properties can be used. The developer defines a property by the means of SCA. Afterwards a variability point has to be set to the property value defined in the composite file Customization of Implementation Files that are used for several Components When an implementation or configuration file is shared between multiple components, special restrictions must be maintained. All components that use such a file automatically have to use the same configuration. With the customization, the developer has to overlook the changes for all concerned components. So it is better to disallow the configuration of implementation files that are used in multiple single instance or single configurable instance components Customization of the Multi-Tenancy Pattern There are restriction for the customization of the multi-tenancy pattern. This means, that not every pattern type is allowed to be changed to any another type on a per tenant basis. All customizations are possible under certain circumstances but some are not useful. The following list discusses the effects of a change of the pattern type by the use of a variability descriptor. 24

31 3 SaaS Application Packages Single Instance Single Configurable Instance This customization is allowed, but not recommended. A configurable instance can be created which is used by all tenants that want the component to be a single configurable instance. This approach is not favorable, since the component should have been tagged as a single configurable instance at first, if some tenants might need to configure it. So the meaning of a single instance component is violated. Furthermore two instances are created. If the component was tagged as a single configurable instance component from the beginning, there would be only one instance. Single Instance Multiple Instances This customization is allowed and can be useful. A separate instance, for every tenant that decides the component to be multiple instance, is created. This can be useful, if a customer does not want to share an instance with other customers. For example such customers may have security concerns. Furthermore it is not encouraged to customize the description or the implementation of such a component. This would violate the meaning of a single instance component. Single Configurable Instance Single Instance This customization can be allowed when a default configuration is supplied, but it is not recommended. Tenants who want the component to be single instance can simply use the same instance like the other tenants, but with the default configuration. This modification is not encouraged since there is no benefit. Single Configurable Instance Multiple Instances This customization is allowed. A separate instance for every tenant that decides the component to be multiple instance can be created. Again, this can be useful, if a customer does not want to share instances with other customers. Furthermore it is not recommended to modify the implementation of such a component, because this would violate the meaning of a single configurable instance component. Multiple Instances Single Instance This customization can only be allowed, if the regarding component has no references to other components which depend on the configuration of a tenant. This must be ensured, because the tenant context is lost along with the modification. Furthermore all tenants that decide the component to be single instance, must be forced to use the same (default) configuration for the components description and implementation. When this applies, 25

32 3 SaaS Application Packages the customization can be useful, because several tenants can share one instance. So less instances have to be created. Multiple Instances Single Configurable Instance This customization can be allowed, if all tenants that decide the component to be a single configurable instance component are forced to use the same (default) implementation. When this applies, some tenants can share an instance and less instances need to be created. Example: A component is implemented by a BPEL file which represents a business process of the customers company. The component is defined to be multiple instances, because every customer may need to supply his own process and therefore his own implementation. If a customer does not need a custom process, he can decide the component to be single configurable instance and therefore, share its instance with other customers Modeling of Wires As stated in the introduction of the Service Component Architecture, the wires between components can be described by different methods. In every case, the way how the components interact is defined via binding elements. They need to have a unique URI. For a SaaS application, multiple instances can be created of the same component. So not every instance can use the URI which was defined for a binding in the composite file. In 4, it can be seen, that a unique URI is created for every instance. Though the URI defined in the composite file can be used as the basis for the generation process. According to section we can name three different ways to define the URI of a SCA binding. The adequacy of each of this methods is different for the different types of multi-tenancy: Combined Hierarchical URI The URI attributes of the component or the service binding are not defined absolutely. A complete hierarchical URI can be derived from the names or the URI attributes of component and service. This way the modeler can dispose the complete form of the URI to the system which runs the application. This method is encouraged to be used for multiple instances components. It is easy for the system which runs the component to derive a unique URI for every instance. Furthermore services of single instance and single configurable instance components can be defined using this method without any problems. 26

33 3 SaaS Application Packages Absolute Hierarchical URI An absolute hierarchical URI is specified via the URI attributes of component or binding. By specifying an absolute URI, the modeler wants to force the system to use a certain URI for a binding. For single instance or single configurable instance components it is no problem to use a certain URI. For multiple instances components the absolute URI cannot be used. The system which runs the component will have to generate a different new URI for every tenant. Therefore, it is not encouraged to use an absolute URI for a binding of a multiple instances component. Absolute non-hierarchical URI An absolute non-hierarchical URI is specified via the URI attributes of component or service binding. This can be necessary, since some bindings only allow non-hierarchical URIs. Like for absolute hierarchical URIs the use of non-hierachical URIs is not encouraged for multiple instances components. If no other binding can be used, the runtime has to try to generate a unique URI from the given non-hierarchical URI. 27

34

35 4. Deployment Strategies A provider that allows the deployment of application solutions, as described in 3, must facilitate the deployment of any amount of packages. Some packages are occurrences of the same application, but are configured for different tenants. This comes along with several challenges for the deployment process. In this section the problems are discussed and as a solution, strategies are introduced which can be used for the deployment on any platform. The section ends with a detailed description, on how the packages can be modified to allow the deployment on a SCA engine Challenges for the Deployment Process The SaaS model described in this thesis allows a customer to decide whether he needs to share an instance of a component or not. Therefore, for every new customer who likes to run an application, possibly many new instances of components have to be created. It would be very unsatisfying to force the configuration of a new endpoint and therefore, the configuration of the service element of any new instance. Because of this, a method has to be introduced that allows the automatic modification of the SCA services. Certainly the wiring between the components of the application must be conserved. Another challenge comes along with component instances that are configurable on a per tenant basis. When such an instance is called, there is the need to know which configuration to use. To facilitate this, a method has to be defined that allows to supply the tenant context. Figure 4.1 illustrates the additional information needed to call a certain kind of component. The information is displayed on the arrows that point to the components. In summary there are two main problems to face: How to decide which instance of a multiple instances component must be called. How the configuration data for single configurable instance components can be supplied. 29

36 4 Deployment Strategies Figure 4.1.: Requirements for Component Calls, dependent on the Multi-Tenancy of the Component 4.2. General Deployment Strategies In this section a general deployment strategy is described. It allows the deployment on any platform. Especially solutions for the two problems stated above are introduced. As a basis for the deployment, the general composite file that was annotated by multi tenancy patterns is used. The composition of all components which make up an application for a customer is established via this file. So it is possible to prepare it before the first component is deployed. The result is a composite file that allows the deployment of the components for a specific tenant. The whole process can be divided into two stages: Figure 4.2.: Two staged Deployment Process Preparation In the preparation step, the general composite is modified to reflect the assembly for a specific tenant. In the following, all steps which are necessary to adapt a composite for a specific tenant are described in detail. For every type of component different preparation steps have to be executed. Since a package is allowed to have several deployable composites, each of these composites has to be prepared. 30

37 4 Deployment Strategies Single Instance Components The bindings and the according URIs which make up the service element of the component can be used for the deployment without any modification. This is due to the fact, that the component will only be deployed once and all tenants will use the same instance. Multiple Instances Components A separate component is deployed for every tenant. Certainly one cannot use the same binding URIs for every instance. So unique URIs have to be created in respect to the way the modeler intended the components to be connected (see 3.3). Examples for the generation of a unique URI: A possible composition for a hierarchical URI is to add a tenant identifier to the implicit URIs as described in An URI created this way has the following buildup: Base System URI / Component URI / Service Binding URI / Tenant ID Certainly non-hierarchical URIs have to be modified too. Therefore, for every schema special modification rules have to be defined. For example an URI using the mailto schema could be modified from mailto:name@domain.de to mailto:name.tenantid@domain.de. A lot of other ways to create unique URIs for every tenant are possible. But the assembly of the URIs is less important for this approach. And therefore, is not discussed any further. The wiring between the components needs to be obtained after the modification of the URIs. All references of other tenant specific components which either point to a modified service via a target attribute or a wire must be set too match the according service element. Figure 4.3 illustrates this step. 31

38 4 Deployment Strategies Figure 4.3.: Process to set the SCA Service of a Multiple Instances Component By this preparation steps the first problem stated above is solved. Every tenant specific component is configured to call the instance of the multiple instances component which is deployed for the same tenant. Single Configurable Instance Components Only one instance of a single configurable instance component will be deployed, but it must be configurable on a per tenant basis. Therefore, a method has to be introduced which handles the configuration of the component. In this approach a wrapper is used that receives all requests which were originally directed to the component. Then the wrapper retrieves the correct configuration data from a configuration repository which stores the configuration data for every tenant. In the next step, the wrapper configures the instance and redirects the request. The only problem that still exists, is how the wrapper can decide, which configuration data it has to use. A simple approach to solve this problem is to provide a separate endpoint for every tenant. To achieve this, a tenant context router is introduced which adds a tenant identifier to a request. A separate version of this router is created for every tenant. So the tenant context of a component is identified by the endpoint of the router it calls. Like for the multiple instances components, all references of components that need to call the single configurable instance must be updated to call the appropriate router instead. Therefore, the router needs to support all bindings of the original component. Certainly, again a unique URI for every router has to be generated. This can be achieved by the methods described for the multiple instances components. Figure 4.4 illustrates the composition after the deployment of a single configurable instance component. 32

39 4 Deployment Strategies Figure 4.4.: Assembly of a deployed Single Configurable Instance Component With the introduction of this concept, the second problem stated above is solved. So after the whole preparation process, a tenant specific composite has the following attributes: The service binding URIs of all multiple instances components are unique. The references pointing to multiple instances components are set to the URIs that were created for the specific tenant. The references which were pointed to a single configurable instance service, now point to a tenant context router. This router calls a wrapper that invokes the component, using the correct context Deployment The deployment of a package which was prepared as stated in can be achieved by the generation of a provisioning flow. The flow handles the deployment of every single component. No special order has to be followed when the components are deployed, so the buildup of the provisioning flow is variable. In this approach, the flow calls services which are used to handle the deployment of a certain kind of component. There have to be three different services: A single instance, a multiple instances and a single configurable instance deployment service. Each of this services has its own functionality. SCA allows to use many different implementation and binding types. So there has to be a separate deployment facility for every combination of implementation and binding. To handle this problem, different implementation specific services can be used. These services can be called by the different pattern specific services (see figure 4.5). If a component has multiple bindings, it has to invoke multiple implementation and binding specific services. 33

40 4 Deployment Strategies So in summary a pattern specific deployment service has to execute several pattern specific functions. Afterwards it invokes the implementation and binding specific deployment service which fits for the component it has to establish. To facilitate this, the pattern specific deployment services can be implemented by a provisioning flow, too. In the following the buildup of such a provisioning flow is described for every type of deployment service: Deploy Single Instance The service checks if an instance already exists. If there is no instance yet, the correct implementation and binding specific deployment services are called. Deploy Multiple Instances Every multiple instances component is deployed without the need for any examination. It is adequate to call the correct implementation and binding specific deployment service. Deploy Single Configurable Instance The deployment service checks if an instance of the component is already deployed. If no instance exists the component is deployed along with a wrapper. In any case an appropriate tenant context router is deployed. Figure 4.5 shows the process which is passed to deploy the components of a composite file which was prepared as described in the preparation step. 34

41 4 Deployment Strategies Figure 4.5.: Deployment Process based on a prepared Composite File 35

42 4 Deployment Strategies 4.3. Deployment on a SCA Engine Because the Service Component Architecture is used to describe the services which make up the SaaS applications in this thesis, it is obvious to search for a way to deploy the packages on a SCA engine. Certainly less steps are needed. The engine handles implementation and binding types automatically. Though the ideas stated for the general deployment strategies can be used. The problem which has to be solved, also for the deployment on a SCA engine, is how the engine can be forced to provide the components according to their multi-tenancy pattern. A possible solution for this problem is presented in [20]. The parts of an application which can be shared between multiple tenants, can be separated from the parts that have to be deployed for every tenant separately. The results are two different SCA compatible packages, which both can be executed by a SCA runtime. This section introduces the method described in [20], along with another approach which is used for the implementation of the prototype Preparation As for the general deployment strategy, it is necessary to make sure that different instances of the same component are distinguishable. Since the SCA engine manages the generation of the binding URIs, the composite has to be modified in a way, that different URIs for different instances of a component are automatically generated. A distinction between combined and absolute URIs is necessary. Combined URI Since the component name is used to assemble the URIs of the bindings, it is sufficient to rename the component or the components URI, if there is one defined. For example for every tenant an identifier can be added to the name of the component. Absolute URI As stated in the preparation steps for the general deployment strategy, a special modification method has to be defined for every schema used for an absolute URI. The generation of such URIs is not discussed, since it is not important for the further approach. 36

43 4 Deployment Strategies Fixed and Tenant Specific Package For every artifact in a solution package, a decision has to be made. Either it is required only once and can be used by all tenants at the same time, or it is needed separately for every tenant. Furthermore the same decision has to be made for the description of a component in the deployable composite files. To separate the artifacts, two different packages are introduced: The fist type is a fixed package which holds the artifacts and descriptions of components which can be shared among several tenants. The second is called tenant specific package. It contains the parts that are necessary for every tenant in a different version. The following table shows the breakup for the different types of components: Multi-Tenancy of the component Storing of the component description Storing of the implementation files Single Instance Fixed Package Fixed Package Multiple Instances Tenant Specific Package Tenant Specific Package Single Configurable Instance Tenant Specific Package Fixed Package (Configurations in Tenant Specific Package) Table 4.1.: Separation of Component Description and Implementation Files When there is a Fixed Package required Since a fixed package contains components and files that are shared amongst multiple tenants, it is not necessary to create a fixed package every time a tenant specific package is created. In fact, a fixed package is only required when the new customer, for whom a solution is created, declares a component to be single instance or single configurable instance. Furthermore this component must not be declared to be single instance or single configurable instance by any other customer before. This especially applies for the first customer that creates a solution from an application template Separation via Composite Implementation In the next step the wiring of components between the tenant specific and the fixed package needs to be obtained. 37

44 4 Deployment Strategies One way to connect the components of a tenant specific package to the components of a fixed package is to use the composite implementation feature of SCA. This method is described in [20] and can be summarized as follows: A new composite file is created for the single instance components of the fixed package. In this composite, a promoted service is created for the services of each component that must be called from another package. References do not have to be promoted, since it is not allowed for single instance components to have references to non-single instance ones. Afterwards a so called virtual fixed component is created in the tenant specific package. It is implemented by the newly created composite of the fixed package. The virtual fixed component is added to every deployable composite within the tenant specific package. References which used to be connected to a service in a fixed package, are connected to the appropriate service of the virtual fixed component instead. The implementation files for single configurable instance components and the composite implementation of the virtual fixed component must be visible in the tenant specific packages. Therefore, appropriate import and export statements must be added to the contribution descriptors of the packages. No concrete statement can be presented here. It is up to the runtime implementation to define them. The following figure illustrates the connection of the fixed and the tenant specific package via the composite implementation feature. Figure 4.6.: Separation of Tenant Specific and Fixed Package via Composite Implementation 38

45 4 Deployment Strategies Separation via Include Another way to separate parts of a composite is provided by the include element of SCA. In this approach two composite files are created, too. One file which contains all components that belong to the tenant specific package. And another file that belongs to the fixed package. Afterwards the two composites will be included in one composite that makes up the application. No special dispositions have to be made to obtain the wiring between the components, since the include statement has the semantic of a textual inclusion. As stated in the introduction of SCA, all composites of a domain are included in one virtual domain composite. Therefore, no concrete composite has to exist that includes the components from the tenant specific and the fixed package. This step is implicitly accomplished via the virtual domain composite. As for the composite-implementation method, all artifacts that are required in the tenant specific package, but reside in the fixed one, must be made available. This is accomplished via import and export statements in the contribution descriptor. The next figure illustrates the separation via the include statement. Figure 4.7.: Separation of Tenant Specific and Fixed Package via Include This approach is used for the implementation of the prototype. In the following it is described in detail. 39

46 4 Deployment Strategies Handling of other SCA Elements In the include approach the component descriptions are separated into two composite files. Some SCA artifacts are directly associated with a component and should therefore be stored in the same composite. The elements which are directly associated to a component are: Promoted services Promoted references Definitions like property types or constraining types are always stored in a fixed package to avoid their duplicate inclusion into the domain composite. Wires that connect components within the fixed composite are stored over there too. Again to avoid a duplicate inclusion. All other wires which cross composite borders can be stored in either composite. Although it would be more clear to store them in a tenant specific composite file Handling of Implementation Files As shown in table 4.1, the implementation files of a component can either reside in the tenant specific or in the fixed package. To be able to know which files must be stored in which package, one has to know which implementation files belong to which components. SCA does not provide a method to describe this connection. Therefore, a new XML based file is introduced. It is called implementation mapping file. The file must be stored in the same path as the contribution descriptor. The schema of this file is as follows: Listing 4.1: Schema of an Implementation Mapping File 1 <xsd : schema xmlns : xsd =" http :// org /2001/ XMLSchema "> 2 3 < xsd : element name =" implementation - mapping " type =" ImplementationMappingType "/ > 4 5 < xsd : complextype name =" ImplementationMappingType " > 6 <xsd : sequence > 7 < xsd : element name =" mapping " type =" MappingType " minoccurs ="0" maxoccurs =" unbounded "/ > 8 </ xsd : sequence > 9 </ xsd : complextype > < xsd : complextype name =" MappingType " > 40

47 4 Deployment Strategies 12 <xsd : sequence > 13 < xsd : element name =" implementation " type =" xsd : string " minoccurs ="0" maxoccurs =" unbounded "/ > 14 < xsd : element name =" configuration " type =" xsd : string " minoccurs ="0" maxoccurs =" unbounded "/ > 15 </ xsd : sequence > 16 <xsd : attribute name =" component " type =" xsd : string "/ > 17 </ xsd : complextype > </ xsd : schema > There is a mapping element for every component. In this element two kinds of files are listed. The implementation element is used to map a file to any type of component. The configuration file is only used for single configurable instance components. This element is used for property files that are used to configure the implementation. Both types of elements contain the relative path to a file within the package. To make the creation of the file easier, folders can be named instead of files. In this case all files in the stated folder are associated with the particular component. Naturally the same files can be associated with different components. The following table shows, where the implementation files have to be stored dependent on the pattern of the associated component. The restrictions that come along with this proceeding are already stated in 3.2. File usage Used in several single instance components Used in several multiple instances components Used in several single configurable instance components Used in single instance and multiple instances components Used in single instance and single configurable instance components Used in multiple instances and single configurable instance components Location of the implementation files fixed package tenant specific package fixed package (configuration files in tenant specific package) fixed package (files must be imported in tenant specific package) fixed package (configuration files in tenant specific package) fixed package (files must be imported in tenant specific package) Table 4.2.: Assignment of the Implementation Files on the Tenant Specific and Fixed Package 41

48

49 5. Prototype The main task of this thesis is to support the development of a prototype which allows to build SaaS application packages using SCA. Furthermore it has to support their deployment on a SCA engine. For the prototype some existing software artifacts and tools are used and some new are created. The result is a complete system which allows to build and deploy SaaS packages which all share a common platform. In a real world scenario, this platform would be shared among several providers. So it would be possible to choose a provider for a SaaS application, like a provider is chosen to host a website today. The following section describes the prototype and the software artifacts which had to be created. The implementation of the customization and provisioning flow is not part of this diploma thesis. The methods which provide the ability to configure XML based files are part of another thesis [9]. The provisioning flow which connects the different modules is implemented by the supervisor of this thesis Architecture Overview To understand the particular modules of the prototype, it is important to understand the complete picture. Figure 5.1 shows the process an application package passes from its creation to its deployment. A textual description of the different steps follows. (1) The developers create a SCA application using the customized editor. The editor is a part of this thesis (see 5.2). They also use the editor to annotate the components of the application with multi-tenancy patterns. (2) The developers create variability points for the XML based files of the application. This describes the configuration options, the customers of the application will have. The result of this step is an application template (see 3.1.1). (3) A developer saves the template to the repository of the package deployer. The repository is realized using the file system. Therefore, a new folder with the name of the application is created. All files of the template are copied into this folder. 43

50 5 Prototype Figure 5.1.: Prototype Overview (4) With the variability descriptor created in step two, a customization flow is generated. This flow is implemented as a BPEL process. The generation of the process is part of another diploma thesis [9]. (5) The customer uses the customization flow to configure the application for his needs. The customization process is provided by a web interface. The result of this step is a XML based modifications file which contains all files that were adapted during the configuration process. (6) A provisioning flow is started which handles the deployment of the application on the SCA engine. The provisioning flow is implemented in BPEL and does not need any adoption. The same process can be used for every package. The provisioning flow uses the Web service interface provided by the package deployer. The package deployer is part of this diploma thesis. It allows the creation of a tenant specific and a fixed solution package as described in 4.3. Furthermore there is the possibility to deploy and 44

51 5 Prototype run the packages using a SCA engine. The SCA engine used for this prototype is apache tuscany. In more detail a special form of a SCA domain, the tuscany distributed domain (see ) is used. Later in this document the deployment process is described in detail. (7) In the next step the provisioning flow calls the package deployer to create a solution. It passes the template and the modifications file as parameters. (8) The tenant specific and the fixed package are now deployed to a tuscany domain. In order to run the packages, tuscany nodes have to be started. This process is described in detail in section (9)+(10) In order to launch the tuscany nodes for the created packages, the tuscany domain manager has to be started. To achieve this, a domain manager launcher is called which allows to start a domain manager via a Web service interface. The domain manager launcher is part of this diploma thesis. (11)+(12) In the final step the package deployer is called to create a tuscany node for the tenant specific and the fixed package. The application is now ready for usage. Removing an Application Certainly there must be a method to stop, undeploy and delete an application from the repository. Therefore, the package deployer can stop a tuscany node and undeploy the package from the tuscany distributed domain. If the solution is not needed anymore, the package deployer provides an operation to delete the solution of a certain customer. Templates can be removed manually from the repository. 45

52 5 Prototype 5.2. Editor One task for this thesis was to extend an existing SCA editor to support the creation of the SaaS application packages. In the following this editor is described in detail. There is only one nameable open source SCA editor today. The editor is part of the eclipse STP Project [12] (SOA Tools Platform) and therefore, realized as a plugin for the eclipse platform. This is obvious because the eclipse platform also allows the creation of implementation files like Java classes and interfaces or even BPEL processes, if the appropriate plugins are installed. So all files needed for an application package can be managed in one eclipse project. The STP Project combines different tools which support the creation of a SOA based environment. Other tools of the STP project for example allow the modeling of BPEL processes or WS-Policy content. Detailed information on the SCA Editor can be found on its website [11]. The editor allows the visual modeling of SCA composites. Therefore, the same illustration as in the SCA specification is used. The program is under the eclipse public license version 1.0. So the modification of the editor is no problem. The source code can be downloaded from a svn repository. The editor is mainly developed by two people as a community service. So a perfect editor can not be expected, which is already appropriate for production use. Though nearly everything stated in the SCA specification can be modeled. The only valuable part that can not be modeled are contribution descriptor files. For these files another editor has to be used that allows to model any XML file. Since the editor is still under development it is not appropriate to enumerate the features that still need tuning. In fact an important point for the extension of the editor is to be able to easily adopt the added features to new releases of the original editor. Figure 5.2 shows an overall view of the editor window. 46

53 5 Prototype Figure 5.2.: Overall View of the Editor Requirements As a first step the requirements for the editor are fixed. The following table enumerates the requirements and compares them with the results achieved by the implementation. Requirement The editor has to support the modeling of a SCA assembly. It must be possible to annotate the components with the multi-tenancy patterns described in The pattern of a component must be reflected in its shape. Implementation The editor supports the modeling of a SCA assembly, but still has some problems, so it can be necessary to adopt the composite files by hand. The components can be annotated by choosing a pattern in the properties view. Different types of shapes are used for each pattern. Table 5.1.: Requirements for the Editor 47

54 5 Prototype Utilized Technologies In the following the different technologies which are used for the implementation of the editor are described. For the extension no new technologies are added but the existing ones are used in an appropriate way Eclipse Modeling Framework The Eclipse Modeling Framework is a Java framework which allows the developer to concentrate on the application model instead of implementation details. Therefore, EMF allows to generate Java classes from a range of input formats. Using this classes, a model can be instantiated, modified and serialized to different formats. Possible input formats are for example UML (Unified Modeling Language) models or XML schema files. Every input format is transferred to an intermediate format, an ecore file [10]. Since the ecore format represents the base for the generation process, it can be more direct to modify the ecore files instead of the source files. Naturally, the XML schema files from the SCA specification are used for the SCA editor. The creators of the Eclipse Modeling Framework provide some plugins which make the generation of an ecore model easier. Furthermore an editor for the modification of an ecore model is available. These plugins were used for the extension of the editor Graphical Modeling Framework The Graphical Modeling Framework (GMF) allows the generation of a visual editor for an ecore model. To start the generation process, some files must be available: An ecore file that describes the model for which an editor is created. A mapping file which maps the elements of the model to the visual elements of the editor. And a tool file which describes the tools needed for the modification of the model. Since the creation of the mapping and tool files is a simple process, GMF allows a very fast development of visual editors. Furthermore new features can be added very easily. The developer simply has to modify the source files and to regenerate the editor Modifications This section describes the modifications which are necessary to implement the required features. 48

55 5 Prototype Ecore Model In the ecore model, the representation of the SCA component is modified to support the new pattern attribute: Attribute Name Possible Values Default value pattern SingleInstance, MultipleInstances, SingleConfigurableInstance SingleInstance Table 5.2.: The new Pattern Attribute After this modification, the editor allows to model components that contain a pattern attribute. The following listing shows a component description tagged with the multiple instances pattern. Listing 5.1: Component using the Multiple Instances Pattern 1 < component name =" ShoppingCart " pattern =" MultipleInstances " > </ component > Changing the Pattern Certainly the user needs the possibility to change the pattern of a component, without having to modify the source code. Therefore, the facility to change the pattern via the properties view of a component was arranged. Figure 5.3 shows the properties view after a component is selected in the main window. 49

56 5 Prototype Figure 5.3.: Choosing a Multi-Tenancy-Pattern Visual Representation of the Multi-Tenancy Patterns To understand the assembly of an application, it is important to recognize the pattern of a component at the first blush. Therefore, a different component shape is used for the different patterns. The shape changes, when another pattern is selected in the properties view. Figure 5.4 shows the different component shapes. The shapes were designed to be similar to the illustrations used in [20]. Single Instance Multiple Instances Single Configurable Instance Figure 5.4.: Shapes of the different Multi-Tenancy Patterns 50

57 5 Prototype 5.3. Package Deployer The main implementation effort during this thesis is spent on the implementation of the package deployer. It is the main program which facilitates the creation of application solutions and their deployment. The biggest challenge was to find a method to automatically deploy the application packages to a tuscany domain. Since tuscany has a very lively community, the source code of the appropriate modules changes very often. So the package deployer had to be adapted to new possibilities multiple times. The method which is used for the deployment and execution is described in detail in this section. For communication purposes a Web service interface is provided. The requirements for this interface were fixed at the beginning of this thesis. Another challenge is the modification of the XML based SCA files. Since there are many dependencies between the elements of such a file, a data binding should be used. The different approaches that were taken into account are described in this section. The technical basis of the package deployer is provided by apache tomcat and apache axis 2. Therefore, the package deployer is distributed as a WAR file. A web interface (see E) and a test client (see F) are created to be able to test the package deployer Requirements Requirement The package deployer must be able to run solution packages on a SCA engine. A Web service interface should be provided to facilitate the deployment. A modifications file must be processed to apply the configurations of a tenant. Components must be deployed according to their multi-tenancy pattern. All packages must be stored in a repository. There must be a way to undeploy a package. Implementation The package deployer uses the tuscany distributed domain to run the application packages. The package deployer is realized as a Web service with a SOAP/HTTP binding. The package deployer provides a parameter which accepts the content of a modifications file. The package deployer creates a tenant specific and a fixed package, according to the method described in The package deployer uses a directory in the file system as the repository. The Web service interface provides operations to undeploy a package. 51

58 5 Prototype The application should run on apache tomcat 5.5. The application runs on apache tomcat 5.5 and 6.0. Additionally apache axis 2 must be installed. Table 5.3.: Requirements for the Package Deployer Utilized Technologies For the implementation of the package deployer many different technologies are utilized. Naturally the most important technology to understand is apache tuscany. In this section it is explained in detail. Special attention is drawn on the possibility to create distributed domains. Afterwards the other technologies and tools which are used for the implementation are presented Apache Tuscany Tuscany [8] is the most accepted SCA engine at the time this thesis is created. It also comes in handy, that tuscany is an open source project. So the code can be used to improve the comprehension of a SCA runtime. Although tuscany is under agile development, some features of SCA are not completely implemented yet. For the execution of different component implementations, tuscany utilizes other apache projects. To execute a BPEL process for example, the apache ODE engine [6] is used. Web services are realized via apache tomcat and axis. Tuscany implements the SCA specification in the version 1.0. It is a very lightweight engine, so it can be easily distributed along with a SCA application. Two different implementations exist. One implementation is written in Java, the other uses C++ as programming language. The C++ implementation is also referred to as native. For this diploma thesis solely the Java implementation was used. This implementation provides two different kinds of SCA domains. A domain which runs on a single JVM (Java Virtual Machine). And a domain, that is distributed over several JVMs. These two options to create a domain using tuscany, are described in the following. Tuscany Node In order to understand the assembly of a SCA domain in tuscany, the concept of a node has to be understood. In tuscany, the runtime which allows to run a SCA application, is always wrapped up in a node. A node therefore contains all functions that are needed to run a SCA composite. These functions are provided by the files in the libs and modules folders of a tuscany distribution. 52

59 5 Prototype In tuscany a node always runs a single composite which runs in a single JVM. A JVM on the other hand, can host multiple nodes. So a tuscany node represents a self-contained application which can be started independently from other nodes. This concept gets more comprehensible, by understanding, how it is used in a standalone and a distributed domain. Standalone Domain To realize a standalone domain, only one node is used. This node executes the most outer composite of an application. Figure 5.5 illustrates the assembly of a standalone domain. The picture shows a calculator application which is distributed as a sample with every tuscany distribution. Each operator of the calculator is managed by a separate component. To start the standalone domain, commonly a Java client program is used. The following listing shows a short Java code snippet which is used to start a domain. Listing 5.2: Client to start a SCA Domain 1 import org. apache. tuscany. sca. host. embedded. SCADomain ; 2 3 public class Client { 4 public static void main ( String [] args ) throws Exception { 5 6 // start the domain 7 SCADomain scadomain = SCADomain. newinstance (" Sample. composite "); 8 9 //... use the application 10 SampleService sampleservice = 11 scadomain. getservice ( sampleservice. class, " SampleServiceComponent "); sampleservice. execute (); // stop the domain 16 scadomain. close (); 17 } 18 } In this code snippet, a number of functions that use the newly started SCA application are called, after the domain is started. At the end the domain is stopped. Certainly it is possible to run a standalone domain without having to stop it instantly. Furthermore not every service is needed to be called from a Java program, like in this example. For instance, one can think of a service that provides a web interface which is called using a web browser. Another method to start a standalone domain, is to create a web application for apache tomcat that runs a tuscany node. 53

60 5 Prototype In summary a standalone domain uses the same concept of a node that is used for the distributed domain. But in this special case, the node is not connected to any other node and therefore represents the whole application. Figure 5.5.: Example of a Standalone Domain [8] Distributed Domain The SCA specification does not provide a detailed description on the way, SCA applications can be distributed over several hosts. Therefore, the distributed domain is a tuscany specific function. Nevertheless it was chosen to be used for this prototype. The advantage of this approach is, that the execution of the application packages which are created by the package deployer, can be distributed to several hosts (see 5.5). In a distributed domain, not only one node is used. In fact several nodes build the domain, where each node again runs a single composite. These composites are not needed to be complete. The application is build up by the domain composite which includes all the composites that make up the application. In the 54

61 5 Prototype case of the tuscany distributed domain, the domain composite is not a virtual composite, but is stored in a concrete composite file. For the administration and the interconnection of the nodes, a domain manager is used. So a distributed domain enables the distribution on the level of components by portioning them to several composites. Figure 5.6 shows the same application as the picture for the standalone domain. In this case the add and subtract operator are distributed to separate nodes. Figure 5.6.: Example of a Distributed Domain [8] Domain Manager In order to understand the assembly of a distributed domain, it is necessary to understand the domain manager. It is used to start and interconnect the single nodes. The information needed by the domain manager is stored in two main composite files. The domain composite which includes all composite files that make up the applications and a cloud composite which is used to interconnect the different nodes. To be included to the cloud composite, a node has to be described by a special node composite file. To locate the files of a contribution, a workspace file is used. 55

62 5 Prototype To ease the comprehension, listings of the different files are presented in the following. These files are used to run the calculator application which is shown in figure 5.6. Domain Composite The domain composite includes all composite files that make up the application. represents the virtual domain composite, described in the SCA specification. It Listing 5.3: Domain Composite File 1 < composite name =" domain. composite " targetnamespace =" http :// tuscany. apache. org / xmlns / sca /1.0" > 2 < include name =" ns 2: CalculatorA " uri =" nodea "/ > 3 < include name =" ns 2: CalculatorB " uri =" nodeb "/ > 4 < include name =" ns 2: CalculatorC " uri =" nodec "/ > 5 </ composite > Node Composite Every node composite file contains exactly one component that uses a special node implementation type. For this implementation type the composite file which has to be executed by the node must be specified. For every node a separate URI has to be assigned. This URI overwrites the base system URIs (see 2.3.6) of all binding URIs. To facilitate this, the nodeuri is specified for every binding type of the node implementation component. The listing shows the composite file for the node which contains the add operation. Listing 5.4: Node Composite File 1 < composite xmlns =" http :// www. osoa. org / xmlns / sca /1.0" 2 xmlns :t=" http :// tuscany. apache. org / xmlns / sca /1.0" 3 targetnamespace =" http :// sample / cloud " 4 xmlns :s=" http :// sample " 5 name =" NodeA "> 6 7 < component name =" NodeA "> 8 <t: implementation. node uri =" nodea " composite =" s: CalculatorA "/ > 9 < service name =" Node "> 10 < binding. sca uri =" http :// localhost :8100"/ > 11 </ service > 12 </ component > </ composite > 56

63 5 Prototype The service of the AddServiceComponent has the following URI: Cloud Composite The cloud composite file includes all node composites. It is used to connect the different nodes that make up an application. Nodes that are not enlisted in the cloud composite, are not accessible from other nodes. Listing 5.5: Cloud Composite File 1 < composite name =" cloud. composite " targetnamespace =" http :// tuscany. apache. org / xmlns / sca /1.0" > 2 < include name =" ns 2: NodeA " uri =" http :// tuscany. apache. org / cloud "/ > 3 < include name =" ns 2: NodeB " uri =" http :// tuscany. apache. org / cloud "/ > 4 < include name =" ns 2: NodeC " uri =" http :// tuscany. apache. org / cloud "/ > 5 </ composite > Workspace Certainly the domain manager needs to have the information, where the contributions are stored. They contain the composite and the according implementation files. Therefore, all contributions must be listed in a workspace file. The following snippet shows the workspace file for the calculator application. Listing 5.6: Workspace File 1 < workspace xmlns =" http :// tuscany. apache. org / xmlns / sca /1.0" xmlns :ns 1=" http :// tuscany. apache. org / xmlns / sca /1.0" > 2 < contribution location =" file :./ src / main / resources / nodea " uri =" nodea "/ > 3 < contribution location =" file :./ src / main / resources / nodeb " uri =" nodeb "/ > 4 < contribution location =" file :./ src / main / resources / nodec " uri =" nodec "/ > 5 < contribution location =" file :./ src / main / resources / cloud " uri =" http :// tuscany. apache. org / cloud "/ > 6 </ workspace > Starting a Domain Manager Like for the standalone domain, the domain manager of a distributed domain can be started via a Java program. The files which build the domain must be stored in the working directory of this program. It is interesting, that the domain manager is implemented using a standalone tuscany domain. 57

64 5 Prototype Tuscany Node Launcher Tuscany provides different ways to launch a node for a distributed domain. The method which is used for the implementation of the package deployer utilizes the domain manager. When a node is successfully established in the workspace, domain composite and cloud composite file, the domain manager provides a so called nodeconfigurationuri. At this endpoint all necessary information is stored, that is needed to start a node. Therefore, a special node launcher program exists that executes a new node only by the specification of this URI. Figure 5.7 illustrates the assembly of a tuscany distributed domain. Figure 5.7.: Assembly of a Tuscany Distributed Domain Apache Tomcat and Apache Axis Apache tomcat [7] implements the Java Servlet [23] and Java Server Pages technology [22]. Today tomcat is used for a diverse range of web applications. And it is employed by many different organizations of different industries. There are special distributions of tomcat for different versions of the Java Servlet and Server Pages Specification. Applications hosted on tomcat are wrapped up in a WAR (Web Archive) file. Besides of the class and resource files which make up the application, a WAR file contains a deployment descriptor that describes the properties and servlets of the web application. To enable the provisioning of a Web service, tomcat is used together with apache axis [4]. Axis implements the SOAP specification and therefore, serves as a Web services engine. It is distributed as a WAR file, so it has to be deployed as a web application in 58

65 5 Prototype tomcat. For the package deployer apache axis version 2 is used. SOAP is a message architecture that enables the communication between Web services. Until version 1.1 SOAP was an acronym for Simple Object Access Protocol. Today SOAP stands for itself. It defines a XML based language that describes a so called SOAP Envelope. The envelope consists of a body element which contains the messages content, and a header that contains properties which define the method used for the communication Web Tools Platform The eclipse web tools platform project [13] is a collection of eclipse plugins. All plugins provide functions to make the development of web or JEE applications easier. For the development of the package deployer the Web services tools of the WTP are used. Besides a WSDL editor and validator, a wizard is provided. It allows the generation of Web services for the use with apache axis 1.4 or 2. There are two methods to create Web services. The fist method is called bottom up. In this approach the Java class which contains the functions of the Web service has to be specified. An appropriate WSDL file is automatically generated. The other method is called top down. In the case of a top down Web service, a WSDL file has to be provided. The WSDL file is then used to create Java classes which contain a function for every operation, specified by the file. Afterwards the developer can implement these functions. Additionally the WTP provides a wizard that allows to create a client that is able to call a Web service. To create such a client, a WSDL file has to be provided. The WTP tool generates stubs that can be used to call the Web service Arrangements for the Implementation This section describes the arrangements that are necessary for the implementation. A possibility to create import and export statements in the contribution descriptor is described. Furthermore, a way to modify composite files and to apply the customizations by the tenants has to be found. At last the repository is introduced which stores the different application packages Import and Export Statements In the SCA specification the import and export facility for the exchange of implementation files between contributions is not described in detail. It is left to the runtime implementation to define the import and export statements. Tuscany defines three different kinds of statements. There is a separate statement for 59

66 5 Prototype Java files, a separate statement for composite files and another one for any other file. The following snippet shows a contribution descriptor that uses all of these three statements. Listing 5.7: Contribution Descriptor using Import and Export Statements 1 < contribution xmlns =" http :// www. osoa. org / xmlns / sca /1.0" targetnamespace =" http :// hello "> 2 3 < export. resource uri =" uiservices / hello. html "/ > 4 < export namespace =" http :// hello "/ > 5 < export. java package =" hello "/ > 6 7 < import. resource uri =" uiservices / world. html "/ > 8 < import namespace =" http :// world "/ > 9 < import. java package =" world "/ > </ contribution > The package deployer needs to add import and export statements to contribution descriptor files. So it is necessary to implement methods to generate these statements. The tuscany assembly model (see ) provides a method to load and save contribution descriptor files. Imports and Exports can be added to the model by specifying the required information. For every type of statement different data is needed. The following list enumerates the statements and explains how the required information is gathered. Resource The resource statement is used for any file except for Java or composite files. For resource imports and exports only the name of the file is required. So no special handling is needed. Java To import or export Java code, the name of the respective package is required. Packages of the class files are unknown to the package deployer. So a method has to be implemented, to read the package names of the class files. To achieve this, apache BCEL (Byte Code Engineering Library) [5] is used. BCEL allows to analyze and manipulate binary Java class files. Amongst other functions, it is able to read the required package name. Namespace For the import or export of composite files, the utilized namespace has to be denoted. The namespace can be read by loading the file via the tuscany assembly model methods (see ). 60

67 5 Prototype Composite Model One task of the package deployer is to modify the files of an application package. Foremost two files have to be modified: composite and contribution descriptor files. The schema for both of them is described in the SCA specification. If one possesses the schema of an XML file, it is unhandy to modify the file without utilizing the schema. In the following, three possible ways to modify the files are considered. JAXP using DOM JAXP (Java API for XML Processing) provides several methods to work with a XML file. A possibility to parse a XML file is provided by the DOM (Document Object Model) interface of JAXP. By the use of this method a complete in memory representation of the document is created. This representation has the form of a DOM-Tree. Its nodes represent the elements and attributes of a XML document. The tree can be traversed and its nodes can be modified. Certainly the DOM representation can be saved back to a XML file. This method works without the utilization of the schema file. Therefore, it is difficult to obtain dependencies between different elements. For example, when a component name is changed, all appearances of this name in target attributes of references have to be changed as well. To achieve this, complex functions would be necessary. Furthermore changes which may destroy the structure of the document are possible. Model of the SCA Editor The creators of the SCA Editor which is customized for this diploma thesis have established an EMF model (see ) of a SCA composite. For being able to modify composite files, a writer is created. It allows to write an EMF representation of a composite to a XML file. For the editor, the model was extended by the pattern attribute. So it could also be used to handle this extension, too. With this approach it is easy to modify a SCA element. Modifications are forwarded to other elements automatically. Unfortunately the writer sometimes creates composite files which cannot be used with tuscany. For example the implementation element of some implementation types appears as the last element within the component description. This is not allowed in tuscany and therefore, leads to an error. It could not be assured, that these problems can be solved in this thesis. So the EMF model is not used for the implementation of the package deployer. Tuscany Assembly Model Tuscany also provides a method to read and write composite files. Therefore, it provides so called processors for all kinds of SCA files. For the implementation of the package deployer the processors for composite and contribution 61

68 5 Prototype descriptor files are used. The composite processor for example, is using a XML stream to create objects and therefore, a data binding for a SCA composite. Like for the EMF approach, changes are forwarded to other elements. Tuscany uses this way to handle SCA files. So it is most likely that files which were modified like this will work with the tuscany runtime. The only part that is not handled by this approach, is the pattern attribute of the extended SCA components. Here JAXP can be used in addition. All functions which are required are assembled in one single library file of the tuscany distribution. This file resides in the libs folder and is named tuscany-sca-all.lib Modifications File As stated in the requirements, the package deployer must be able to apply a modifications file. It is provided by the customization process. The file contains names of the artifacts within the package which are changed during the configuration. Along with the name, the new content of the respective file is supplied. So the package deployer does not have to cope with the problem, how the configurations can be applied. It just has to replace a number of files. The following listing shows the schema of such a modifications file. Listing 5.8: Schema for a Modifications file 1 <xsd : schema xmlns : xsd =" http :// org /2001/ XMLSchema "> 2 < xsd : element name =" modifications " type =" ModificationType "/ > 3 4 < xsd : complextype name =" ModificationType " > 5 <xsd : sequence > 6 < xsd : element name =" File " type =" FileType " minoccurs ="0" maxoccurs =" unbounded "/ > 7 </ xsd : sequence > 8 </ xsd : complextype > 9 10 <xsd : complextype name =" FileType "> 11 <xsd : sequence > 12 < xsd : any minoccurs ="0" namespace ="## any " processcontents =" skip "/ > 13 </ xsd : sequence > 14 <xsd : attribute name =" filename " type =" xsd : string "/ > 15 </ xsd : complextype > 16 </ xsd : schema > The content of a file can be any XML-based content. supported by the package deployer. Non-XML based files are not 62

69 5 Prototype Repository One requirement for the package deployer is to provide a repository. It stores the template and solution packages. Tuscany is able to read a contribution from a folder on the file system. So it is obvious to use the file system to create a repository. The repository consists of two main folders: template solution A template package is stored to the template folder by creating a new sub folder. It is named like the application, the template represents. This folder represents the root folder of the SCA contribution, the package consists of. The solution packages reside in the solution folder. Again for every application a separate folder is created. But in this case, sub folders to store the tenant specific packages are required. A special folder is the fixed-folder. It contains all fixed packages which are required for different tenants. The following figure shows an example of such a repository. Figure 5.8.: Assembly of a Repository The sub folders of a fixed-folder are named like the folders of the tenant specific packages. It is incorrect to belief that such a fixed package is only used by a single tenant. In fact it can be used by many tenants. The name belongs to the first tenant, for which the package is needed. It is obvious to use this tenantid, since every single fixed package must have a unique name. 63

70 5 Prototype According to the needs of the package deployer the repository implementation provides the following functions: create a new package from a template remove a package from the repository replace a file within a package by a new one delete a file within a package create a new file within a package get/search files within a package get templates, solution, etc. Repository for Distributed Nodes In the scenario of a distributed execution of the nodes, it is necessary to provide the repository for all nodes at the same time. To achieve this, the repository can be made available by using a web server. Tuscany only accepts to load jar files from a web resource. Therefore, the package deployer allows to create a jar file in addition to the folder that contains the package Interface This section describes the interface which is provided by the package deployer. As described in the architecture overview of the prototype, the package deployer must facilitate the execution of solution packages in a tuscany distributed domain. To match the requirements, the package deployer provides six different operations. The functionality of the different operations and their parameters are enumerated in the following tables. In section the implementation of these operations is described. Create Solution In the first step the create solution operation applies the modifications file for the specific tenant. Afterwards, a tenant specific and if needed, a fixed package is created in the repository. 64

71 5 Prototype Parameter Description applicationid The applicationid depicts the template for that the solution is created. Therefore, the applicationid must match the folder name which is used for the template package. tenantid The tenantid is a unique identifier of the tenant for that the solution is created. The newly created package will be identified using the applicationid together with the tenantid. modifications A modifications file as described in section This file represents the configurations that must be applied for the particular tenant. Table 5.4.: Create Solution Operation Delete Solution The delete solution operation removes a tenant specific package from the repository. If the package is the last one for an application, the fixed packages are deleted, too. They are useless. Parameter applicationid tenantid Description The applicationid of the tenant specific package that will be deleted. The tenantid of the tenant specific package that will be deleted Table 5.5.: Delete Solution Operation Deploy Solution The deploy solution operation establishes a tenant specific package for the tuscany domain manager. Therefore, a node composite is created for every deployable composite in the package. The workspace, domain composite and cloud composite file of the domain are adapted to support the new package. If the package needs a fixed package for its operation which is not already deployed, then a fixed package is deployed, too. 65

72 5 Prototype Parameter applicationid tenantid nodeuri Description The applicationid of the tenant specific package that will be deployed. The tenantid of the tenant specific package that will be deployed. The URI for the node which will be created to run the first deployable composite of the package. If there is more than one deployable composite, for every new node a unique nodeuri has to be generated. If no nodeuri is supplied, the URI of the node for the first deployable composite is generated, too. Table 5.6.: Deploy Solution Operation Undeploy Solution The undeploy solution operation removes a tenant specific package from the tuscany domain. Therefore, the node composite is deleted for every deployable composite of the package. The composite files are also removed from the workspace file, domain composite and cloud composite file. If the package is the last deployed package of the application, all fixed packages are undeployed, too. Parameter applicationid tenantid Description The applicationid of the tenant specific package that will be undeployed. The tenantid of the tenant specific package that will be undeployed Table 5.7.: Undeploy Solution Operation Start The start operation starts all nodes that belong to a tenant specific package. Every node is started in a separate JVM. To start the nodes, the nodeconfigurationuri which is provided by the domain manager is used. Nodes can either be started locally by the package deployer, or via an external node launcher on any other system. The nodes for the fixed package are started, if the tenant specific package needs a fixed package for its operation. 66

73 5 Prototype Parameter applicationid tenantid domainmanageruri nodelauncheruri Description The applicationid of the tenant specific package, for which the nodes will be started. The tenantid of the tenant specific package, for which the nodes will be started. The URI of the domain manager which provides the nodeconfigurationuri. The request to start the node is redirected to a node launcher, if a nodelauncheruri is specified. Table 5.8.: Start Solution Operation Stop The stop operation stops all nodes that belong to a tenant specific package. The process of the respective JVM is destroyed. The stop request is redirected to a launcher, if an external launcher was used to start the node. If the nodes for the last tenant specific package are stopped, the nodes of the fixed packages are stopped as well. Parameter applicationid tenantid Description The applicationid of the tenant specific package for which the nodes will be stopped. The tenantid of the tenant specific package for which the nodes will be stopped. Table 5.9.: Stop Solution Operation Implementation Details This section describes the implementation of the different operations. For every operation, the preconditions are enumerated. Afterwards a process is displayed. It represents the activities that are required to achieve the intended result. Every activity is described in detail Create Solution Preconditions The template for the specified applicationid is stored in the repository. 67

74 5 Prototype No tenant with the specified tenantid already exists. The supplied modifications change the package only in a correct way. This means, the package must still represent a complete SCA contribution. Otherwise errors will occur during the creation of the tenant specific and fixed package. Creation of a Tenant Specific Package As stated in 4.3, for every tenant, a tenant specific package has to be created. This package contains all artifacts needed to run the components, tagged with the multiple instances pattern. It also has to contain the component description of single configurable instance components. The following figure shows the process, passed for the creation of a tenant specific package. Below every step is described in detail. Figure 5.9.: Tenant Specific Package Creation Create a new Package from the Template As a first step, a folder for the new package is created in the repository. The content of the chosen template is copied to this location. Therefore, the new package equals the template package, at the beginning. Apply the Modifications File The modifications file is applied for the newly created package. Therefore, the content of all files, listed in the modifications file, is replaced by the according modified content. Read Deployable Composites A list of all deployable composites is created. The deployable composites are read from the contribution descriptor. If no contribution descriptor exists, all composites in the package are treated as deployable composites. This list is important for the further process. 68

75 5 Prototype Read Pattern Attributes of all Components A map of all component names and their according multi-tenancy patterns is created. Only the components of the deployable composites are considered. To read the patterns JAXP is used. This is necessary because the pattern attribute does not exist in the tuscany assembly model. Modify the Deployable Composite Files The following modification steps are executed in order to adapt the deployable composite files for a tenant specific package. In general the steps described in section are performed. So, at the end of this step all multiple instances components will have a unique name. They will not interfere with components of other tenants. To modify the composite files, they are loaded into a tuscany assembly model representation as described in After the modification they are saved back to the same composite file. The following modification steps are performed: All components tagged with the single instance pattern are removed. These components reside in a fixed package. They can therefore be removed from the tenant specific package. All promoted references and services of the components that are removed in the first step, are removed too. These elements also reside in a fixed package. All wires that have a source and target outside the composite are removed. The property type and constraining type definitions are removed. The names of all components are modified by adding the tenantid to the name attribute. With this name change the URI of the component s service binding changes, too. So the requirement, that every multiple instances component must have a unique endpoint, is met. To obtain the wiring, the target attributes of all references need to be renamed to match the component names that emerged from the last step. The name of the composite is modified by adding the tenantid. This is necessary, since all tenant packages are deployed to the same domain. All composites within a domain are required to have different names. Check if a Composite File is Empty After the modification of the composite files, it can be possible, that a composite file does not contain any components. This happens for example, if all components are tagged with the single instance pattern. Such an empty composite file is without any function, if it is deployed. To avoid useless composites, these files are deleted and removed from the deployable composites list of the contribution descriptor. If all composite files of a package are deleted this way, then the package is 69

76 5 Prototype without any function after its deployment. But to avoid confusion, such a package is not deleted automatically. Apply the Implementation Mapping As stated in , the implementation mapping file represents a list of components and implementation files which are required to run a particular component. Depending on the multi-tenancy pattern of a component, an action is performed. Single Instance The implementation files can be deleted if they are not needed for other components. Because the according component descriptions reside in a fixed package, the files are not required in a tenant specific package. To make them available in other packages, an import statement is added to the contribution descriptor of the package. Multiple Instances The implementation files are needed in the tenant specific package. Therefore, no actions are performed. Single Configurable Instance The implementation files are deleted in the tenant specific package, if they are not needed for multiple instances components. The files reside in a fixed package, because all tenants that utilize a single configurable instance component can share the same implementation files. To make them available in other packages, an import statement is added to the contribution descriptor of the package. Creation of a Fixed Package The components which reside in a fixed package can be shared by several tenants. Therefore, it is not necessary to create a fixed package for every tenant. Nevertheless it is important to check, if all required single instance components are available in one of the fixed packages. Additionally all required implementation files for single configurable instance components must be available. According to section there are two situations where a new fixed package is required. First, when a deployable composite file contains a single instance component that no other tenant configured to be single instance before. And second, when an implementation file is exported which was not exported by any fixed package before. To be able to reuse the creation process for a tenant specific package, a potential fixed package is created every time the create solution operation is called. The package is not needed, if it contains no components and no implementation files are exported. The following figure shows the creation process of a fixed package. 70

77 5 Prototype Figure 5.10.: Fixed Package Creation The first four steps are the same like for the creation of a tenant specific package. But in the case of a fixed package, an inspection has to be performed, which single instance components already reside in a fixed package and which implementation files are already exported. This has to happen before the composite files are modified. This way it is ensured, that the modified composite files only contain single instance components that do not exist in other packages. Modify Deployable Composite Files The following steps are performed during the modification of the composite files of a fixed package. All components tagged with the multiple instance or single configurable instance pattern are removed. Such components reside in a tenant specific package. All components that are already handled by other fixed packages are removed. All promoted references and services of the components that are removed in the steps above have to be removed, too. These elements also reside in a tenant specific package. Wires that have a source or a target outside the fixed package are deleted. The name of the composite is modified by adding a fixed-prefix along with the identifier of the tenant, for that the package is created first. This is necessary, since in most cases, there are several fixed packages for the same application. 71

78 5 Prototype The constraining type or property definitions are not deleted in the first fixed package of an application. In any further package these elements are deleted. This avoids duplicate emergence in the domain composite. Apply Implementation Mapping File Like for the tenant specific package, different actions have to be performed for the different patterns. Additionally a check is performed, if a file is already exported by another fixed package. Single Instance The implementation files are needed in the fixed package. Therefore, only an export statement has to be added to the contribution descriptor for every file. If it is already handled, the files are deleted and no export statement is added. Multiple Instances The implementation files for the multiple instances components reside in a tenant specific package. Therefore, the files of multiple instance components are deleted in the fixed package. Single Configurable Instance These implementation files are shared between several tenants. They reside in the fixed package and an export statement has to be added to the contribution descriptor for every file. If a file is already exported by another fixed package, no export statement is added and the file is deleted. Check if the Package is Useful At the end of the creation process of a fixed package, a check is performed, if the package is required. The package is deleted if no deployable composite file contains any components and no implementation file is exported Delete Solution Preconditions A solution for the given applicationid and tenantid exists in the repository. The solution is not established in the tuscany domain manager yet. The delete solution operation is simple. The package deployer calls the repository operations to remove the folder of the tenant specific package which matches the applicationid and tenantid. If the package is the last tenant specific package for the application, all fixed packages are removed as well. 72

79 5 Prototype Deploy Solution Preconditions A solution for the given applicationid and tenantid exists in the repository. The solution is not already deployed. The specified nodeuri is not already in use. The deployment establishes the tenant specific package along with all needed fixed packages in the files of the tuscany domain manager. This enables the domain manager to provide the nodeconfigurationuri. It then, can be used to start the nodes and therefore, the tenants application. The deployment process starts with the tenant specific package. Afterwards for every fixed package a check is performed, whether the package is already deployed. If a fixed package is not deployed, it passes the same deployment process as the tenant specific package. So at all times, when a tenant specific package of an application is deployed, all fixed packages are deployed, too. The following figure shows the deployment process for any package. Below the particular steps are described in detail. Figure 5.11.: Implementation of the Deploy Operation Add the Contribution to the Workspace In the workspace, all contributions within a domain are listed. Therefore, the contribution which makes up the new package is added, too. Every contribution within the workspace has an URI. This is necessary to refer to the contribution within the other files that are used to describe the node. So a contributionuri has to be generated for the new contribution. 73

80 5 Prototype This URI has the following buildup for a tenant specific package: contributionuri-prefix + applicationid + tenantid An URI for a fixed package is assembled as follows: contributionuri-prefix + fixed-prefix + applicationid + tenantid The parts which build the URI are separated by a configurable character. In both cases, this creates a URI which is unique under all other contributions within the domain. The contributionuri-prefix is used to identify all contributions within a domain that are deployed by the package deployer. The fixed-prefix denotes, if a contribution represents a fixed or a tenant specific package. Both prefixes are configured in a property file and therefore, are the same for all newly deployed packages. The following snippet shows a contribution entry in the workspace of the domain manager. The location element either points to a folder in the file system, or to a location where a jar file is made available via a web server. A properties file allows to configure whether a jar file is used. Listing 5.9: Contribution Entry in the Workspace 1 < contribution location =" file :/C:/ repository / solution / sample / tenant 01/" uri =" SSPD. sample. tenant 01" > The next steps are executed for every deployable composite within the package. Include the Composite to the Domain Composite In the next step, all deployable composites are included into the domain composite of the tuscany domain manager. The URI of the include statement has to be the one which is created for the contribution in the last step. The following snippet shows such an include statement: Listing 5.10: Include Statement in the Domain Composite 1 < include name =" ex: sampletenant 01" uri =" SSPD. sample. Tenant 01" xmlns :ex =" http :// example "> 74

81 5 Prototype Generate nodeuris Like described in , every node needs a unique nodeuri. For the first composite of a tenant specific package, this URI can be assigned via the operation call. This allows a client to force the provisioning of the functions for a specific tenant at certain URIs. If no URI is specified via the operation call or more than one composite is present, a new nodeuri is generated. This URI has the following assembly: The port is generated from a port range which is specified in a properties file. The used ports are stored in a file to maintain the ports, even when the package deployer is stopped. Create the Node Composite File After the URI for the node was defined, a node composite file can be created. As a basis for this composite, a composite-template (see : Node Composite) is used which is stored in the folder of the domain manager. To create a node composite, the following configurations have to be applied: The name of the composite is set to: Node-Prefix + applicationid + tenantid + compositename A configurable separator is placed between the parts of this name. The name of the only component, is set to the name of the node composite, too. The composite attribute of the implementation element of the only component is set to the name of the composite for which the node is created. The URI of the implementation element is set to the URI of the contribution. The URIs of all bindings of the component are set to the nodeuri. The composite file is saved to the folder of the domain manager. The file is named like the composite, but without a separator between the different parts. 75

82 5 Prototype Create Database for BPEL Implementations When a BPEL implementation is used for a component within a composite, a database must be available in the classpath of the respective node. This is due to the fact, that tuscany uses the apache ODE engine to host a BPEL component. This BPEL engine needs a database to work properly. A separate database has to be created for every node. To achieve this, tuscany is distributed with a zip file that contains such a database. So, it is adequate to extract this zip file to a separate location for every node. Therefore, the repository of the package deployer provides a folder where new databases are created. Every database is stored in a sub folder. It is named like the node file, it is created for. Include the Node Composite File in the Cloud Composite As a last step the newly created node composite has to be included to the cloud composite. The following snippet shows such an include statement. Listing 5.11: Include Statement in the Cloud Composite 1 < include name ="t: node. sample. Tenant 01. sampletenant 01" uri =" http :// tuscany. apache. org / cloud " xmlns :t=" http :// www. osoa. org / xmlns / sca /1.0" > Undeploy Solution Preconditions A solution for the given applicationid and tenantid exists in the repository. The solution is deployed. This means, the respective tenant specific package and all fixed packages of the application are established in the tuscany domain manager. To undeploy a solution all steps that are performed during the deployment process must be undone. In every case the tenant specific package which is specified by the applicationid and tenantid is undeployed. If the package is the last deployed package of an application, all fixed packages are also undeployed. The undeployment process is the same for both kinds of packages. In the following, the steps which are performed during the undeployment of a package are enumerated. The contribution is removed from the workspace of the domain manager. All deployable composites are removed from the domain composite. All respective node composites are removed from the cloud composite. All respective node files are deleted. 76

83 5 Prototype All respective databases are deleted Start Preconditions A solution for the given applicationid and tenantid exists in the repository. The solution is deployed. In detail, the respective tenant specific package and all fixed packages of the application are established in the tuscany domain manager. The nodes for the solution are not started yet. The nodes of an application have to be started. In every case, the nodes of the tenant specific package are started. Afterwards all non-started fixed nodes are started. This ensures that all nodes which make up an application for a specific tenant are available. The following figure shows the process which is required to start the nodes of any package. Again the particular steps are described below. Figure 5.12.: Implementation of the Start Operation Get the nodeconfigurationuris As a first step the nodeconfigurationuris of the nodes which are created for the package are retrieved. These URIs are required to start the nodes by the use of the tuscany node launcher. The nodeconfigurationuris are created as follows: domainmanageruri + /node-config/ + name of the node composite 77

84 5 Prototype Example: The URI depicts the endpoint, where the domain manager provides the information to start a node. This information is required by the tuscany node launcher. The following steps are executed for every nodeconfigurationuri of a package. This means, that every node that is prepared for the package in the deployment process is started. Save the Node Information All information which is used to identify a node is saved before the node is started. This is necessary because nodes can be started either locally or by an external node launcher. Without saving the node information, it would not be possible to determine which nodes are already started. Remote nodes cannot be accessed by the package deployer directly. The following information about each node is saved: The endpoint of the node launcher that is used to start the node. The nodeuri of the node Information about the package, for which the node is created (applicationid, tenantid, package type) Start a Node in a new Java Virtual Machine There are two ways to start a node. Either a node is started locally by the package deployer or by an external node launcher. If a nodelauncherenpoint is specified with the call of the start operation, the request is redirected to this external launcher. Before an external node Launcher can be called, additionally the nodeuris of the respective node composites are set to the location of the distant system. In both cases the node is started using the node launcher, provided by tuscany. Every node is started in its own JVM. Therefore, the following application call is performed: java -cp DatabasePath;nodeLauncherPath org.apache.tuscany.sca.node.launcher.nodelauncher nodeconfigurationuri The path of the nodes database is added to the classpath. This way, the apache ODE engine is assigned a database. The nodelauncherpath depicts the path to the lib file 78

85 5 Prototype that contains the tuscany node launcher. The process information of the new JVM instance is saved. So it is simple to stop the node, later Stop Preconditions A solution for the given applicationid and tenantid exists in the repository. The solution is deployed. This means, the respective tenant specific package and all fixed packages of the application are established in the tuscany domain manager. The nodes for the solution are started. The first step, once the stop operation is called, is to retrieve the information about the nodes of the respective package. If the nodes are started using an external node launcher, the request is redirected. The method to stop the nodes is the same for local and remote nodes. To stop a node, the process of the respective JVM is destroyed. If no other nodes of tenant specific packages of the application are running, the nodes of all fixed packages are stopped. The method to start every node in a separate JVM, and to stop it by destroying the respective process, is derived from the implementation of the web interface of the tuscany domain manager Restrictions The package deployer has some additional restrictions regarding the modeling of the application packages. These restrictions are enumerated in the following. The service binding URIs of multiple instances and single configurable instance components must not contain non-hierachical URIs. For these bindings no unique URIs are generated. The URI attribute of the component element must not be used for multiple instances and single configurable instance components. A unique URI is created in using the component name. The URI attributes are not considered. All names of components in different applications must be unequal. This is due to the fact that all components of all applications are included in the domain composite. If two or more components use the same name, a duplicate component error is raised in tuscany. 79

86 5 Prototype 5.4. Domain Manager Launcher To avoid a manual start of the tuscany domain manager, the domain manager launcher is introduced. As stated in the architecture overview, the first operation for the provisioning flow is to call this service. This is necessary, because the domain manager is required to start any node within the domain. So the requirements for the domain manager launcher are simple. The launcher needs to provide two operations. One operation to start a tuscany domain manager, and one to stop it. The domain manager launcher therefore provides a Web services interface. To start the tuscany domain manager the domain manager launcher executes an ANT script [3] that resides in the folder of the domain manager. The script to launch a domain manager is copied from a sample of the tuscany distribution Distributed Nodes The following section describes, how the package deployer can be used to start the packages for different tenants on different hosts. This allows to share the load which emerges in a domain with many nodes. In section the external node launcher is already mentioned. This service can be hosted on any amount of systems. The external node launcher provides the same operations to start and stop nodes as the package deployer does. Therefore, the same implementation is used to start and stop nodes in a new JVM. Figure 5.13 shows two different hosts which both run the nodes of a tenant specific package. Host two additionally runs a fixed node. All nodes belong to the same application. Figure 5.13.: Distributed Execution of Nodes 80

87 5 Prototype This allows to distribute instances of tenant specific packages. Instances that are shared by many tenants cannot be distributed this way. They always reside on one specific host. So all tenant specific packages will call the same instance. In addition to the possibility to balance the load, tenants may choose to host their tenant specific package on their own infrastructure. For example this can be useful for security reasons. 81

88

89 6. Scenario As a example, a scenario is described. It consists of a simple store. Certainly this store is provided as a SaaS application as described in this thesis. This allows to recapitulate all steps which are needed to create such an application. The section describes the development of the store as a SCA application along with the annotation of the components with multi-tenancy patterns. The implementation of the scenario is part of this diploma thesis. It can be deployed and started using the package deployer. For the development of the scenario, the extended editor is used. As a basis, the store sample of the tuscany distribution is extended. The features of the shop are the following: The store provides a web interface. The store lists the products along with a price. The products are stored in a XML-based format. A currency converter allows to use different currencies. The store provides the possibility to calculate a discount for students. A mail is sent after a purchase was completed Components As a first step, the necessary components are identified. Every component is listed along with its properties, services and references. Furthermore the implementation type and the utilized multi-tenancy pattern is named. A list of configuration options describe the customizable elements of a component. The bindings, which are used for the particular references and services, are only described where it is necessary. One can inspect the whole composite file of this scenario at G. To provide an overview, the figure below shows the application s diagram. This diagram is created using the extended editor. 83

90 6 Scenario Figure 6.1.: Diagram of the Simple-Store Scenario Store This is the most significant component which provides the web interface. To display the website, the Store component has to call two other components. The first one is the Catalog component to receive the products and prices. And the second one is the ShoppingCart component to provide the products a customer already added. Once a purchase is committed, the Store component calls the StoreOwnerMailer component. It informs the shop owner. 84

91 6 Scenario Component Assembly Properties Implementation Services References title (the title of the store) widget (Javascript, HTML) A HTTP binding provides the web interface. Catalog (get products) ShoppingCart/Cart (get shpping cart content) ShoppingCart/Total (get total price) ShoppingCart/DiscountSetter (set type of the customer to student or non-stutdent) StoreOwnerMailer/Mailer (send a mail to the store owner) Table 6.1.: Assembly of the Store Component within the Scenario Multi-Tenancy Pattern The Store component needs to be configured with the multiple instances pattern. This is because every tenant needs a separate website. By setting the binding s URI to /store, the shop becomes available at an address which is build up by the URI of the node that hosts the store (Example: Furthermore the multiple instances pattern allows the SCA property title to be configured on a per tenant basis. Configuration Options The value of the SCA property title is configurable. Therefore, a variability point has to be set to the respective description in the composite file of the simple store Catalog This component is used to retrieve the products from a products file. It also calculates the prices, using the CurrencyConverter. 85

92 6 Scenario Component Assembly Properties Implementation Services References currencycode (for example EUR or USD) Java Catalog (provides products) CurrencyConverter (used to calculate prices) Table 6.2.: Assembly of the Catalog Component within the Scenario Multi-Tenancy Pattern The Catalog component uses the single configurable instance pattern. This is necessary, because every shop owner has to configure its own products. The products file has to be marked as a configurable element in the implementation mapping file. Configuration Options The value of the SCA property currencycode is configurable. The products file can be configured to the needs of the store owner CurrencyConverter The CurrencyConverter component converts a price to a particular currency. All prices must be basically supplied in USD. A currency code then defines the currency to which a price has to be translated. Component Assembly Implementation Services Java CurrencyConverter (translate a price) Table 6.3.: Assembly of the CurrencyConverter Component within the Scenario Multi-Tenancy Pattern The CurrencyConverter uses the single instance pattern. This is due to the fact, that it is not dependent on any tenant context. So all tenants can use the same instance. 86

93 6 Scenario Configuration Options The pattern of the CurrencyConverter component is configurable. Some tenants might not want to share the same instance with other tenants. Therefore, they can choose to use the multiple instances pattern ShoppingCart This component manages the shopping cart during the stay of a customer. Therefore, it provides several services to get information about the purchase. Furthermore the ShoppingCart component saves the information whether a customer stated to be a student or not. Component Assembly Implementation Services References Java Cart (provide shopping cart) Total (calculate the total price of a purchase) DiscountSetter (set the type of a customer to student or nonstudent) DiscountCalculator Table 6.4.: Assembly of the ShoppingCart Component within the Scenario Multi-Tenancy Pattern The ShoppingCart component uses the multiple instances pattern. This is due to the fact, that for this shopping cart implementation, every shop needs its own shopping cart. Otherwise products from different shops would get mixed up. Configuration Options Nothing is configurable DiscountCalculator The DiscountCalculator enables to determine a certain reduction on the price, referring to the specific customer status. If the customer is a student, the price is modified by a value that is stored in a BPEL variable. 87

94 6 Scenario Component Assembly Implementation Services BPEL Discount (calculate modified price) Table 6.5.: Assembly of the DiscountCalculator Component within the Scenario Multi-Tenancy Pattern The DiscountCalculator component is configured with the multiple instances pattern. This is necessary, because the implementation needs to be changed in order to configure the discount modifier. Therefore, a separate instance for every tenant has to be created. Configuration The value of the BPEL variable which stores the discount modifier is configurable. Therefore, a variability point has to be set to the according element of the BPEL file StoreOwnerMailer This component is used to send a mail to the store owner once a purchase was received. The respective mail address is stored in a component property. Component Assembly Properties Implementation Services address (the mail address of the store owner) Java Mailer (send purchase information to the store owner) Table 6.6.: Assembly of the StoreOwnerMailer Component within the Scenario Multi-Tenancy Pattern The StoreOwnerMailer is configured with the single configurable instances pattern. This pattern is used, because the mail address of the store owner needs to be configurable on a per tenant basis. Furthermore it is not necessary to modify the components implementation. So a multiple instances component is not required. 88

95 6 Scenario Configuration The value of the SCA variable which holds the address of the store owner is configurable. The whole component can be removed from the composite file, if a tenant does not want to receive mails Preparations for the Customization Process After the development of the simple store is finished, two main parts are created. These will be used to setup the application. The first part is the SCA contribution that consists of the following artifacts: The composite file of the simple store. All implementation files for the components. A mapping file which maps the implementation files to their components (see H). This contribution is copied to the template folder of the package deployer. To refer to the application, the folder is labeled like the applications name, simplestore. The second part, that is created, is a variability descriptor file. This file is used to generate the customization flow. It can be used by the customers to configure the application to their needs Customization by the Shop Owners There are three customers in the scenario. All of these customers want to adept the simple store to sell their products. Every customer has different needs. So it is not sufficient to simply adapt the products which are provided by a shop. The first customer plans to sell books. He has little requirements, so few adoptions are necessary. The second customer offers food. His shop is targeted to European customers. So he needs to offer his goods in Euro. Futhermore he likes students, so he increases the student discount. The third one is a car dealer. He is more careful and does not want to share the same currency converter with other customers. At first, the car store should only be deployed for testing purposes. So he does not want to receive mails. All customers use the customization flow to configure their store. The table summarizes the requirements of the three customers. 89

96 6 Scenario Store Book Store Food Store Car Store Requirements Set title to: Book Store Set mail address to: Set Books as products Set title to: Food Store Set mail address to: Set Euro as currency Increase student discount Set meals as products Set title to: Car Store Set mail address to: Don not share currency converter with other tenants Do not send mails Set cars as products Table 6.7.: Customers within the Scenario 6.4. Deployment After finishing a customer configuration of the respective shop, the customization flow starts the provisioning flow that calls the package deployer. As the first step, the modifications file that is created during the customization flow is used to create a solution for the particular customer. In the next step, this solution is deployed and started. The following picture shows the shops of the three shop owners. 90

97 6 Scenario Figure 6.2.: Websites of the three different Stores 91

98

99 7. Conclustion and Outlook The task of this thesis is too prove that the Service Component Architecture can be used to create a common platform for SaaS applications. Furthermore strategies for the deployment of such an application are developed. These strategies are used to introduce a prototype that allows the creation of the described packages and their deployment on a SCA engine. For the prototype the packages proposed in [20] are modified to use the include statement to split the application packages, instead of using a composite implementation. This approach allows to easily distribute the single tenant specific and fixed packages amongst multiple nodes and therefore, multiple host systems. Additionally, research is done on critical restrictions during modeling the SaaS application packages using SCA What Level is It In four different levels of SaaS applications are stated. In the following, the approach is presented the same way as in Configuration Instances Changes Scalability Each customer is able to configure the application on the level of services. For every customer a separate instance of individual parts of the application is created. Furthermore customers share instances of common parts. For the common parts, there is only one instance. The implementation of customer specific parts need to be changed separately for every customer. For common components only one implementation has to be changed. The instances of customer specific parts can be distributed over several hosts. Common components cannot be distributed. Table 7.1.: Level of SaaS Applications of this Thesis With the SaaS system presented in this thesis it is possible to create applications that fulfill the requirements of level 3. The applications are configurable and the same code 93

100 7 Conclustion and Outlook base can be used for all customers. As an addition, this approach allows a customer to create custom parts in an application, using the multiple instances pattern. To satisfy level 4, there would have to be the possibility to create multiple instances of common parts of the application. So the SaaS system can be arranged between level 3 and 4 in the continuum proposed in [14] Propositions for Future Work Within this thesis a SaaS system is introduced. Furthermore there are several considerations to improve the SaaS system which are described in the following. Security A very important topic for SaaS applications are security considerations. Further research has to take place to examine how the police framework provided by SCA can be used in the context of the SaaS application packages of this thesis. Deployment The prototype allows the deployment of a SaaS application on a SCA engine. But the deployment strategies (see 4) are developed without a certain platform in mind. Therefore, these strategies can be used to deploy the packages on other platforms as well. Editor The editor allows to annotate a SCA component by a multi-tenancy pattern. To improve the comfort for a developer, the modeling restrictions described in 3.2 should be also implemented. Another useful feature would be the possibility to export an eclipse project directly as an application template as described in Furthermore it is important to update the editor periodically to the newest version of the underlaying SCA editor. Package Deployer Some restrictions for the package deployer are stated in To allow the use of non-hierarchical URIs for multiple instances components, it would be necessary to implement a method that creates a unique URI for a tenant out of a general non-hierarchical URI. In order to be able to use components with the same names in multiple applications, it would be adequate to add the applicationid to the names and URIs of all components. Also some implementation and binding types are not tested yet. Further research has to be done to see the impact on these. Mainly the Java, Javascript and BPEL implementations are tested. For the bindings, Web services and JSON-RPC [15] are used. 94

101 7 Conclustion and Outlook Distributed Execution The external node launcher application allows to launch the nodes of tenant specific and fixed packages on different host systems. This enables the distribution on the level of packages. In principle, tuscany allows the distribution on the level of components. Therefore, a facility could be created, to allow the developer to choose which components can be swapped to separate nodes. Another improvement would be the possibility to create multiple instances of a fixed package. This is required, once the applications of many tenants need to use the same fixed packages. To control the distribution, a load balancer could be used to direct the package deployer to use different external node launchers. 95

102

103 A. Bibliography [1] Fabric3, [2] SCArWare, [3] apache.org: ANT, [4] apache.org: Apache Axis 2, [5] apache.org: Apache BCEL, [6] apache.org: Apache ODE (Orchestration Director Engine), [7] apache.org: Apache Tomcat, [8] apache.org: Apache Tuscany, [9] Auer, Kai: Generierung von WS-BPEL Prozessen aus Variabilitätsbeschreibungen. Diplomarbeit, [10] eclipse.org: Ecore, org/eclipse/emf/ecore/package-summary.html. [11] eclipse.org: SCA Tools, [12] eclipse.org: SOA Tools Platform Project, [13] eclipse.org: Web Tools Platform Project, [14] F. Chong, G. Carraro: Building Distributed Applications Architecture Strategies for Catching the Long Tail. MSDN architecture center, library/aa aspx, [15] Metaparadigm: JSON-RPC, [16] Mietzner, Ralph: Using Variability Descriptors to Describe Customizable SaaS Application Templates. Techreport, January [17] OASIS: Web Services Business Process Execution Language Version 2.0, i

104 Bibliography [18] OSOA: SCA Service Component Architecture, Assembly Model Specification Version AssemblyModel V100.pdf, [19] Ralph Mietzner, Frank Leymann: Towards Provisioning the Cloud: On the Usage of Multi-Granularity Flows and Services to Realize a Unified Provisioning Infrastructure for SaaS Applications. Proceedings of the International Congress on Services, [20] Ralph Mietzner, Frank Leymann, Mike P. Papazoglou: Defining Composite Configurable SaaS Application Packages Using SCA, Variability Descriptors and Multi-Tenancy Patterns. 3rd International Conference on Internet and Web Applications and Services (ICIW), [21] Software Engineering Institute, Carnegie Mellon University: Software Product Lines, [22] Sun: Java Server Pages Technology, [23] Sun: Java Servlet Technology, [24] W3C: Web Services Policy Framework (WS-Policy), [25] W3C: SOAP Version 1.2, [26] W3C: Web Services Description Language (WSDL) Version 2.0, ii

105 B. List of Figures 2.1. The Long Tail of Businesses [14] The different Levels of SaaS Applications [14] SCA Overview [18] Variability Descriptors [16] Template Package Solution Package Requirements for Component Calls, dependent on the Multi-Tenancy of the Component Two staged Deployment Process Process to set the SCA Service of a Multiple Instances Component Assembly of a deployed Single Configurable Instance Component Deployment Process based on a prepared Composite File Separation of Tenant Specific and Fixed Package via Composite Implementation Separation of Tenant Specific and Fixed Package via Include Prototype Overview Overall View of the Editor Choosing a Multi-Tenancy-Pattern Shapes of the different Multi-Tenancy Patterns Example of a Standalone Domain [8] Example of a Distributed Domain [8] Assembly of a Tuscany Distributed Domain Assembly of a Repository Tenant Specific Package Creation Fixed Package Creation Implementation of the Deploy Operation Implementation of the Start Operation Distributed Execution of Nodes Diagram of the Simple-Store Scenario Websites of the three different Stores iii

106 List of Listings E.1. Repository View in the Web Interface of the Package Deployer viii E.2. Deployment View in the Web Interface of the Package Deployer ix E.3. Nodes View in the Web Interface of the Package Deployer ix F.1. Web Interface of the Test Client xi iv

107 C. Listings 4.1. Schema of an Implementation Mapping File Component using the Multiple Instances Pattern Client to start a SCA Domain Domain Composite File Node Composite File Cloud Composite File Workspace File Contribution Descriptor using Import and Export Statements Schema for a Modifications file Contribution Entry in the Workspace Include Statement in the Domain Composite Include Statement in the Cloud Composite G.1. Composite File of the Simple Store Scenario H.1. ImplementationMapping File of the Simple Store Scenario xii xv v

108 D. List of Tables 2.1. Level 1 of SaaS Applications Level 2 of SaaS Applications Level 3 of SaaS Applications Level 4 of SaaS Applications Restrictions on the Modification of Component Description and Implementation, dependent on the Multi-Tenancy Pattern Separation of Component Description and Implementation Files Assignment of the Implementation Files on the Tenant Specific and Fixed Package Requirements for the Editor The new Pattern Attribute Requirements for the Package Deployer Create Solution Operation Delete Solution Operation Deploy Solution Operation Undeploy Solution Operation Start Solution Operation Stop Solution Operation Assembly of the Store Component within the Scenario Assembly of the Catalog Component within the Scenario Assembly of the CurrencyConverter Component within the Scenario Assembly of the ShoppingCart Component within the Scenario Assembly of the DiscountCalculator Component within the Scenario Assembly of the StoreOwnerMailer Component within the Scenario Customers within the Scenario Level of SaaS Applications of this Thesis vi

109 E. Web Interface of the Package Deployer To have an overview of the status of the package deployer, a web interface is provided. This interface displays information about the templates and solutions in the repository, about the deployment status of each solution and about the running nodes. This can be very helpful, especially, for testing purposes. From the technical view, the web interface is created using JSPs (Java Server Pages) that utilize a class that retrieves the repository information. This appendix describes the different views of the web interface. E.1. Repository Status View The repository status displays the packages which are stored in the repository. The view is separated into two main parts. On the top, all templates are listed which are available for the creation of a solution. Below the templates, all solutions are enumerated. The packages in the solutions view are ordered by their application and their package type. Figure E.1 shows an example of the repository status view. E.2. Deployment View The deployment view enumerates the packages which were deployed to the tuscany domain manager. Furthermore a complete status, of which composites exist in the domain is displayed. Information about the created nodes can also be displayed using the web interface of the tuscany domain manager. The link to this web interface is provided by the deployment view. The log information of the tuscany domain manager can be displayed via a separate web page. E.3. Nodes View The nodes view is separated into two parts. The first part shows information about all running nodes in the domain. For every node this display shows the nodeconvii

110 E Web Interface of the Package Deployer figurationuri that was used to start it. Furthermore the view contains information about the package, the node belongs to. This includes the applicationid, tenantid and package type. At last the URI of the node is displayed. The left picture in figure E.3 shows the first part of the nodes view. The second part of the nodes view shows all nodes which were started locally by the use of the package deployer. A link entry allows to view the log entries of every single node. This can be very helpful to debug the SaaS applications. The second view is imaged on the right in figure E.3. To monitor nodes that are started by an external node launcher, every external node launcher provides a separate web interface. This interface displays the same information as the local nodes view of the package deployer. Figure E.1.: Repository View in the Web Interface of the Package Deployer viii

111 E Web Interface of the Package Deployer Figure E.2.: Deployment View in the Web Interface of the Package Deployer All Nodes within the domain Local running nodes Figure E.3.: Nodes View in the Web Interface of the Package Deployer ix

112 F. Test Client for the Package Deployer To be able to test the package deployer, a simple test client was created. This client allows to call all operations of the package deployer and domain manager launcher, like the provisioning flow would call them in the complete prototype assembly. All functions are provided via a web interface. On the main page of the test client all callable operations are listed. The available operations for the package deployer are create solution, delete solution, deploy solution, undeploy solution, start and stop. The operations for the domain manager launcher are start domain manager and stop domain manager. For each parameter of an operation, a matching input field exists which has to be filled with the respective values. After a request was submitted, the test client displays a message showing the result of the invocation. To easily start the scenario described in 6, the test client provides a separate page. On this page, methods are presented to create and deploy all packages of the three tenants, by one click. Furthermore, there are methods to start all nodes or to remove everything that refers to the scenario. From the technical view, the web pages of the test client are created using JSPs. The methods to call the services of the package deployer and domain manager launcher where generated using the WTP (see ). Figure F.1 shows the operations, provided on the main page of the test client. x

113 F Test Client for the Package Deployer Figure F.1.: Web Interface of the Test Client xi