Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware: Part 3: Resource sharing, isolation and customization in the single instance multi-tenant application

This article focuses on the single shared application instance based on the multi-tenancy enablement model. It introduces the multi-tenant resources sharing, isolation and customization mechanisms of those important J2EE artifacts in such patterns. It also leverages a sample application to illustrate how to design a multi-tenant enabled J2EE application base on IBM middleware software.

Share:

Bo Gao (crlbgao@cn.ibm.com), Research Engineer, IBM

Bo GaoBo Gao is a Research engineer working on next generation service within IBM China Research Lab in Beijing, China. His current focus is on Massive Multi-tenancy technology in SaaS (Software as a Service) area. He has rich experiences on typical IBM SOA Software Stack.



Chang Jie Guo (guocj@cn.ibm.com), Research Staff Member, IBM

Chang Jie GuoDr. Chang Jie Guo is a research staff member working on next generation service within IBM China Research Lab in Beijing, China. In rencent years, he focus on some key technologies in Software as a Service (SaaS) area including massive multi-tenancy, agile business process management (BPM) and Web 2.0.



Zhi Hu Wang (zhwang@cn.ibm.com), Research Engineer, IBM

Zhi Hu WangZhi Hu Wang is a Research engineer working on next generation service within IBM China Research Lab in Beijing, China. His current focus is on Massive Multi-tenancy technology in SaaS (Software as a Service) area.



Wen Hao An (anwenhao@cn.ibm.com), Software Engineer, IBM

Wen Hao AnWen Hao An is a software engineer working on next generation service within IBM China Research Lab in Beijing, China. His current focus is on Massive Multi-tenancy technology in SaaS (Software as a Service) area.



Wei Sun (sunwei@cn.ibm.com), Researcher, IBM

Wei SunDr. Wei Sun is a research staff member working on next generation service within IBM China Research Lab in Beijing, China. In recent years, Dr. Sun has been working on Business Process Services, Software as Services and Web 2.0 related research projects.



11 March 2009

Also available in Chinese Russian Spanish

Introduction

In the second article in this series ("Develop and deploy multi-tenant Web-delivered solutions using IBM middleware, Part 2: A taxonomy of current approaches to enable multi-tenancy"), we discussed the three types of multi-tenancy enablement approaches, e.g. virtualization, mediation and sharing. This article, Part 3 of the series, focuses on the third approach and addresses how to leverage a single, shared application instance to support multiple client organizations (or tenants) simultaneously, so as to achieve the goal of cost effectiveness. It explores an architecture to develop a cost effective, secure and configurable multi-tenant application using IBM middleware. We primarily focus on three key aspects of the multi-tenant application design and implementation:

  • The resource sharing mechanism to reduce the hardware, software and management cost of each tenant
  • The security isolation mechanism to prevent the potential invalid access, conflict and interference among tenants
  • The customization mechanism to support tenant-specific UI, access control, process and data model via configuration approaches

For a better understanding, we've designed a sample application, EasyOA, which should help to illustrate how to implement the multi-tenancy model using IBM middleware products, especially the IBM WebSphere Application Server (WAS), DB2, Tivoli Directory Server (TDS) and WebSphere Process Server (WPS).


Resources sharing based multi-tenancy enablement approaches

As illustrated in Figure 1, there are generally two kinds of resources for sharing-based multi-tenancy enablement patterns: 1) multiple application instances, and 2) single, shared application instance. The former supports each tenant with its dedicated application instance over a shared hardware, an operating system (OS) or middleware server in a hosting environment, whereas the latter can support a lot of tenants by a single shared application instance over various hosting resources. These two patterns scale quite differently in terms of the number of tenants that they can support. Multi-instance is adopted to support several (up to dozens) of tenants, each of which may own hundreds of users with a set of servers. The single shared instance is used to support a much larger number of small tenants, usually ranging from the hundreds to thousands or even more.

Figure 1. Multiple application instances vs. Single shared application instance pattern
Multiple application instances vs. single shared applicaiton instance pattern

The selection of resources sharing patterns depends on the specific application scenarios and the target clients' requirements. Typically, a large enterprise may prefer to pay a premium for multiple instances to prevent the potential risks associated with resource sharing. For most services targeting SMB clients with small budgets for a service subscription, to achieve economies of scale, the business model has to increase revenues by recruiting a large number of clients and reducing the average service delivery cost per client by serving these clients with a highly efficient and scalable multi-tenant infrastructure. In these cases, the multiple instances pattern is not practical as the small revenue generated from each tenant won't justify the allocation of dedicated hardware/software resources for the tenant.

Although owning the great benefit of cost effectiveness, the multi-tenancy application that this article focuses on will face many challenges especially with regards to isolation and customization.

First, we should support application-level isolation among different tenants. Although all tenants essentially share the same infrastructure and application instance, from the user experience, Quality of Service (QoS) and administration perspectives, the tenant would naturally desire to access and use the service as if there were dedicated tenants. Therefore, isolation should be carefully considered in almost all parts of architecture design, from both the non-functional and functional level, for aspects such as security, performance, availability, and administration.

Secondly, we should support tenants that customize their own service in runtime without impacting others. Traditionally, customization would involve code modifications and application re-deployment. However, such a customization pattern is impractical in a multi-tenancy-enabled service environment. As all the tenants share the same application instance, once the customization is done for a particular tenant, the services for all tenants will be affected, and possibly interrupted during the update. As the number of tenants increases, the interruptions become more frequent and lead to very serious service availability issues. Therefore, the customization for one tenant without impacting other clients during the runtime should be a key requirement of a multi-tenant application.


Multi-tenant resources: sharing, isolation and customization mechanism of J2EE artifacts

