Software As A Service - Build A Web-Delivered SaaS Framework For Forms and Workflow-Driven Applications

Software as a Service: Build a Web-delivered
SaaS framework for forms and workflow-driven

applications
Use products from IBM's Enterprise Software Portfolio
Skill Level: Introductory
Tamer Nassar (tamer@us.ibm.com)

Software Engineer
IBM
Murali Vridhachalam (mural@us.ibm.com)

IT Architect
IBM
09 Dec 2008
Software as a Service (SaaS), largely enabled by the Internet and corporate

intranets, has become an innovative way for enterprises to do business. In the past,
software had to be installed in an infrastructure close to end users. The current
industry-wide trend is for Internet based services. Deployment of software as a
service, accessible on the Internet and supported by multi-tenant architecture, makes
new applications (or tenants) available with significantly lower costs. In this article,
learn how a team built a Web-delivered SaaS framework to host applications, from
different business domains, that were driven by forms and workflow.
Introduction
Software as a Service (SaaS), largely enabled by the Internet and corporate
intranets, has become an innovative, cost-efficient way for enterprises to do
business. Many people predict that SaaS will grow much faster within corporate
intranets. Companies can reduce costs by providing SaaS frameworks rather than
traditional infrastructure-based applications.
Software as a Service: Build a Web-delivered SaaS framework for forms and workflow-driven applications
© Copyright IBM Corporation 1994, 2008. All rights reserved. Page 1 of 19
developerWorks® ibm.com/developerWorks
This article describes how a team built a Web-delivered SaaS framework to host
various applications, from different business domains, that are forms and workflow
driven. Before an application (or tenant) can be added to the deployed SaaS
framework, it has to be designed and implemented following technical guidelines
published by the SaaS framework provider. From a technical perspective, the main
benefit of this solution is that no code changes are required to the SaaS framework
when new tenants are added.
In this article, the terms tenant and application are used interchangeably. The Sales
Application or HR Application shown in Figure 3 are an example of a tenant.
The team used Lotus Forms 3.0, WebSphere Process Server 6.1, Business Process
Execution Language (BPEL), and the pureXML capabilities of DB2 9.5 to build and
deploy the solution.
Traditional approach
Many enterprises have numerous forms-driven processes, across several business
domains, requiring workflow processing. Enterprises usually meet these varied
needs with custom application development, as shown in Figure 1.
Custom-developed applications have proven to be very expensive; custom
development, infrastructure needs, and maintenance and upgrades are costly.
Figure 1. Traditional approach
Page 2 of 19 © Copyright IBM Corporation 1994, 2008. All rights reserved.
ibm.com/developerWorks developerWorks®
SaaS framework approach

The SaaS framework uses the multi-tenant architecture, shown in Figure 2, which
significantly reduces costs by hosting a generic solution for all forms and workflow
driven applications. With this approach, a new forms and workflow-driven application
can be added to the SaaS framework without code changes to the framework itself.
Figure 2. SaaS approach
This article describes how a team built a SaaS framework for forms and
workflow-driven applications with parallel and serial approval flows, as shown in
Figure 3. This SaaS framework may have multiple applications from different
domains, such as Sales, Human Resources, Procurement, and so on. The
applications might have multiple forms that require different approval workflows.
Figure 3. SaaS framework
Technology and software products enabling the framework

To build the Web-delivered SaaS framework the team used the following products
from IBM's enterprise software portfolio.
Lotus Forms 3.0

