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
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
|Components||Shared Resources||Isolation Approaches||Configurable Approaches|
|Persistant Data Model|
|Database Server (JDBC, SDO etc.)|
Data Source, Connection Pool
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
Fixed reserved fields
XML extended field
|File and I/O|
Share files with tenant specific filter
Directory structure or file format
|Directory Server (LDAP)|
Dedicated sub-Tree per tenant
Share tree with tenant specific filter
Directory tree structure and schema definition
|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|
Variable of Singleton Class
Dedicate (static) variable per tenant using container object
|Remote Access (Socket/Http, RMI, CORABA, JNDI, Web Service)|
Connection Parameters like URI, port, username, password etc.
Dedicated Remote Service
Shared Remote Service, Propagating tenant information to remote services
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
Log file location, content, format and configuration
Dedicate Log file
Shared Log file with tenant specific filter
Log format and setting parameters
Dedicated cache container
Shared cache container with tenant specific filter
Cache setting parameters
Application Scope Variable (tag, usebean, applicationContext etc.)
Tenant specific filter for the application scope variable
Dedicated declaration variable
CSS, Layout, Picture etc.
Dedicated servlet for single-thread servlet
Tenant specific filter for the servletContext variable
|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
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
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
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.
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.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- "Develop and deploy multitenant Web-delivered solutions using IBM middleware, Part 1: Challenges and architectural patterns" (developerWorks, Apr 2008) describes what multi-tenancy is and presents several technical challenges for building and deploying multi-tenant web-delivered solutions.
- "Develop and deploy multi-tenant Web-delivered solutions using IBM middleware, Part 2: A taxonomy of current approaches to enable multi-tenancy" (developerWorks, To Appear) present a taxonomy of current approaches to enable multi-tenancy in web-delivered business solution (a.k.a software-as-a-service) and compare the costs and benefits of the three approaches that we have identified.
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®.
- Participate in the discussion forum.
- Check out developerWorks blogs and get involved in the developerWorks community.