Dynamic Service Substitution in Service-Oriented Architectures Manel Fredj , Nikolaos Georgantas , Valérie Issarny and Apostolos Zarras ARLES Project-Team, INRIA Paris-Rocquencourt, France University of Ioannina, Greece July 11th, 2008 2008 IEEE Congress on SERVICES , Honolulu, Hawaii SOA Industry Summit (SOAIS 2008) ) 1 ( ) 1 ( ) 1 ( ) 2 ( ) 1 ( ) 2 (
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Dynamic Service Substitution in Service-Oriented Architectures
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?
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?
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.
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.
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.
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.
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.
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.
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.
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