slides
DESCRIPTION
TRANSCRIPT
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
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
SA-WSDLSA-WSDLSA-WSDL SA-WSDL SA-WSDL SA-WSDL
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 the Internet meets SOA… …Web Services
SOA abstracts heterogenous 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
Heterogeneous
User
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Environment Characteristics
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
SA-WSDLSA-WSDLSA-WSDL SA-WSDL SA-WSDL SA-WSDL
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 the Internet meets SOA… …Web Services
SOA abstracts heterogenous 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
Heterogeneous
User
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Environment Characteristics
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
SA-WSDLSA-WSDLSA-WSDL SA-WSDL SA-WSDL SA-WSDL
Interoperable
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 the Internet meets SOA… …Web Services
SOA abstracts heterogenous 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
Open
Heterogeneous
User
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Environment Characteristics
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
SA-WSDLSA-WSDLSA-WSDL SA-WSDL SA-WSDL SA-WSDL
Interoperable
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 the Internet meets SOA… …Web Services
SOA abstracts heterogenous 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
RichOpen
Heterogeneous
User
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Environment Characteristics
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
SA-WSDLSA-WSDLSA-WSDL SA-WSDL SA-WSDL SA-WSDL
Interoperable
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 the Internet meets SOA… …Web Services
SOA abstracts heterogenous 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
RichOpen
Heterogeneous
Dynamic
User
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Environment Characteristics
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
SA-WSDLSA-WSDLSA-WSDL SA-WSDL SA-WSDL SA-WSDL
Interoperable
The other side of the coin …
Dependability is not ensured
when a service becomes unavailable
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
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?
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Issues Jeopardizing Dependability Use Scenario : e-Prescription
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
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Issues Jeopardizing Dependability Use Scenario : e-Prescription
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
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Issues Jeopardizing Dependability Use Scenario : e-Prescription
4
e-Prescription Scenario
BPEL
BPEL
Doctor PharmacyNational Social Security
Flow
Patient
receiveSymptoms()
replyprescriptionResults()
invokeDoctor
enqueueRequest()
invoke
getCoordinates()
invokeSocial SecurityAh c
updatePatientRecord()
receive
receivePrescription()
invokePharmacy
issueRequest() "empty"
1
2
3 4
5
6
7 8
1
3
Service unavailability
Patient 2
SA-WSDLSA-WSDL SA-WSDL
receive
Doctor
Patient
Doctor
2
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Issues Jeopardizing Dependability Use Scenario : e-Prescription
e-Prescription Scenario
BPEL
BPEL
Doctor PharmacyNational Social Security
Flow
Patient
receiveSymptoms()
replyprescriptionResults()
invokeDoctor
enqueueRequest()
invoke
getCoordinates()
invokeSocial SecurityAh c
updatePatientRecord()
receive
receivePrescription()
invokePharmacy
issueRequest() "empty"
1
2
3 4
5
6
7 8
1
3
Service unavailability
Patient 1 Patient 2 Patient 3
SA-WSDLSA-WSDL SA-WSDL
receive
Doctor
Patient
Doctor
2
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Issues Jeopardizing Dependability Use Scenario : e-Prescription
e-Prescription Scenario
BPEL
BPEL
Doctor PharmacyNational Social Security
Flow
Patient
receiveSymptoms()
replyprescriptionResults()
invokeDoctor
enqueueRequest()
invoke
getCoordinates()
invokeSocial SecurityAh c
updatePatientRecord()
receive
receivePrescription()
invokePharmacy
issueRequest() "empty"
1
2
3 4
5
6
7 8
1
34
7
1
3
5
4
1
Service unavailability
Patient 1 Patient 2 Patient 3
SA-WSDLSA-WSDL SA-WSDL
receive
Doctor
Patient
Doctor
22
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Issues Jeopardizing Dependability Use Scenario : e-Prescription
e-Prescription Scenario
BPEL
BPEL
Doctor PharmacyNational Social Security
Flow
Patient
receiveSymptoms()
replyprescriptionResults()
invokeDoctor
enqueueRequest()
invoke
getCoordinates()
invokeSocial SecurityAh c
updatePatientRecord()
receive
receivePrescription()
invokePharmacy
issueRequest() "empty"
1
2
3 4
5
6
7 8
1
34
1
3
5
4
1
Service unavailability
Patient 1 Patient 2 Patient 3
SA-WSDLSA-WSDL SA-WSDL
receive
Doctor
Patient
Doctor
22
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Issues Jeopardizing Dependability Use Scenario : e-Prescription
SIROCO: A middleware transparent approachfor
Dynamic Service Substitution
e-Prescription Scenario
BPEL
BPEL
Doctor PharmacyNational Social Security
Flow
Patient
receiveSymptoms()
replyprescriptionResults()
invokeDoctor
enqueueRequest()
invoke
getCoordinates()
invokeSocial SecurityAh c
updatePatientRecord()
receive
receivePrescription()
invokePharmacy
issueRequest() "empty"
1
2
3 4
5
6
7 8
1
34
1
3
5
4
1
Service unavailability
Patient 1 Patient 2 Patient 3
SA-WSDLSA-WSDL SA-WSDL
receive
Doctor
Patient
Doctor
22
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Issues Jeopardizing Dependability Use Scenario : e-Prescription
SIROCO: A middleware transparent approachfor
Dynamic Service Substitution
Doctor Catalog
e-Prescription Scenario
BPEL
BPEL
Doctor PharmacyNational Social Security
Flow
Patient
receiveSymptoms()
replyprescriptionResults()
invokeDoctor
enqueueRequest()
invoke
getCoordinates()
invokeSocial SecurityAh c
updatePatientRecord()
receive
receivePrescription()
invokePharmacy
issueRequest() "empty"
1
2
3 4
5
6
7 8
1
4
1
4
1
Service unavailability
Patient 1 Patient 2 Patient 3
SA-WSDLSA-WSDL SA-WSDL
receive
Doctor
Patient
Doctor
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Issues Jeopardizing Dependability Use Scenario : e-Prescription
SIROCO: A middleware transparent approachfor
Dynamic Service Substitution
Doctor Catalog
Doctor
33
5
22
e-Prescription Scenario
BPEL
BPEL
Doctor PharmacyNational Social Security
Flow
Patient
receiveSymptoms()
replyprescriptionResults()
invokeDoctor
enqueueRequest()
invoke
getCoordinates()
invokeSocial SecurityAh c
updatePatientRecord()
receive
receivePrescription()
invokePharmacy
issueRequest() "empty"
1
2
3 4
5
6
7 8
1
4
1
4
1
Service unavailability
Patient 1 Patient 2 Patient 3
SA-WSDLSA-WSDL SA-WSDL
receive
Doctor
Patient
Doctor
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
Issues Jeopardizing Dependability Use Scenario : e-Prescription
SIROCO: A middleware transparent approachfor
Dynamic Service Substitution
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
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic 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
SIROCO Middleware Architecture
State Storage
Monitoring Manager
Service Registry Execution Engine
Adaptation Manager
for runtime, semantic-based service substitution
manages information concerning Web services that are
available in networked environment
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic 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
SIROCO Middleware Architecture
State Storage
Monitoring Manager
Service Registry Execution Engine
Adaptation Manager
for runtime, semantic-based service substitution
manages information concerning Web services that are
available in networked environment
executes the user orchestrations
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic 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
SIROCO Middleware Architecture
State Storage
Monitoring Manager
Service Registry Execution Engine
Adaptation Manager
for runtime, semantic-based service substitution
manages information concerning Web services that are
available in networked environment
executes the user orchestrations
inspects the execution of these
orchestrations
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic 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
SIROCO Middleware Architecture
State Storage
Monitoring Manager
Service Registry Execution Engine
Adaptation Manager
for runtime, semantic-based service substitution
manages information concerning Web services that are
available in networked environment
executes the user orchestrations
dynamically reconfigures the orchestrations
when necessary
inspects the execution of these
orchestrations
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic 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
SIROCO Middleware Architecture
State Storage
Monitoring Manager
Service Registry Execution Engine
Adaptation Manager
for runtime, semantic-based service substitution
manages information concerning Web services that are
available in networked environment
executes the user orchestrations
dynamically reconfigures the orchestrations
when necessary
inspects the execution of these
orchestrations
How does this architecture deal with the dependability risks?
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic 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
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
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
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architecture o Dealing with the Dependability Risks
* WSRF: OASIS standard http://www.globus.org/wsrf/
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.
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architecture o Dealing with the Dependability Risks
* WSRF: OASIS standard http://www.globus.org/wsrf/
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.
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.
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architecture o Dealing with the Dependability Risks
* WSRF: OASIS standard http://www.globus.org/wsrf/
II. Managing Service StateDoctor Interface
SA-WSDL
WS-Properties document
Doctor Catalog
SA-WSDL
WS-Properties document
State-aware Service Interface
SA-WSDL
State-unaware category Service Interface
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architecture o Dealing with the Dependability Risks
* WSRF: OASIS standard http://www.globus.org/wsrf/
II. Managing Service StateDoctor Interface
SA-WSDL
WS-Properties document
Semantic matching
Syntactic matching
Doctor Catalog
SA-WSDL
WS-Properties document
State-aware Service Interface
SA-WSDL
State-unaware category Service Interface
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.
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architecture o Dealing with the Dependability Risks
* WSRF: OASIS standard http://www.globus.org/wsrf/
II. Managing Service StateDoctor Interface
SA-WSDL
WS-Properties document
Semantic matching
Syntactic matching
Doctor Catalog
SA-WSDL
WS-Properties document
State-aware Service Interface
SA-WSDL
State-unaware category Service Interface
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.
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.
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
Managing Service State (cont’d)
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.
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
Behavior Ontology
Managing Service State (cont’d)
BPEL
Flow
Patient
receiveSymptoms()
replyprescriptionResults()
invoke Doctor
enqueueRequest()
invokegetCoordinates()
invokeupdatePatientRecord()
receive
receivePrescription()
invokePharmacy
issueRequest() "empty"
1
2
3 4
5
6
7 8
receive
Doctor
Patient
Doctor
Social SecurityAh c
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.
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
Behavior Ontology
Managing Service State (cont’d)
BPEL
Flow
Patient
receiveSymptoms()
replyprescriptionResults()
invoke Doctor
enqueueRequest()
invokegetCoordinates()
invokeupdatePatientRecord()
receive
receivePrescription()
invokePharmacy
issueRequest() "empty"
1
2
3 4
5
6
7 8
receive
Doctor
Patient
Doctor
Social SecurityAh cinvokeGetResource
Properties
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 state 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.
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
Behavior Ontology
Managing Service State (cont’d)
BPEL
Flow
Patient
receiveSymptoms()
replyprescriptionResults()
invoke Doctor
enqueueRequest()
invokegetCoordinates()
invokeupdatePatientRecord()
receive
receivePrescription()
invokePharmacy
issueRequest() "empty"
1
2
3 4
5
6
7 8
receive
Doctor
Patient
Doctor
Social SecurityAh cinvokeGetResource
Properties
invokeSetResource
Properties
III. Limiting the Side Effects
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
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)
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
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
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
Limiting the Side Effects (cont’d)
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
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
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
Dependency Graph
C21
C31
Data dependency
due to the
change in the
value of X in I2
Limiting the Side Effects (cont’d)
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
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
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
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
Limiting the Side Effects (cont’d)
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
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
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
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
C11
X value is not changed
within I1=[C11,C12] =>
there is not any data
incoherence after rolling
back to C11
Limiting the Side Effects (cont’d)
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
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
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
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
C11
X value is not changed
within I1=[C11,C12] =>
there is not any data
incoherence after rolling
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
Limiting the Side Effects (cont’d)
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
Dependency Graph
C21
C31
Data dependency
due to the
change in the
value of X in I2
C11
X value is not changed
within I1=[C11,C12] =>
there is not any data
incoherence after rolling
back to C11
Limiting the Side Effects (cont’d)
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
Service1
Service2
Service3
C21 C22
C11 C12
C31 C32
I1
I2
I3
Consti-
tuent
services
Sending X to I1
Sending X to I2 Receiving X from I2
Sending X to I3
Service1Orchestr
ator
view-
SIROCO
Service2
Service 3
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
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
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
X value is not changed
within I1=[C11,C12] =>
there is not any data
incoherence after rolling
back to C11
Limiting the Side Effects (cont’d)
Environment Characteristics Dependability Risks SIROCO Middleware for Dynamic Service Substitution
o SIROCO Architectureo Dealing with the Dependability Risks
Service1
Service2
Service3
C21 C22
C11 C12
C31 C32
I1
I2
I3
Consti-
tuent
services
Sending X to I1
Sending X to I2 Receiving X from I2
Sending X to I3
Service1Orchestr
ator
view-
SIROCO
Service2
Service 3
Propagate the rollback
Rollback_to(C31)
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
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
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
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
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/
ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008