 | Level: Intermediate Amber Roy-Chowdhury (amberr@us.ibm.com), Senior Software Engineer, IBM
Germán Goldszmidt (gsg@us.ibm.com), Distinguished Engineer, IBM
Carl Osipov (osipov@us.ibm.com), Software Architect, IBM
25 May 2007 Multi-tenancy is the capability to service multiple organizations
(clients) from a shared, common hosting environment. This article describes the
concept of multi-tenancy, and it describes the network-delivered approach to
software-as-a-service.
Introduction
Previous articles in this series introduced the concept of composite business
services (CBS), and they outlined some of the core elements of the deployment
environment they require. This article describes multi-tenancy, which is the
capability to service multiple organizations (clients) from a shared, common
hosting environment. It also describes the network-delivered approach to
software-as-a-service (SaaS), and it describes different types of users who might
take advantage of SaaS multi-tenancy. You will learn the principles and technical
implementation that support multi-tenancy in a SaaS hosting environment. This
article offers an implementation of a multi-tenant platform using WebSphere®
Process Server and Portal, virtual portals, and a clone-and-configure
implementation pattern for portlets. The example also offers changes to the
portlet implementation to support extended profile information for portal roles.
This article focuses on the design changes to the software services and to
portlet-based user interfaces in order to support subscribers and end users.
Multi-tenancy
In the software-as-a-service model (SaaS), also known as software
on-demand, delivery of services (such as services described using WSDL) is
based on network-based access to a service provider's software product. This
approach is in contrast to the traditional, shrink-wrapped software delivery
through an installation mechanism. A typical service provider hosts its software
in a large-scale data center and delivers business services using the Internet.
Although the examples in this article focus on a specific case where the service
provider is an independent firm, a service provider could be a department within a
larger enterprise.
Figure 1 describes a SaaS example. Here, a Bank Account Opening service provider
hosts an implementation of an Account Opening service while each subscriber
(tenant) of the service is a bank, such as First Bank and Second Canadian Bank.
Each of these banks, in turn, delivers a bank-specific configuration of the
Account Opening services to its customers.
Figure 1. SaaS example
Detailed examples of the roles in banking software-as-a-service applications are
described in
Building SOA composite business services, Part 1: Develop SOA composite applications to enable business services.
Part 1 refers to the capability to support multiple business service subscribers
(tenants) from a common, shared hosting environment of a service provider as
multi-tenancy.
Support for multi-tenancy is a design concern that cuts across the entire runtime
stack. It requires careful consideration across all of the layers of the runtime
environment's topology, implementation of the services, and user interface. The
options for implementation of a multi-tenant platform span a spectrum: from
hardware-based to virtualized. At one extreme, each subscriber can be hosted on a
dedicated set of hardware and software. This topology yields the most flexibility
to the subscriber through the variety of options available by selecting the actual
hardware used in the hosting environment. For example, you can select specific
performance through the choice of the CPUs. You can also select levels of
reliability based on the server hardware. However, this topology can be the most
expensive, because it forces the provider to manage a dedicated set of servers for
the subscriber. The provider can realize savings by sharing hardware for many
customers. For example, the provider can cut costs by installing multiple
databases on a server with one database per customer. The provider can also share
an instance of an application server to host multiple instances of business
services.
Conceptually, the spectrum of the options for a multi-tenant platform can be
broadly categorized as one of the following:
- Shared nothing
- Shared physical server
- Shared application
It is important to recognize that even the shared-nothing environment can benefit
from a well-defined topology, common hardware/software product definitions, and a
roadmap for consolidation. The shared server category is fairly broad,
encompassing the following options:
- Sharing just the support infrastructure, which is provisioned using products
such as the Tivoli® Provisioning Manager
- Sharing security using products such as the Tivoli Access Manager and WebSeal
- Sharing database services using products such as DB2
- Sharing middleware, such as application, process, and portal servers
This article considers the shared application end of the spectrum: an environment
where the entire stack, including the hardware and software, is reused across the
user population; and the software can be configured (while leaving the option of
customization) for the individual subscribers.
In the upcoming sections of this article, you will learn how support for
multi-tenancy can be implemented. The sections will focus on three core types of
services needed for composite applications, as shown in Figure 2.
Figure 2. Composite application
services
Enterprise services
The following products are used in this article's multi-tenant platform example
to build the infrastructure for CBS:
- WebSphere Portal
- WebSphere Process Server
- WebSphere Service Registry and Repository
- DB2
- An assortment of Tivoli products, including Directory Server
Figure 3. Composite business
services architecture
Although the runtime environment shown in Figure 3 enables the capabilities
required for presentation and business services, some work has to be done by the
service provider administrator to actually expose and configure these capabilities
for the subscribers. Specifically, to introduce a new subscriber (tenant) to the
platform, the service provider administrator must do the following:
- A dedicated realm must be created on the LDAP directory server (Tivoli
Directory Server). The realm must be configured using a predefined structure
directory expected by WebSphere Portal.
- A subscriber account ID must be assigned to the subscriber. The ID is used
with the virtual portals feature of the WebSphere Portal and becomes a part of
the unique URL serving as the Web channel destination for the subscriber.
- Themes and skins must be created for each bank to define the general layout
and the look-and-feel of the subscriber's virtual portal, as well as the
individual portlets. The themes and skins must be installed on the WebSphere
Portal running the multi tenant platform.
Presentation services
The presentation services of a multi-tenant hosting platform should allow for the
subscribers to provide their users with a dedicated entry point for authentication
accompanied with a unique branding. The platform must ensure security for both
subscribers and end users, while safeguarding the information of all of the
platform users. In light of these considerations, the following features must be
available in the presentation services of a multi-tenant platform:
- Channel destination provides the subscriber's end users with an entry point to
the platform. For example, for a Web channel, a unique URL can serve as a
channel destination, but for an IVR channel, a toll-free number can be used.
- Subscriber isolation ensures that the user populations of the individual
subscribers cannot access the business service and information of the other
subscribers of the platform. For example, consider a situation where a single
banking service provider, SaasBank, has two banking service subscribers: First
Bank NA and Second Canadian Bank. In this example, when a customer of First Bank
NA signs in through a Web site, the customer must to be authenticated against
the user population for First Bank NA and not Second Canadian Bank or the
SaasBank.
- Branding ensures that when an end user accesses a channel destination or
authenticates with a channel, the end user is presented with a look and feel
specific to his or her subscriber. For example, after a First Bank NA customer
signs in, the user interface has to be specific to the bank, and any
look-and-feel configurations (such as layout or a user specific skin) modified
by an end user must belong to First Bank NA.
So far, this section of the article has focused on the infrastructure
capabilities, ignoring the effect of the multi-tenant design on the user-facing
portions of a multi-tenant application. In the context of a portal-based
environment, such as WebSphere Portal, the portlets created for a multi-tenant
application must be designed and developed to take into account the considerations
described in the next section.
Because a subscriber provider shares portlets across individual subscribers, each
portlet must be configurable for each subscriber. To enable a high level of reuse,
the degree of configurability in the portlets must support subscriber-specific
settings in a range from name-and-value pair configurations, such as subscriber
IDs or subscriber's service endpoints, to subscriber-specific look-and-feel, with
settings to indicate which form fields or action buttons should be rendered to
end-users. In addition to enabling configurability at the subscriber level, the
individual subscribers must be able to perform the configuration without support
from the service providers.
To address the configuration considerations described in the previous paragraph,
you can adopt a clone-and-configure approach to the implementation and
deployment of the portlets in multi-tenant applications. WebSphere Portal allows
individual portlets deployed to the server to be cloned. For each WAR file
containing the portlet code, a clone or a copy of the portlet can be created with
different configuration options. To support different configuration settings for
different subscribers, the service provider administrator is responsible for
cloning the portlets for each subscriber and assigning the Portal authorization
settings such that the subscribers have access only to their portlet clones. Also,
the service provider administrator assigns additional rights to the subscriber
administrators so that the subscriber administrators are authorized to configure
the cloned portlets.
For example, in the context of a banking multi-tenant application, consider a
portlet that handles user-facing aspects of a Funds Transfer service. If a
fictional SaasBank's service provider wants to expose the Funds Transfer portlet
to Second Canadian Bank, the clone-and-configure approach to deploying the portlet
involves the following steps:
- Open the WebSphere Portal Portlet Management group from the Administrative
console.
- Use the Manage Portlets capability to find and create a cloned copy of the
Funds Transfer portlet.
- Use the Resource Permissions from the Administrative console to find the clone
of the Funds Transfer portlet.
- Add the subscriber administrator for Second Canadian Bank as an administrator
for the cloned Funds Transfer portlet.
From the point of view of the Second Canadian Bank's subscriber administrator,
once the Funds Transfer portlet is available to the bank (the cloned portlet has
been created and assigned the appropriate rights), the subscriber administrator
performs the following steps:
- Find the Funds Transfer portlet using Administrative console > Portlet
Management > Manage Portlets.
- Open the configuration for the Funds Transfer portlet, and specify the
subscriber account ID for the Second Canadian bank.
- Review and modify as necessary the other settings of the Funds Transfer
portlet, such as service endpoints.
Business services
As shown in Figure 2, the business services of a multi-tenant
application must be designed to receive and process requests originating from
different subscribers by way of a presentation layer. Furthermore, the design and
implementation of business services must permit the services to be both reused and
customized for each of the subscribers and users.
As discussed in the previous section, each subscriber of a multi-tenant platform
is identified by a unique, platform-wide subscriber ID. At the user interface
layer, the subscriber-specific portlet configuration is responsible for
maintaining the ID and keeping the IDs associated with the subscriber's end-users.
The service requests generated by the end-users at the presentation layer are
handled at the business logic layer, where the IDs are treated as configuration
parameters to the business services.
Passing the subscriber ID from the presentation to the business layer affects the
business service implementation in two ways. First, the design of the WSDL
interface, specifically the design of the message schema for the data flowing into
the service, must contain the subscriber ID as one of the parameters. For example,
in the code snippet below, the subscriber ID is implemented as a variable called
bankID as part of the processLoan message used in a sample
loan-processing business process.
Listing 1. Sample code listing at maximum width
<!--
<wsdl:types>
<schema elementFormDefault="qualified"
targetNamespace="http://process91958946.www.example.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:impl="http://process91958946.www.example.com"
xmlns:intf="http://process91958946.www.example.com"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<element name="processLoan">
<complexType>
<sequence>
<element name="bankId" nillable="false" type="xsd:string"/>
<element name="loanAmount" nillable="true" type="xsd:decimal"/>
<element name="customerId" nillable="true" type="xsd:string"/>
<element name="ssn" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
</element>
<element name="processLoanResponse">
<complexType>
<sequence/>
</complexType>
</element>
</schema>
</wsdl:types>
|
Second, the implementation of the services at the business layer must use the
subscriber ID to provide variability for service subscribers and individual
end-users. A multi-tenant platform built using WebSphere Process Server (WPS)
offers a number of options for adding variability to a service implementation. For
example, a business process created using WebSphere Business Modeler can be
augmented to indicate the points of variability that translate into business
process execution language (BPEL) business rules suitable for execution on WPS.
Alternatively, business rules can be specified in the BPEL workflows directly,
using WebSphere Integration Developer, without the need for WebSphere Business
Modeler. For instance, a single rule in a loan approval process for different
subscribers can use different credit scores for pre-approvals for loan applicants,
such as automatic approvals for those of First Bank NA who have a credit score of
over 720, but a score of over 750 is required for applicants with Second Canadian
Bank.
Conclusion
This article described key architectural concepts of a multi-tenant-enabled
platform for CBS. Roles in multi-tenant platform were explained using examples
from a banking application by showing relationships between service providers,
service subscribers, and end-users of a multi-tenant application. The application
architecture was decomposed into key types of services: infrastructure,
presentation, and business. The article discussed the underlying runtime
architecture of the infrastructure services, the issues around presentation
services, the clone-and-configure pattern, and the impact of multi-tenant
application design on business services implementation.
Resources Learn
Discuss
About the authors | 
| | Amber Roy-Chowdhury is a Senior Software Engineer at IBM, based in Research Triangle Park, NC. He works on WebSphere Portal architecture and development. He is currently the architect and technical lead for the brokered communication framework for WebSphere Portal, known as the Property Broker. Previously, Amber has worked on lead development roles on the WebSphere Application Server and Encina Transaction Processing Monitor products. Amber holds a Ph.D. from the University of Illinois, Urbana-Champaign. |
| 
| | Dr. Germán Goldszmidt is a Distinguished Engineer working in the IBM Software Group, with focus on architecture of an integrated platform to deliver, customize, and deploy SOA composite business services. Previously, he was a researcher at the IBM T.J. Watson Research Center, and he led the design and implementation of several technologies, including Océano, the first prototype autonomic computing eUtility, and Network Dispatcher, the load balancer component of WebSphere products. |
| 
| | Carl Osipov is an experienced software architect with the Strategy and Technology organization in IBM Software Group. His skills are in the area of distributed computing, speech application development, and computational natural language understanding. He has published and presented on Service-Oriented Architecture and conversational dialog management to peers in the industry and academia. His current focus is on design of reuse techniques for composite business services. |
Rate this page
| |
