2012 2nd International Conference on Computer Science and Network Technology

A Design of Two-tier SaaS Architecture Based on Group-tenant

Hao Yuan1,2
Dept. of Computer Science, School of Mechanical, Electrical & Information Engineering Shandong University at Weihai Weihai, Shandong, China yuanhao@sdu.edu.cn
AbstractIn China, an increasing number of small and medium organizations have expressed interest in informatization. However, there are many challenges faced by software engineering practitioners, such as the numerous amount of entities, the scattered geographic location, and the lack of professionals and initial funding within these organizations. In this paper, a two-tier SaaS architecture based on group-tenant is proposed, providing a convenient solution for the problems. Therefore organizations, such as a key enterprise and its partners, are able to manage their own business, share information and minimize configuration of customization within the same SaaS application. We also design a complex data model that can satisfy unique requirements of group-tenant and two-tier configuration (extension). The case study explains how the target architecture of SaaS application would be developed and deployed by developers, and configured by group tenants. Keywords-group-tenant; two-tier SaaS architectur; complex data model; data sharing
1

Xiaoping Liu2, Chunhui Guo1

Dept. of Computer Science, School of Computer and Information Hefei University of Technology Hefei, Anhui, China lxp@hfut.edu.cn, guochunhui3024@mail.sdu.edu.cn process management. SaaS has become the first option of business software, such as CRM and ERP. Additionally, the leading software companies have incorporated SaaS into their business strategies [3]. Attracted by the merits of low initial investment, free of maintenance and ease of use, many Chinese management software providers stepped into the SaaS market, improving the awareness of SaaS amongst small and medium companies. However, current SaaS providers treat customers as independent entities and therefore ignore business interaction and integrated relationship amongst software customers. As a result, the implementation of SaaS in small and medium organizations slows down. Aimed at solving this problem, a two-tier SaaS architecture based on group-tenant which can describe business interaction between each tenants of a group, provide information sharing and achieve two-tier configuration (extension) is proposed in this paper. II. RELATED WORK
2

I.

INTRODUCTION

With the widespread implementation of information technology, the demand for informatization is no longer a requirement unique to large enterprises, federal and state government in China. More and more small and medium enterprises and local government have launched informatization projects. However, there are many substantial challenges faced by these entities and software developers, for example, the numerous amount of entities, the scattered geographic location, insufficient technological infrastructure within the entities and the lack of funding. Software providers have to address the above issues to successfully develop and deploy a software that fits these small and medium entities. Software as a service (SaaS) [1] [2], as a novel software delivery model, provides an effective solution to the above challenges. In SaaS, software and associated data are centralized, hosted in a data center, which is managed and maintained by the software provider. Customers access services through network based on tenancy contracts. Due to these features, SaaS has significant benefits for both software providers and customers. SaaS has not only been widely used in individual applications, but also in business environment to facilitate
This work is supported by National Natural Science Foundation of China (Grant No. 61070124 & Grant No. 11005028), the Fundamental Research Funds for the Central Universities(Grant No. 2010HGZY0001), and 2011 Special Technology Funds of Weihai Government Co-building with Shandong University at Weihai.

There have been some researches on SaaS and its configuration, customization and multi-tenant. Nitu [4] addresses the issue of how to effectively and efficiently support configurability in SaaS software and proposes SaaS architecture to support configurability. A set of research issues in the design, testing and maintenance of multi-tenant SaaS systems is outlined in [5]. Cor-Paul Bezemer and Andy Zaidman [6] discuss some potential challenges in implementation and maintenance of multi-tenant SaaS systems and present an architectural approach to separate the multitenant configuration as much as possible. A conceptual architecture of SaaS platform that enables executing of configurable and multi-tenant SaaS applications is proposed in [7]. Craig D. Weissman and Steve Bobrowski [8] give an insight on how multi-tenant is being handled in their application framework - the Force.Com multi-tenant internet application development platform. Frederick Chong, Gianpaolo Carraro, and Roger Wolter [9] describe the approaches to design SaaS data structure for multitenant in order to take advantage of the benefits of SaaS and to ensure security of tenants business data. A novel metadatadriven schema-sharing data storage architecture for multi-level customization in SaaS applications is designed in [10].

