JAVA Spring Hibernate Multi-tenant (SASS) — practical implementation

JAVA Spring MVC Hibernate Multi-tenant (SASS-Cloud) — practical implementation

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Spring Multi-tenant architecture — practical implementation

Abstract

Multi-tenancy architecture is often used where single instance of software or components run on server the central idea is that multiple tenant applications share single instance or components stored in the infrastructure Meta data., In other words, in Multi-tenancy architecture each tenant application not only needs to develop its own functionalities, but also needs to prepare an infrastructure to allow its tenants to run customized applications. This article propose implementation models for Multi-tenancy in Spring as an example, and discusses their trade-offs including their formal notations and application scenarios.

• What is Multi-tenancy?

– Multi-tenancy is a principle in software architecture where a single instance of the software runs on a server, serving multiple tenants

– A tenant is a group of users sharing the same view of the software instance Under specific privileges

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Architecture of the application

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Benefits of Multi-tenancy

Cost savings

What if we try to implements all types of requirements for all application instances?

Assume we have different instance running on different Application Server and all have the same application what are the issue of this design?

– Number of components increased if the application tries to handle every specific user or group of users requirements

– Components will explode more if another group of users requirements joins the to accommodate all permutations and combinations

– Hard to manage the components and leads to lot of refactoring, defects, and post-production maintenance problems due to complexity

– Components management difficulties at source control level especially for large scale

– Complex build script to deploy each specific application

– Component configuration complexities for spring configuration and bean injection issues

– Unnecessary other instance of application specific bean creation issues to support multi-tenancy that leads to memory bloating

– Need to support customizations for existing program functionality for each version at various levels such as

– Source code level support

– Java server pages (JSPs)

– Controllers

– Delegators

– Service classes

– Data Access Layer classes

– Configuration files

Solution:

Create instance specific beans using spring framework scope functionality by creating custom scope

· Keep each specific functionality in the same base component

· Differentiate each specific functionality by using a predefined package structure that starts with specific code by using the pattern for naming

· Keep jsp files under specific folder in webapp for each

· Create specific configuration file to keep all specific configurations at one place

· And more importantly, create new scope class to support instantiation of each specific bean instead of instantiating each bean (one time at framework level)

Spring MVC snapshot concept

The Spring Web model-view-controller (MVC) framework is designed around a DispatcherServlet that dispatches requests to handlers, with configurable handler mappings, view resolution, locale, time zone and theme resolution as well as support for uploading files. The default handler is based on the @Controller and @RequestMapping annotations, offering a wide range of flexible handling methods.

Spring configurations for beans definitions

Files involved in MVC configuration:

· Tables definition (definitions-xxx.xml)

· Controller (XXServlet.xml)

· Service definition (xxx.xml)

· DAO definition (xxx.xml and xxx.hbm.xml)

We can see that spring architecture make a clear separation between each layer in the three tiers architecture.

Multi-tenancy Scenarios

Code level support for multi-tenancy is needed for three types of requirements:

– Scenario 1: Overriding the existing functionality which is unique to each instance

• Screen level:

– adding new fields

– removing fields,

– customizing the labels

– Custom error or validation messages

• Business logic: each instance may need specific business rules implementation

– Overriding the existing functionality

– Scenario 2: new requirement for one instance only (unique to the specific instance)

– Scenario 3: New requirement for all instance that is same for all

– Scenario 4: New requirement that is common for all instance except different for other instances

Scenario 1: Overriding existing functionality for each instance

• Possible requirements:

Ø Screen fields may be different from baseline and different for each instance

Ø Business logic may be different from baseline and different for each instance

Ø Database changes to implement each specific functionality

• No impact to Baseline Code:

Ø Common data model, so no impact at database level for each instance.

Ø Since it is common data model, data objects such as entity objects, value objects and command objects are common for all instances. Changes for one instance are applicable to all with no business impact

• Multi-tenancy Support:

Ø If screen changes are needed:

• Custom screen for each instance

• Changes needed at tiles definition configuration file

• Bean id definition changes in Spring configuration file

• No changes needed at controller level

• Delegator classes need to be created and configured

Ø If business logic changes are needed (Service Layer):

• Custom service class need to be created

• Configuration changes in spring configuration file

• Extend the base class and either override an existing method or add new method

Ø If database changes are needed (DAO Layer):

• Custom persistence class need to be created

• Extend the base class and either override an existing method or add new method

• Configuration changes in spring configuration file

• Database changes

• hbm file changes

• Changes to entity object, value object and command object if needed

Scenario 2: New requirement for one instance only (unique to each instance)

· Possible requirements:

- New Screen

- New service classes to accommodate business logic

- Database changes to implement instance specific functionality

· No impact to Baseline Code:

- Since it is common data model, data objects such as entity objects, value objects and command objects are common for all instances. Changes for one instance are applicable to all with no business impact

· Multi-tenancy Support:

If new screen is needed:

- Custom screen for each instance

- Changes needed at tiles definition configuration file

- Bean id definition changes in Spring configuration file

- No changes needed at controller level

- Delegator classes need to be created and configured

– At business logic changes are needed (Service Layer):

• Custom service class need to be created

• Configuration changes in spring configuration file

• If applicable, extend the base class and either override an existing method or add new method

– If database changes are needed (DAO Layer):

• Custom persistence class need to be created

• If needed, extend the base class and either override an existing method or add new method

• Configuration changes in spring configuration file

• Database changes (through DRR)

• hbm file changes

• Changes to entity object, value object and command object if needed

Scenario 3: New requirement for all each instance that is same for all

· Possible requirements:

- New Screen

- New service classes to accommodate business logic

- Database changes to implement instance specific functionality

· Multi-tenancy Support:

- All the steps are same as Scenario 2 but all the files are put at base product level instead of instance specific custom package level

Scenario 4: New requirement that is common for more than one instance and different for other

§ Possible requirements:

- New Screen

- New service classes to accommodate business logic

- Database changes to implement instance specific functionality

§ Multi-tenancy Support:

- The requirements that are common for more than one instance follows scenario 3 flow and all the changes and new files are part of product level

- The requirements unique for one follow scenario 1 flow and the new files are placed in respective instance packages

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Structure Of The Application

Project name
src
com.example.configuration
com.example.controller
com.example.service
com.example.serviceimpl
com.example.entity
com.example.master
com.example.multitenant
com.example.dao
com.example.daoimpl
com.example.helper

application.peroperties

web contents

all view folders

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

master database contains only client name and its schema related data i.e. database URL , username, password etc.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —