Multitenancy refers to the architectural principle whereby a single instance of software runs on a software-as-a-service (SaaS) vendor’s servers, whilst serving multiple client organizations (tenants). This is in contrast to multi-instance architecture where separate software instance or hardware systems are set up for different client organizations. in other words, under a multitenant architecture, applications are required to virtually partition data and configuration so that each client organization works with a customized virtual application instance. Customization typically includes aspects like user interface branding, access control, data and configuration, workflow, etc
The primary goal of multitenancy is cost savings, both for the SaaS provider and client. For the client the saving results from not having to operationally manage the application. For the provider the saving results from lower operational costs because of a single application instance on shared infrastructure providing a sevice to multiple tenants.
Deployment Options
From a deployment perspective there are several options whereby the requirement to host multiple tenants may be supported. For each option there are the following criteria to considered by the SaaS provider:
• the capability of the underlying platform to host the desired configuration
• the trade off between operational cost and application performance
• regulatory requirements
• perceived data isolation
• operational costs
• solution extensibility
• business continuity
• liability regarding breaches
JEE Application Server Deployment Scenarios
1. Fully Isolated Application server
Each tenant accesses an application server running on a dedicated server
2. Virtualized Application Server
Each tenant accesses a dedicated application running on a separate virtual machine
3. Shared Application Server
The tenants shared the application server and access application resources through separate session or threads.
Database deployment scenarios
1. Fully isolated data center
The tenants do not share any data center resources
2. Virtualized servers
The tenants share the same host but access different database running on
separate virtual machines
3. Shared Server
The tenants share the same server (Hostname or IP) but access different databases
4. Shared Database
The tenants share the same server and database (shared or different ports) but access different
schema (tables)
5. Shared Schema
The tenants share the same server, database and schema (tables). Their respective data is segregated by key and rows.
Challenges to JEE Applications
Typical JEE applications using EJBs with a DBMS back-end that have not been built with multitenancy in mind can usually support most of the deployment options above quite easily. The challenge is supporting that shared application server and schema model. An approach for these is proposed below.
Application Server Challenges
For a single server instance (JVM), hosting the same application more than once will require a some changes, e.g. a unique web context root for each instance and a mechanism for ensuring the JNDI names do not clash. This would typically require a build brocess that generates EARs targeted at tenants, tweaking the context root and JNDI names in the deployment descriptors. The use of resource references to remove hardcoded JNDI names from source code would also be required.
In addition, the tenant id would need to be propagated all the way through the application to enable correct JNDI lookups to be performed.
Of course the ideal would be that only stateless session beans are used and are packaged in a way that they are common to multiple tenant web applications. This is one more instance where entity beans suck.
Database Challenges
For a single database schema to be shared amongst multiple tenants, 2 options exist. Either (i) use a DBMS native feature such as Oracle Virtual Private Database to create multiple, tenant-specific virtual schemas, or (ii) add an ENTITY_ID column to every table and SQL statement in the application.
The former is of course much easier, but if portability is important then the latter option is preferred. The impact to the application server is in the first instance that a different datasource would be required for each tenant, and in the second instance, that the tenant id be added to each SQL statement.
So if your sales team has dropped you in it and sold your J(2)EE application to a SaaS provider, you now know that its not the end of the world! ;-)