• Like
Slides
Upcoming SlideShare
Loading in...5
×
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
142
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Dynamic Service Substitution in Service-Oriented Architectures Manel Fredj (1), Nikolaos Georgantas (1), Valérie Issarny(1) and Apostolos Zarras ( 2) (1 ) ARLES Project-Team, INRIA Paris-Rocquencourt, France ( 2) University of Ioannina, Greece July 11th, 2008 2008 IEEE Congress on SERVICES , Honolulu, Hawaii SOA Industry Summit (SOAIS 2008)
  • 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
  • 3.  Environment Characteristics  Dependability Risks Environment Characteristics  SIROCO Middleware for Dynamic Service Substitution When Internet meets SOA… … Web Services  SOA abstracts heterogeneous applications as Services, which are The world is a “couple of clicks” far from you described using well-defined interfaces (e.g. SA-WSDL desc.) User  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 SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL functionalities using the service orchestrations … and many more Camera Sport training Health e-Business e-Learning Repair services lessons assistance ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 4.  Environment Characteristics  Dependability Risks Environment Characteristics  SIROCO Middleware for Dynamic Service Substitution When the Internet meets SOA… …Web Services  SOA abstracts heterogenous The world is a “couple of clicks” far from you applications as Services, which are described using well-defined interfaces (e.g. SA-WSDL desc.) User  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 Heterogeneous  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 SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL functionalities using the service orchestrations … and many more Camera Sport training Health e-Business e-Learning Repair services lessons assistance ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 5.  Environment Characteristics  Dependability Risks Environment Characteristics  SIROCO Middleware for Dynamic Service Substitution When the Internet meets SOA… …Web Services  SOA abstracts heterogenous The world is a “couple of clicks” far from you applications as Services, which are described using well-defined interfaces (e.g. SA-WSDL desc.) User  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 Heterogeneous Interoperable  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 SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL functionalities using the service orchestrations … and many more Camera Sport training Health e-Business e-Learning Repair services lessons assistance ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 6.  Environment Characteristics  Dependability Risks Environment Characteristics  SIROCO Middleware for Dynamic Service Substitution When the Internet meets SOA… …Web Services  SOA abstracts heterogenous The world is a “couple of clicks” far from you applications as Services, which are described using well-defined interfaces (e.g. SA-WSDL desc.) User  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 Heterogeneous Interoperable  Services can be deployed, and thus available in a couple of Open “clicks”, anywhere, at any time  Users can dynamically compose services in order to perform advanced SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL functionalities using the service orchestrations … and many more Camera Sport training Health e-Business e-Learning Repair services lessons assistance ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 7.  Environment Characteristics  Dependability Risks Environment Characteristics  SIROCO Middleware for Dynamic Service Substitution When the Internet meets SOA… …Web Services  SOA abstracts heterogenous The world is a “couple of clicks” far from you applications as Services, which are described using well-defined interfaces (e.g. SA-WSDL desc.) User  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 Heterogeneous Interoperable  Services can be deployed, and thus available in a couple of “clicks”, Open Rich anywhere, at any time  Users can dynamically compose services in order to perform advanced SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL functionalities using the service orchestrations … and many more Camera Sport training Health e-Business e-Learning Repair services lessons assistance ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 8.  Environment Characteristics  Dependability Risks Environment Characteristics  SIROCO Middleware for Dynamic Service Substitution When the Internet meets SOA… …Web Services  SOA abstracts heterogenous The world is a “couple of clicks” far from you applications as Services, which are described using well-defined interfaces (e.g. SA-WSDL desc.) User  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 Heterogeneous Interoperable  Services can be deployed, and thus Dynamic available in a couple of “clicks”, Open Rich anywhere, at any time  Users can dynamically compose services in order to perform advanced SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL SA-WSDL functionalities using the service orchestrations … and many more Camera Sport training Health e-Business e-Learning Repair services lessons assistance ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 9. The other side of the coin … Dependability is not ensured when a service becomes unavailable ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 10.  Environment Characteristics  Issues Jeopardizing Dependability  Dependability Risks  Use Scenario : e-Prescription  SIROCO Middleware for Dynamic Service Substitution 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 performed How 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
  • 11.  Environment Characteristics  Issues Jeopardizing Dependability  Dependability Risks  Use Scenario : e-Prescription  SIROCO Middleware for Dynamic Service Substitution Issues Jeopardizing Dependability  Services can be un-deployed at any time, without beforehand notification I. fd Managing How to prevent the orchestration from the service unavailability? Unavailability  Services may maintain a state Interactions with the unavailable services have to be restarted from the beginning, losing thereby II. fe all the computation performed Managing How to ensure reliability (i.e., continuity in service provisioning) for the service orchestrations? State  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? III. ld  Orchestration involves more than one service… Side Effects How far are the other services affected? ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 12.  Environment Characteristics  Issues Jeopardizing Dependability  Dependability Risks  Use Scenario : e-Prescription  SIROCO Middleware for Dynamic Service Substitution e-Prescription Scenario BPEL BPEL Patient 1 receive receiveSymptoms() invoke Doctor 2 1 getCoordinates() 6 Patient 2 Flow Doctor Social Security 3 invoke 4 invoke enqueueRequest() updatePatientRecord() receive Doctor 5 receivePrescription() Patient 6 reply prescriptionResults() 7 Pharmacy 8 2 7 invoke 4 issueRequest() "empty" 3 5 National Social Doctor Pharmacy Security SA-WSDL SA-WSDL SA-WSDL ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 13.  Environment Characteristics  Issues Jeopardizing Dependability  Dependability Risks  Use Scenario : e-Prescription  SIROCO Middleware for Dynamic Service Substitution e-Prescription Scenario BPEL BPEL Patient 1 receive receiveSymptoms() invoke Doctor 2 1 getCoordinates() Patient 2 Flow Doctor Social SecurityAh 3 invoke 4 invoke enqueueRequest() updatePatientRecord() receive Doctor 5 receivePrescription() Patient 6 reply prescriptionResults() 7 Pharmacy 8 invoke 2 issueRequest() "empty" 3 National Social Doctor Pharmacy Security SA-WSDL SA-WSDL SA-WSDL Service unavailability ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 14.  Environment Characteristics  Issues Jeopardizing Dependability  Dependability Risks  Use Scenario : e-Prescription  SIROCO Middleware for Dynamic Service Substitution e-Prescription Scenario BPEL BPEL Patient 1 receive receiveSymptoms() invoke Doctor 2 1 getCoordinates() Patient 1 Patient 2 Patient 3 Flow Doctor Social SecurityAh 3 invoke 4 invoke enqueueRequest() updatePatientRecord() receive Doctor 5 receivePrescription() Patient 6 reply prescriptionResults() 7 Pharmacy 8 invoke 2 issueRequest() "empty" 3 National Social Doctor Pharmacy Security SA-WSDL SA-WSDL SA-WSDL Service unavailability ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 15.  Environment Characteristics  Issues Jeopardizing Dependability  Dependability Risks  Use Scenario : e-Prescription  SIROCO Middleware for Dynamic Service Substitution e-Prescription Scenario BPEL BPEL Patient 1 receive receiveSymptoms() invoke Doctor 2 1 1 1 getCoordinates() Patient 1 Patient 2 Patient 3 Flow Doctor Social SecurityAh 3 invoke 4 invoke enqueueRequest() updatePatientRecord() receive Doctor 5 receivePrescription() Patient 6 reply prescriptionResults() 7 Pharmacy 8 2 2 7 invoke 4 4 issueRequest() "empty" 3 3 5 National Social Doctor Pharmacy Security SA-WSDL SA-WSDL SA-WSDL Service unavailability ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 16.  Environment Characteristics  Issues Jeopardizing Dependability  Dependability Risks  Use Scenario : e-Prescription  SIROCO Middleware for Dynamic Service Substitution e-Prescription Scenario BPEL BPEL Patient 1 receive receiveSymptoms() invoke Doctor 2 1 1 1 getCoordinates() Patient 1 Patient 2 Patient 3 Flow Doctor Social SecurityAh 3 invoke 4 invoke enqueueRequest() updatePatientRecord() SIROCO: A middleware transparent approach for 5 receive Doctor Dynamic Service Substitution receivePrescription() Patient 6 reply prescriptionResults() 7 Pharmacy 8 invoke 4 4 2 2 issueRequest() "empty" 3 3 5 National Social Doctor Pharmacy Security SA-WSDL SA-WSDL SA-WSDL Service unavailability ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 17.  Environment Characteristics  Issues Jeopardizing Dependability  Dependability Risks  Use Scenario : e-Prescription  SIROCO Middleware for Dynamic Service Substitution e-Prescription Scenario BPEL BPEL Patient 1 receive receiveSymptoms() invoke Doctor 2 1 1 1 getCoordinates() Patient 1 Patient 2 Patient 3 Flow Doctor Social SecurityAh 3 invoke 4 invoke enqueueRequest() updatePatientRecord() SIROCO: A middleware transparent approach for 5 receive Doctor Dynamic Service Substitution receivePrescription() Patient 6 reply prescriptionResults() 7 Pharmacy 8 invoke 4 4 2 2 issueRequest() "empty" 3 3 5 National Social Doctor Pharmacy Security SA-WSDL SA-WSDL SA-WSDL Service unavailability Doctor Catalog ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 18.  Environment Characteristics  Issues Jeopardizing Dependability  Dependability Risks  Use Scenario : e-Prescription  SIROCO Middleware for Dynamic Service Substitution e-Prescription Scenario BPEL BPEL Patient 1 receive receiveSymptoms() invoke Doctor 2 1 1 1 getCoordinates() Patient 1 Patient 2 Patient 3 Flow Doctor Social SecurityAh 3 invoke 4 invoke enqueueRequest() updatePatientRecord() SIROCO: A middleware transparent approach for 5 receive Doctor Dynamic Service Substitution receivePrescription() Patient 6 reply prescriptionResults() 7 Pharmacy 8 invoke 4 4 2 2 issueRequest() "empty" 3 3 5 National Social Doctor Pharmacy Doctor Security SA-WSDL SA-WSDL SA-WSDL Service unavailability Doctor Catalog ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 19.  Environment Characteristics  Issues Jeopardizing Dependability  Dependability Risks  Use Scenario : e-Prescription  SIROCO Middleware for Dynamic Service Substitution e-Prescription Scenario BPEL BPEL Patient 1 receive receiveSymptoms() invoke Doctor 2 1 1 1 getCoordinates() Patient 1 Patient 2 Patient 3 Flow Doctor Social SecurityAh 3 invoke 4 invoke enqueueRequest() updatePatientRecord() SIROCO: A middleware transparent approach for 5 receive Doctor Dynamic Service Substitution receivePrescription() Patient 6 reply prescriptionResults() 7 Pharmacy 8 4 4 2 2 invoke issueRequest() "empty" 3 3 5 National Social Doctor Doctor Pharmacy Security SA-WSDL SA-WSDL SA-WSDL Service unavailability Doctor Catalog ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 20.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution SIROCO Middleware Architecture for runtime, semantic-based service substitution 1 Patient 1 receive Patient 1 Patient 1 Patient 2 Doctor 2 invoke Doctor 2 Doctor 2 Doctor 3 Doctor 4 3 invo 4 invoke 3 Doctor 4 3 Doctor 4 ke 5 receive Doctor 5 receive Doctor 5 5 Doctor 6 reply 6 reply Patient 6 Patient 6 Patient 7 8 7 8 Pharmacy 7 8 7 Pharmacy invoke invoke BPEL BPEL BPEL BPEL Service Registry Execution Engine Adaptation Manager Monitoring Manager State Storage ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 21.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution SIROCO Middleware Architecture for runtime, semantic-based service substitution 1 Patient 1 receive Patient 1 Patient 1 Patient 2 Doctor 2 invoke Doctor 2 Doctor 2 Doctor 3 Doctor 4 3 invo 4 invoke 3 Doctor 4 3 Doctor 4 ke 5 receive Doctor 5 receive Doctor 5 5 Doctor 6 reply 6 reply Patient 6 Patient 6 Patient 7 8 7 8 Pharmacy 7 8 7 Pharmacy invoke invoke BPEL BPEL BPEL BPEL manages information concerning Web Service Registry Execution Engine services that are available in networked environment Adaptation Manager Monitoring Manager State Storage ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 22.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution SIROCO Middleware Architecture for runtime, semantic-based service substitution 1 Patient 1 receive Patient 1 Patient 1 Patient 2 Doctor 2 invoke Doctor 2 Doctor 2 Doctor 3 Doctor 4 3 invo 4 invoke 3 Doctor 4 3 Doctor 4 ke 5 receive Doctor 5 receive Doctor 5 5 Doctor 6 reply 6 reply Patient 6 Patient 6 Patient 7 8 7 8 Pharmacy 7 8 7 Pharmacy invoke invoke BPEL BPEL BPEL BPEL manages information executes the user concerning Web Service Registry Execution Engine orchestrations services that are available in networked environment Adaptation Manager Monitoring Manager State Storage ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 23.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution SIROCO Middleware Architecture for runtime, semantic-based service substitution 1 Patient 1 receive Patient 1 Patient 1 Patient 2 Doctor 2 invoke Doctor 2 Doctor 2 Doctor 3 Doctor 4 3 invo 4 invoke 3 Doctor 4 3 Doctor 4 ke 5 receive Doctor 5 receive Doctor 5 5 Doctor 6 reply 6 reply Patient 6 Patient 6 Patient 7 8 7 8 Pharmacy 7 8 7 Pharmacy invoke invoke BPEL BPEL BPEL BPEL manages information executes the user concerning Web Service Registry Execution Engine orchestrations services that are available in networked environment Adaptation Manager Monitoring Manager inspects the execution of these orchestrations State Storage ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 24.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution SIROCO Middleware Architecture for runtime, semantic-based service substitution 1 Patient 1 receive Patient 1 Patient 1 Patient 2 Doctor 2 invoke Doctor 2 Doctor 2 Doctor 3 Doctor 4 3 invo 4 invoke 3 Doctor 4 3 Doctor 4 ke 5 receive Doctor 5 receive Doctor 5 5 Doctor 6 reply 6 reply Patient 6 Patient 6 Patient 7 8 7 8 Pharmacy 7 8 7 Pharmacy invoke invoke BPEL BPEL BPEL BPEL manages information executes the user concerning Web Service Registry Execution Engine orchestrations services that are available in networked environment Adaptation Manager Monitoring Manager dynamically reconfigures the inspects the execution orchestrations of these orchestrations when necessary State Storage ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 25.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution SIROCO Middleware Architecture for runtime, semantic-based service substitution 1 Patient 1 receive Patient 1 Patient 1 Patient 2 Doctor 2 invoke Doctor 2 Doctor 2 Doctor 3 Doctor 4 3 invo 4 invoke 3 Doctor 4 3 Doctor 4 ke 5 receive Doctor 5 receive Doctor 5 5 Doctor 6 reply 6 reply Patient 6 Patient 6 Patient 7 8 7 8 Pharmacy 7 8 7 Pharmacy invoke invoke BPEL BPEL BPEL BPEL manages information executes the user concerning Web Service Registry Execution Engine orchestrations services that are available in networked environment Adaptation Manager Monitoring Manager dynamically reconfigures the inspects the execution orchestrations of these orchestrations when necessary State Storage How does this architecture deal with the dependability risks? ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 26.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution 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 * WSRF: OASIS standard http://www.globus.org/wsrf/ ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 27.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution II. Managing Service State Doctor Interface How to describe the service state? SA-WSDL WS-Properties document  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 Doctor Catalog  Lifting and lowering SA-WSDL-enabled techniques allow to deal with post semantic matching issues. * WSRF: OASIS standard http://www.globus.org/wsrf/ ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 28.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution II. Managing Service State Doctor Interface How to describe the service state? SA-WSDL WS-Properties document  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 Doctor Catalog  Lifting and lowering SA-WSDL-enabled techniques allow to deal with post semantic matching issues. * WSRF: OASIS standard http://www.globus.org/wsrf/ ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 29.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution II. Managing Service State Doctor Interface How to describe the service state? SA-WSDL WS-Properties document  According to Web Service Resource Framework (WSRF*) standard, services advertise, together with their SAWSDL description, their state using WS-Resource Properties document State-aware How is the compatibility checked? Service Interface SA-WSDL  The catalog related to the unavailable service is WS-Properties document split into 2 categories  State-aware interfaces  State-unaware interfaces  State compatibility is checked by matching SA-WSDL between the WS-Resource Properties documents State-unaware category Service Doctor Catalog  Lifting and lowering SA-WSDL-enabled Interface techniques allow to deal with post semantic matching issues. * WSRF: OASIS standard http://www.globus.org/wsrf/ ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 30.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution II. Managing Service State Doctor Interface How to describe the service state? SA-WSDL WS-Properties document  According to Web Service Resource Framework (WSRF*) standard, services advertise, together with their SAWSDL description, their state using Syntactic WS-Resource Properties document Semantic matching matching State-aware How is the compatibility checked? Service Interface SA-WSDL  The catalog related to the unavailable service is WS-Properties document split into 2 categories  State-aware interfaces  State-unaware interfaces  State compatibility is checked by matching SA-WSDL between the WS-Resource Properties documents State-unaware category Service Doctor Catalog  Lifting and lowering SA-WSDL-enabled Interface techniques allow to deal with post semantic matching issues. * WSRF: OASIS standard http://www.globus.org/wsrf/ ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 31.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution II. Managing Service State Doctor Interface How to describe the service state? SA-WSDL WS-Properties document  According to Web Service Resource Framework (WSRF*) standard, services advertise, together with their SAWSDL description, their state using Syntactic WS-Resource Properties document Semantic matching matching State-aware How is the compatibility checked? Service Interface SA-WSDL  The catalog related to the unavailable service is WS-Properties document split into 2 categories  State-aware interfaces  State-unaware interfaces  State compatibility is checked by matching SA-WSDL between the WS-Resource Properties documents State-unaware category Service Doctor Catalog  Lifting and lowering SA-WSDL-enabled Interface techniques allow to deal with post semantic matching issues. * WSRF: OASIS standard http://www.globus.org/wsrf/ ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 32.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution 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
  • 33.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution Managing Service State (cont‟d) How is the state transfer enabled? Behavior Ontology  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, BPEL Patient  1 receive This is enabled by enriching the BPEL description of 2 receiveSymptoms() invoke Doctor the orchestration by sending GetResourceProperties getCoordinates() message 3 invoke Flow Doctor 4 invoke Social SecurityAh c enqueueRequest() updatePatientRecord() 5 receive Doctor How is the state transferred? receivePrescription() 6 Patient reply prescriptionResults() 7 8 Pharmacy  invoke By sending a SetResourceProperties message to the issueRequest() "empty" 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
  • 34.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution Managing Service State (cont‟d) How is the state transfer enabled? Behavior Ontology  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, BPEL Patient  1 receive This is enabled by enriching the BPEL description of 2 receiveSymptoms() invoke Doctor the orchestration by sending GetResourceProperties getCoordinates() message invoke 3 invoke Flow Doctor 4 invoke Social SecurityAh c enqueueRequest() updatePatientRecord() GetResource 5 receive Doctor How is the state transferred? Properties receivePrescription() 6 Patient reply prescriptionResults() 7 8 Pharmacy  invoke By sending a SetResourceProperties message to the issueRequest() "empty" 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
  • 35.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution Managing Service State (cont‟d) How is the state transfer enabled? Behavior Ontology  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, BPEL Patient  1 receive This is enabled by enriching the BPEL description of 2 receiveSymptoms() invoke Doctor the orchestration by sending GetResourceProperties getCoordinates() message invoke 3 invoke Flow Doctor 4 invoke Social SecurityAh c enqueueRequest() updatePatientRecord() GetResource 5 receive Doctor How is the state transferred? Properties receivePrescription() 6 Patient reply prescriptionResults() invoke 7 Pharmacy 8  invoke By sending a SetResourceProperties message to the SetResource issueRequest() "empty" substitute service in order to synchronize with the last state Properties 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
  • 36.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution 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 ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 37.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution Limiting the Side Effects (cont‟d)  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 ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 38.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution Limiting the Side Effects (cont‟d) X is an output of an activity included btw C21 and C22 Consti- Service2  Create a graph that reflects the tuent services C21 I2 C22 X is input parmater dependencies between the activities in I3 of the services participating in the Service3 C31 I3 C32 orchestration  Reason by intervals of activities, included between two GetResourceProperties activities (denoted Cij).  Create a dependency graph ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 39.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution Limiting the Side Effects (cont‟d) X is an output of an activity included btw C21 and C22 Consti- Service2  Create a graph that reflects the tuent services C21 I2 C22 X is input parmater dependencies between the activities in I3 of the services participating in the Service3 C31 I3 C32 orchestration  Reason by intervals of activities, included between two GetResourceProperties activities (denoted Cij).  Create a dependency graph C21 Dependency Graph Data dependency due to the C31 change in the value of X in I2 ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 40.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution Limiting the Side Effects (cont‟d) X is an intput of an activity btw C11 and C12 Service1 C11 I1 C12 X is an output of an activity included btw C21 and C22 Consti- Service2  Create a graph that reflects the tuent services C21 I2 C22 X is input parmater dependencies between the activities in I3 of the services participating in the Service3 C31 I3 C32 orchestration  Reason by intervals of activities, included between two GetResourceProperties activities (denoted Cij).  Create a dependency graph C21 Dependency Graph Data dependency due to the C31 change in the value of X in I2 ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 41.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution Limiting the Side Effects (cont‟d) X is an intput of an activity btw C11 and C12 Service1 C11 I1 C12 X is an output of an activity included btw C21 and C22 Consti- Service2  Create a graph that reflects the tuent services C21 I2 C22 X is input parmater dependencies between the activities in I3 of the services participating in the Service3 C31 I3 C32 orchestration  Reason by intervals of activities, included between two GetResourceProperties activities (denoted Cij).  Create a dependency graph X value is not changed within I1=[C11,C12] => there is not any data incoherence after rolling C11 back to C11 C21 Dependency Graph Data dependency due to the C31 change in the value of X in I2 ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 42.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution Limiting the Side Effects (cont‟d) X is an intput of an activity btw C11 and C12 Service1 C11 I1 C12 X is an output of an activity included btw C21 and C22 Consti- Service2  Create a graph that reflects the tuent services C21 I2 C22 X is input parmater dependencies between the activities in I3 of the services participating in the Service3 C31 I3 C32 orchestration  Reason by intervals of activities, included between two Sending X to I1 Service1 Orchestr GetResourceProperties activities ator Service2 (denoted Cij). View- Sending X to I2 Receiving X from I2 SIROCO  Create a dependency graph Sending X to I3 Service 3 X value is not changed within I1=[C11,C12] => there is not any data incoherence after rolling C11 back to C11 C21 Dependency Graph Data dependency due to the C31 change in the value of X in I2 ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 43.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution Limiting the Side Effects (cont‟d) Service1 C11 I1 C12  Create a graph that reflects the Consti- Service2 dependencies between the activities tuent services C21 I2 C22 of the services participating in the orchestration Service3 C31 I3 C32  Reason by intervals of activities, included between two GetResourceProperties activities Orchestr Sending X to I1 Service1 (denoted Cij). ator Service2 view- Sending X to I2 Receiving X from I2  Create a dependency graph SIROCO Sending X to I3 Service 3  At runtime, according to the dependency graph, the rollback is X value is not changed within I1=[C11,C12] => propagated. there is not any data incoherence after rolling  When a service unavailability is C11 back to C11 detected (e.g., Service2)  A first rollback is performed to the last C21 compatible state Dependency Graph  Rollback is propagated accordingly Data dependency due to the C31 change in the value of X in I2 ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 44.  Environment Characteristics o SIROCO Architecture  Dependability Risks o Dealing with the Dependability Risks  SIROCO Middleware for Dynamic Service Substitution Limiting the Side Effects (cont‟d) Service1 C11 I1 C12  Create a graph that reflects the Consti- Service2 dependencies between the activities tuent services C21 I2 C22 of the services participating in the orchestration Service3 C31 I3 C32  Reason by intervals of activities, included between two GetResourceProperties activities Orchestr Sending X to I1 Rollback_to(C31) Service1 (denoted Cij). ator Service2 view- Sending X to I2  Create a dependency graph SIROCO Propagate the rollback Receiving X from I2 Sending X to I3 Service 3  At runtime, according to the dependency graph, the rollback is X value is not changed within I1=[C11,C12] => propagated. there is not any data incoherence after rolling  When a service unavailability is C11 back to C11 detected (e.g., Service2)  A first rollback is performed to the last C21 compatible state Dependency Graph  Rollback is propagated accordingly Data dependency due to the C31 change in the value of X in I2 ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 45. 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 ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008
  • 46. Thank you for your attention Any Question? Contact member: Manel Fredj manel.fredj@inria.fr Institution: INRIA Paris-Rocquencourt, ARLES Project-Team http://www-rocq.inria.fr/arles/ ARLES Project-Team, INRIA Paris-Rocquencourt SOAIS 2008