slides

Dynamic Service Substitution in Service-Oriented Architectures

Manel Fredj , Nikolaos Georgantas , Valérie Issarny and Apostolos Zarras

ARLES Project-Team, INRIA Paris-Rocquencourt, FranceUniversity of Ioannina, Greece

July 11th, 2008

2008 IEEE Congress on SERVICES , Honolulu, HawaiiSOA Industry Summit (SOAIS 2008)

)1( )1( )1( )2(

)1(

)2(

Talk outline

Environments Characteristics

Dependability Risks upon Service Unavailability

Issues Jeopardizing Dependability Use Scenario : e-Prescription

SIROCO Middleware for Dynamic Service Substitution

SIROCO Architecture Dealing with the Dependability Risks

ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008

Camera Sport training

lessons

The world is a “couple of clicks” far from you

Health assistance

e-Business e-Learning Repair services

… and many more

When Internet meets SOA… … Web Services

SOA abstracts heterogeneous applications as Services, which are described using well-defined interfaces (e.g. SA-WSDL desc.)

With Semantic Web, the interoperability is enhanced in order to increase the chances to respond to user requests

Users discover and consume services on-the-fly

Services can be deployed, and thus available in a couple of “clicks”, anywhere, at any time

Users can dynamically compose services in order to perform advanced functionalities using the service orchestrations

User

Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution

Environment Characteristics


SA-WSDLSA-WSDLSA-WSDL SA-WSDL SA-WSDL SA-WSDL


lessons


Health assistance


… and many more

When the Internet meets SOA… …Web Services

SOA abstracts heterogenous applications as Services, which are described using well-defined interfaces (e.g. SA-WSDL desc.)





Heterogeneous

User






lessons


Health assistance


… and many more







Heterogeneous

User





Interoperable


lessons


Health assistance


… and many more







Open

Heterogeneous

User





Interoperable


lessons


Health assistance


… and many more







RichOpen

Heterogeneous

User





Interoperable


lessons


Health assistance


… and many more







RichOpen

Heterogeneous

Dynamic

User





Interoperable

The other side of the coin …

Dependability is not ensured

when a service becomes unavailable


Issues Jeopardizing Dependability

Services can be un-deployed at any time, without beforehand notification

How to prevent the orchestration from the service unavailability?

Services may maintain a state

Interactions with the unavailable services have to be restarted from the beginning, losing thereby all the computation performedHow to ensure reliability (i.e., continuity in service provisioning) for the service orchestrations?

Stateful service are not implemented the same, and thus the service state may not be understood by all the service candidates

How to describe the service state in an interoperable manner? And when should it be transferred?

Orchestration involves more than one service…

How far are the other services affected?




Issues Jeopardizing Dependability

Services can be un-deployed at any time, without beforehand notification

How to prevent the orchestration from the service unavailability?

Services may maintain a state

Interactions with the unavailable services have to be restarted from the beginning, losing thereby all the computation performedHow to ensure reliability (i.e., continuity in service provisioning) for the service orchestrations?

Stateful service are not implemented the same, and thus the service state may not be understood by all the service candidates

How to describe the service state in an interoperable manner? And when should it be transferred?

Orchestration involves more than one service…

How far are the other services affected?

I. fd ManagingUnavailability

II. fe Managing State

III. ldSide Effects




e-Prescription Scenario

BPEL

BPEL

Doctor PharmacyNational Social Security

Flow

Patient

receiveSymptoms()

replyprescriptionResults()

invokeDoctor

enqueueRequest()

invoke

getCoordinates()

invokeSocial Security

updatePatientRecord()

receive

receivePrescription()

invokePharmacy

issueRequest() "empty"

1

2

3 4

5

6

7 8

1

3

5

6

7

Patient 2

SA-WSDLSA-WSDL SA-WSDL

receive

Doctor

Patient

Doctor

2




4


BPEL

BPEL


Flow

Patient

receiveSymptoms()


invokeDoctor

enqueueRequest()

invoke

getCoordinates()

invokeSocial SecurityAh c


receive


invokePharmacy


1

2

3 4

5

6

7 8

1

3

Service unavailability

Patient 2


receive

Doctor

Patient

Doctor

2





BPEL

BPEL


Flow

Patient

receiveSymptoms()


invokeDoctor

enqueueRequest()

invoke

getCoordinates()



receive


invokePharmacy


1

2

3 4

5

6

7 8

1

3


Patient 1 Patient 2 Patient 3


receive

Doctor

Patient

Doctor

2





BPEL

BPEL


Flow

Patient

receiveSymptoms()


invokeDoctor

enqueueRequest()

invoke

getCoordinates()



receive


invokePharmacy


1

2

3 4

5

6

7 8

1

34

7

1

3

5

4

1




receive

Doctor

Patient

Doctor

22





BPEL

BPEL


Flow

Patient

receiveSymptoms()


invokeDoctor

enqueueRequest()

invoke

getCoordinates()



receive


invokePharmacy


1

2

3 4

5

6

7 8

1

34

1

3

5

4

1




receive

Doctor

Patient

Doctor

22




SIROCO: A middleware transparent approachfor

Dynamic Service Substitution


BPEL

BPEL


Flow

Patient

receiveSymptoms()


invokeDoctor

enqueueRequest()

invoke

getCoordinates()



receive


invokePharmacy


1

2

3 4

5

6

7 8

1

34

1

3

5

4

1




receive

Doctor

Patient

Doctor

22






Doctor Catalog


BPEL

BPEL


Flow

Patient

receiveSymptoms()


invokeDoctor

enqueueRequest()

invoke

getCoordinates()



receive


invokePharmacy


1

2

3 4

5

6

7 8

1

4

1

4

1




receive

Doctor

Patient

Doctor






Doctor Catalog

Doctor

33

5

22


BPEL

BPEL


Flow

Patient

receiveSymptoms()


invokeDoctor

enqueueRequest()

invoke

getCoordinates()



receive


invokePharmacy


1

2

3 4

5

6

7 8

1

4

1

4

1




receive

Doctor

Patient

Doctor






Doctor Catalog

3

Doctor

3

5

22

SIROCO Middleware Architecture

State Storage

Monitoring Manager

Service Registry Execution Engine

Adaptation Manager

for runtime, semantic-based service substitution



o SIROCO Architectureo Dealing with the Dependability Risks

BPEL BPEL BPEL BPEL

Patient

reply

Doctor

receive

invoke

1

2

3 4

5

6

7 8

Doctor

Doctor

Patient

reply

invoke

invoke

invoke

receive

invokePharmacy

1

2

3 4

5

6

7 8

receive

Doctor

Patient

Doctor

Patient

Doctor

1

2

3 4

5

6

7 8

Patient

Doctor

Patient

Doctor

Pharmacy

1

2

3 4

5

6

7

Doctor

Patient

Doctor


State Storage

Monitoring Manager


Adaptation Manager


manages information concerning Web services that are

available in networked environment




BPEL BPEL BPEL BPEL

Patient

reply

Doctor

receive

invoke

1

2

3 4

5

6

7 8

Doctor

Doctor

Patient

reply

invoke

invoke

invoke

receive

invokePharmacy

1

2

3 4

5

6

7 8

receive

Doctor

Patient

Doctor

Patient

Doctor

1

2

3 4

5

6

7 8

Patient

Doctor

Patient

Doctor

Pharmacy

1

2

3 4

5

6

7

Doctor

Patient

Doctor


State Storage

Monitoring Manager


Adaptation Manager




executes the user orchestrations




BPEL BPEL BPEL BPEL

Patient

reply

Doctor

receive

invoke

1

2

3 4

5

6

7 8

Doctor

Doctor

Patient

reply

invoke

invoke

invoke

receive

invokePharmacy

1

2

3 4

5

6

7 8

receive

Doctor

Patient

Doctor

Patient

Doctor

1

2

3 4

5

6

7 8

Patient

Doctor

Patient

Doctor

Pharmacy

1

2

3 4

5

6

7

Doctor

Patient

Doctor


State Storage

Monitoring Manager


Adaptation Manager





inspects the execution of these

orchestrations




BPEL BPEL BPEL BPEL

Patient

reply

Doctor

receive

invoke

1

2

3 4

5

6

7 8

Doctor

Doctor

Patient

reply

invoke

invoke

invoke

receive

invokePharmacy

1

2

3 4

5

6

7 8

receive

Doctor

Patient

Doctor

Patient

Doctor

1

2

3 4

5

6

7 8

Patient

Doctor

Patient

Doctor

Pharmacy

1

2

3 4

5

6

7

Doctor

Patient

Doctor


State Storage

Monitoring Manager


Adaptation Manager





dynamically reconfigures the orchestrations

when necessary


orchestrations




BPEL BPEL BPEL BPEL

Patient

reply

Doctor

receive

invoke

1

2

3 4

5

6

7 8

Doctor

Doctor

Patient

reply

invoke

invoke

invoke

receive

invokePharmacy

1

2

3 4

5

6

7 8

receive

Doctor

Patient

Doctor

Patient

Doctor

1

2

3 4

5

6

7 8

Patient

Doctor

Patient

Doctor

Pharmacy

1

2

3 4

5

6

7

Doctor

Patient

Doctor


State Storage

Monitoring Manager


Adaptation Manager





dynamically reconfigures the orchestrations

when necessary


orchestrations

How does this architecture deal with the dependability risks?




BPEL BPEL BPEL BPEL

Patient

reply

Doctor

receive

invoke

1

2

3 4

5

6

7 8

Doctor

Doctor

Patient

reply

invoke

invoke

invoke

receive

invokePharmacy

1

2

3 4

5

6

7 8

receive

Doctor

Patient

Doctor

Patient

Doctor

1

2

3 4

5

6

7 8

Patient

Doctor

Patient

Doctor

Pharmacy

1

2

3 4

5

6

7

Doctor

Patient

Doctor



o SIROCO Architecture o Dealing with the Dependability Risks

* WSRF: OASIS standard http://www.globus.org/wsrf/

I. Managing Unavailability

We envision to deal with service unavailability rather than preventing it

An unavailable service does not necessarily lead to restart the whole orchestration

In the worst case the orchestration has to be resumed from the first activity that involves the unavailable service

SIROCO limits the scope of the service unavailability by suspending the affected orchestrations

The orchestrations that are still interacting with the unavailable service e.g., Patient 2 ‘s orchestration

The orchestrations that have not yet started interacting with the unavailable service e.g., Patient 1 ‘s orchestration





II. Managing Service StateDoctor Interface

SA-WSDL

WS-Properties document

Doctor Catalog

How to describe the service state?

According to Web Service Resource Framework (WSRF*) standard, services advertise, together with their SAWSDL description, their state using WS-Resource Properties document

How is the compatibility checked?

The catalog related to the unavailable service is split into 2 categories State-aware interfaces State-unaware interfaces

State compatibility is checked by matching between the WS-Resource Properties documents

Lifting and lowering SA-WSDL-enabled techniques allow to deal with post semantic matching issues.












SA-WSDL


Doctor Catalog

SA-WSDL


State-aware Service Interface

SA-WSDL

State-unaware category Service Interface






SA-WSDL


Semantic matching

Syntactic matching

Doctor Catalog

SA-WSDL


State-aware Service Interface

SA-WSDL

State-unaware category Service Interface







How is the state transfer enabled?

We enhance the SAWSDL description with behavior annotation to be informed about the impact of operations on the resources

SIROCO enables the state transfer By saving the state of the service after performing an

‘UpdateState’-annotated operation, This is enabled by enriching the BPEL description of

the orchestration by sending GetResourceProperties message

How is the state transferred?

By sending a SetResourceProperties message to the substitute service in order to synchronize with the last sate stored at SIROCO middleware.

If the SetResourceProperties returns an error message, SIROCO tries to synchronize with a prior state stored, rolling back the orchestration accordingly.




Managing Service State (cont’d)












Behavior Ontology


BPEL

Flow

Patient

receiveSymptoms()


invoke Doctor

enqueueRequest()

invokegetCoordinates()

invokeupdatePatientRecord()

receive


invokePharmacy


1

2

3 4

5

6

7 8

receive

Doctor

Patient

Doctor

Social SecurityAh c












Behavior Ontology


BPEL

Flow

Patient

receiveSymptoms()


invoke Doctor

enqueueRequest()



receive


invokePharmacy


1

2

3 4

5

6

7 8

receive

Doctor

Patient

Doctor

Social SecurityAh cinvokeGetResource

Properties







By sending a SetResourceProperties message to the substitute service in order to synchronize with the last state stored at SIROCO middleware.





Behavior Ontology


BPEL

Flow

Patient

receiveSymptoms()


invoke Doctor

enqueueRequest()



receive


invokePharmacy


1

2

3 4

5

6

7 8

receive

Doctor

Patient

Doctor

Social SecurityAh cinvokeGetResource

Properties

invokeSetResource

Properties

III. Limiting the Side Effects




At substitution time, SIROCO middleware may roll back the results of the unavailable service to the last compatible activity

However, due to dependencies among the services participating in the orchestration, the still-available services may be affected by the substitution

Propagate the rollback to the still-available services

Create a graph that reflects the dependencies between the activities of the services participating in the orchestration

Reason by intervals of activities, included between two GetResourceProperties activities (denoted Cij).

Create a dependency graph

Limiting the Side Effects (cont’d)







Service2

Service3

C21 C22

C31 C32

I2

I3

X is an output of an activity

included btw C21 and C22

X is input parmater

in I3

Consti-

tuent

services








Service2

Service3

C21 C22

C31 C32

I2

I3



X is input parmater

in I3

Consti-

tuent

services

Dependency Graph

C21

C31

Data dependency

due to the

change in the

value of X in I2








Service2

Service3

C21 C22

C31 C32

I2

I3



X is input parmater

in I3

Consti-

tuent

services

Dependency Graph

C21

C31

Data dependency

due to the

change in the

value of X in I2

Service1

C11 C12I1

X is an intput of an activity

btw C11 and C12








Service2

Service3

C21 C22

C31 C32

I2

I3



X is input parmater

in I3

Consti-

tuent

services

Dependency Graph

C21

C31

Data dependency

due to the

change in the

value of X in I2

Service1

C11 C12I1


btw C11 and C12

C11

X value is not changed

within I1=[C11,C12] =>

there is not any data

incoherence after rolling

back to C11








Service2

Service3

C21 C22

C31 C32

I2

I3



X is input parmater

in I3

Consti-

tuent

services

Dependency Graph

C21

C31

Data dependency

due to the

change in the

value of X in I2

Service1

C11 C12I1


btw C11 and C12

C11





back to C11

Sending X to I1

Sending X to I2 Receiving X from I2

Sending X to I3

Service1Orchestr

ator

View-SIROCO

Service2

Service 3





Dependency Graph

C21

C31

Data dependency

due to the

change in the

value of X in I2

C11





back to C11




Service1

Service2

Service3

C21 C22

C11 C12

C31 C32

I1

I2

I3

Consti-

tuent

services

Sending X to I1


Sending X to I3

Service1Orchestr

ator

view-

SIROCO

Service2

Service 3





At runtime, according to the dependency graph, the rollback is propagated.

When a service unavailability is detected (e.g., Service2)

A first rollback is performed to the last compatible state

Rollback is propagated accordingly

Dependency Graph

C21

C31

Data dependency

due to the

change in the

value of X in I2

C11





back to C11




Service1

Service2

Service3

C21 C22

C11 C12

C31 C32

I1

I2

I3

Consti-

tuent

services

Sending X to I1


Sending X to I3

Service1Orchestr

ator

view-

SIROCO

Service2

Service 3

Propagate the rollback

Rollback_to(C31)





At runtime, according to the dependency graph, the rollback is propagated.

When a service unavailability is detected (e.g., Service2)

A first rollback is performed to the last compatible state

Rollback is propagated accordingly

Conclusions & Future Work


Our add Add-ons with SIROCO middleware platform Dynamic (at runtime) service substitution in service orchestration Semantic-based service substitution of stateful services Saves the performed computation by transferring the service state

Evaluations results We compared “SIROCO-based” service reconfiguration with the

“restarting-based” reconfiguration SIROCO service substitution performs better when the service

unavailability takes place at an advanced stage of the orchestration execution

Future Work Coordinate multiple instances of SIROCO middleware Extend the state compatibility with semantic matching

Thank you for your attention

Any Question?

Contact member:Manel Fredj [email protected]

Institution: INRIA Paris-Rocquencourt, ARLES Project-Team http://www-rocq.inria.fr/arles/


slides

Documents

advanced sawsdlsa

flyheterogeneous services

couple of clicks

sawsdl desc

semantic web

wsdl functionalities

user requestsusers

inria parisrocquencourt