This document discusses the relationship between service-oriented architecture (SOA) and software-as-a-service (SaaS) models. It uses an example of a roadside assistance service (RoSAS) to illustrate how demand for services in a SaaS application can fluctuate, requiring the application to scale in or out depending on current needs. The ROAD4SaaS approach is presented for designing SaaS applications that can explicitly represent service relationships and accommodate varying capabilities among business services through organizational hierarchies that capture commonalities and variations across different levels. This approach aims to minimize disruption when adaptations are needed in response to changing demand or business service requirements.

1. 1
CAiSE 2013 - Valencia, Spain

2. 2
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. 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.
Let us use an example scenario...

4. 4
• RoSAS : Roadside Assistance as a Service.
Tow Trucks Call Center Garages Paramedics Taxis
Tenants
SaaS
vendor
3rd party
business
services

5. 5

6. 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.
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. 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.

8. 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.
ROAD4SaaS...

9. 9
• 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.

10. 10
Let us consider the RoSAS example scenario.
WeCall.com FastRepairs.com
JimsTow.com
Mr. John Doe
A contract
A player
A role

11. 11
• Root Organization is the initial design of the composite.
Root Organization
(The initial design)
Player
Role Interface

12. 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].
The contract CC-GR

13. 13
• Increased demand –> more players need to be bound -> scale-out the
organization.
Root Organization
FastRepairs.com
AceRepairs.com
BestRepairs.com
Expansion Organization,
GR_ExpOrg
Role Interaction Description
is a projection of interaction terms
of adjoining contracts of the
expansion role.
Expansion Role

14. 14
Root Organization
FastRepairs.com
AceRepairs.com
BestRepairs.com
FastTow.com
JimsTow.com
(Virtual) Organizational
Hierarchy

15. 15

16. 16

17. 17
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. 18
• 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. 19

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

21. 21
• 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. 22
• [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. 23