Representing Service-Relationships as First Class Entities in Service Orchestrations
-
Upload
malinda-kapuruge -
Category
Technology
-
view
511 -
download
4
description
Transcript of Representing Service-Relationships as First Class Entities in Service Orchestrations
1
Representing Service-Relationships as First Class Entities in Service Orchestrations
Malinda Kapuruge, Jun Han and Alan Colman
WISE – 2012 Paphos, Cyprus
2
Outline
• Introduction
• Problem
• Service Relationships
• Approach and Benefits
• Meta-model, Language and Implementation
• Questions
3
Introduction
• Service Orchestration
• Automated coordination
• Used to build complex service-based systems
• An IT representation of real word business requirements
Approx.
Real World Business IT Representation
4
The Problem – Motivational Scenario
Service Aggregator
Roadside Assistance !!!
Partner Services
Taxis
Garages
Case Officers
Tow Trucks
BOB
5
The Problem - State of the Art and Limitations
Partner Services
• Services are orchestrated according to an activity flow. • Partner Services : e.g., Web services• De-facto standard : WS-BPEL
• Represents Activity Relationships. • But lack of representation of Service Relationships.
A Process
6
Service Relationships
How I model my service
orchestration ?
Service Aggregator
From the Aggregator’s point of view, • Partner Services play certain positions/roles.• Roles have connections or relationships.
• Obligations and interactions?
1. The garage (service) needs to inform the tow-truck the nearest repair station to tow the car.
2. The case officer needs to pay a bonus payment to garage upon every 10th repair request.
3. The garage needs to inform the case officer, when repair is complete.
BOB
7
How to represent Service Relationships
in a Service Orchestration ?
8
Our Approach – an overview
• We envision a Service Composition as an Organisation.
• The Roles and...
• The Relationships between roles are explicitly captured
• The Processes are defined on the organisation structure
Role
Relationship
9
The Organisation – an Analogy
10
But, why?
Why treat a service composition as an organisation?
Provide StabilityCapture Biz. Relationships Improves Adaptability
What are the benefits ?
11
Benefit 1: To Capture Business Relationships
• Service orchestration is an “IT level” representation of “real world” business requirements.
• There are mutual obligations and interactions between these services.
• e.g., Road Side Assistance Scenario• Case Officer <-> Tow Truck• Garage <-> Tow Truck• Case Officer <-> Garage
• Need to be represented in the Service Orchestration.
CO GR
Order Repair
Notify Repair
Repair CountContract Grade
Rules/Interpretation Logic
• Interactions• Facts• Interpretation Rules
12
Benefit 1: To Capture Business Relationships
• Activity Relationships depends on Service Relationships.E.g., Upon every 10th Repair Request, CO must pay a Bonus Payment to GR.
• We use events to bridge the two via Organisational Behaviours.
• Organisational BehavioursDeclarative and Event-DrivenMultiple Behaviours (units) can be defined
13
Example Scenario
CO GR
Organisational BehavioursOrganisational Behaviours(Event-driven Coordination)
T= RepairT= Pay Bonus
<Event(s)>
Rule :BonusEvalRule “On every 10th repair request, CO is
obliged to pay a bonus payment to GR”.
Behaviour: RepairingeRepairReqd -> GR.Repair -> eRpairDone
ePayBonus -> CO.PayBonus -> eBonusPaid
14
Benefit 1: To Capture Business Relationships
• The next triggered events (ε ) depend on the current state (φ) and the interpretation (ρ) of interactions (ι)
• The next business activity/task (T) depend on the triggered Events (ε) and the defined organisational behaviour (β).
ε = ƒcontract-evaluation (φ, ρ, ι)τ = ƒcoordination (ε, β)
15
Benefit 2: Stability
• Grounding processes upon concrete services is unstable.• The organisation structure (abstract representation) provide
the stability to define business processes.• No tight-coupling between processes and partner services.• Partner services are bound to the organisation.
CO
GRMM
TT
RoSAS Composite
Concrete Services / Consumers (Players)
Contract
GR Role
Play / Binding
Players
Abstract Organisational Structure
Concrete Layer of Bound/Candidate ServicesCO_MM
CO_TT
GR_TT
CO_GR
16
Benefit 3: Adaptability
• Service Relationships can be changed.• Interactions• Facts• Rules
• Change in Service Relationship influence the next task to be executed. (Coordination is driven by Service Relationships)
• The coordination logic too can be changed.• Add/Remove/Update Organisational Behaviours
CO GR
Organisational BehavioursOrganisational Behaviours(Event-driven Coordination)
17
Three Benefits – a Summary
StabilityCapture Biz. Relationships
Adaptability
18
Meta-model
19
Serendip Language
20
Implementation - Highlights
• Contract state: Drools Stateful Knowledge Sessions.
• Message Delivery and Interface Generation: Axis2 + ROAD4WS.
• Modelling: An Eclipse-based plugin.
http://www.swinburne.edu.au/ict/research/cs3/road/implementations.htm
21
Conclusions
• A novel approach to model service orchestrations.
• Service Relationships are treated as first class entities.
• Separation of concerns
• Modularity
• Declarative descriptions
• Easy to add/remove/update.
• Flexible coordination
• A meta-model and Language
• Tool Support
22
Thank You
• http://www.onlinepetcart.com.au
• http://usa.astoria.com
• https://endtimesrevelations.wordpress.com
• http://fromthedogpark.blogspot.com.au/
• http://www.abc.net.au
• http://www.thefeltsource.com/Nutrition.html
• http://www.jwire.com.au
• http://internetbusinessmastery.com
• http://venturebeat.com
• http://www.theenterprisearchitect.eu
• http://www.surveyshack.com
Photo Credit