SaaS with Multi-tenancy Support for an e-Contract Management Application

Kwok et al. [KNL08] described the need for exploring SaaS with multi-tenancy support for electronic contract management applications as the commercially viable applications demanded different customized code base has to be developed, deployed and operated to support each tenant. Though few advanced applications did use a single code base with

configuration options to support multi-tenants still, a separate instance of the code base was to be deployed and operated for each tenant even in these applications. These applications were anyways outnumbered by the former application type. Maintaining individual code bases for each tenant is a costly and high maintenance task. Therefore Kwok et al. [KNL08]

proposed a new multi-tenancy SaaS model that promises to reduce the application hosting cost and make the application more affordable to the tenants because of its capabilities in customization and scalability while continuing to support an increasing number of tenants.

The model also supports our work by providing realistic approach to allow multi-tenancy features for using the same application for various tenants.

3.5.1 Motivation

SaaS can be very well associated with business software applications as it lowers the cost of development, customization, deployment and operation of a software application with feature to support multiple tenants over the internet and contract management applications creates a substantial value for any company. A few characteristics of a multi-tenancy SaaS application include multi-users supports and installation of management accessibility along with maintaining data isolation and security. It benefits the Application Service Providers (ASP) by reducing hosting cost due to customization and scalability with the increasing number of tenants or customers. With a single application code base to support several tenants, the total deployment time is shorter. In addition, updating of application features is simpler and centralized because there is only one instance of a single source code base.

The cost to use the application is a per user basis and pays as it goes. However, there are initial setup, configuration and maintenance steps that have to be carried out first in order for the application to support multi-tenants in a SaaS operational structure [KNL08]. Although tenants are using the same building blocks in their configuration, the appearance or workflow of the application may be different for two tenants [BZ10]. Our work emphasizes in this aspect by considering the appearance of the application varying on the basis of shared database.

The architectural approach in which the tenants (or users) make use of a single application and database instance is the differentiating factor between multi-user and multi-tenancy and is also explained in the section 2.6.

3.5.2 Approach and Implementation

The architectural framework of the multi-tenancy SaaS electronic contract management appli-cation provides the capability of hosting multi-tenants using a single or multiple appliappli-cation instances supported by the same set of computing backend servers. It consists of a web server, a DB2 server and an application server.

The presentation and customization modules of the application are deployed in a web server.

Though, in our work the customization of the application is not availed to the tenant users.

The security, directory, metadata and shared services, the tenant extensions module as well as the core modules of the application are deployed in the application server and this architecture is similar for our work too. The DB2 server contains a central user account database, a central

3.5 SaaS with Multi-tenancy Support for an e-Contract Management Application

Figure 3.4:Architecture framework of a multi-tenant e-contract management application [KNL08]

tenant metadata database, and a shared database along with the schema. The server contains all the tenant related information, tenant user information and the electronic contracts and their related documents. The server also contains the instances of the workflow designed by the user which can be used for later references. The structure of each component in the above shown architecture is described as:

1. For each tenant the application provider registers an administrator and assign a unique tenant identification (ID) using the security services.

2. The tenant’s administrator can create user accounts and register the users.

3. The tenant information is stored on a central tenant metadata database through the metadata services while the end user information are stored on a central user account database through the directory services.

4. When the end user from different tenants access the application through HTTP or HTTPS communications, the security and directory services in the application server have to authenticate and authorize their accesses to the application. The users are tagged with their tenant ID numbers. The identification for an already existing tenant user is done by the authentication service and for the newer members, the registration is done and related user roles are assigned. The users are indeed tagged with their tenant ID numbers.

5. The shared services in the application server provide the metering and billing for each tenant. The shared database and schema in the DB2 server is used as a repository for all the electronic contracts and their related documents.

The proposed data model by Kwok et al. [KNL08], has a shared database with separate schema. Since a multi-tenancy SaaS application shares computing resources and software codes among all the tenants on the same set of servers, the data of the tenants are also hosted in the same database with the same set of tables in this approach. This is the condition for our work too hence, it is taken into consideration. This approach uses a tenant ID in a table column to associate every record with the appropriate tenant. Each record has a number of pre-allocated custom fields (typed or un-typed) that tenants can use for their own purpose.

The tenant specific data is stored in a fixed extension set with these pre-allocated fields.

Figure 3.5:A shared database and schema with custom extensions [KNL08]

The multi-tenancy SaaS electronic contract management application also uses an enhanced approach to manage multi-tenant data approach for shared database and schema with custom extension where the tenant specific data is stored as name-value pairs in a separate table.

The tenant record with tenant data is assigned a unique record ID that matches one or more rows in a separate extension table. It allows tenants to extend the data model arbitrarily. A data type identifier is needed in the third column, as data in the tenant specific data table cannot be typed. However, this enhanced approach has an added level of complexity for

3.5 SaaS with Multi-tenancy Support for an e-Contract Management Application

database functions, such as searching, indexing, query, and updating records. Since in our approach, we consider implementing data bucket then the content or data stored by any user are recorded and is available to the user via the assigned bucket. There are some challenges even with the implementation of multi-tenancy architecture which have been explained in the section 2.6.2. In this particular approach, database security and data isolation, such as permissions, trusted database connections, secure database tables, tenant view filter and data encryption are the majorly faced challenges [KNL08]. Features like scalability, such as scaled up by moving the application to a larger, more powerful server, scaled out by running the application on more servers and scaling the data by partitioning the data into smaller segments in order to improve the efficiency of queries and updates or by replication [KNL08]

have been stated as the main areas of investigation for the betterment of the application.