1

Scalable, Business Service-based SaaS Applications

by Malinda Kapuruge

CAiSE 2013 - Valencia, Spain

2

SaaS and SOA

SOASaaS

Service Oriented Architecture (SOA) is a software construction model

Software-as-a-Service is a software delivery model

• Two models complement each other [Laplante et al., 2008]• SOA principles are used to design and develop SaaS applications.• SaaS provides components for SOA.

• In SaaS model, a vendor maintains the software and its infrastructure whilst tenants pay for use, i.e., rent the software.

3

• Demand for services can fluctuate and might be difficult to predict• Tenants may join or leave• Demand of an individual tenant may fluctuate (elasticity guarantee)

• The application need to scale-out/in depending on the demand.

SaaS and Scalability

Let us use an example scenario...

4

• RoSAS : Roadside Assistance as a Service.

Example business service

Tow Trucks Call Center Garages Paramedics Taxis

RoSAS software (Service Composition)

Tenants

SaaS vendor

3rd party business services

5

Advantages

Quick Return on Investment (ROI)

Economies of Scale

Lower start-up cost

Automatic updates (maintenance)

6

• Demand fluctuations • Tenants (e.g., Travel agency) may join or leave during the runtime.• A tenant may add / remove its own customers (e.g., travellers).

• More third party services (e.g., Repair stations, Tow trucks) need to be bound, when the demand is high.

• Affiliating with unnecessarily large number of services could be not economical, so services need to be released when the demand is low.

Scalability

This sounds similar to the classical scalability issue in computational or data services ! A business-service bound to a composition could be treated as a computational or data storage unit ???

• Well.. there are additional considerations associated with business services.

7

1. Typically, the business services are not homogenous like data storages or computational service instances. There are varying business requirements.Not even among the same type of services. E.g., Garage service A: Need a bonus payment upon every 10th request.Garage service B: No bonus payment required but need an advance payment.

2. Typically, the business services are autonomous and managed by third party business organizations. In certain cases, the composite need to be adapted to accommodate changes of these business services. E.g., Garage service A (earlier): Need a bonus payment upon every 10th request.Garage service A (now) : Need a bonus payment upon every 5th request.

Additional Considerations

8

1. Design should be extensible to increase and decrease the number of services that could be accommodated.

2. Commonalities and variations needs to be captured in the design and managed at runtime.

3. Middleware needs to ensure there is minimal disruptions during adaptations.

Requirements of a Methodology

ROAD4SaaS...

9

ROAD4SaaS - Overview

• SaaS application is viewed as a hierarchy of organizations.• Organization hierarchy can grow or shrink to accommodate more or less partner

services. • Relationships between services (Service Relationships) are explicit in the design

of the organization.

Sub Organizations

Root Organization+

10

Let us consider the RoSAS example scenario.

Root Organization

CC GR

WeCall.com FastRepairs.com

TT

JimsTow.com

MM Mr. John Doe

A contract

A player

A role

11

• Root Organization is the initial design of the composite.

Root Organization

CC GR

TT

MM

Root Organization (The initial design)

Player

Role Interface

+

12

• A contract representing a service-relationship consists of • Facts: A set of parameters to capture the contract state, e.g., total repair

count, Allowed repair types.• Interaction terms: A set of well-defined interactions between two roles, e.g.,

orderRepair(), payRepair(), noMoreCapacity().• Rules: A set of evaluation rules to evaluate ongoing interactions against

contract state [Kapuruge et al., 2012].

Contract

CC GRThe contract CC-GR

13

• Increased demand –> more players need to be bound -> scale-out the organization.

Extensibility

CC GR

TT

MM

Root Organization

FastRepairs.com

GR1

GR2

GR3

AceRepairs.com

BestRepairs.com

Expansion Organization, GR_ExpOrg

GRr

Role Interaction Description is a projection of interaction terms of adjoining contracts of the expansion role.

Expansion Role

14

Extensibility

CC GR

TT

MM

Root Organization

FastRepairs.com

GR1

GR2

GR3

AceRepairs.com

BestRepairs.comGRrTT1

TTr

TT1FastTow.com

JimsTow.com

(Virtual) Organizational Hierarchy

15

Scale-Out

16

Scale-In

17

Commonalities and Variations

GR

GR1

GR2

GR3

GRr

F1, F2

R1, R2, R3

F3

F4,F5

F5

R4

R5

R6,R7

• In an organization hierarchy,• Contracts of higher level organization capture commonalities.• Contracts of lower level organizations capture variations.

Facts= F1, F2, F3, F4, F5

Rules = R1, R2, R3, R4, R5, R6, R7

18

Middleware Support

• Extend Apache Axis2 [Kapuruge, EDOC-2011].• Messages in XML/SOAP, Interface in WSDL 2.0• Seamless access to WS-* , e.g., WS-Security.

• ROAD Framework [Colman, 2008].• Role Oriented Adaptive Design • Scale-out/in operations – on top of basic ROAD operations,

e.g., addRole(), removeRole(), addOperation(), removeOperation(). • Contracts

• Drools 5.0 StatefulKnowledgeSessions• Scale-out/in operations can be scheduled via Adaptation Scripts.

[Kapuruge, 2012]

19

Evaluation

20

Evaluation

• Scale-out operation is slower than Scale-in. • Rule deployments and contract population etc.

21

Related Work

• GridSaaS: Grid-enabled, SOA-based SaaS application platform.• Lack of support for integrating business services with varying capabilities.

• Component references of SCA (Service Component Architecture) • Lack of support for explicitly capture the complex and heterogeneous

business service relationships. • Cloud Service Bus: An ESB-enabled

• Lack of support for capturing commonalities and variations. • Proxy-based: E.g., TRAP/BPEL.

• Helps to Scale-out/in, but lack of support for capturing commonalities and variations.

Approach [16] [17] [6] [8] [18] [19] [7] [20] [21] ROAD4SaaS

Req1 - - ~ + + + + + - +

Req2 - - - - - - - - ~ +

Req3 - - ~ + + ~ - + + +

22

References

• [Laplante, 2008] : What's in a Name? Distinguishing between SaaS and SOA. IT Professional. Vol. 10,pp. 46-50 (2008)

• [Kapuruge, 2012]: Representing Service-Relationships as First Class Entities in Service Orchestrations. WISE 2012, Paphos, Cyprus. Springer LNCS, pp 257-270 (2012).

• [Kapuruge, EDOC-2011]: ROAD4WS – Extending Apache Axis2 for Adaptive Service Compositions. In: IEEE International Conference on Enterprise Distributed Object Computing (EDOC) pp. 183-192. IEEE Pres, (2011).

23

Thank You !

mkapuruge [at] swin.edu.au