This talk presents a novel approach to design and enact service orchestrations that explicitly capture the service relationships in service orchestrations. Presented at WISE - 2012 conference, Paphos, Cyprus.

1. Representing Service-Relationships as
First Class Entities in Service
Orchestrations
Malinda Kapuruge, Jun Han and Alan Colman
1

2. Outline
• Introduction
• Problem
• Service Relationships
• Approach and Benefits
• Meta-model, Language and Implementation
• Questions
2

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
3

4. The Problem – Motivational Scenario
Roadside
Assistance !!!
Garages
Case Officers
BOB Taxis
Tow Trucks
Service Aggregator Partner Services
4

5. The Problem - State of the Art and Limitations
Partner Services
A Process
• 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.
5

6. Service Relationships
From the Aggregator’s point of view,
How I model my
• Partner Services play certain positions/roles.
service
• Roles have connections or relationships.
orchestration ?
• Obligations and interactions?
1. The garage (service) needs to inform the tow-truck the
BOB 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.
Service Aggregator
6

7. How to represent
Service Relationships
in a Service Orchestration ?
7

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
8

9. The Organisation – an Analogy
9

10. But, why?
Why treat a service composition
as an organisation?
What are the benefits ?
Capture Biz. Relationships Provide Stability Improves Adaptability
10

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 • Interactions
• Need to be represented in the Service Orchestration. • Facts
• Interpretation Rules
Order Repair
Repair Count
CO Contract Grade
Rules/ GR
Interpretation Logic
Notify Repair
11

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 Behaviours
Declarative and Event-Driven
Multiple Behaviours (units) can be defined
12

13. Example Scenario
Behaviour: Repairing
eRepairReqd -> GR.Repair -> eRpairDone
ePayBonus -> CO.PayBonus -> eBonusPaid
T= Pay Bonus Organisational Behaviours T= Repair
Organisational Behaviours
(Event-driven Coordination)
<Event(s)>
CO GR
Rule :BonusEvalRule
“On every 10th repair request, CO is
obliged to pay a bonus payment to GR”.
13

14. Benefit 1: To Capture Business Relationships
ε = ƒcontract-evaluation (φ, ρ, ι)
τ = ƒcoordination (ε, β)
• 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 (β).
14

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.
RoS
AS C
CO omp
osite
Abstract Organisational Structure
Concrete Layer of Bound/
CO_MM CO_GR Candidate Services
MM GR
CO_TT
Contract
GR_TT
TT GR Role
Play /
Binding
Concrete Services /
Consumers (Players) Players
15

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
Organisational Behaviours
Organisational Behaviours
(Event-driven Coordination)
CO GR
16

17. Three Benefits – a Summary
Adaptability
Stability
Capture Biz. Relationships
17

18. Meta-model
18

19. Serendip Language
19

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
20

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
21

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
22