As technology professionals, one of our goals is to share our experiences and the lessons we learn, in this case the knowledge we gained from building multi-tenant applications that run on IBM® SmartCloud Enterprise. In particular, we'll describe the techniques that we used to transform existing single-tenant SOA applications into multi-tenant Software as a Service (SaaS) applications.

Eventually, though, we expect tools will be developed to help developers by automating the more complex transformations of single-tenant applications into multi-tenant ones.

First, let's examine some of the more traditional solutions from an IBM perspective (since we are most familiar with that).

IBM industry solutions

IBM offers a broad and deep software portfolio with a rich set of capabilities. In addition, based on many of our client engagements, we can say that IBM is in a unique position to combine these capabilities to create out-of-the-box industry solutions that help clients solve specific business problems. This approach enables clients to spend less time and effort integrating software products from IBM in order to address their specific business needs.

Many of these solutions are developed following the IBM SOA Reference Architecture. For example,

• A portal is used to aggregate components of applications into a single view and allow people to collaborate and interact with their business or IT services based on their roles.
• An enterprise service bus is used to provide flexibility when integrating and connecting services.
• Security principles such as identity, authentication, authorization, audit, and compliance are applied to the entire service-oriented life cycle.
• Key performance indicators are monitored in real time so that the solution can get the information they need to prevent, isolate, diagnose, and fix problems.
• Business analytics are applied to discover subtle associations and help a solution make the right decisions.
• Reports are designed, customized, and consumed via the integrated portal.

As you can imagine, the capabilities from a software portfolio that includes WebSphere® Portal, Lotus® Sametime, Cognos Business Intelligence, WebSphere MQ, WebSphere Message Broker, Business Process Management, Tivoli® Access Manager, DB2®, Rational® Asset Manager, etc. can be combined to create new, out-of-the box solutions.

So then the challenge becomes ...
...how do you create a multi-tenant SaaS application that leverages existing enterprise products that do not have their own native notion of a tenant, especially since you need scale up to support more and more tenants in the solution?

Recently we undertook a development effort with our Industry Solutions teams to transform single-tenant SOA solutions into multi-tenant SOA solutions that are ready for deployment in the IBM SmartCloud Enterprise as SaaS solutions. Although an SOA solution can make use of many IBM middleware products, and transforming it to multitenancy might seem daunting, the extensibility of the IBM middleware products actually makes this transformation fairly straightforward.

This article describes techniques and insights that can be useful if you want to transform your existing single-tenant solutions into multi-tenant SaaS solutions.

Let's first examine the concept of multitenancy.

Back to top

The concept of multitenancy

Increasingly, large and small companies, as well as ISVs, are exploring cloud-based solutions and SaaS as their new delivery model. Within the IBM software portfolio, there are multiple approaches to create new SaaS offerings.

One approach is to create a brand new offering from scratch to be offered as an SaaS solution; for example, IBM Blueworks Live. Another approach is to take a product that started out as an on-premise, enterprise offering and "evolve" it into a SaaS solution; for example, Commerce-as-a-Service, Cognos, and IBM SmartCloud for Social Business (formerly LotusLive™).

In the first approach, multitenancy tends to be built from the ground up. For the second approach, the on-premise offering may not contain the notion of a tenant, but you can achieve multitenancy by employing custom configurations.

Let's examine some common multitenancy scenarios to enhance the baseline definition of tenancy.

Back to top

Common multitenancy scenarios

The general concept of multitenancy has been discussed in previous articles (see Resources). A key concept to understand is that there is a spectrum of possibilities for sharing resources.

Figure 1 defines the technology stacks where multitenancy is relevant in a cloud environment.

As you can see, the multitenancy scenarios include:

1. No sharing of resources.
2. Shared hardware resources.
3. Shared operating system.
4. Shared middleware.
5. Shared applications.

Let's look at each in more detail.

