Develop and Deploy Multi-Tenant Web-delivered Solutions Using IBM Middleware: Part 5: A mediation approach for multi-tenancy and three implementation options

Part 1 of this series described multi-tenancy in a web-delivered business solution (a.k.a Software-as-a-Service) and Part 2 discussed the three different approaches for enabling multi-tenancy. In this article, we focus on the mediation approach for multi-tenancy first introduced in Part 2. We present three implementation options for this approach using different IBM middleware products and compare the relative benefits. The detailed implementation steps for each option will be described in the following three tutorials.

Indrajit Poddar (ipoddar@us.ibm.com), Software Architect, IBM

Indrajit PoddarIndrajit Poddar (IP) is a member of the Strategy, Technology, Architecture, and Incubation team at IBM Software Group Strategy, where he leads several integration PoCs for building composite business services delivered in the Software-as-a-Service (SaaS) model.



Devaprasad Nadgir (devaprasad@in.ibm.com), IBM Certified Senior IT Architect, IBM

NadgirDevaprasad is a Certified Senior IT Architect and works out of India Software Lab, Bangalore. He is currently involved in Service Registry and Federated SOA Governance initiatives in IBM Software Group. His areas of interest also include Architectural Methods, Cloud Computing, Virtualization and Software-as-a-Service. Check out his blog where he shares some of his insights and technology trends.



01 June 2009

Also available in Chinese Spanish

Introduction

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
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
Interface definition for a simple credit score service
Figure 3. Interface definition changes for adding tenant specific request attribute
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
Banking example

The requirements include:

  1. Ability to enable multi-tenancy without any code changes to his existing single tenant credit check service.
  2. 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.
  3. 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.
  4. Ability to authorize Bob Nottingham and Carrie Serrano before they can access his multi-tenant credit check service.
  5. 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:

  1. WebSphere Business Services Fabric (WBSF)
  2. WebSphere Enterprise Service Bus (WESB) with WebSphere Service Registry and Repository and Tivoli Access Manager (TAM)
  3. 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:

  1. Define a composite business service with routing policies for each tenant specific endpoint:
    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
  2. Enroll tenant organizations and users to business services using the WBSF Subscriber Manager.
  3. 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:

  1. 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
  2. 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
  3. 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):

  1. 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
  2. Add authorization policies in TAM
    a). Configure access control policies in TAM
    b). Integrate TAM with WESB
  3. 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 FabricWebSphere Enterprise Services BusWebSphere 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.

Conclusion

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.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=412996
ArticleTitle=Develop and Deploy Multi-Tenant Web-delivered Solutions Using IBM Middleware: Part 5: A mediation approach for multi-tenancy and three implementation options
publish-date=06012009