Application Multi-Tenancy for Software as a Service

Transcription

1 ACM SIGSOFT Software Engineering Notes Page 1 March 2015 Volume 40 Number 2 Application Multi-Tenancy for Software as a Service Sanjukta Pal Department of Computer Applications National Institute of Technology, Durgapur, India sanjukta.nit@gmail.com Amit Kr Mandal Department of Computer Applications National Institute of Technology, Durgapur, India amitmandal.nitdgp@gmail.com Anirban Sarkar Department of Computer Applications National Institute of Technology, Durgapur, India sarkar.anirban@gmail.com ABSTRACT Software as a service has evolved as a new software deployment paradigm in the cloud, which offers information technology services dynamically, on-demand. Application Multi-tenancy in SaaS leads to improved resource utilization and reduces overall application costs by sharing the same applications, resources and data services through multiple tenants. In this paper a graph-based approach called SaaS Level Application Multi Tenancy graph is proposed to represent the multitenant aspects of the SaaS model of cloud environment formally. The proposed approach will facilitate the analysis of service interaction paths for accessing shared sets of services in SaaS by the multiple tenants. The proposed approach is capable enough to model several kinds of tenant like isolated tenant, shared tenants with single or multiple data services and multiple tenants in SaaS. Further, several metrics are defined for the proposed approach to describe the essential features of multi-tenant SaaS applications. The expressiveness of the proposed approach is illustrated using several examples and a detailed case study. Keywords Application multi-tenancy, tenant, interface, labels, data heterogeneity, zero-downtime. 1. INTRODUCTION Cloud computing is scalable, flexible and robust environment for designing and developing web-based applications. It enables on-demand network access to a shared pool of configurable computing resources [9]. In general the cloud environment is comprised of three major service models [20], namely (i) Software as a Service or SaaS, which is an online software delivery model, (ii) Platform as a Service or PaaS, which provides the development platforms and allows consumers to develop cloud services and applications, and (iii) Infrastructure as a Service or IaaS, which offers the services related to infrastructural resources like processors, storages, networks etc. Cloud computing is still an evolving paradigm and it exhibits several major challenges [16], which include, software and hardware architecture, data management, cloud interoperability, privacy, service provisioning and multi-tenancy implementation with the support of efficient customization of application instances. Multi-tenancy is an architectural pattern in which a single instance of the software will run on the service provider's infrastructure, and multiple tenants access the same instance. [1]. In this context, the term tenant refers to a user group which represents to the stake holders of the same organization. A multi-tenant application lets tenants share the same hardware resources, by offering them one shared application and database instance, while allowing them to configure the application to fit their needs as if it runs in a dedicated environment [9]. The benefits of the multi-tenant applications are twofold. Firstly, application maintenance becomes easier for the service provider, as only one application instance has to be maintained. Secondly, it can increase the utilization of resources. These two factors reduce the overall cost of the application, encourages high degree of shareability. However, some major objectives for implementing and monitoring a multi-tenant environment are better performance with high availability, efficient service delivery with zero downtime [9], cost optimization and managing the applications [8]. Beside these, application management is one of the crucial issues required to attain multi-tenancy, particularly with the shared data sets. An efficient SaaS model of cloud also adhered to share the same infrastructural resources for multiple tenant towards software delivery. However, with the increasing adaption of the SaaS service model, organizations are facing serious challenges to achieve multi-tenancy for shared services due to its on-demand nature and scalability requirements. Moreover, multi-tenant applications should conform to a SaaS architectural framework In this paper a graph-based approach called SaaS Level Application Multi Tenancy graph (SaaSAMT) is proposed to formalize the multitenant aspects of the SaaS model of cloud environment. The proposed graphical approach will facilitate the analysis of service interaction paths for accessing shared sets of services related to SaaS applications by the multiple tenants. The interaction path is also helpful in measuring the degree of shareability. Several useful metrics like degree of shareability and implementation complexity related to the multi-tenant SaaS applications can be measured using the proposed approach. Based on the implementation strategy of shared application instances, tenants can be classified into several categories, namely isolated tenant, shared tenants with single or multiple data services and multiple tenants. The proposed approach is expressive to represent such categories of tenants at conceptual level. The proposed SaaSAMT is based on the SaaS architectural framework, called Flexible Cloud Architecture for Data Centric Applications (FCADCA) [11, 12]. However, in general, the proposed approach can also be applicable to any SaaS architectural framework for a cloud environment. In this context, FCADCA is a conceptual cloud architecture for SaaS. FCADCA is a layered architectural approach that provides abstractions of different components in SaaS by incorporating all the non-functional features that are necessary for data-centric cloud applications such as scalability, flexibility, portability, adaptability, coexistence and integrity. This paper is organized as follows. In section 2 the approaches and results of related literatures are summarized. In section 3, a brief introduction of the FCADCA framework is discussed. The formalization of our proposed SaaS Level Application Multi Tenancy graph is described in section 4. It also includes the conceptual representation of different kind of multi-tenancy using the proposed approach, several important properties and metrics related to the proposed SaaSAMT graph. In section 5, the proposed SaaSAMT graph is illustrated using a case study. Section 6 compares and analyses different application multitenancy methodologies. Finally, the conclusion and future research directions of the proposed work has been discussed in section RELATED WORK Application multi-tenancy is one of the important aspects of the SaaS service model. Here, services are shared with multiple tenants. Tenants can have access of customized applications instances with shared services to serve multiple users as per their need. In recent years many research works have focused on better scalability of SaaS applications. Application multi-tenancy is an architectural pattern of SaaS and serves for sharing by permitting multiple services to multiple consumers [1]. This architecture is divided into four layers those are: application, middle ware, virtual machine and operating system. Among them only