Scenario 1: No sharing. Each tenant has its own complete stack of applications, middleware, operating systems, and infrastructure (hardware). Each tenant is completely isolated from one another with the exception that it can be running in the same physical data center.

Scenario 2: Shared hardware. The tenant is starting to share the infrastructure in a data center. For example, the tenant can be sharing servers (for example, Intel®, Power), storage (SONAS®, NetApp®), and networks (Juniper, Cisco) in the data centers.

Scenario 3: Shared operating system. The tenant is now sharing the infrastructure and the operating systems. Hypervisors such as KVM and VMware® are typically used to virtualize the hardware to allow multiple operating systems to run on the hardware. The tenant is still pretty isolated from other tenants since each can have their own versions of the application servers, database servers, and applications. This level of sharing is also referred to as Infrastructure as a Service (IaaS).

Scenario 4: Shared middleware. The tenant is now starting to share a set of middleware services that run on top of the shared operating systems and infrastructure; for example, security services, portal, database services, monitoring services, etc. Different applications can be built on these shared middleware components. This level of sharing is also referred to as Platform as a Service (PaaS).

Scenario 5: Shared applications. The tenant is now sharing the same application with other tenants. By the very nature of this sharing, tenants are sharing the same middleware too, including versions that are used to implement the application. Although the tenants are sharing the same underlying resources, they are still logically isolated from each other. A tenant has no visibility to another tenant's assets (such as data that can be stored in database servers or file systems). This level of sharing is also referred to as Software as a Service (SaaS).

In general, the higher the multitenancy point (meaning that in scenario 5, the shared applications), the less effort is required for setting up a new tenant because more of the underlying stack is shared. For any business that plans to bring on more and more tenants over time, being able to scale without a massive increase in both technical and business resources should be an important up-front consideration. Having one shared code base can increase the time-to-value measure for both the provider and the customers and enable new innovations to be deployed in weeks instead of months or years.

Earlier, we mentioned that some of the single-tenant software solutions did not contain a notion of a native tenant in their designs; let's discuss how that can be solved before we unveil seven techniques to help you convert single-tenant software to multi-tenant solutions.

Back to top

Isolation creates a tenant in disguise

Although none of the software products we mentioned carries with it the explicit notion of a tenant (or for that fact, the notion of users within a tenant), each product does contain a built-in notion of isolation which can be leveraged to implement a multi-tenant solution.

For example, the article on best practices on achieving collaborative multitenancy using Rational Asset Manager ("Best practices for cloud-based asset-centric collaboration", see Resources) describes how to leverage the asset communities concept in Rational Asset Manager to achieve asset isolation and sharing between tenants. An asset community can be created for a tenant and users from the tenant can publish assets to the community; users from another tenant however will not have the visibility or access to this asset community by default.

A similar method can be applied to the rest of the IBM offerings mentioned earlier. Since IBM software is extensible, many times it is a matter of using the APIs in the products to do the customization.

Using this notion, let's look at seven techniques that will help you convert to multitenancy.

Back to top

Seven techniques to convert to multitenancy

In our efforts to transform the industry SOA solutions, we identified seven techniques that may be useful as you transform your single-tenant applications into fully multi-tenant SaaS applications that are built on IBM middleware products. Those techniques are

• Shared LDAP
• Single sign-on
• Shared database server
• Shared Enterprise Service Bus
• Tenant-specific reports
• Tenant-specific log files
• Unified user interface via WebSphere Portal

Let's look at each in detail.

Shared LDAP

To create a multi-tenant environment, one of the first things to deploy is a shared LDAP so that you can have a central place to consistently manage users' and organizations' information. The IBM Tivoli Directory Server is a popular LDAP implementation that we use. All of our IBM software products already provided out-of-the-box integration with Tivoli Directory Server, so many of the existing installation assets can be leveraged.

There are a few areas to watch out for. Each product typically comes with its own default LDAP directory structure and attributes that are optimized for the construction of search filters specific to the product. You will need to do some normalization and tuning of these default settings when sharing the LDAP among many products.