978-1-4673-2964-4/12/$31.00 2012 IEEE

340

CHANGCHUN, CHINA

However, all above researches and approaches treat customers as individual tenants, ignoring their relationship in real world. Thus they dont provide a good solution to the problem of data sharing between customers. III. TWO-TIER SAAS ARCHITECTURE BASED ON GROUPTENANT

information, the manufacturers products information and shipping information, distributors transfer information etc. All tenants (both the master tenant and slave tenants) in a group can access the information in the information sharing pool entirely or conditionally. For example, when a distributor (slave tenant) filling in a purchase voucher, it can complete it using shipping information from the information pool which is requested by the invoice code of the manufacturer (master tenant). C. Two-tier SaaS Architecture The two-tier SaaS architecture is proposed for above grouptenant model and shown in Fig. 2. In Fig. 2, one-way arrows mean tenants subscribe application from SaaS provider or master tenant. Rectangles with no filling represent the original part of subscribed SaaS application, rectangles filled with slashes represent the configured part of SaaS application by tenants, and rectangles filled with backslashes represent the extended part of SaaS application by tenants. Gray filling means common configuration (extension) of master tenants, blue filling means secondary configuration (extension) based on common configuration (extension) of slave tenants, red filling means specific configuration (extension) of slave tenants. A master tenant is in the first tier and can configure (extend) common information such as product lists to meet demands of itself and its most slave tenants. Slave tenants whose any configuration (extension) is not based on common configuration (extension) of its master tenant and dose not includes the common configuration (extension) are also in the first tier and can configure (extend) its own specific part. For example, a supplier of the key enterprise such as Slave Tenant D in Fig. 2 configures (extends) its own specific material information.

A. Group-tenant Model In SaaS, a tenant is defined as a customer who subscribes the SaaS application. We extend the concept of tenant and define the term group-tenant as follows: a group-tenant is a set of customers who have relative business and shared data and subscribe the SaaS application as the whole. A group tenant is composed of a master tenant and numerous slave tenants. The master tenant initiates and leads a business, slave tenants participate the business and interact and share information with the master tenant and other slave tenants. For example, a group tenant can be defined as a profit group in supply chain management (SCM), each tenant in the supply chain should interact timely with the purpose of maximizing the profit. Fig. 1 shows the business interaction of a group tenant, a rectangle represents a master tenant or a slave tenant, a rounded rectangle represents a group of slave tenants with a common business, and the line with two arrows means that the business interaction between two tenants is bilateral.

Figure 1. Business Interaction

In the business model shown in Fig. 1, the master tenant can be defined as the end-product manufacturer (also called a key enterprise), and slave tenants are its associated suppliers and/or distributors. What they interact is components information between manufacturer and its suppliers, or products information between manufacturer and its distributors. The interaction is bilateral and relates with purchase management, sales management, shipping management, transfer management, inventory management etc. of each tenant. B. Information Sharing Pool A pool in computer science is a set of initialized resources that are kept ready to use, rather than allocated and destroyed on demand [11]. In this SaaS architecture, we define an information sharing pool as a data structure that is composed of a set of business interaction information between the master tenant and its slave tenants. In a supply chain, for example, the information sharing pool includes suppliers components

Figure 2. Two-tier SaaS Architecture

Slave tenants whose part of configuration (extension) is based on common configuration (extension) of its master tenant or includes the common configuration (extension) are in

341

the second tier and can both configure (extend) secondarily based on common configuration (extension) and configure (extend) its own specific part. For example, a distributor of the key enterprise such as Slave Tenant A in Fig. 2 configures (extends) product lists secondarily based on the common product lists configuration (extension) to meet its specific demand, another distributor of the key enterprise such as Slave Tenant C in Fig. 2 inherits the common product lists configuration (extension) and configures (extends) employee information specifically, another distributor of the key enterprise such as Slave Tenant B in Fig. 2 configures (extends) both product lists secondarily and employee information specifically. Tenants in the first tier can be seen as traditional SaaS tenants, and tenants in the second tier can be seen as traditional SaaS providers. Master tenants reflect only single-tier (traditional) SaaS characteristics, slave tenants reflect both single-tier and two-tier SaaS characteristics. The two-tier SaaS architecture has the following advantages: A master tenant configures (extends) common part, slave tenants configures (extends) the part secondarily, it reduces the complexity of configuring (extending) the same part repeatedly. A master tenant configures (extends) common part unified, it is conducive to the standardization of information.