2 ACM SIGSOFT Software Engineering Notes Page 2 March 2015 Volume 40 Number 2 application layer supports multi tenancy, where multi-tenancy can support only relational database through Elastic Extension Table (EET) which is the combination of Common Tenant Table (CTT) and Virtual Extension Table (VET). In [6], three approaches are used to implement multi-tenant data architecture and those are separate database, shared database separate schema and shared database shared schema. Here for security purpose Kerberos protocol have been used, which is the authentication protocol based on symmetric key cryptography. But it also fall short of explaining some key aspects of multi tenancy like scalability, performance, zero downtime [9] etc. In [4], an approach is described to achieve multi-tenancy via physical separation of tenant data, by storing it in separate database or in same database or by using same database and set of tables to host multiple tenant data. The main focus of the approach described in [8] is to architect a metadata driven approach to support multi-tenancy using three different approaches, those are, Separate DB, Shared DB Separate schema and Shared DB Shared schema. Implementation of multi-tenancy in the approach has considered two layers of SaaS, namely Data layer and Application layer. In this, shareable application instances hosted on shared hardware for multiple enterprises yields less development cost and assures relative data security and trust. According to Paul et al. [9], three layers in SaaS are required to implement multi-tenancy and those are authentication, configuration and database layer. Authors have listed various functional and non-functional challenges for implementing multi-tenancy, like availability, zerodowntime, performance, scalability and security. However, the main focus of this paper is to re-engineering the single tenants into multiple tenants. In [5], the challenges are discussed whether the multi-tenancy pattern can be applied on the SaaS. They proposed a framework for devising multi-tenant applications in SaaS. Besides these, few approaches are also studied in literatures to apply multi-tenancy in IaaS level. In [7], an approach is described to support multi-tenancy in shared database shared schema scenario to manage heterogeneity in terms of varying attributes, database technology and resources. The main focus of this approach is to decompose data to the node specific granularity to optimize the resource utilization at IaaS level. In [2], the researchers concentrated mainly on data centric multi-tenancy rather than application multi-tenancy. This paper has proposed a general architecture for representing multi-tenancy for cloud environments and employed customer integration on three layers, namely application, infrastructure and data center. In the approach application-layer multitenancy is thought of as architectural implementations concern both the software and infrastructure layers. In [3], an approach is proposed to achieve multi-tenancy through database storage virtualization using virtual machine technology. In summary, very few of the existing approaches are specifically concerned about the application multi-tenancy in SaaS that would allow tenant specific configurations on the services, business processes and databases. These tenant specific configurations should be guided by some architectural framework which will control the behavioral, technical and data access mechanisms of the tenant. Further a formal approach of application multi-tenancy in SaaS will give better understanding of the complex interactions among the tenants, applications instances and services in the cloud environment. 3. BRIEF INTRODUCTION OF FCADCA FRAMEWORK The conceptual architectural framework called, Flexible Cloud Architecture for Data-Centric Applications (FCADCA) [11, 12], is devised considering three core functionality of SaaS, namely Customizability, Scalability, and Flexibility. Apart from these, the architecture is capable of providing support for implementation of datacentric cloud applications with heterogeneous data sets. As depicted in Figure-1, FCADCA is comprised of four layers. (1) Application Layer: this is the outer most layers which directly interact with the users. It is responsible for providing services and managing service configurations. (2) Service Management Layer: it is responsible for providing services to the requester as per their requirements. Here several functional modules are combined together to define a service. Application customization can be done by defining the fields, formulas and work flows among the services. (3) Business Layer: this layer consists of several business components and a set of business rules operating on the services and its components. With this kind of framework designer is able to achieve business oriented service grouping which are independent of the functional modules used to define them. Therefore, the changes in business layer can be more readily accommodated since business components and business rules are separated. (4) Data Layer: in this architectural framework, the data layer is divided into two sub layers, namely metadata management sub layer and data management sub layer. Metadata management layer works as a bridge between business layer and the data management layer. Depending upon types of data, metadata represents the meta-information about user data, application data, service data and event data. Data in cloud is highly evolving in nature. FCADCA framework supports heterogeneous representation and storage of large scale business data compatible to different database services such as structured, semi-structured or unstructured. In FCADCA each layer contains a set of interfaces which provide the means of interactions among different layers and supports exchange of information. Information exchange can be messages which conforms a referenceable exchange pattern, structure and semantics. Interface also provides a barrier that enables application logic to change without affecting the users of the interface. An interface consists of a number of access points which provides access to the functional aspects of related layer. An access point of an interface can interact with more than one access points of the other interfaces across the adjacent layers. The access points are selected dynamically for a particular service or service composition based upon their availability and type. Therefore the dynamic addition or deletion of service components for a particular service composition can be achieved. The FCADCA architectural framework provides a reference architecture of data centric SaaS applications. But it fall short of providing any formal approach for applications multi-tenancy with the shared set of services for SaaS model. Therefore, to conceptualize the multi-tenancy aspects with shared set of services formally a graph-based approach called SaaS Level Application Multi Tenancy (SaaSAMT) is proposed in this paper. For the purpose, the interfaces for each layer of FCADCA are divided into a number of sub-interfaces depending on the service type of different layers. Even though the proposed SaaSAMT is based on FCADCA framework, but the approach is applicable for conceptualization of the application multi-tenancy in general. Fig 1: SaaS layer form FCADCA [11] for architecting SaaSAMT 4. FORMAL REPRESENTATION OF APPLICATION MULTITENANCY FOR SaaS A multi-tenant application allows the consumers (tenants) to access the shared applications and database instances with the support for high degree of customization. A tenant can be considered as the organizational entity which accesses multi-tenant SaaS solutions. Typically a tenant, groups a number of users which are the stakeholders in the organization [9]. In FCADCA architectural framework, these tenants directly interacts with the interface of the application layer. These further access the desired shared data sets of the data layer by interacting with the interfaces and shared services of the intermediate layers.