For example, pay attention to case sensitivity: Some products may ignore the case while other products may not, exemplified in the following:

cn=users, o=ibm, c=us

versus:

cn=Users, o=IBM, c=US

Single sign-on

Single sign-on (SSO) allows a user to login once and then gain access to all the systems without being prompted to login again to each of them. Since many of the middleware products are built on WebSphere Application Server (WAS), the IBM Lightweight Third-Party Authentication (LTPA) technology can be used and it works effectively in a browser-based environment.

Figure 2 shows an example of an overall flow.

When an HTTP request arrives, WebSEAL works with the Tivoli Access Manager Policy Server to determine if the requested resource is protected. If it is protected, WebSEAL ensures that the user is authenticated before allowing the request to reach the application; for example, a portlet running on WebSphere Portal.

If the portlet needs to access another server, for example the Sametime Community Server, the shared LTPA token identifies the user who has already been authenticated by WebSEAL; the user will not be challenged again to re-authenticate.

Although the LTPA token is a standard technique for implementing SSO between WebSphere application servers, in practice you must still be careful when deploying such a system in the cloud. Here are a few challenges that we encountered when deploying the solution.

• The LTPA key file is normally exported from one system (for example, WebSEAL) and then imported into another (example, WebSphere Portal, Domino server). It is important that this key file uses a consistent way to describe the shared LDAP, for example using a fully qualified domain name such as:

  com.ibm.websphere.ltpa.Realm=vhost1111.site1.compute.ihost.com\:389

  
  

  If one server is using an alias and exported a LTPA key file with the alias name but another server does not support using an alias, then SSO will not work properly.

  
  
• You may see an error in the log files that indicate your LTPA token has expired. This can occur if the OS time set on each virtual machine is not the same. For example, if the time set on the WebSEAL VM is 10:00 and the time set on the Portal VM is 1:00, then when the Portal server opens the token and compares it against its local time, it will think that the token has already expired.

  This issue is quite prominent in the IBM SmartCloud environment since the clock on the VMs that are provisioned are not guaranteed to be the same. We must take extra steps to reset or re-sync the clock on each VM to the same time and time zone in order for SSO to work properly.

We also recommend pair-wise SSO testing to be done first before you test the overall flow. For example, ensure SSO is working between:

• WebSEAL and Portal
• WebSEAL and Sametime
• Portal and Sametime

When these are working, test the entire path from WebSEAL > Portal > Sametime. There are many servers involved in a SOA solution, so having a systematic way to test and then repeat the test is a critical success factor for managing different kinds of failures that are possible in a cloud environment.

Shared database server

The third thing you want to consider in your multi-tenant environment is how to isolate your tenants' data from each other. Assuming your single-tenant application is using a relational database such as DB2, this task is relatively straightforward.

There are a few common patterns as illustrated in Figure 3.

1. Each tenant has its own database.
2. Each tenant has its own schema within a single database.
3. All the tenants share the same database.

The first scenario requires the least amount of change in the application to recognize the notion of tenant. Typically all it requires is for the application to connect to the right tenant-specific database based on the tenant ID.

Scenario 1 also provides the most isolation between tenants. For example, tenant 1 and tenant 2 databases can be archived at a different schedule.

The second scenario is typical if the existing application has the notion of its own metadata and user's data that need to reside in the same database because of how the existing database connections were designed. In that case, you might consider separating the tenant's data by schema within the same database and that should minimize the redesign that is necessary.

The third scenario requires the most changes in the application and the tables design. The notion of the tenant ID must be incorporated into the tables design so that the application can scope the data it is updating or retrieving for a particular tenant based on the tenant ID. This scenario is more typically used by applications that are designed from the ground-up to be offered as SaaS.

Shared Enterprise Service Bus

An Enterprise Service Bus (ESB) supports the concepts of SOA implementation by decoupling the consumer's view of a service from the implementation of a service.

