Thursday, 16 October 2008

SaaS and J(2)EE


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! ;-)


Post a Comment