 | Level: Intermediate Germán Goldszmidt (gsg@us.ibm.com), Distinguished Engineer, IBM
Indrajit Poddar (ipoddar@us.ibm.com), Senior Software Engineer, IBM
24 Apr 2008 Web-delivered solutions that follow a Software as a Service (SaaS) delivery
model—where customers subscribe to software and access it from a service provider
site rather than get licenses and have software installed on their premises—can
offer compelling business value for businesses of any size. Solution developers who
develop new solutions or transform existing solutions and service providers who
deploy these solutions are faced with several technical challenges. One example is
multitenancy, where a single instance of the software, running on a service
provider's premises, serves multiple organizations. This article series describes
different patterns to address these challenges, often using Service-Oriented
Architecture (SOA) techniques. Also learn how IBM® software
products can help you build and deploy
scalable, configurable, and cost-effective multitenant Web-delivered solutions.
What is multitenancy,
and what are its benefits and drawbacks?
The ability to deliver software to multiple client organizations (or
tenants) from a single, shared instance of the software is an important
requirement for Web-delivered solutions. For example, consider a simple banking
application offered as a service by a banking service provider.
Multitenancy in this context refers to the ability to offer the banking
service to multiple banks from a single, shared instance of the banking
application. Figure 1 illustrates a multitenant banking service offered to two
banks—1st Bank N.A. and 2nd Canada Bank—from shared application
servers, databases, operating systems, and physical servers.
Figure 1. Sample multitenant
Web-delivered service for banking built using shared middleware and hardware
The major benefit of multitenancy is cost effectiveness. Sharing software,
hardware, application development, and maintenance costs between tenants can lower
the costs for each tenant. Furthermore, sharing a single instance of an
application between tenants can provide additional benefits, for example, all
tenants can be simultaneously upgraded whenever the application is upgraded.
However, multitenancy also brings potential issues, such as:
-
Isolation: Because tenants share the same instance of the software and
hardware, it's possible for one tenant to affect the availability and
performance of the software for other tenants. For example, if the shared
software doesn't have adequate safeguards, it might be possible for one tenant's
user to bring down the shared software, thus denying service to all the tenants
sharing that instance.
-
Security: If the shared software doesn't have adequate safeguards, it
might be possible for users of one tenant to access data belonging to another
tenant.
-
Customizability: Because the software is shared between tenants, it may
not be possible to customize the software for each tenant. For example, without
adequate extension points, it may not be possible for one tenant to provide its
own implementation of a business process.
-
Application upgrades can cause problems for a tenant: Simultaneously
upgrading the shared software may not be desirable for all tenants.
-
Recovery: Sharing the database amongst tenants makes it difficult to
back up and restore data for each tenant separately.
While there are multiple approaches for building a multitenant architecture, this
article focuses primarily on techniques that enable sharing a single instance of
the middleware and database, and amongst multiple tenant applications.
Other approaches for multitenancy include operating system (OS)-level
virtualization. For example, VMWare, Xen, or OpenVZ allow multiple virtual
instances of the OS to run on a shared instance of hardware. Each virtual OS
instance can execute software for a different tenant. Another approach can be
establishing OS-level boundaries for each tenant. For example, each tenant's
application could be running in a new instance (different OS process) of
IBM WebSphere® Application Server.
Multitenancy technical
challenges
The technical challenges of multitenant applications can be categorized in terms
of the major organizations and roles facing these challenges: the solution
developers and the service providers.
Technical challenges faced by solution developers include:
-
Access control: How can application resources—for example,
virtual portals; database tables; workflows; Web services; Java™ 2
Platform, Enterprise Edition (J2EE) artifacts—be shared between tenants
so that only users belonging to a tenant can access the instances belonging to
that tenant? For example, how can you ensure that users of other banks (such as
1st Bank N.A.) aren't able to access the resources (such as the virtual portal)
for 2nd Canada Bank?
-
Customizability:
-
Database: How do you customize a shared database schema for one
tenant without affecting others? For example, how can 2nd Canada Bank
introduce a new data field into the shared database table for customer
profiles without impacting the schema definition for 1st Bank N.A.?
-
User interface: How can you enable customization of the Web site
look through configuration only (that is, without code changes)? For
example, how do you ensure that bank administrators for 1st bank N.A. and
2nd Canada Bank can configure different designs and show additional fields
in their customer profile portlets?
-
Business logic: How can you allow the business logic to be
customized for each tenant without code changes? For example, how can 1st
Bank N.A. use a minimum credit score for automatically rejecting loan
applications, which is different from 2nd Canada Bank?
-
Workflows: How do you let tenant banks customize the assignment of
human tasks and other conditional tasks in shared workflows? For example,
how can 1st Bank N.A. ensure that the loan approval tasks in shared
workflows be assigned to employees of 1st Bank N.A. only?
-
Tenant provisioning: How can you automate the provisioning of a new
tenant? For example, how can a new bank, 3rd Fairfield Trust for example, be
brought on board with very few manual steps (that is, how can steps like
creating a new LDAP subtree or database, creating a new virtual portal,
deploying new instances of portlets, and registering new IBM DB2® XML
schemas be automated)?
-
Usage-based metering: How do you record usage of a service so that each
tenant can be charged only for the usage of a service? For example, how can the
banking service provider administrator meter service usage for the tenants, 1st
Bank N.A. and 2nd Canada Bank, for the number of times their customers have
invoked the loan application service?
Technical challenges faced by service providers include:
-
Database sharing, customization, backup, and restore of tenant-specific
data: How can service providers choose between different database
partitioning schemes based on performance, management, and scalability criteria?
For example, how can the service provider accommodate 2nd Canada Bank's
disaster-recovery requirement of backing up only its data from tables shared
between multiple tenants?
-
Rapid enablement of multitenancy for existing Web services: How can
single-tenant Web services implementations be enabled for multitenancy with
little or no code changes? For example, how can you enable multitenancy for a
single-tenant credit-check service without making code changes to the Web
service interface and implementation?
-
Managing connectivity between a large number of third-party service
providers and departmental service consumers in a large enterprise: Lines
of business (LOBs) within large enterprises demonstrate many characteristics of
a tenant in a Web-delivered application. Different LOBs in the same enterprise
may consume services from different third parties or from internal service
providers. A large number of such service providers may lead to management
problems for the central IT department in the enterprise. For example, different
LOBs (such as line-of-credit and mortgage loan departments) in the banking
service provider enterprise may use different credit-check service providers.
How can the central IT department monitor, authorize, and meter the usage of the
multiple credit-check services by different LOBs in the enterprise?
-
Scalability, improved hardware usage, and tenant-specific quality of
service (QoS): How can service providers improve the usage of hardware
that's shared between different tenants and provide scalability? How can service
providers offer differentiated QoS for different tenants? For example, how would
you accommodate differentiated QoS requirement from 2nd Canada Bank so that its
services are hosted in dedicated hardware in return for higher service usage
charges?
 |