IV.

DATA MODEL

A. Complex Data Model There are three data models for SaaS separate-database, shared-database separate-schema, and shared-database sharedschema [9]. In our SaaS architecture, a complex data model of separate-database and shared-database shared-schema is adopted as shown in Fig. 3.

Figure 3. Data Model

D. Comparison SaaS is on-demand software and has significant differences with on-premise software in aspects of delivery mode, apply scope, maintenance, price etc. Table I shows the comparison between SaaS and traditional software. This paper also compares group-tenant two-tier SaaS with traditional SaaS in aspects of architecture, tenants relationship, data sharing method, and configuration (extension), and the result is shown in Table II.
TABLE I. COMPARISON BETWEEN SAAS AND TRADITIONAL SOFTWARE SaaS low subscribe, plug in similar customers flexible configuration or extension fixing a problem for one customer fixing it for everyone Traditional Software high separate installation specific customer specific re-development or upgrade fixing problem for every customer respectively

From a group tenants perspective, the SaaS architecture uses separate-database model to ensure data security while facilitating configuration and extension. Database structure of each group tenant is similar and includes one master tenants database, such as Master Database A and Master Database B in Fig. 3, and one or more slave tenants databases whose name are unique to ensure the uniqueness of data access, such as Slave Database A1, Slave Database A2, Slave Database B1 etc. in Fig. 3. User data of all tenants are stored in one database which doesnt belong to any group tenant, such as Public Database in Fig. 3. From a master tenants perspective, the SaaS architecture also uses separate-database model. Data of a master tenant are stored in a database separately, such as Master Database A in Fig. 3. From a slave tenants perspective, the SaaS architecture uses multi-instance same-structure and shared-database sharedschema model. Data of slave tenants are stored in one or more databases whose structure are exactly same, such as Slave Database A1, Slave Database A2 and Slave Database A3 in Fig. 3. In a slave tenants database, records from multiple tenants are stored in any order, and the MasterTenantID column and the SlaveTenantID column jointly associate every record with the appropriate salve tenant. According to the number of slave tenants and the amount of slave tenants data, the master tenant determines the number of slave tenants databases and data of which slave tenant storing in which appropriate database. The complex data model has the following advantages: Without relation between group tenants, separatedatabase model for a group tenant ensures its security entirely. Database structure of the master tenant is completely different with slave tenants, separating their data in

Aspect Total Cost of Ownership(TCO) Use Mode Apply Scope Specific Demand Maintenance

TABLE II. Aspect Architecture Tenants Relationship Data Sharing Method Configuration (Extension)

COMPARISON BETWEEN GROUP-TENANT TWO-TIER SAAS AND TRADITIONAL SAAS Group-tenant Two-tier SaaS two-tier business interaction and information sharing a convenient way of direct database access configuration (extension) based on nothing or superimposition with common configuration (extension) Traditional SaaS single-tier no relationship a complex way of service integration configuration (extension) based on nothing

342

different databases makes the data structure clear and facilitates data access control and data sharing. Multi-instance model for slave tenants balances the load of database servers using horizontal database partitioning.

SharedEntityName field is name of entity (table) which the master tenant allows its slave tenants to access. SharingType field explains type of data sharing entire or partial. Entire sharing type means any slave tenant of the master tenant can access all records of the table, and partial type means that a slave tenant can only access part of records.
TABLE IV. Shared EntityID 1 2 SHAREDENTITY TABLE Sharing Type entire partial PRODUCT TABLE MasterTenantID 1 1 1 1 1 INVOICE TABLE MasterTenantID 1 1 1 1 1 SlaveTenantID 2511 4304 235 NULL 0 SlaveTenantID 0 0 0 235 NULL Master TenantID 1 1