3 ACM SIGSOFT Software Engineering Notes Page 3 March 2015 Volume 40 Number Formalization of SaaSAMT Graph SaaS level Application Multi-Tenancy (SaaSAMT) is modelled for application multi-tenancy and can be represented as a graph G (V, E, L) on layered architectural framework of FCADCA. This graph is represented as a directed labelled graph, where interfaces are represented as a set of nodes V, directed set of interactions through the request or reply paths are represented as set of edges E and edge identifier is represented as the label L. More formally they can defined as follows, Set of vertices V (Interfaces): In FCADCA, every layer has multiple numbers of interfaces. Each of these interfaces are treated as nodes or vertices of graph G. Here V is defined the universal set of interfaces for all layers. Graphically, each vertex will be represented as rounded rectangle. Here, each node is denoted by v ij, where i represents the index on layer in FCADCA, and j represents the index on interfaces in some layer i. For example v1j indicates the j th interface of Application layer or layer 1. Therefore, in general node V can be represented as, 4 n V = v ij i=1 where 1 i 4 and 1 j n Set of edges E: The edges of SaaSAMT represents the interaction among the vertices of the adjacent layers. For interaction, an edge must starts from a vertex, then it interacts with service of the concerned layer and next the edge ends at the vertex of adjacent layer. So, formally this interaction can be expressed as tuple and can be represented as, Ti = <<Vij, Sik, V (i+1) l> <Vij, Sik, V (i-1) l>> Depending upon the type of interactions, edges can be classified into (i) request edge (Ereq), where interaction is represented as <Vij, Sik, V (i+1) j> and (ii) response edge (Eres), where interaction is represented as <Vij, Sik, V(i-1) j>. Therefore, E = E req E res The request edges are directed towards the data layer starting from the application layer of FCADCA, whereas the reply edges direction is towards the application layer. The reply edge generally follows the same path of opposite direction of the request edge. The edges in SaaSAMT graph will be represented by a solid directed line. Path notation: Path notation is the combination of vertices and services of consecutive layers of FCADCA. For formal representation of the individual path it is defined as the combination of interaction tuples of the consecutive layers. So, service request path for a tenant can be expressed as, Preq= < Vij, Sik, V (i+1)l >,<V(i+1)j, S(i+1)k, V (i+2)l >,.. = Vij, Sik, V(i+1) j, S(i+1)k, V (i+2) j,.. by truncating the repetitive destination node V (i+1) j. However, the request path of any tenant can also be represented using the interaction tuple T, Preq = T1, T2, Label L: The label L is used to identify the edges of SaaSAMT graph, thus it can be defined as the function over the edges, l(e). Labels are defined for identifying different service interaction within a pair of vertices of the adjacent layers. Therefore, the label over the edges is defined by the service id of the concerned layer. More formally, label can be represented as, l (e) = S ik, where i presents the layer number and k represents the service id of layer i. The list of graphical notations for SaaSAMT is given in table 1. j=1 Table 1: Summarized graphical notations of SaaSAMT Formal notation V Description of notation Set of interface Graphical notation Fig 2: Graphical representation of the SaaSAMT using request edge with labelling Figure 2, demonstrates a scenario of SaaSAMT graph. In the figure, first three layers contain single vertex, V11, V21, V31 of layer 1, layer 2 and layer 3 respectively. Whereas, layer 4 contains two vertices, namely V41 and V42. Here, label over the edge (V11, V21) is S11 and it represents the interaction <V11, S11, V12> in layer 1. In layer 3 for two different edges (V31, V41) and (V31, V42), the label over the edges are same, and it emphasize the use of two different database instances in layer 4. Hence in layer 3, service S31 is shared. The possible request paths in the example graph are, Request path 1: P1req: V11, S11, V21, S21, V31, S31, V41 Request path 2: P2req: V11, S11, V21, S21, V31, S31, V42 As discussed earlier, the service response will follows the same path as the service request path in the reverse direction. This is also important to note that with the help of labelling it is possible to identify the interaction path of individual tenant. 4.2 Properties of the SaaSAMT Graph Based on the characteristics of software as a service and formal definition of SaaSAMT, several interesting properties of SaaSAMT can be drawn to conceptualize the important aspects of multi-tenant cloud applications. The properties are as follows, a) Request and reply edge: In the SaaSAMT graph G, the edges which are directed towards layer 4 are called request edge. The edges which are in opposite direction of request edge are called reply edge. These reply edges are directed towards layer 1. In figure 2, the edge propagates from vertex V11 is interacting with next layer interface V21 using the service S11 of layer 1. The edge is directed towards layer 4 and is a request edge. b) Access points: An access points are incorporated in a vertex and are the originating points of interacting with particular service of same layer. So, a vertex can originate multiple edges, and in maximum it is equal to the number of access points. c) Service interaction of edges: Each layer may consists of multiple numbers of services with their unique service id. The edges propagates from a vertex and interacts with adjacent layer vertex through the service Fig 3: Single service single pair of vertices E L Set of edges Label of edges for edge identification Fig 4: Multiple service single pair of vertices

