Achieving Multi-tenanted Business Processes in SaaS Applications

Presenter: Malinda Kapuruge

Co-Authors: Prof. Jun Han and Dr. Alan Colman

WISE 2011 - SYDNEY

1

Outline Introduction

SaaS

SOA and Business Process Modelling

Multi-tenancy

Challenges

State of the Art

Our Contribution and Approach

Addressing Challenges

Questions

2

Software as a Service (SaaS) – A long story in short.

A software delivery model.

SaaS users (tenants) rent the software.

SaaS vendor owns, hosts and maintain the software and infrastructure.

3

Tenant VendorSubscription fee

Software (as a Service)

Rent Owns, host and maintain

SaaS - Benefits for Tenants

TenantQuicker time to market

Low start-up cost

No ongoing maintenance

Lower risk

Quick access to latest features

4

SaaS - Benefits for Vendors

VendorEconomies of scale

Maintain a single code

base

Track usage of software by

customer Predictable revenue stream

Quickly target new market

opportunities

5

SaaS and SOA

SaaS and SOA complements each other (Laplante, 2008).

SOA is widely used to construct SaaS applications.

SaaS application a Service Composite

In order to achieve the SaaS benefits, service compositions need to be multi-tenanted.

VsSOA - A construction model.SaaS - A delivery model.

6

Scenario - Roadside Assistance as a Service

RoSaaS.com

Insurance Co. Travel Agent

Tow trucks Case Officers Garages Paramedics Taxis

SaaS Tenants

SaaS Vendor

Service Providers

Car Seller

Small and medium businesses

SOA

BPM

7

Business Process Management– Why?

BPM advantages

Automated Enactment

Easy Re-design

Automated Verification

Multi-tenancy?

8

Multi-tenancy

Multi-instance multi-tenancy

Separate application instances.Separate infrastructure.

Single-instance multi-tenancy

Separate application instances.Shared infrastructure.

Shared application instance.Shared infrastructure.

9

$

$

Scenario - revisited

10

Service Composition

Cloud

Single shared code base

Scenario - revisited

Tenants have many overlapping requirements.

Ex:- All need roadside assistance which require managing activities such as Towing, Repairing etc.

Requirement are ‘similar’ but not the ‘same’.

Ex:- The way towing need to be carried out for CarSeller might ‘slightly’ different from the InsuranceCo.

Tenant requirements can change in the future.

Ex:- CarSeller might need Tow activity to be paused until a Taxi picks up the motorist.

Changes are made on a shared code base. Invalid boundary crossings?

Ex:- A change proposed by CarSeller can harm goals of InsuranceCo.

11

Challenges for SaaS vendor

Challenge 1 : Capturing commonalities

Tenants have many overlapping requirements.

Duplications need to be minimized.

Challenge 2 : Allowing variations

Requirements are similar but not the same.

Variations with minimal duplications.

Challenge 3: Avoiding invalid boundary crossings

Common application instance.

Many tenants and many collaborations.

Unpredictability

12

State of the Art WS-BPEL – the front runner.

No explicit support for multi-tenancy.

Flexibility issues.

Improvements - Two major categories.

Template based approaches

Aspect oriented approaches

Still not good enough to address the challenges due to single-instance multi-tenancy.

Code duplications and maintainability issues.

Lack of support for unpredictability at runtime.

SOA

BPM

SaaS

13

Our Contribution

We propose an ‘Organizational’ approach.

Uses SOA+BPM to model SaaS applications.

Multi-tenanted BPM

Equipped with specific features to employ BPM in multi-tenanted SaaS applications.

Addresses above mentioned challenges.

Contributions

An architecture to model multi-tenanted process-aware service-composites.

A flexible process modeling and execution language.

14

Approach - overview

15

Service Composition

How to model and maintain a single application instance? Adaptable

Organization

Approach - overview

PD_Insurance PD_Travel PD_CarSeller

...HotelBooking

...Towing Repairing

