scalable, business service-based saas applications
Post on 11-May-2015
430 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related