Is open standards based (w3c XForms specification), and provides digital
signature capabilities to support compliance with government and industry
regulations. Lotus Forms 3.0 also supports integration with business process
workflows and file attachments. The Lotus forms suite includes Lotus Forms
server, Lotus Forms API, Lotus Forms Viewer, Webform Server, and Lotus
Forms Designer. The following components were used to build the SaaS
framework:
• Webform Server, which translates Extensible Forms Description
Language (XFDL) documents into HTML/JavaScript documents, allows
users to view, fill out, sign, and submit XFDL documents using only a
Web browser. Users can fill out XFDL forms without downloading or
installing browser plug-ins or other programs.
• Lotus Forms Server API, commonly called the API, is a collection of
specialized functions that allow users to extend the capabilities of Lotus
Forms.
• Lotus Forms Viewer, commonly called the Viewer, lets users view,
complete, and submit forms. In a typical scenario, users go to a Web site
and click a link to open a form within their browser. The Viewer
automatically opens as a browser plug-in. The Viewer can also be used
as a standalone application, independent of any browser.
• Lotus Forms Designer, commonly called the Designer, is a graphical
design tool for creating and editing forms.
Lotus Forms uses XFDL as its form templates language. XFDL is a standard
forms design and document processing meta-language. The end user may
save the form locally to disk and work offline, or e-mail the form to others
involved in a workflow. Once a form is completed, the full document can be
archived in a records management system for auditing. The XML data can
easily be harvested from the surrounding XML document to drive back-end
data processing systems.
Lotus Forms integration with Web services helps end users complete forms
quickly and efficiently. For example, an end user is filling out a purchase order
form to buy stationery. When a supplier number is entered, a Web service call
can be made to automatically fill in the supplier's name, address, and contact
information from another source, thus reducing data entry and enhancing data
integrity.
DB2 version 9.5

A market-leading relational database that supports XML as a native data type.
This powerful feature facilitates multi-tenant architectures from the data
perspective. The example implementation stores XFDL (Lotus Forms structure)
in XML columns within relational tables.
WebSphere Process Server 6.1

Using WebSphere Process Server 6.1 to deploy the solution enables simple
and flexible execution of standards-based business process solutions in a

Service Oriented Architecture (SOA). Process Server provides robust process
automation, advanced human workflow, business rules, and integration
capabilities on a common SOA platform.
WebSphere Process Server is built on WebSphere Application Server, so it
inherits the robust capabilities and qualities of service provided by Application
Server. Process Server also provides flexible connectivity infrastructure for
integrating applications, data, and services. The plug-and-play capabilities, and
ability to modify business rules on the fly, make the promise of SaaS a reality.
Costs are greatly reduced when existing applications can be changed, and new
applications added, with significantly lower -- or no -- down time.
Process Server also ensures interoperability and flexibility through adoption of

popular standards such as WS-BPEL, JMS, XML, SCA, SDO, Web services,
and many more.
WS-BPEL
Web Services BPEL was used to handle the notification flow. WS-BPEL, an
XML-based language, enables the description of business process activities as
Web services and defines how the Web services are connected to accomplish
certain business tasks.
Difference between SaaS and ASP (Application

Service Provider)
With the SaaS model, application functions are delivered remotely
over the Internet and by a subscription model. Customers don't own
the software, and have no choice of what type of hardware and
middleware are used to host the software.
In the ASP model, customers buy the software which is hosted by
the service provider, who may decide to bring it in-house at any
time. The infrastructure may be tailored to customer needs.
Dave Mitchell's interview has more about SaaS in IBM, ASP and
how SaaS is changing IT.
Technical design
To understand the rationale for the technical design of the SaaS framework, it's
beneficial to understand some of the major stakeholders and user roles. While there
are many players, fundamentally there are two major stakeholders and two major
user roles in a Web-delivered SaaS framework.
The two major stakeholder roles are:
• SaaS provider, who owns the SaaS framework and provides different
services. For example, if the SaaS framework is deployed within a
company or enterprise, the company or enterprise may be the SaaS
provider. Another example of an SaaS provider in the customer
relationship management (CRM) arena is Salesforce.com.
• Infrastructure services include hardware provisioning, security,
performance monitoring, and capacity planning.
• Tenant services include billing, service level agreements, contracts,
and subscriber management.
• Developer services include providing a platform for developers to
develop and test tenant applications before boarding them onto the
SaaS platform. The provider will give technical guidance to
developers to ensure an application or tenant is designed correctly so
the application can be offered through the SaaS provider.
• End user customer services provide 24x7 technical and non-technical
support and training.
• Application owner or tenant, who typically owns one or more applications
in the SaaS platform. This stakeholder is responsible for providing
features to meet end user requirements. The features and forms-driven
processes in a sales application may be different from those in an HR
application. If the SaaS framework is deployed within a company, different
business units within the company could be the application owner.
The two major user roles are:
• Developers who use the services of the platform provider to develop, test,
and deploy new applications (tenants) or new releases of the application.
For example, the developers will need to understand the data model that
supports multi-tenancy before designing their application.
• End user who uses the features of one or more applications offered by
the tenants. In the example in this article, the end user is a user of the
Sales application, HR application, or Procurement application (see Figure
3).
Figure 4 shows the architecture of the SaaS framework.
Figure 4. SaaS framework architecture
Design in the context of stakeholders and users
The SaaS provider architects and develops the framework using the following design
points. The design points are published as technical guidance to the application
developers.
• A multi-tenant data model is implemented to host multiple applications