Complain TaxiOrdering

CO

MM

TC

GR

TX

Composite

RolesContractsStr

uctu

ral

leve

lB

ehav

ior

leve

lP

acka

ging

leve

l

16

Three layers

Process/Packaging layer

Behavior layer

Structure layer

Structure

PD_Insurance PD_Travel PD_CarSeller

...HotelBooking

...Towing Repairing

Complain TaxiOrdering

CO

MM

TC

GR

TX

Composite

RolesContractsStr

uctu

ral

leve

lB

ehav

ior

leve

lP

acka

ging

leve

l

17

Structure Abstraction for Stability.

Roles and Contracts among them.

Contracts: Represent role-role relationships. Mutual obligations and interactions.(Colman, 2007)

18

CO

MM

TC

GR

TX

Composite

RolesContracts

Behavior

PD_Insurance PD_Travel PD_CarSeller

...HotelBooking

...Towing Repairing

Complain TaxiOrdering

CO

MM

TC

GR

TX

Composite

RolesContractsStr

uctu

ral

leve

lB

ehav

ior

leve

lP

acka

ging

leve

l

19

...HotelBooking

...Towing Repairing

Complain TaxiOrdering

Behavior Modeling A Behavior Term capture allowed

behavior (collaboration) of the organization. E.g., Towing

An organization can have many such behavior terms.

E.g., Repairing, Complaining, Hotel booking

Define collaboration constraints.

Modifications to behavior terms are subjected to these constraints.

Re-usable, Declarative.