For J2EE/SOA applications, there are many kinds of resources that are accessible, as well as runtime artifacts located in multiple tiers, e.g. user interface, business logic, process/workflow, and data model. To design a highly efficient multi-tenant application, we need to carefully manage those resources via the following two steps:

  • Identify all resources types that may be shared among tenants. Prioritize them according to the estimation of the degree of cost saving it can take via some sharing mechanisms
  • For each kind of sharable resource, list all its potential isolation and configurable points. Evaluate and summarize the most suitable isolation and customization approaches for different multi-tenant scenarios

Table 1 gives a brief summary about those important resources and the corresponding sharing, isolation and customization mechanisms they use. We will introduce them in detail in the following articles of this series.

Table 1. Overview of multi-tenant resource sharing, isolation and customization mechanisms
ComponentsShared ResourcesIsolation ApproachesConfigurable Approaches
Persistant Data Model   
Database Server (JDBC, SDO etc.)

Data Source, Connection Pool

DB Account

Database/Schema/Table/Buffer Pool etc.

Storage Isolation: Dedicated table/schema or database vs. Shared table/schema

Access Isolation: DBMS level access control via dedicated data source and connection vs. Application level access control via filter

Database/table schemas

Fixed reserved fields

Extended sub-tables

XML extended field

File and I/O

Directory

File

Dedicated directory/file

Share files with tenant specific filter

Directory structure or file format

Directory Server (LDAP)

Directory Tree

Schema

Dedicated sub-Tree per tenant

Share tree with tenant specific filter

Directory tree structure and schema definition

Business Logic   
Authentication / Authorization

Organization Structure / Privileges Repository

Login / authorization modules

Isolated repository according to specific persistent data storage (LDAP, DB etc.)

Extended tenant-awareness user registry plug-in

Organization structure, Roles, Privileges and their mapping relationships

Global Java Object

Static variable

Variable of Singleton Class

Dedicate (static) variable per tenant using container object

N/A

Remote Access (Socket/Http, RMI, CORABA, JNDI, Web Service)

Remote Services

Connection Parameters like URI, port, username, password etc.

Dedicated Remote Service

Shared Remote Service, Propagating tenant information to remote services

Connection parameters

EJB

State EJB instance

Data source connection, table of Entity Bean

Queue, sender's identity of MDB

Dedicated State EJB instance, MDB, Queue per tenant

Shared Entity Bean with tenant specific filter

Shared MDB, Queue with tenant identity embedded in Message

Reserved attributes of the shared Entity Bean

Customizable Message Format

Logs

Log file location, content, format and configuration

Dedicate Log file

Shared Log file with tenant specific filter

Log format and setting parameters

Cache

Cache Container

Dedicated cache container

Shared cache container with tenant specific filter

Cache setting parameters

UI   
JSP

Application Scope Variable (tag, usebean, applicationContext etc.)

Declaration variable

Logo,Style,Layout etc

Tenant specific filter for the application scope variable

Dedicated declaration variable

CSS, Layout, Picture etc.

Servlet

Single-thread servlet

servletContext

Dedicated servlet for single-thread servlet

Tenant specific filter for the servletContext variable

N/A

Process/Workflow   
BPEL Process Template

Template Level Attribute, Activity, Link Condition etc.

Dedicated Process Template

Shared Process Template with tenant specific filter in process instances

Skeleton of the Process Templates

Human Task

Verb, Task UI etc

Extended verb to isolate the people selection mechanisms according to the tenant information of the starter

UI elements and setting of Shared Task

People selection rules

Business Rule

Rules

Dedicated Business Rule

Shared business rule with tenant specific filter as rule parameter

Rule value setting of business rules


EasyOA, A sample application

EasyOA is a simple office automation application developed for small businesses. The application primarily includes a vacation application process, in which the employees may raise vacation requests and query their vacation history, while a manager approves the requests of his employees. The administrator has the privileges to view the operation logs of all users of his company.

EasyOA is a typical J2EE application that is based on the following IBM middleware:

  • IBM WebSphere Application Server V6.02
  • IBM WebSphere Process Server V6.02
  • IBM Tivoli Directory Server V6.0
  • IBM DB2 V8.2
Figure 2. Overall architecture and multi-tenancy enablement features of EasyOA
Overall architecture and multi-tenancy enablement features of EasyOA

EasyOA is designed with multi-tenancy enablement. As illustrated in Figure 2, the primary multi-tenant features supported are as follows:

  • Authentication and authorization introduce how to design the organizational structure and access control (privileges) data storage/access patterns. These also enhance the standard Java Authentication and Authorization Service (JAAS) modules/processes in the multi-tenant context.
  • Common J2EE Artifacts introduce how to isolate and customize the resources of user interfaces and business logic via an implicit filter-based mechanism among tenants.
  • Persistent Data Model identifies and evaluates all potential multi-tenant design patterns of data storage/access from many perspectives like isolation, security, customization, and performance.
  • Business Process introduce how to isolate and customize the people/roles selection of human tasks or processes among tenants in a shared process templates pattern

An overall description on the architecture and implementation of these features will be given in the fourth part of this series.


Conclusion

The multi-tenant design pattern - using a single shared application instance to support multiple tenants simultaneously - is very important to the delivery of Web applications in terms of cost effectiveness. In this article, we looked at the overall architectural design principles and related techniques of developing a secure and configurable multi-tenant application by using IBM middleware. It's the overview of a series that will follow with articles that provide more detailed information on this topic.

Resources

Learn

Get products and technologies

  • Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services, Architecture
ArticleID=375225
ArticleTitle=Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware: Part 3: Resource sharing, isolation and customization in the single instance multi-tenant application
publish-date=03112009