In the mediation approach for multi-tenancy, a centralized proxy layer as shown in Figure 1, mediates between requests coming from users belonging to multiple tenants and multiple instances or partitions of an application. This centralized proxy layer routes requests from a particular tenant’s users to a tenant specific application instance or partition and efficiently enables additional common multi-tenancy features such as access control, metering, monitoring, auditing etc. The mediation pattern thus offers a separation of concerns between the service provider/developer and a new role which we will refer to as the platform provider (see SaaS Platform in Resources). With such a separation, service providers or service developers can re-use existing applications while leveraging multi-tenancy enablement features from a platform provider.
Figure 1. A mediation approach for multi-tenancy
Technical challenge to be addressed with the mediation approach
Part 1 of this series describes several technical challenges faced by service providers when deploying multi-tenant web-delivered solutions. One such challenge is how to enable multi-tenancy for existing single tenant web services with little or no code changes.
One approach for addressing this challenge is to parameterize all operations in the web service interfaces and implementations with a tenant id parameter. Figure 2 shows an example single tenant web service called retrieveCreditScoreBySSN and Figure 3 shows the addition of a tenantID parameter for multi-tenancy. We have referred to this approach as the “multi-tenancy with sharing” approach in Part 2 of this series. This approach will require code changes (WSDL and java classes) and redeployment for the existing application and therefore may be difficult and expensive to carry out.
Figure 2. Interface definition for a simple credit score service
Figure 3. Interface definition changes for adding tenant specific request attribute
The "multi-tenancy with mediation" approach can be applied to this challenge with certain benefits. In this approach, service providers can build a web service mediation proxy layer which can route service requests from a tenant’s user to tenant specific service endpoints. This will offer the benefit of little or no code changes for the existing service implementation. In addition, they will be able to efficiently enable other desirable multi-tenancy features such as metering and access control. This approach will be illustrated through a scenario and describe three implementation options using IBM middleware products.
Illustrating the mediation approach
Our example scenario has a multi-tenant banking application called Jivaro with two tenants: First Bank of NA (First Bank) and Second Canada Bank (Second Bank). The Jivaro service provider administrator Sam Peters, would like to offer a new credit check web service integrated with two external service providers: Expo and S&R.
Figure 4. Banking Scenario
The requirements include:
- Ability to enable multi-tenancy without any code changes to his existing single tenant credit check service.
- Based upon requests from Betty Nord, the First Bank administrator and Caren Sims the Second Bank administrator, he’d like to specify a routing rule in the mediation pattern layer.
- After specifying this rule, Bob Nottingham, a First Bank customer, will have his requests routed to the Expo service provider, and Carrie Serrano, a Second Bank customer will have her requests routed to the S&R service provider.
- Ability to authorize Bob Nottingham and Carrie Serrano before they can access his multi-tenant credit check service.
- Capable of monitoring the number of times First Bank N.A.’s and Second Canada Bank’s customers are using his credit check service in a given period.
The scenario is described in three recorded demos corresponding to three implementation options, which can all be found on the IBM SaaS Blueprints website.
Implementing the mediation approach
In three tutorials following this article (Parts 6, 7, 8), we will show how the mediation approach can be implemented using any of the following three options of IBM middleware products:
- WebSphere Business Services Fabric (WBSF)
- WebSphere Enterprise Service Bus (WESB) with WebSphere Service Registry and Repository and Tivoli Access Manager (TAM)
- WebSphere DataPower SOA appliances with Tivoli Access Manager
Note: WebSphere Message Broker can also be used as another implementation option. Please refer to the following article for more details on WebSphere Message Broker.
As discussed in Part 2 of this series, this approach can be combined with a sharing approach or a virtualization approach for enabling multi-tenancy. In the three following tutorials, we will assume that service provider uses approach 3 as described in Part 2 for lower development effort. In this model, each tenant gets its own instance of the application and middleware but use a shared operating system and hardware.
The remaining sections will introduce the major steps for each of the three options discussed above. The details for each step will be described in the following tutorials.
Major Implementation steps when using WBSF
There are three major steps when using WebSphere Business Services Fabric (WBSF) to implement this mediation approach:
- Define a composite business service with routing policies for each tenant specific
a). Install the WBSF Modeling Tool on Rational Software Architect 7
b). Model a new TenantIDAssertion using the WBSF Modeling Tool
c). Configure the WBSF server and import the TenantIDAssertion
d). Create a Credit Score Composite Business Service using WebSphere Integration Developer (WID)
e). Create a Business Policy for routing multiple tenant requests using WBSF Composition Studio in WID
- Enroll tenant organizations and users to business services using the WBSF Subscriber Manager.
- Monitor tenant specific service usage using the WBSF Performance Manager.
These steps are discussed in details in a following tutorial (Part 6) in this series.
Major implementation steps when using WebSphere DataPower SOA appliances
These are the three major steps when using WebSphere DataPower (WDP) with Tivoli Access Manager (TAM) to implement the mediation approach:
- Configure Web Services Proxies in WDP
a). Upload the WSDL files and LTPA keys to WDP
b). Configure the SaasCreditCheckService Web Services Proxy in WDP
c). Create policies for accepting WebSphere LTPA authentication tokens
d). Delegate authorization decisions to Tivoli Access Manager
e). Configure a routing action for each tenant-specific web service endpoint
f). Configure tenant specific CreditCheckServices Web Services Proxies in WDP
- Configure authorization policies in TAM
a). Create tenant specific users and groups
b). Create an access control list (ACL) for the CreditScoreWebService
c). Add authorized tenant specific users and groups to the ACL
- Configure tenant specific monitoring and web services traffic-shaping rules in WDP
These steps are discussed in details in a following tutorial (Part 7) in this series.
Major implementation steps when using WESB
These are the major steps when using WebSphere Enterprise Services Bus (WESB) with WebSphere Service Registry (WSRR) and Repository and Tivoli Access Manager (TAM):
- Create a mediation module in WESB for routing tenant requests
a). Create a mediation module in WID
b). Add a custom mediation primitive to extract the tenant ID
c). Delegate authorization decisions to TAM in the custom mediation primitive
d). Add a WSRR endpoint lookup primitive to retrieve tenant-specific endpoints
e). Wire the mediation primitives in the mediation flow
- Add authorization policies in TAM
a). Configure access control policies in TAM
b). Integrate TAM with WESB
- Add tenant specific service metadata for routing to WSRR
a). Load service metadata
b). Annotate service endpoint meta-data with a tenant ID property
c). Integrate WSRR with WESB
These steps are discussed in detail in Part 8 of this series.
Relative benefits for each implementation option
Table 1 below describes the relative advantages for each implementation option.
Table 1. Relative benefits of 3 different implementation options for the mediation pattern
|WebSphere Business Services Fabric||WebSphere Enterprise Services Bus||WebSphere DataPower SOA appliance|
|Semantic mediation through business policies containing assertions on properties in the service context. Very little application coding required.||Complex routing logic can be added in the mediation flow through mediation primitives.||Hardware accelerators for better performance.|
|New tenants can be added through policy changes only and without impacting existing tenants. Built in governance manager to deploy policy changes at runtime.||New tenant specific service meta-data can be added at runtime in WSRR without impacting existing tenants potentially without any code changes to the mediation flow.||New tenants can be added by adding new routing rules using configuration steps only and no code development is required.|
|Built in taxonomy and an extensible ontology for semantic mediation. Example concepts include: business services, endpoints, organizations, subscribers, channels and roles.||Built-in protocol transformation capabilities and support for multiple types of adapters.||Built in Web services and XML security features in support of leading industry standards such as WS-Security. Built in protocol transformation capabilities. Easy to use web console for configuring the appliance remotely|
|Built in subscriber manager and performance manager.||Seamless integration with Tivoli Access Manager for better management of access control policies and with WebSphere Services Registry and Repository for better management of service meta-data.||Seamless integration with Tivoli Access Manager for better management of access control policies and with WebSphere Services Registry and Repository for better management of service meta-data.|
In this article, we have described how a mediation proxy layer can offer a viable approach for a multi-tenancy in SaaS. We have introduced three implementation options for this approach using IBM middleware products: 1. WebSphere Business Services Fabric, 2. WebSphere Enterprise Service Bus and 3. WebSphere SOA DataPower appliance, in combination with WebSphere Service Registry and Repository and Tivoli Access Manager. We have also presented some relative advantages for each implementation option. In the following tutorials, we will present detailed implemention steps for each of the three aforementioned options.
- More about SaaS Platform.
- View the SaaS Demo Series.
- Read the "Develop and deploy multi-tenant Web-delivered solutions using IBM middleware, Part 1: Challenges and architectural patterns" article.
- Read the "Develop and deploy multi-tenant Web-delivered solutions using IBM middleware, Part 2: Approaches for enabling multi-tenancy" " article.
- View the Web service mediation patterns for dynamic routing of multiple tenant requests using WebSphere DataPower SOA Appliances demo.
- WebSphere Business Services Fabric.
- WebSphere Enterprise Services Bus.
- WebSphere DataPower SOA Appliances.
- WebSphere Service Registry and Repository.
- Tivoli Access Manager.
- WebSphere Integration Developer.
Dig deeper into SOA and web services on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.