Patterns for addressing
multitenancy technical challenges
You can apply several SOA techniques to address the technical challenges related
to multitenancy.
Patterns for solution developers
-
Start small with standards-based entry-level middleware: An upcoming
article in this series describes how you can develop a multitenant Web-delivered
application using entry-level middleware from IBM. This entry-level middleware
stack includes IBM WebSphere Application Server Community Edition, IBM DB2
Express-C, and OpenLDAP. Solutions developed for the entry-level stack can give
service providers the option of purchasing support from IBM.
Watch a
demo and download sample code
for an application built using the entry-level stack. Figure 2 depicts the
different functional layers of the sample multitenant application. Future
articles in this series will show how to combine the entry-level stack with some
products in the enterprise-level stack, such as IBM Tivoli® Usage and Accounting Manager and WebSphere Application Server, Extended Edition to support metering, scalability, and isolation.
Figure 2. Functional layers in a sample multitenant application built using IBM middleware
-
Grow into enterprise-level middleware: While it may be easier to get
started with an entry-level stack, often advanced features, scalability,
performance, and integration concerns are inadequately addressed. Thus, to build
mission-critical Web-delivered applications, it's better to use enterprise-level
middleware. In a series of recorded demonstrations, which you can access from
the
SaaS demonstration series,
we describe multiple features of an enterprise-level IBM middleware stack and
techniques that can be used to develop multitenant Web-delivered solutions.
Additional technical details for each demo are included in a set of articles
listed in the Resources section. Topics presented in
the demo series include:
-
Introduction: How middleware features can be exploited to build a
multitenant application.
-
WebSphere Portal Server: A technique for supporting multitenancy
using virtual portals in WebSphere Portal Server (note that there are
different ways of supporting multitenancy; this shows one possible
technique). Read technical details from
"Building
SOA composite business services, Part 7:
Supporting multitenancy for composite business services"
(developerWorks, May 2007).
-
IBM WebSphere Portlet Factory: How can you compose a portlet-driven
multitenant user interface using dynamic profiles in WebSphere Portlet
Factory? Read technical details from
"Building
SOA composite business
services, Part 8: Building multitenant portlets using WebSphere Portlet
Factory dynamic profiles"
(developerWorks, Jun 2007).
-
IBM DB2 V9: Designing a multitenant data architecture that allows
customizing the schema for each tenant using pureXML. Read technical details
from
"Data Integration and Composite Business Services, Part 3: Build a multi-tenant data tier with access control and security"
(developerWorks, Dec 2007).
-
IBM WebSphere Portal Server, IBM WebSphere Process Server, and IBM
Tivoli Directory Server: Demos on building a multitenant user registry
and on enforcing role-based access control using WebSphere Portal Server and
Tivoli Directory Server, and a demo on building secure workflows with human
tasks using WebSphere Process Server and Tivoli Directory Server. Read
technical details from
"Securing a composite business service delivered as a
software-as-a-service: Part I, secure multi-tenancy with WebSphere Portal
Server"
(developerWorks, Sep 2007) and
"Securing a composite business service delivered as a
software-as-a-service: Part II, Supporting identity propagation (enterprise and federated
SSO) and authorization"
(developerWorks, Sep 2007).
Figure 3 shows how different IBM middleware products in the entry-level
stack and in the enterprise-level stack address these functional layers.
Figure 3. IBM middleware products used to implement the functional layers in the sample multitenant application built using IBM middleware
This series of articles builds on the above articles and demos, and describes
some advanced techniques for building multitenant applications using IBM
middleware. For example, one article will demonstrate how to isolate human tasks
in shared multitenant workflows in WebSphere Process Server. Another article will
describe how to use Tivoli Usage and Accounting Manager to provide usage-based
metering and billing solutions.
Patterns for the service provider
-
Choose the right level of data-tier isolation for customizability and ease
of tenant data management: Service providers can choose to:
- Isolate the data for each tenant into different databases.
- Isolate the data for each tenant into separate tables and a schema.
- Share the same set of tables and a schema between all tenants.
When sharing the schema between tenants, customizing the data fields for
each tenant is a challenge. An upcoming article in this series evaluates a set
of patterns for addressing this challenge from many dimensions, including
performance, management, and scalability. IT also demonstrates some techniques
to improve manageability, for example, showing how to accommodate backup and
restore of tenant-specific data when sharing the schema between all tenants.
-
Rapidly enable multitenancy for existing Web services using IBM WebSphere
Enterprise Service Bus, IBM WebSphere Business Services Fabric or IBM
WebSphere DataPower® SOA Appliances: Service providers may need to
rapidly enable multitenancy for an existing Web service implementation. Making
code changes in existing implementations to support multitenancy from the ground
up may require a significant effort. Alternatively, it's possible to build a
middleware-based mediation layer to enable different Web service endpoints to
service requests for different tenants. In this case, the existing Web service
implementation doesn't need to be modified. An upcoming article in this series
illustrates how you can implement this pattern using WebSphere Business Services
Fabric, WebSphere Enterprise Services Bus, and WebSphere DataPower SOA
Appliances.
-
Route third-party SaaS service invocations in large enterprises through a
central mediation layer: An enterprise IT department can use a central
mediation layer to route all third-party service invocations from different
departments in an organization. This type of mediation layer can provide
additional functions, such as authorization, monitoring, and metering for
service usage. An upcoming article in this series demonstrates how a mediation
pattern based on an enterprise service bus (ESB) can support these types of
requirements.
-
Scale with entry-level middleware, and improve usage of hardware using IBM
WebSphere Application Server, Extended Edition: Scalability requirements
are often not given adequate consideration at the onset. When these requirements
become important, service providers often scale out with a larger number of
low-cost small servers. However, scaling out might bring out other challenges.
For example, this approach may either:
- Lead to overprovisioning of hardware to support infrequent peak loads for
a few tenants.
- Increase the management complexity due to a large number of middleware
instances.
-
Isolate applications for different tenants, and support tenant-specific QoS
requirements with WebSphere Application Server, Extended Edition: Service
providers can isolate a tenant's application into dedicated hardware, while
running other tenants' applications in shared hardware by exploiting server
isolation policies in IBM WebSphere Extended Deployment. In addition, solution
developers can take advantage of the programming model of the WebSphere
Partitioning Facility feature in WebSphere Extended Deployment to build multitenancy-enabled
applications. An upcoming article demonstrates how you can use WebSphere
Extended Deployment to support tenant-specific QoS requirements and partition
applications for multitenancy.
|
Conclusion
Scalable multitenancy is an important requirement for Web-delivered (SaaS)
solutions. However, building multitenant solutions requires addressing several
technical challenges. Using IBM middleware, solution developers and service
providers can build and deploy scalable, customizable, manageable, and
cost-effective multitenant solutions. This series of articles presents a few
relevant IBM middleware features and techniques, and describes how to apply them
to address the above technical challenges. Stay tuned!
Resources Learn
- Check out the
SaaS
demonstration series
for a lot of great information.
- Read the following articles for more
information:
- "Building
SOA Composite Business Services, Part 7: Supporting multitenancy for Composite Business
Services"
(developerWorks, May 2007)
- "Building
SOA composite business services, Part 8: Building multitenant portlets using WebSphere
Portlet Factory dynamic profiles"
(developerWorks, Jun 2007)
- "Data
Integration and Composite Business Services, Part 3: Build a multitenant data tier with
access control and security"
(developerWorks, Dec 2007)
- "Securing a
composite business service delivered as a software-as-a-service: Part I, secure
multitenancy with WebSphere Portal Server"
(developerWorks, Sep 2007)
- "Securing a
composite business service delivered as a software-as-a-service: Part II, Supporting
identity propagation (enterprise and federated SSO) and authorization Using Tivoli Access
Manager and Tivoli Federated Identity Manager"
(developerWorks, Sep 2007)
- "Make composite business
services adaptable with points of variability, Part 1: Choosing the right
implementation"
(developerWorks, Apr 2007)
- The
SOA and Web services zone
on IBM developerWorks hosts hundreds of informative articles and introductory,
intermediate, and advanced tutorials on how to develop Web services applications.
- Play in the
IBM SOA Sandbox!
Increase your SOA skills through practical, hands-on experience with the IBM SOA
entry points.
- The
IBM SOA Web site
offers an overview of SOA and how IBM can help you get there.
- Stay current with
developerWorks technical events and webcasts.
- Browse for books on these and other technical
topics at the
Safari bookstore.
- Check out a quick
Web services on demand demo.
Get products and technologies
- Innovate your next
development project with
IBM trial software,
available for download or on DVD.
Discuss
About the authors | 
| | Dr. Germán Goldszmidt is a distinguished engineer working in the IBM Software
Group, with a focus on architecture of an integrated platform to deliver,
customize, and deploy Service-Oriented Architecture (SOA) composite business
services (CBSs). |
| 
| | Indrajit Poddar (IP) is a member of the Strategy, Technology, Architecture and Incubation (STAI) team in the IBM Software Group, where he is architecting a number of PoCs for building SOA composite business services using IBM SOA Foundation products. |
Rate this page
| |
