Slides

295 views
225 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
295
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Slides

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×