4 ACM SIGSOFT Software Engineering Notes Page 4 March 2015 Volume 40 Number 2 of concern layer. The interactions among two adjacent layers vertices can be represented in different forms and are as follows: (i) Single service within single pair of vertices: The edge within a single pair of vertices will interact with a single service. Here (figure 3) the edge connecting two interfaces V11 and V21 through the only service S11. ii) Multiple services within single pair of vertices: The edges within a single pair of adjacent layer vertices can interact with multiple numbers of services. For each service interaction a separate edge need to be considered between the pair of vertices. Here in figure 4, the interactions between vertices V11 and V21 are represented by three different edges with S11, S12 and S13 as label respectively. A vertex can interact with the adjacent layer vertex through a composed service. In this case service composition will occur first and on next the pair of vertices will interact through the composed service. Let in figure 4, if V11 and V12 need to interact through the composed service comprised of S12 and S13 then the related edge can be described with the label as S1(2,3). Such label describes the service id of composed service. Fig 5: Multiple service multiple vertices iii) Multiple services within multiple pair of interfaces: Here, a service can interacts with the multiple pair of vertices. It represents the shared service interaction scenario. Here, multiple edges can have same label, but different source and target vertices. In figure 5, the edges connecting two pair of interfaces (V11, V21) and (V12, V22) through service S11, S12, S13. Here, S12 service is shared among tenant 1 and tenant 2. d) Tenant: In the SaaSAMT, tenant is considered as a group of users interacting directly with interfaces of layer 1 or application layer of FCADCA. A tenant can be associated with a dedicated interface of the application layer. In other word, the number of interfaces in the application layer is equal to the number of tenants. e) Data service management: In SaaSAMT, data management layer s interfaces (layer 4 vertices) are responsible for handling one or multiple data services. However, the shared data services can be accessed through a single interface on data management layer. 4.3 Metrics on proposed SaaSAMT Graph Several interesting metrics can be defined based on the concept of SaaAMT graph which are effective for the evaluation of application multi-tenancy scenarios. (i) Number of tenant: The number of tenants can be defined by the number of interfaces on application layer. It is represented by U. Therefore, U= v1 Where, v1 represents the number of interfaces on application layer or layer 1, and v1 V. Here, v1 =1 implies single tenant, and v1 >1 implies multiple tenants. (ii) Degree of shareability: In multi-tenancy, each tenants shares the same application instance, though it appear to them as if they are using a dedicated one. Thus a key parameter of evaluating multi-tenancy is the degree of shareability which reflects how well resources are shared among the tenants. Here, the degree of shareability is represented as Ds. The value of Ds depends upon the, number of vertices in layer 1 or number of tenants U, number of shared services m, maximum possible number of individual path P and total number of layers L. Formally P can be represented as, P=( 4 4 i=1 V i ) ( i=1 S i ), Where Vi is the number of vertices at the layer i and Si is the number of services in layer i. As FCADCA framework is comprised of four layer so the value of L is always 4. Therefore degree of shareability can be represented as, (m U) Ds = (P L) For application multi-tenancy degree of shareability DS will increase either the number of shared services increase or both number of tenants and shared services increase. The value of Ds will always lie in between 0 and 1. For isolated tenant, where no services are shared, the value of Ds is minimum and equal to 0. On other hand multiple tenants with shared sets of services, the value of Ds would lie between 0 and 1. Therefore, the range of degree of shareability is 0 Ds < 1. (iii) Implementation complexity: This metric defines complexity measure for application multi-tenant architectural specification based on SaaSAMT graph. It indicates the relative difficulty of implementing a multi-tenant SaaS application. It is evident that implementation complexity will be higher if the number of shareable services are less in application multi-tenant architecture and/or number of possible paths are higher. Thus the implementation complexity C is inversely proportionate with the degree of shareability Ds, except in the case of isolated tenant, where Ds=0. Formally this can be expressed as, P, where Ds = 0 C = k/ds, where Ds 0 Where, k is the constant, whose value depends upon the type of services used and customization capability of the tenants. Here, for simplicity the value of k is considered as 1. Again for isolated tenant the value of complexity is extremely high, when a significant number of isolated tenants are deployed in SaaS. For a highly shared service scenario or for maximum value of Ds, the implementation complexity will become lower. 4.4 Realization of Application Level Multitenancy by SaaSAMT Graph Based on the types of shareability, application level tenants can be classified into several categories, namely isolated tenant, shared tenants with single or multiple data services and multiple tenants. These categories will affect the shareability of services in different layers. High degree of shareability can be achieved if services of most of the layers are shared. (i) Isolated tenant: In this case, for each tenant there exist a separate service request path, which is not consists of any shared services. Therefore, each tenant uses a separate set of services and interfaces. Figure 6 shows isolated tenant scenario. In this example scenario, number of shared services m=0, number of user group is U=1, maximum possible number of path P=128 and number of layers is L=4. So, Ds = (m U) = (0 1) =0 and implementation complexity C= (P L) (128 4) P=128, implies maximum possible number of individual path. Fig 6: Isolated Tenant

