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.
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
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
- 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.
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.
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.
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.
- Use an
to request notification for the upcoming articles in this series. (Find out more
RSS feeds of developerWorks content.)
- Learn more about the
Member Manager LDAP repository configuration.
- Learn more about
multiple virtual portals.
- Consult this
for a valuable piece on how to customize the portal.
- Stay current with
technical events and webcasts.
- Check out a quick
services on demand demo.
The IBM SOA Web site
offers an overview of SOA and how IBM can help you to get there.
- Visit the
SOA and Web services zone
to learn more about SOA.
- Participate in
and get involved in the developerWorks community.
- Collaborate with a community of architects
and developers in the
SOA and Web services discussion forums.
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.