B. Data Access Control Every tenant are enabled to have multiple users, and all these user data of all tenants are stored in one database. Table III shows the structure and sample data of Users table which stores all user data.
TABLE III. UserID 1 2 3 4 5 6 7 8 9 10 11 UserName MA01 MA02 MAS251101 MAS251102 MAS23501 MAS430401 MAS135201 MAS96301 MB01 MBS7201 MBS23501 MTID 1 1 1 1 1 1 1 1 2 2 2
a

SharedEntity Name Product Invoice TABLE V.

USERS TABLE STID

a

MDB

SDB

NULL NULL 2511 2511 235 4304 1352 963 NULL 72 235

MDB A MDB A MDB A MDB A MDB A MDB A MDB A MDB A MDB B MDB B MDB B

NULL NULL SDB A1 SDB A1 SDB A1 SDB A1 SDB A2 SDB A3 NULL SDB B1 SDB B2

ProductID 1 2 3 4 5

ProductName Product A Product B Product C Product D Product E TABLE VI.

a. MTID replaces MasterTenantID, and STID replaces SlaveTenantID. b. MDB replaces MasterDatabase, and SDB replaces SlaveDatabase.

InvoiceID 1 2 3 4 5

InvoiceCode I201103020001 I201103020002 I201103030001 I201103030002 I201103040001

The combination of MasterTenantID field and SlaveTenantID field determines which tenant a user belongs to. If the value of SlaveTenantID is NULL, the user belongs to the master tenant whose unique identity of master tenant is the value of MasterTenantID. Else, it belongs to the slave tenant which is attached to the master tenant determined by the value of MasterTenantID and whose unique identity of slave tenant is the value of SlaveTenantID.

Shared data between a master tenant and its slave tenants, such as product information and invoice information, are also stored in the master tenants database. Table V and Table VI show the structure and sample data of Product table and Invoice table. SlaveTenantID field explains which slave tenant can access the record. If the value of SlaveTenantID is 0, any slave tenant of the master tenant can access the record. If the value of SlaveTenantID is NULL, no slave tenant can access the record. If the value of SlaveTenantID is others, only the slave tenant whose unique identity of slave tenant is the value can access the record.

The combination of MasterDatabase field and SlaveDatabase field describes the name of databases which a user can access. If the user belongs to a master tenant, the value of SlaveDatabase is NULL and it can only access the database whose name is the value of MasterDatabase. If the user belongs to a slave tenant, it can access both the master tenants database whose name is the value of MasterDatabase and the slave tenants database whose name is the value of SlaveDatabase.

C. Data Sharing The SaaS architecture proposed in this paper provides a sample way to share data between the master tenant and slave tenants directly database access. With the purpose of ensuring master tenants data security while sharing data, SharedEntity table which stores master tenants entities that can be accessed by slave tenants is designed and stored in a master tenants database. Table IV shows the structure and sample data of SharedEntity table. The value of field

Both SharedEntity table and SlaveTenantID field of every shared table can control whether slave tenants can access a record of the master tenant. Data access control priority of SharedEntity table is higher than SlaveTenantID fields. When a slave tenant wants to access the master tenants tables, firstly to determine whether the table is allowed to access and its sharing type by SharedEntity table, if the sharing type is partial then using SlaveTenantID field of the table to determine which records can be accessed. For example, for the sample data in Table IV, table V, and Table VI, the slave tenant whose SlaveTenantID is 2511 want to access tables of its master tenant whose MasterTenantID is 1. If the slave tenant wants to access Inventory table, the SQL statement SELECT * FROM SharedEntity WHERE SharedEntityName=Inventory returns no record, so the slave tenant cant access Inventory table.

343

If the slave tenant wants to access Product table, the SQL statement SELECT * FROM SharedEntity WHERE SharedEntityName = Product returns one record whose SharingType is entire, so the slave tenant can access all records in Product table although the SlaveTenantID value of some records is not 0. If the slave tenant wants to access Invoice table, the SQL statement SELECT * FROM SharedEntity WHERE SharedEntityName=Invoice returns one result whose SharingType is partial, then to execute the SQL statement SELECT * FROM Invoice WHERE SlaveTenantID = 2511 OR SlaveTenantID = 0 and returns two records which can be accessed by the slave tenant. V. CASE STUDY