BehaviorTerm Towing{ Task SendTowReq{ EPpre TowReqd; EPpost TowReqSent & PickupLocKnown; PerfProp 2h; Roblig CO; }; Task Tow{ EPpre PickupLocKnown & DestinationKnown; EPpost CarTowed ; PerfProp 24h; Roblig TC; }; Task PayTow{ EPpre CarTowed & TowAcked; EPpost TCPaid; PerfProp 2h; Roblig CO; }; //More tasks ...

Constraint c1: (CarTowed>0)->(TCPaid>0); Constraint c2: (TowReqSent>0)->[4h,24h](CarTowed>0); //More constraints...};

Sample behaviour term, Towing

20

Processes

PD_Insurance PD_Travel PD_CarSeller

...HotelBooking

...Towing Repairing

Complain TaxiOrdering

CO

MM

TC

GR

TX

Composite

RolesContractsStr

uctu

ral

leve

lB

ehav

ior

leve

lP

acka

ging

leve

l

21

Process Modeling A process definition is a collection of behavior terms.

Can dynamically include or exclude behavior terms

Capture process level constraints (to protect tenant goals)

A process view is dynamically constructed depending on grouped behavior terms.

Event-driven Process Chain (EPC) view

22

Towing

PD_Insurance

Repairing

PD_Travel

HotelBookingTaxiOrdering

Dynamic Process Views (EPC)

23

Challenge 1: Capturing Commonalities

24

A pool of behaviour terms defined in the organization

Overlapping requirements.

Solution: Behavior terms can be re-used / shared.

Code duplication is minimized.

Processes get automatically updated upon changes to behavior terms.

Separate process views for each tenant

Challenge 2: Allowing Variations

Requirements are similar but not the same.

Example 1: Both tenants CarSeller and InsuranceCo share Towing. Only the tenant CarSeller require an additional pre-condition to be added to start task Tow.

Use behavior specialization.

Specialize behavior Towing to create another (Towing2).

Only the additional properties are specified.

Towing2 inherits all the properties of Towing except thoseoverridden.

25

PD_CarSeller

Challenge 2: Allowing Variations

Example 2: TravlCo require an additional Task to be added to alert the motorist (MM) once the towing is complete.

Solution: Specialize behavior Towing to create Towing3.

Multiple variations of same behavior can co-exist in the organization.

26

PD_Travel

Challenge 2: Allowing Variations

27

TowReqdCO.SendTow

Req

V

TowReqSent

PickupLocKnown

TC.Tow

DestinationKnown

CarTowed

TowAcked

V

CO.PayTow

V

TCPaid

TowReqdCO.SendTow

ReqV

TowReqSent

PickupLocKnown

TC.Tow

DestinationKnown

CarTowed

TowAcked

V

CO.PayTow

V

TCPaid

Variation due to modified EPpre of task Tow of the specialized behavior

TaxiPickupTowReqd

CO.SendTowReq

V

TowReqSent

PickupLocKnown

TC.Tow

DestinationKnown

CarTowed

TowAcked

V

CO.PayTow

V

TCPaid

CO.AlertMM MMAlertedV

Variation due to new task in specialized behavior

Tasks

Events

Lege

nd

Originally

Example 1Example 2

Challenge 3: Avoiding Invalid Boundary Crossings Changes are carried out in a common code base. Possible invalid boundary

crossings.

Example: CarSeller request a modification to a behavior term shared with InsuranceCo.

How to identify the boundary for safe modification?

Solution: Two-tier scoped constraints.

28

Constraint Type Defined in (Scope) Purpose

Behavior Constraints Behaviour Terms Protect collaboration goals.

Process Constraints Process Definitions Protect tenant goals

Challenge 3: Avoiding Invalid Boundary Crossings

29

Towing

PD_CarSeller PD_Insurance

Change ?

Behaviour constraints

Process constraints

Links among behaviour terms and process definitions, provide the exact constraints need to be validated.

Better than global set of constraints. No unnecessary restrictions. (Kapuruge, SCC 2011)

Nothing less …! Nothing more …!

Implementation

30

...

Validation Module

Axis2

Enactment Validation

Romeo-pluginValidation

plugins

(Behavior terms)

EnactmentEngine

Process customization and visualization tools

Model Provider Factory (MPF) Romeo

SaaS designer/vendorTenant 1 Tenant 2 Tenant 3

Towing3

Towing Repairing

ComplainOrderTaxi

Towing2

Customizations patches/upgrades

Service Providers

ROAD4WS

...

Web services PetriNet and CTL

Related Work and Evaluation

31

Table I: A summary of comparison

Approach Feature

Kuo [26]

Charfi [23]

Graml [24]

Michiel [22]

Grivas [2]

Mietzner[21]

Serendip4SaaS

Customizability + + + + + + +

Process support - + + + - - +

Support for single-instance multi-tenancy

- - - - - + +

Capturing commonalities in behavior

- ~ ~ ~ ~ ~ +

Facilitating variability in behavior

- ~ ~ ~ ~ ~ +

Prevent invalid boundary crossings

- - - - - - +

+ exist, ~ exist with limitations, - does not exist/not applicable

Code duplications and maintainability issues.

Lack of support for adaptability at runtime.

Are we there?

32

Not yet !

We addressed ONLY THREE identified challenges.

Many challenges need to be addressed to achieve true multi-tenanted business processes.

Example: Better tooling support, scalability issues of the enactment engine, challenges in managing data-flow.

Future Work !!!

References

(Laplante, 2008) : Laplante, P.A., Jia, Z., Voas, J.: What's in a Name? Distinguishing between SaaS and SOA. IT Professional. Vol. 10,pp. 46-50 (2008)

(Colman, 2007): Colman, A.: Role-Oriented Adaptive Design (PhD Thesis). Swinburne University of Technology, Melbourne (2007)

(Kapuruge, SCC-2011): Kapuruge, M., Colman, A., Han, J.: Controlled flexibility in business processes defined for service compositions. In: Services Computing (SCC) pp. 346-353. IEEE Press, (2011)

(Kapuruge, EDOC-2011): Kapuruge, M., Colman, A., King, J.: ROAD4WS – Extending Apache Axis2 for Adaptive Service Compositions. In: Enterprise Computing Conference (EDOC) IEEE Pres, (2011)

33

Questions ?

34