Decoupling the consumer's view of a service from the actual implementation increases the flexibility of the architecture. It allows the substitution of one service provider for another without the consumer being aware of the change or alternation of the architecture.

There are many different ESB patterns and corresponding product mappings (see the Redbook in Resources). Our current working project focus on a typical topology using WebSphere MQ and WebSphere Message Broker.

WebSphere MQ facilitates communication between applications. A queue in WebSphere MQ acts as container for the messages that are exchanged between the applications. A queue manager manages the queues and acts as a container for the queues. WebSphere Message Broker extends WebSphere MQ and can be used to manipulate the messages that are in the queue using broker rules.

In a multi-tenant system, all the tenants share a single instance of WebSphere MQ and WebSphere Message Broker. In such a setup, the information sent by one tenant must be isolated from another tenant. One way to achieve this isolation is to provision a unique queue manager for each tenant. The queues within the tenant-specific queue managers are isolated from each other, thus isolating the messages passed in the queue. The queue managers can be managed individually so that issues that affect a tenant's queue infrastructure do not affect the other tenants.

Each tenant in the multi-tenant system might have a different set of broker rules. In order to allow each tenant to have their own broker rules, the tenant-specific queue managers can be associated with tenant-specific broker rules. This allows broker rule isolation between the tenants.

Figure 4 summarizes the overall idea showing two separate tenants running in the same ESB instance.

Tenant-specific reports

Reporting is a common requirement for all solutions. IBM Cognos Business Intelligence (BI) provides comprehensive query and reporting capabilities that allow users to create reports and analyze data to make better business decisions. In addition, Cognos BI is a proven platform that can operate in a multi-tenant environment where resources can be shared among multiple customers.

Cognos BI groups reports and reporting metadata into folder structures. A report can access its required data by using a datasource connection object which defines the location and access parameters for the data shown in the report.

In a multi-tenant environment in which all tenants share a single instance of the Cognos BI, isolation between the tenants can be achieved by creating tenant-specific folders and datasource connections. The users from the tenant can only access the folders and datasource connections created for the tenant. This enforces the isolation between the tenants so that they cannot see each other's data or reports.

The IBM Cognos Software Development Kit allows a developer to seamlessly enable multitenancy and integrate the Cognos functionalities into its own multi-tenant applications. For example, when a new tenant registers, an activation handler can transparently access Cognos BI by making a web services call to create a new folder and a datasource connection visible to this tenant only.

Tenant-specific log files

Since the tenants are now sharing the same middleware, it is important to consider how to separate the log files for each tenant so that a tenant can only view the logging messages that were generated by its own executions. Separating out the trace files and log files by tenant helps the SaaS administrators troubleshoot issues that are specific to a certain account.

Tenant-specific log files can be created by simply extending WebSphere logging frameworks. In addition, each product will have different directory structure, so the log file locations can vary from product to product.

A log aggregator utility can aggregate the log files together for each software product into a single archive for a tenant.

Unified user interface via WebSphere Portal

WebSphere Portal can provide a unified presentation to the different components, applications, processes, and content that need to be integrated in a SOA solution. For example, as shown in Figure 2, a seamless single-sign-on experience can be realized through WebSphere Portal so that after a user logs into the portal, all the underlying applications can be accessed without having to re-enter a user ID and password.

In addition, we found the following capabilities from WebSphere Portal particularly useful for creating multi-tenant SaaS applications:

• Portal component model portlets allow you to create reusable components that can be used in multiple SaaS applications. It provides a standard programming model so that it is easy for a tenant to extend a SaaS solution by providing its own custom portlets.
• With portal customization, a tenant can customize the UI with its own specific skins by modifying style sheets.
• Access to portlets based on roles. When adding users to a tenant, you can automatically entitle the users to the right portlets by setting their respective roles in the shared LDAP; for example, company administrators versus company sales.
• Mobile and multiple devices support. Most SaaS applications can be accessed through mobile devices. IBM Mobile Portal Accelerator enables you to support multiple devices quickly without requiring device-dependent authoring.
• Support for portal farms in WebSphere Portal 7.0 make it particularly suitable to run in a cloud environment. Portal farms are series of independent instances of portal servers that behave like a traditional cluster but are far easier to manage and scale. You can automatically grow and shrink the size of the farm based on capacity needs.