5 ACM SIGSOFT Software Engineering Notes Page 5 March 2015 Volume 40 Number 2 Algorithm 1. Algorithm for discovering request path input: tenant id output: interaction path Fig 7: Single tenant multiple data services (ii) Single tenant multiple data services: A single tenant may requests for multiple dedicated data layer services by interacting through the series of intermediate layers interfaces. In figure 7, multiple data services are accessed by Tenant 1. In the figure, number of services m = 2, number of tenant U = 1, maximum number of individual path P= ((1*1*2*2) * (1*1*2)) = 8 and number of layers L= 4. Therefore, degree of shareability Ds = (m U) (P L) = (2 1) =1/16 and (8 4) implementation complexity C = 16. (iii) Multiple tenant with shared services: For this category multiple tenants shares single or multiple data services. Depending on the shared services, it can be categorized into two types, a) Multiple tenant single data service: In this type of multi-tenancy, a single data service is shared by multiple tenants. In this scenario, if number of tenant increases, then shareability also will increase. In figure 8, data service has been shared by multiple tenants. In this example number of shared service m= 2, number of tenant U=2, maximum number of individual path P=((2*2*1*1) * (2*1*1)) = 8 and number of layers L=4. Therefore, degree of shareability Ds = (m U) (P L) implementation complexity C = 8. Fig 8: Multiple tenants with single data Service = (2 2) =1/8 and (8 4) b) Multiple tenants multiple data service: Here, multiple tenants accesses multiple data services through intermediate shared services. This is the most complex scenarios of shareability in application level multi-tenancy in SaaS. Figure 9 depicts this type of multi-tenancy with shared services. Here, number of shared service m=1, number of tenants U=2, maximum number of individual path P= ((2*1*2*2) * (2*1*2)) = 32 and number of layers L= 4. Hence the degree of shareability Ds = (m U) (P L) implementation complexity C = 64. Fig 9: Multiple tenants with multiple data services = (1 2) = 1/64 and (32 4) Request_path (TN) Stack S Interaction Vertex Ver1 Service Ser Vertex Ver2 T[] Path Interaction T[] P[] Or = NULL v = vertex to which T is connected push v into stack S while S is not empty v1 = pop from Stack S list[] = adjacent nodes of v1 for i = 1 to n If label(v1,list[i]) matches service requested by the tenant T[] = <V1, label(v1,list[i]), list[i]> push(list[i]) Built_path(Or, T[], P[]) Or = v1 ReturnP[] Function: Built_path(Or, T[], P[]) n = mod(t[]) if(or == NULL) for i=1 to n add T[i] in P[] else P =search in the path P[] where (P[i].T[i].ver2)== Or for i=1 to n add T[i] in P built a new path P in P[] 4.5 Algorithm for finding paths for a tenant In SaaS model, from user s service request to service response some steps are followed in a systematic way. In SaaSAMT graph, interfaces of each layer interacts with the adjacent layers interfaces and interactions starting from the application layer interfaces will form the request path. Here, it has been assumed that the reply from the data management layer will follow the same path in reverse direction. For the services requested by the tenant, it is important to discover the request path to complete the request-reply cycle in an efficient way. The algorithm for discovering request path takes a tenant (TN) as input and finds a continuous service request path to access data services by using the adjacent interfaces.

