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