within the framework, providing extensibility and security. Figure 8 shows
an example of the multi-tenant data model.
• The forms that are part of an application in the framework must include
the following metadata fields.
Field name Description
ApplicationID Unique ID for each application
ApplicationName Name of the application
FormID Unique ID for each form
FormName Name of the form
Status Contains the form status and is
updated during processing
DisplayFormState Contains the initial state of the form
PreviousDisplayFormState Contains previous state of the form
LevelOfApprovals Contains how many levels of
approvals are needed

ParallelApproval Contains value to indicate parallel
approval or serial approval
ParallelApprovalBothNeeded Contains value to indicate if form
needs both parallel
approvals or just one to move to
next approval level
• The approver data is stored as XML in DB2, as shown in Figure 5. This

data contains an approver ID for each approval level. The approver ID is
used to look up approver information from the person_directory table.
Figure 5. Approver data in XML
• Approval routing is handled by BPEL. When the form is inserted or

updated in DB2, a JDBC adaptor in BPEL is triggered. It passes routing
information to the approval routing flow through the Java Bridge
component, as shown in Figure 6.
Figure 6. Approver routing using BPEL
The Application owner (tenant) determines the need to add forms-driven applications
to the framework, and engages developers to develop the application so that it can
be added to the framework.
The developers follow technical guidance published by the SaaS provider to design
the application. Approver data, and user information such as name, ID, roles, and so
forth are provided when the application is added to the SaaS framework. Figure 7
shows the form with application specific fields and metadata fields.
Figure 7. Form with metadata and application specific fields
End user scenario
The following sequence outlines an end user scenario.
1. The end user authenticates to the SaaS framework. The framework

retrieves user details such as Name, Organization, and so on from an
LDAP directory. Roles are retrieved from data stored in the database or
LDAP directory.
2. Based on the user's role, the framework determines which applications

the end user is allowed to work with. A list of applications is then
displayed. The user interface menus are generated based on the user's
role.
For example, the Procurement application may be restricted to the
Procurement department employees in an organization. In this case, only
employees belonging to the Procurement department will see the
Procurement application in the user interface.
3. The end user may choose to work with one of the forms within the
application. When they open the form, field-level security is enabled and
is based on the user's role.
For example, an end user may not act as an approver.
4. The user fills the form, and the fields are validated. After validation, the
user submits the form.
The SaaS framework parses the XFDL in the servlet (using the Lotus
Forms API), retrieves the key metadata fields, and looks up the approver
data to determine the next approver in the approval workflow. Appropriate
metadata fields are updated, and the XFDL form is saved as XML in a
DB2 table.
5. When the form is inserted or updated in DB2, the notification flow will be
triggered to invoke the e-mail service. It could also invoke any other
interface or Web service to update external systems.
6. The form will be marked as completed after all approvals have been
obtained, and the form initiator will be notified.
7. The form will be marked as rejected if one of the approvers rejects the
form. In this case, the form initiator will be notified to take action and
resubmit the form.
SaaS framework architecture principles

From an architecture perspective, the hallmarks of the SaaS framework are
extensibility, security, and scalability. This section highlights how each is achieved in
the SaaS framework.
Extensibility
The SaaS framework should be designed so new tenants or applications can be

added without having to change the framework code. In our case, the extensibility
requirements are met through a combination of design points, as follows.
• For workflow processing, certain XML fields in the Lotus forms are used
as metadata fields. When new applications are added to the SaaS
framework, the forms have to include these key metadata fields.
• Database design must provide relational and hierarchical data (XML) to

support multi-tenancy. This was achieved by using the pureXML
capabilities in DB2 v9.5, which let the team store the XFDL (form) into an
XML column in a table. With this approach, the SaaS framework can store
hundreds of tenants, as shown in the entity relationship diagram in Figure
8.
Figure 8. Partial entity relationship showing multi-tenant data model
• A generic BPEL implementation is used to handle the e-mail notifications

during the approval workflow processing. No code changes are needed to
handle e-mail notifications for new forms.
Security
There are different perspectives of security in a SaaS framework. This article

focuses on security from a tenant and end user perspective, which is achieved
through the following guidelines.
• Control application access. Who can access the tenant is achieved with
DB2 and the LDAP directory, which contain the end user information.
• Control role-based access (who can access which features within an

application) using groups in the LDAP directory or relational tables. These
groups would be authorized to access certain features within the
application.
• Achieve tenant data security with a few different approaches.

• The first approach is to grant appropriate access to the database
tables to groups to meet user authorization needs. For example:
Grant select, insert, update, delete on table to group groupname;
The queries that are issued by the application code against the
multi-tenant database will always have the tenant name as a
constraint. For example:
Select columnname from schema.tablename where app_code = tenant and ...
where tenant is dynamically determined using the application context

under which the query is being executed. Using the example tenants
in this article, tenant may be Sales, Procurement, or HR.
• The second approach is to use the powerful Label Based Access

Control (LBAC) feature in DB2 9.5 to secure the data. With LBAC,
users can be restricted from accessing certain rows of data or certain
columns in a table. In the example, you can restrict access to the
Sales application data from end users of the Procurement application,
and so on.
For example, the following statements can be issued to create LBAC
security for the different tenants. With this approach, even a user with
DBADM authority and with direct access to the database cannot
access certain rows of data. Additional authorization will be needed
for a user with DBADM authority to view all the rows of data.
• Define security label components:
Create security label component APPLICATION_ACCESS set

{'SALES',
'PROCUREMENT','HR'}
• Define the security policy:
Create security policy tenant_access_policy components

APPLICATION_ACCESS
With db2lbacrules
Restrict not authorized write security label
• Define the security labels:
Create security label tenant_access_policy.SALES

Component APPLICATION_ACCESS 'Sales'
Create security label tenant_access_policy.PROCUREMENT
Component APPLICATION_ACCESS 'Procurement'
Create security label tenant_access_policy.HR
Component APPLICATION_ACCESS 'HR'
• Update the security label column:
Alter table schema.tablename add column access_tag

db2securitylabel
Add security policy tenant_access_policy
Now, the table schema.tablename is protected.
Update schema.tablename set access_tag = seclabel_by_name

('tenant_access_policy','Sales') where application_name =
'Sales'
('tenant_access_policy','Procurement') where
application_name =
'Procurement'
('tenant_access_policy','HR') where application_name = 'HR'
• Grant the security labels to users:
GRANT security label tenant_access_policy.SALES to group SALES

FOR ALL
ACCESS
GRANT security label tenant_access_policy.PROCUREMENT to group
PROCUREMENT
FOR ALL ACCESS
GRANT security label tenant_access_policy.HR to group HR FOR
ALL ACCESS
Scalability
You can achieve scalability with partitioning of applications. New tenants may be
hosted in another identical infrastructure instance with its own multi-tenant database.
In this case, tenant traffic will be redirected using a smart balancing and routing
approach. Figure 9 shows an example.
Figure 9. SaaS framework scalability
Summary
SaaS adoption is growing rapidly worldwide. In this article, you learned how products
from IBM's enterprise software portfolio can be used to build a very robust SaaS
framework that is extensible, secure, and scalable. The example shows how you can
use the SaaS paradigm to transform businesses to be more cost effective and
services-centric.
Resources
• Learn more about WebSphere Process Server features, benefits, system
requirements, library and more.
• IBM Lotus Forms eForms provides eForms software to speed automation of
forms-based business processes and helps integrate data with existing IT
systems.
• Explore DB2 9 for Linux UNIX and Windows.
• Read and watch how WebSphere Business Services Fabric can be used for
dynamic routing of multiple tenants using Web Service mediation patterns.
• The developerWorks interview with Dave Mitchell on Software as a Service and
IBM explores why developers need to understand SaaS and how IBM can help.
• Find valuable information about IBM Partnerworld and SaaS.
• SaaS Showcase connects you with leading Independent Software Vendors
(ISVs).
• Browse the technology bookstore for books on these and other technical topics.
About the authors

Tamer Nassar
Tamer Nassar is a software engineer in the office of the IBM CIO, and has been with
IBM since 2000. He has been involved in different projects, with a variety of
technologies, designing, implementing, and testing many end-to-end enterprise
solutions. His areas of interest and expertise include SOA, IT architecture and
methodology, WebSphere Application Server, WebSphere Process Server,
WebSphere MQ, and WebSphere Message Broker.
Murali Vridhachalam
Murali Vridhachalam is an Open group certified IT Architect, and has been with IBM
since 1994. He has architected and deployed several enterprise applications within
IBM. Murali currently provides technical leadership to a team whose mission is to
develop innovative solutions using IBM's wide array of enterprise software products.
Trademarks
IBM, the IBM logo, ibm.com, DB2, developerWorks, Lotus, Rational, Tivoli, and
WebSphere are trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries, or both. These and other
IBM trademarked terms are marked on their first occurrence in this information with
the appropriate symbol (® or ™), indicating US registered or common law
trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A
current list of IBM trademarks is available on the Web at
http://www.ibm.com/legal/copytrade.shtml.
Microsoft and Windows are trademarks of Microsoft Corporation in the United States,
other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Windows is a trademark of Microsoft Corporation in the United States, other
countries, or both.
Other company, product, or service names may be trademarks or service marks of
others.

Software As A Service - Build A Web-Delivered SaaS Framework For Forms and Workflow-Driven Applications

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software As A Service - Build A Web-Delivered SaaS Framework For Forms and Workflow-Driven Applications

Uploaded by

Copyright:

Available Formats

Software as a Service: Build a Web-delivered

SaaS framework for forms and workflow-driven

Skill Level: Introductory

Tamer Nassar (tamer@us.ibm.com)

Murali Vridhachalam (mural@us.ibm.com)

Software as a Service (SaaS), largely enabled by the Internet and corporate

Figure 1. Traditional approach

SaaS framework approach

Figure 2. SaaS approach

Figure 3. SaaS framework

Technology and software products enabling the framework

Lotus Forms 3.0

DB2 version 9.5

WebSphere Process Server 6.1

and flexible execution of standards-based business process solutions in a

Process Server also ensures interoperability and flexibility through adoption of

Difference between SaaS and ASP (Application

The two major stakeholder roles are:

Figure 4. SaaS framework architecture

Design in the context of stakeholders and users

• A multi-tenant data model is implemented to host multiple applications

approvals are needed

• The approver data is stored as XML in DB2, as shown in Figure 5. This

• Approval routing is handled by BPEL. When the form is inserted or

Figure 7. Form with metadata and application specific fields

End user scenario

The following sequence outlines an end user scenario.

1. The end user authenticates to the SaaS framework. The framework

2. Based on the user's role, the framework determines which applications

SaaS framework architecture principles

The SaaS framework should be designed so new tenants or applications can be

• Database design must provide relational and hierarchical data (XML) to

• A generic BPEL implementation is used to handle the e-mail notifications

There are different perspectives of security in a SaaS framework. This article

• Control role-based access (who can access which features within an

• Achieve tenant data security with a few different approaches.

Grant select, insert, update, delete on table to group groupname;

Select columnname from schema.tablename where app_code = tenant and ...

where tenant is dynamically determined using the application context

• The second approach is to use the powerful Label Based Access

• Define security label components:

Create security label component APPLICATION_ACCESS set

• Define the security policy:

Create security policy tenant_access_policy components

Restrict not authorized write security label

• Define the security labels:

Create security label tenant_access_policy.SALES

• Update the security label column:

Alter table schema.tablename add column access_tag

Now, the table schema.tablename is protected.

Update schema.tablename set access_tag = seclabel_by_name

• Grant the security labels to users:

GRANT security label tenant_access_policy.SALES to group SALES

Figure 9. SaaS framework scalability

About the authors

You might also like