Addressing Software-as-a-Service Challenges by using IBM Middleware
Building a software-as-a-service solution requires addressing a few key technical
challenges. In a set of recorded demonstrations, we will show how to address a number of
these technical challenges through a set of architectural patterns exploiting key features in
IBM middleware.
One of the most important technical challenges faced by architects when building a
software-as-a-service solution, is multi-tenancy.
Multi-tenancy refers to the ability to host a single instance of a software solution that
serves multiple client organizations.
In the first demo in this series, we will show an approach for supporting multiple tenants
on a single instance of an application server.
We will also show how multiple roles can be supported for each tenant and how a a new
tenant can be provisioned on this single instance of the application server.
In order to demonstrate how to address the multi-tenancy technical challenge, we have
constructed a fictitious multi-tenant banking application.
This banking application provides different virtual portals for different banks on a single
instance of WebSphere Portal Server.
Each virtual portal is configured with its own look-and-feel elements to provide unique
branding for each bank.
Each virtual portal supports isolation of user populations for each tenant bank through a
multi-tenant LDAP tree structure in a single instance of Tivoli Directory Server.
Each tenant bank supports a set of banking scenarios targeted towards common banking
roles as illustrated in this chart.
For example, the bank administrator role for each tenant bank can add or delete bank
customers for their respective banks as well as view and update customer profiles.
More details are included in the recorded demonstration. Links to the demos are
available at the end of this presentation.
The second technical challenge in a SaaS implementation is how to enable a unique user
experience.
How can the user interface layer in the multi-tenant application be customized for
different tenants through configuration, as opposed to writing new application code?
By using the WebSphere Portlet Factory dynamic profiles feature in conjunction with
virtual portals, a developer can create multiple highly customized applications from one
code base.
Through dynamic profiles an application developer can define variables in a common
‘profile set’ that can be configured by each tenant’s administrator at runtime.
Tenant specific customizations can be created by applying those configured profiles to
their portlets at runtime to change the appearance, content and behavior of the portlet.
For example, the provider administrator can configure the portlet fields ‘account name’
and ‘account description’ to show in bank1’s “add account for customer” portlet.
However, these fields can be hidden from the same portlet for bank2.
A provide administrator can also change the list box selections for the Account type
element so that the choices differ amongst the tenants.
In this demo we will describe how to implement, manage and specify profiles for
multiple tenant banks.
The third technical challenge in a SaaS implementation is how to configure the data tier.
There are varying degrees of data isolation for a SaaS application that range from an
isolated environment to a shared environment, including shared database tables.
This demo will address how can you use a shared database environment (as opposed to
an isolated database environment) for supporting a multi-tenant data tier in a SaaS
application.
When considering a data architecture in a shared environment, an important challenge a
SaaS provider is faced with is how to customize the database schema for each tenant.
One way to provide a very high degree of customization requiring minimal application
changes is to use the pureXML capabilities provided in DB2 version 9.
In the sample banking application, this scenario will show how to share database schema
across two tenant banks through the use of a bank id column and an xml column in each
of the database tables.
Through the use of an XML column to hold the tenant-specific data, we are able
configure each tenant’s data as simply as you could by using custom columns in an
isolated database environment.
In addition, by using the same XSD with optional XML elements, we are able to use the
same web services across tenants to update and maintain the tenant-specific data.
The final technical challenge addressed in this series of demos is security. There are
three security challenges that are addressed in the sample banking application.
The security demos will explain how to prevent the user population of one tenant from
accessing the virtual portal and portlet components of another tenant.
Also explained is how to enforce access control for the different roles for each tenant.
Lastly, how can you ensure that human tasks in a workflow are assigned to the
appropriate roles?
In order to address these security challenges for multi-tenancy, the following product
features were exploited :
-WebSphere Portal multi-realm security was used to isolate the user populations for each
tenant bank so that a user for one bank can only authenticate to the virtual portal for that
bank.
-WebSphere portal access control was used to restrict access to portal pages and portlets
by role
-WebSphere Process Server was used to assign human tasks in BPEL processes to
specific bank roles.
-A Tivoli Directory Server user registry was used to assign each tenant’s user population
to different LDAP subtrees.
More details can be seen in the set of three security demos.
This chart depicts IBM’s enterprise-class offerings which were used to build the sample
Software-as-a-Service banking application.
WebSphere™ Portal Server version 6.0 was used to build virtual portals with
configurable JSR-168 standard portlets for supporting multi-tenancy.
WebSphere Process Server version 6.0 was used to host shared SCA modules, BPEL
processes, WebServices and J2EE components for multi-tenancy.
DB2 v9.1 was used to build shared databases.
Multiple Tivoli Security products, for example Tivoli Directory Server, were used to
secure our software as a service solution.
Rational Software Architect, WebSphere Integration Developer and WebSphere Portlet
Factory were used for modeling and developing configurable service components and
meta-data.
The developerWorks articles listed here provide more details on the architectural patterns
used for addressing the technical challenges discussed in this demo series.
IBM software provides a number of features which can be exploited to build a Softwareas-a-Service solution
Please click here to view these demos.
IBM has innovative resources and programs to help you manage change & become
relevant in the Software as a Service market. Whether you’re an ISV, System Integrator
or Reseller, we can provide education, support and benefits to help you grow revenue and
differentiate yourself.
The first step will be to join the SaaS community. You will automatically be kept aware
of new SaaS technical benefits and workshops and get the enablement help that you need
to transform your application for delivery in the IBM Software as a Service model.
Then, as a member of IBM SaaS community, you can register at the Virtual Innovation
Center (VIC) where you will get personalized access to product support and education to
help build your Software as a Service knowledge and skills.
As an Advanced level member of PartnerWorld, you have the opportunity to gain access
to additional marketing and sales support by qualifying for the Software as a Service
(SaaS) specialty.
For more information, Visit our main site at www.ibm.com/partnerworld/saas.