Multi-Tenant SOA Middleware for
Srinath Perera, Ph.D.,
Architect, WSO2 Inc.
● What does a Cloud Native Platform needs?
● Challenges of Multi-tenancy
● Carbon Platform
● Multi-tenancy Architecture
Outsourcing IT through Cloud
● Ideally users want to just outsources their non-
competitive IT parts.
● They want to buy IT aspects as a Utility (like
water or electricity), making Niclous Carr's “IT
does not matter” prediction a reality
For developers, integrators, architects
For infrastructure specialists
What does Cloud a Native Platform
● Distributed/Dynamically Wired (works properly in
– Supports deploying in a dynamically sized cluster
– Finds services across applications even when they
● Elastic (Uses the cloud efficiently)
– Scales up and down as needed
– Works with the underlying IaaS
● Multi-tenant (Only costs when you use it)
– Virtual isolated instances with near zero incremental
– Implies you have a proper identity model
What does Cloud a Native Platform
● Self-service (in the hands of users)
– De-centralized creaton and management of tenants
– Automated Governance across tenants
● Granularly Billed and Metered (pay for just what
– Allocate costs to exactly who uses them
● Incrementally Deployed and Tested (seamless live
– Supports contnuous update, side-by-side operaton, in-
place testng and incremental producton
What Multi-tenancy ?
● Many Parties shared same set of resources,
while giving each an his own space
Multi-tenancy is for Maximizing
● Possible SaaS Implementations
– First generation: Machine for User
– Second Generation: VM per User
– Third Generation: Using multi-tenancy to share
same server/machine/VM across users.
Efficient implementations of SaaS needs 3
Multi-tenant SOA Platform
● Data multi-tenancy is great – most of the focus
has been there
● But we need multi-tenancy in other layers as
– E.g. Google apps provides a Servelt as a
● Mosts apps, SOA handles most
logic/executions. A Multi-tenant SOA platform
will ease the development of Apps as a Service
to a greater extent.
To Understand Multi-tenant SOA
platform, you have to first
understand Our SOA Platform
● Developing an architecture to provide SOA
Container (s)/ Platform as a Service.
● Let users run their single tenet apps (Services,
Business processes, Web applications,
Mediation logic, Rules etc. ) in this multi-tenant
environment without any change.
● Goal of multi-tenancy is to provide different users
of the system (which we shall call tenants)
isolation in each of these spaces while
maximizing resource sharing.
● Resource sharing and isolation are a tradeoff.
● Furthermore, Chang et al.  has proposed three
properties for multi-tenancy in addition to
– Multi-tenant-efficient: same instance hosts
Challenges of Multi-tenancy
● Isolation between tenants
● Admin view vs tenants views and programming
model, maximum configuration without
● Scalability: multi-tenancy tend to accumulate
load so it has to be scalable.
● We break multi-tenancy at SOA in to three parts (Based on
Chang et al.).
– Execution: Business Processes, Workflows and Mashups
– Security: ownership and authorization of both data, as well as
executions in the framework
Achieving Tenant Isolation
● Each Tenant is given a Security Domain
● Each domain may have its own User Store and Permissions,
thus have a set of users and permissions enabling users to access
● Each domain is isolated and do not have access to other
Achieving Data Isolation
● All data access to the Carbon platform is done
through Registry interface.
● At Multi-tenant environments, system loads with
multi-tenant implementation of the registry,
which enforces isolation
● Multi-tenancy options at Database level
● Separate database
● Separate tables
● Shared tables ** [We use this]
Achieving Execution Isolation
● All executions are based on Axis2
● Axis2 have stateless executions and keep all state in a
● So if we create different context for each tenant, they
Extending this to Products
● WSAS (Web Services Application Server) ,
Registry, Identity Server directly get Multi-
tenancy once security, data, and execution,
● BPS keeps all the data either in Context or in
registry, and each tenet see a specific view.
● Some products need some work, but in general
they are implemented using registry for data
and services for executions So the
aforementioned model covers most usecases.
● Scaling Up beyond simple Clustering: Tenant partitioning
strategy combined with tenant aware load balancing
● Archival Formats that describe applications that uses
different parts of the SOA (Services, BPEL, Workflows,
Rules, CEP etc).
● Bringing in discovery: WS-Discovery based deployment
● Monitoring and Managing Stratos Deployment
● Making Sessions work with Scalability Solutions
● Tenant-aware JDBC driver
● Supporting Hybrid Cloud Architectures, and on demand
scaling out to Public Cloud.
● Incremental deployment and versioning
● We discussed an architecture to enable multi-
tenancy in an SOA platform
● We discussed how architecture handle three
aspects, Security, data, and execution and how
those three aspects can yield a Multi-tenet SOA
Corporate website: http://wso2.com
Developer portal: http://wso2.org
Business development team: email@example.com