6 ACM SIGSOFT Software Engineering Notes Page 6 March 2015 Volume 40 Number 2 Firstly, it pushes tenants interfaces (layer 1 vertices in SaaSAMT Graph) into the stack S then it checks for the adjacent vertices. If the label over the edges connecting the vertices matches the tenant s services then it will store the interaction. The interaction and its origin vertex then used to find the all possible interaction path for a tenant. This process continues until the stack is empty. Algorithm 1 depicts the pseudo code of the proposed methodology. In this algorithm, the loop takes Θ(V) time and for each vertex the adjacent layer s vertices are also are checked. Therefore, the complexity of the algorithm can be defined as, complexity = (v 1 + v v n ) + [(interaction_edges v 1 ) + (interaction_edges v 2 ) (interaction_edges v n )] = V i + E i = Ο(V + E) Therefore, from the complexity analysis it is evident that the complexity increases with the number of interfaces (vertices) in the SaaSAMT graph. If the number of vertices increases then the degree of shareability decreases which in turn affect the application scalability. 5. ILLUSTRATION OF PROPOSED SaaSAMT APPROACH To illustrate the concepts of SaaSAMT for multi-tenant applications an example of simplified direct care Electronic Health Record (EHR) system has been used. The direct care EHR system requires an infrastructure that can deliver information for patient care anytime and anywhere. Therefore the example is suitable for realization in the cloud environment. It has been realized by using FCADCA and proposed SaaSAMT. The simplified direct care EHR system consists of two different components registration and billing service component and medication and care service component. From these components several set of services are derived as listed in table 2. With these services two different applications are created; which are named as, app1 (S21, S25, S26) and app2 (S22, S23, S24). For the storing of patient related information two separate data services are considered. Moreover, for the simplicity in this example only two different tenants are considered, one is the user group of the registration and billing services and another one is the consultant s user group. These two tenants are using both of the data services as they are dependent on each other. The Use Case representation of the above example illustrates possible valid engagements among its components; it also shows the capability of the system and demonstrates interaction mechanisms for the users of the system. Figure 10 depicts the interaction among actors (tenants) and different component and concepts of simplified EHR Cloud. Here tenants are associated with the applications app1 and app2. App1 includes the demographic service (S21), order and purchase service (S25) and billing service (S26); whereas app2 includes diagnostic service (S22), consultation service (S23) and medication service (S24). However, in this example service (S25, S26) and (S22, S23) are combined together. These services are derived from the business components S31 and S32, which uses the data services S41 and S42 respectively. This use case diagram can be easily mapped into the SaaSAMT graph. From the use case diagram it is evident that the application layer requires two different interface V11 and V12. In service layer two pair of services are combined together out of the six different services. Therefore the combined services can be treated a single unit, so in SaaSAMT the total number of interface vertices in service layer will be four (V21, V22, Table 2. Different components of layers of Direct Care EHR system Fig 10: Use case diagram for direct care EHR Fig 11: SaaSAMT Graph for Direct care EHR Service functionalities ID Business components ID Data components ID Demographic service S21 Registration service S31 Patient information, financial data S41 Order and purchase service S25 Billing service S26 Diagnostics service S24 Medication and care S32 Consultants information, medical S42 Consultation service S22 service report, clinical record Medication service S23

7 ACM SIGSOFT Software Engineering Notes Page 7 March 2015 Volume 40 Number 2 V23, V24). However, all the services are extended from the two business components therefore business process layer will have two interface vertices (V31, V32). As discussed earlier the business component uses two data services which are also associated, therefore the data layer will have one interface vertices (V41). The corresponding SaaSAMT graph for this example is depicted in figure 11. Here the edges represents the interaction among the interface vertices. The label over the edges represents the services. So, the degree of shareability for retrieving any data service using multiple tenant is, Ds = (m U) = (2 2) = 1/256 and implementation (P L) (256 4) complexity C = 256. Because here number of tenant U= 2, number of shared service m= 2, number of maximum individual path P= ((2*4*2*1) * (2*4*2)) =256 and number of layers L= DETAIL COMPARATIVE ANALYSIS OF APPLICATION LEVEL MULTI-TENANT METHOLOGY A SaaS application should be on-demand, self-service, broad network based access, resource pooling, rapid elasticity, and measured service as defined by NIST [10]. To achieve these goals along with application multi-tenancy a SaaS architectural framework required to supports several features. These features are described in this section and used to compare SaaS architectural frameworks with multi-tenancy support. The model described in [1, 6, 4, 8, 9, 5, 7] and the proposed SaaSAMT graph is used for the purpose. The comparison has been summarized in Table 3. a) Service model used for multi-tenancy: Very few application multi-tenancy approaches has been studied in literature. Further most of them are not formal. Proposed SaaSAMT provides a graph-based formal approach to represent different application level multi-tenant scenarios in SaaS. b) Framework: Most of the application multi-tenancy approaches in recent literatures have not followed a sound SaaS architectural framework. Thus, those approaches are limited to represent and analyze various kinds of application multi-tenancy with shared services in SaaS. The SaaSAMT devised based on the SaaS architectural framework, called Flexible Cloud Architecture for Data Centric Applications (FCADCA). However, in general, the proposed approach can also be applicable to any SaaS architectural framework of cloud environment. c) Performance: In the proposed approach, several metrics like number of tenants, degree of shareability and implementation complexity have been defined and which are crucial to analyze the performance feature at the design level. Those metrics emphasize that better performance of application multi-tenancy can be achieved through the high degree of shareability, less number of possible path and moderate number of tenants. d) Scalability: It refers how well a solution to some problem will work when the size of the problem increases. In proposed SaaSAMT Table 3. Comparison table for different features of multi-tenancy approach scalability can be controlled by the number of interfaces (vertices) and number of tenants. It has been shown that if the number of vertices increases then the degree of shareability decreases which in turn affects the application scalability. e) Cost optimization: The target of this functional issue is to minimize the data retrieval cost, implementation cost against user service request in multi-tenancy. By increased number of tenants or shared services or by both, SaaSAMT can optimize the implementation cost significantly. Implantation complexity metrics has been defined for SaaSAMT graph for that purpose. f) Availability: Availability is related to an application s presence in SaaS. If an application is not available for use when needed, then it is unlikely to be fulfilling its functional requirements of tenants. During the recovery process, the application is unavailable. The proposed SaaSAMT approach uses the layered architectural framework of FCADCA and also influenced by the availability features of FCADCA. g) Data heterogeneity: In general, cloud applications and associated data are heterogeneous in nature. The SaaS architecture in cloud environment must facilitates structured, semi-structured and unstructured data services at the same time towards the support of wide range of data centric applications. Since the proposed SaaSAMT approach is based on FCADCA framework and where the data management layer vertices are responsible for handling different types of multiple data services. Moreover, the shared data services can be accessed through a single interface (vertex) on data management layer. 7. CONCLUSION AND FUTURE WORK Application multi-tenancy leverage the consumers to access the shared applications and database instances with high degree of customization in cloud environment. This paper has proposed a formal representation of application level multi-tenancy and its different aspects in the SaaS model of cloud environment. For the purpose, a graph-based approach called SaaS Level Application Multi Tenancy graph (SaaSAMT) is proposed. The proposed graphical approach facilitates the analysis of service interaction paths for accessing shared sets of services related to SaaS applications by multiple tenants. The proposed SaaSAMT graph is based on the SaaS architectural framework, called Flexible Cloud Architecture for Data Centric Applications (FCADCA) [12, 13]. However, in general, the proposed approach can also be applicable to any SaaS architectural framework of cloud environment. The proposed approach is capable enough to represent and analyze several kinds (like isolated tenant, shared tenants with single or multiple data services and multiple tenants) of application multi-tenancy based on service shareability features. Several useful metrics like degree of shareability and implementation complexity also have been defined on the proposed approach and which are crucial to describe the essential features of multi-tenant SaaS applications. Moreover, an algorithm also has been devised based on SaaSAMT graph for discovering request and reply path in multi-tenant applications scenario. It shows that time Citation index (a) (b) (c) (d) (e) (f) (h) [1] SaaS P [6] SaaS P [4] SaaS, IaaS Y - - [8] SaaS, IaaS - Y Y - Y - [9] SaaS Y [5] - Y Y - - Y - [7] - Y - Y - Y - SaaSAMT SaaS Y Y Y P P Y Here Y means present, P means partially supported, and - means not defined in the table.

8 ACM SIGSOFT Software Engineering Notes Page 8 March 2015 Volume 40 Number 2 complexity of discovering request path will increase with the number of interfaces (vertices) in the SaaSAMT graph. All these features shows that scalability can be handled in application level multi-tenancy with the number of shared services and interfaces. Further the expressive power of the proposed approach has been illustrated using a case study and detailed comparison with existing approaches. The future work includes the refinement of the set of metrics for SaaSAMT graph which will facilitate exhaustive analysis of application multi-tenancy scenarios in SaaS. Validation of the proposed approach in real time cloud environment also is a prime future objective. 8. REFERENCES [1] HaithamYaish, Madhu Goyal, George Feuerlicht, An Elastic Multi-tenant Database Schema for Software as a Service, IEEE 9 th International Conference on Dependable, Automatic and secure Computing, Pages , 2011 [2] Jinan Fiaidhi, Irena Bojanova, Jia Zhang, Liang Jie Zhang, Enforcing Multi tenancy for Cloud computing Environments, IT Professional, IEEE Computer Society, 14(1), Pages 16-18, [3] F. Chong, Multi-tenancy-and virtualization, URL: Oct, 2006, [accessed on: 10 Sep 2014]. [4] F.Chong, G.Carraro, and Roger Wolter, Multi-tenant data architecture, Microsoft: June 2006, [accessed on: 10 Sep 2014]. [5] Chang Jie Guo, Wei Sun, Ying Huang, Zhi Hu Wang, and Bo Gao, A framework for native multi-tenancy application development and management, International Conf. on E-Commerce Technology (CEC) & Int. Conf. on Enterprise Computing, E- Commerce, and E-Services (EEE), Pages IEEE, [6] Snjeev Pippal, Vishu Sharma, Shakti Mishra, D.S. Kushwaha, An Efficient Schema Shared Approach for Cloud Based Multitenant Database with Authentication & Authorization Framework, IEEE Computer Society, pages , [7] Sanjeev Kumar Pippal, Dharmender Singh Kushwaha, A simple, adaptable and efficient heterogeneous multi-tenant database architecture for ad hoc cloud, Journal for cloud computing a Springer open journal, pages 1-14, [8] Shailesh Paliwal, Cloud Application Services (SaaS) Multitenant Data Architecture, Infosys technologies limited, URL: [accessed on: 10 Sep 2014]. [9] Cor paul Bezemer, Andy Zaidman, Challenges of Reengineering into Multi-tenant SaaS Application, Software Engineering Research Group Technical Report, , URL: repository.tudelft.nl/assets/uuid:d2e /tud-serg pdf, [accessed on: 10 Sep 2014]. [10] The NIST Definition of Cloud Computing URL: [accessed on: 10 Sep 2014]. [11] A. Mandal, S. Changdar, A. Sarkar, N. Debnath, Novel and Flexible Cloud Architecture for Data Centric Applications, International Conference on Industrial Technology, Pages , [12] A. Mandal, S. Changdar, A. Sarkar, N. Debnath, Architecting Software as a Service for Data Centric Cloud Applications, International Journal of Grid and High Performance Computing, IGI Global, USA, Vol. 6(1), Pages77 92, 2014.