Back to top

In conclusion

In this article, we've continued our efforts to share our latest experiences and lessons learned from building multi-tenant applications that run on IBM SmartCloud Enterprise.

In particular, we described the techniques that we used to transform existing single-tenant SOA applications into multi-tenant SaaS applications. Over time, we expect new tools to be available to assist in more complex transformations as the SaaS market matures.

Acknowledgement

The authors would like to thank Tony Carrato from IBM for his assistance on this article.

Resources

Learn

• Learn more about IBM Software Industry Solutions.
  
  
• Two articles that describe multitenancy include, Best practices to architect applications in the IBM Cloud and Best practices for cloud-based asset-centric collaboration.
  
  
• The Redbook, Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB explains how to use the IBM Tivoli Directory Server LDAP implementation.
  
  
• Find more information about Cognos Business Intelligence.
  
  
• Find more information about IBM Mobile Portal Accelerator.
  
  
• Find more information about WebSphere Portal farm topologies.
  
  
• The article Convert your web application to a multi-tenant SaaS solution details considerations and steps to quickly turn your web app into a cloud application. It also highlights a tool from Corent that aids in the task.
  
  
• For more on how to perform tasks in the IBM Cloud, visit these resources:
  • Up and download files from a Windows instance.
  • Install IIS web server on Windows 2008 R2.
  • Create an IBM Cloud instance with the Linux command line.
  • Create an IBM Cloud instance with the Windows command line.
  • Extend your corporate network with the IBM Cloud.
  • High availability apps in the IBM Cloud.
  • Parameterize cloud images for custom instances on the fly.
  • Windows-targeted approaches to IBM Cloud provisioning.
  • Deploy products using rapid deployment service.
  • Integrate your authentication policy using a proxy.
  • Configure the Linux Logical Volume Manager.
  • Deploy a complex topology using a deployment utility tool.
  • Provision and configure an instance that spans a public and private VLAN.
  • Secure IBM Cloud access for Android devices.
  • Recover data in IBM SmartCloud Enterprise.
  • Secure virtual machine instances in the cloud.
  
  
• In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
  
  
• Find out how to access IBM SmartCloud Enterprise.
  
  

Get products and technologies

• See the product images available for IBM SmartCloud Enterprise.
  
  

Discuss

• Join a cloud computing group on developerWorks.
  
  
• Read all the great cloud blogs on developerWorks.
  
  
• Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
  
  

About the authors

Christina Lau is a distinguished engineer in WebSphere, experienced in such emerging technologies as cloud and mobile computing. Her current focus is on developing advanced technologies that support the delivery of online cloud services across the BPM, connectivity, and ILOG portfolio.

Valentina Birsan is a senior developer in WebSphere, currently focused on cloud projects. Previously Valentina was a technical lead on Rational Application Developer. Valentina was one of the initial members of the Eclipse TPTP open source project and served as the chair of the TPTP Architecture Group. She was the lead architect for the Cosmos Service Modeling Eclipse open source project and member of the SML open standard.

Bhadri Madapusi is an advisory software developer in WebSphere, currently focused on cloud projects. Bhadri has over 10 years of software development experience. Previously he worked on business process management and WebSphere Commerce.

Rate this article

Comments

Back to top

Table of contents

• IBM industry solutions
• The concept of multitenancy
• Common multitenancy scenarios
• Isolation creates a tenant in disguise
• Seven techniques to convert to multitenancy
• In conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

Learn more, join the cloud community

---

• Community: Cloud computing conversations led by IBM community members
• Buy: Try IBM software on IBM SmartCloud Enterprise

Dig deeper into Cloud computing on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers