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.
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 IBM® Lotus® Forms 3.0, IBM WebSphere® Process Server 6.1, Business Process Execution Language (BPEL), and the pureXML capabilities of IBM DB2® 9.5 to build and deploy the solution.
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
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.
(See a larger version of Figure 2.)
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/Java™Script 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 V9.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.
WebSphere 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.
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 nontechnical 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 multitenant data model is implemented to host multiple applications
within the framework, providing extensibility and security.
Figure 8 shows an example of
the multitenant 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
The following sequence outlines an end user scenario.
- 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.
- 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.
- 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.
- 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.
- 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.
- The form will be marked as completed after all approvals have been obtained, and the form initiator will be notified.
- 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.
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 multitenancy. 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 multitenant 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.
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 multitenant 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' Update schema.tablename set access_tag = seclabel_by_name ('tenant_access_policy','Procurement') where application_name = 'Procurement' Update schema.tablename set access_tag = seclabel_by_name ('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
- Define security label components:
- The first approach is to grant appropriate access to the
database tables to groups to meet user authorization needs.
For example:
You can achieve scalability with partitioning of applications. New tenants may be hosted in another identical infrastructure instance with its own multitenant 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
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 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.
Learn
- 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).
- Stay current with
developerWorks
technical events and webcasts.
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware
products from IBM DB2, Lotus, Rational®,
Tivoli®, and WebSphere.
Discuss
- Participate in the
IT architecture forum to exchange tips and techniques and to share other related information about the broad topic of IT architecture.
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, an Open Group certified IT architect, has been involved with XBRL since early 2005. He was the lead architect for IBM's first ever submission of financial reports using XBRL, as part of the SEC's XBRL voluntary filing program. His current interests include SOA and Software as a Service offerings built using the IBM enterprise software portfolio.