business together and minimizing the customization difference between slave tenants, and provide a convenient way to share information between them. It has two innovations grouptenant and two-tier architecture. Group-tenant extends multitenancy, reflects SaaSs economies of scale better and makes deployment and maintenance easier. Two-tier architecture reduces repeat configuration (extension), makes common configuration (extension) standard, and provides a more flexible way for configuration and extension. In the future, we plan to perfect the SaaS architecture to support tenants to develop customization functions and integrate their own services and implement a SaaS platform based on the group-tenant two-tier SaaS architecture. It is easy to extend the two-tier SaaS architecture to multi-tier, we will try to develop a multi-tier case and explore the feasibility of multi-tier SaaS architecture. We will discover more tenant groups and extend this SaaS architecture to other industries. ACKNOWLEDGMENT The authors would like to thank Professor Shangping Ren of Illinois Institute of Technology for her suggestion about technical writing. REFERENCES
SIIA, Software as a Service: Strategic Backgrounder, Washington, D.C.: Software & Information Industry Association, Feb. 2001. [2] Software as a Service, http://en.wikipedia.org/wiki/Software_as_a_service. [3] Peter Laird, Oracle, IBM, SAP, Microsoft, Intuit and Cloud Computing Revolution, http://cloudcomputing.sys-con.com/node/608960, Jul. 2008. [4] Nitu, Configurability in SaaS Applications, 2nd India Software Engineering Conference (ISEC 2009), ACM Press, Feb. 2009, pp. 1926. [5] Bikram Sengupta and Abhik Roychoudhury, Engineering Multi-Tenant Software-as-a-Service Systems, 3rd International Workshop on Principles of Engineering Service-Oriented Systems (PESOS 2011), Colocated with ICSE 2011, IEEE Press, May 2011, pp. 15-21. [6] Cor-Paul Bezemer and Andy Zaidman, Multi-Tenant SaaS Applications: Maintenance Dream or Nightmare, 25th IEEE/ACM International Conference on Automated Software Engineering (ASE 2010), ACM Press, Sep. 2010, pp. 88-92. [7] Sungjoo Kang, Sungwon Kang, and Sungjin Hur, A Design of the Conceptual Architecture for a Multitenant SaaS Application Platform, 1st ACIS/JNU International Conference on Computers, Networks, Systems, and Industrial Engineering (CNSI 2011), IEEE Press, May 2011, pp. 462-467. [8] Craig D. Weissman and Steve Bobrowski, The Design of the Force.com Multitenant Internet Application Development Platform, International Conference on Management of Data and 28th Symposium on Principles of Database Systems (SIGMOD-PODS 2009), ACM Press, Jul. 2009, pp. 889-896. [9] Frederick Chong, Gianpaolo Carraro, and Roger Wolter, Multi-Tenant Data Architecture, http://msdn.microsoft.com/enus/library/aa479086.aspx, Microsoft Corporation, Jun. 2006. [10] Zheng Xuxu, Li Qingzhong, and Kong Lanju, A Data Storage Architecture Supporting Multi-Level Customization for SaaS, 7th Web Information Systems and Applications Conference (WISA 2010), IEEE Press, Aug. 2010, pp. 106-109. [11] Pool (computer science), http://en.wikipedia.org/wiki/Pool_(computer_science). [1]

We have designed and implemented a case of group-tenant two-tier SaaS architecture a manufacturers sales management system. This system provides effective management functions for the manufacturer and its distributors, such as shipping information management, purchase management, sales management, inventory management, account management, after-sale service management, basic information management, report management etc. All users access the system by a web browser over the Internet. The application and databases are deployed on the manufacturers servers, and Fig. 4 shows the server structure. There are one application server and four database servers, one database server (Master Database Server in Fig. 4) stores the manufacturers data (including data enabled to be shared by distributors), the other three database servers store the distributors data using the complex model described in part A of section IV.

Figure 4. Server Structure

VI.

CONCLUSION AND FUTURE WORK

This paper proposes a two-tier SaaS architecture based on group-tenant and focuses on the complex data model combined separate-database with shared-database shared-schema. The method to solve data access control and data sharing is also discussed. A case study is presented to prove the feasibility and advantages of the two-tier SaaS architecture based on grouptenant. This SaaS architecture can solve the problem of a key enterprise and its partners unified using a system to manage

344