Correcting Deadlocking Service Choreographies Using a Simulation-Based Graph Edit Distance


Published on

Conference presentation given by Niels Lohmann on September 2, 2008 in Milan, Italy at the Sixth International Conference on Business Process Management (BPM 2008).

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • manyparticipantsno globalcontrol
  • applications: e.g. testing (as you will see)
  • Zahlen feiern! (für Kathrin)
  • Correcting Deadlocking Service Choreographies Using a Simulation-Based Graph Edit Distance

    1. 1. Correcting Choreographiesusing Graph Similarities<br />Niels Lohmann<br />BPM 2008 ▪ Milan ▪ 2 September 2008<br /><br />UNIVERSITÄT ROSTOCK<br />
    2. 2. 2<br />a deadlock in a choreography<br />How can weavoid this?<br />What wentwrong?<br />Who is toblame?<br /><br />
    3. 3. State-of-the-art choreography analysis <br />3<br />translate BPEL choreography into formal model<br />check for deadlocks<br />if deadlock found:<br />choose a &quot;scapegoat&quot; participant<br />remove it from the choreography<br />synthesize a corrected version (if possible)<br />retranslate synthesized participant back to BPEL<br />Full tool support available! [WS-FM2007]<br />
    4. 4. Problem with that approach<br />4<br />the synthesized service<br />is built independently from the scapegoat<br />gives no information what was changed<br />is correct, yet might not cover the original intention<br />
    5. 5. Example choreography<br />5<br />✓<br />
    6. 6. Example choreography<br />6<br />✗<br />
    7. 7. Fix the customer service<br />7<br />✗<br />scapegoat<br />✓<br />✓<br />better choice<br />
    8. 8. Setting<br />8<br />given:<br />a service (the scapegoat)<br />a set ofcandidates<br />find:<br />the candidate that is most similar to the scapegoat<br />…without sequentially checking all candidates <br />
    9. 9. Operating Guidelines in a Nutshell<br />9<br />automaton annotated with Boolean formulae<br />characterizes all partners of a service [ATPN2007]<br />partner iffsimulated by OG + fulfilling the annotations<br />
    10. 10. OG characterizes all possible corrections<br />10<br />and 2001 additional candidates<br />✓<br />✗<br />✓<br />
    11. 11. Setting (refined)<br />11<br />given:<br />a service automaton (the scapegoat)<br />an operating guideline characterizing allcandidates<br />find:<br />the candidate that is most similar to the scapegoat<br />…without sequentially checking all candidates <br />
    12. 12. Graph edit distance<br />a measure to compare graphs: edit distance= no. of needed actions to achieve graph isomorphism<br />maybe associated with a cost function<br />b<br />a<br />modify b to a<br />a<br />d<br />0,5<br />a<br />d<br />add c branch<br />e<br />c<br />d<br />c<br />d<br />e<br />0,7<br />delete e branch<br />e<br />0,3<br />12<br />
    13. 13. Graph edit distance vs. behavior<br />!a<br />?b<br />!c<br />?b<br />!a<br />low edit distance<br />unsimilar behavior<br />high edit distance<br />equivalent behavior<br /><br />!c<br />!a<br />?b<br />?b<br />!a<br />high edit distance<br />unsimilar behavior<br />!c<br />13<br />
    14. 14. Simulation-based graph similarity<br />Idea: find a similarity that respects simulation<br />compare two states and find best transitionsw.r.t. successor states [TACAS2006]<br />a<br />a<br />b<br />c<br />c<br />b<br />d<br />d<br />d<br />14<br />
    15. 15. Simulation-based graph similarity<br />Mismatches are treated with stuttering steps<br />penalize stuttering by label similarity function<br />choose best pairs by maximizing label similarity<br />a<br />a<br />b<br />c<br />c<br />b<br />e<br />d<br />ε<br />f<br />15<br />
    16. 16. Simulation-based edit distance<br />label similarity function defines an edit distance<br />(a,a) ➙keep a<br />(e,d) ➙change e to d<br />(ε,x) ➙insert x<br />(f,ε) ➙delete f<br />values can be derived from semantic Webinformation<br />(!€,!$) or (?receipt,?confirmation) rather high<br />(!login,?invoice) rather low<br />a<br />a<br />b<br />c<br />b<br />c<br />e<br />d<br />ε<br />f<br />16<br />
    17. 17. Simulation and OG matching<br />17<br />Simulation is only one part of the OG matching<br />next step: make edit distance aware of formulas<br />✗<br />
    18. 18. Respect formulas<br />18<br />instead of comparison with the OG&apos;s structure…<br />compare with satisfying assignments of the formula<br />worst-case complexity: O(|QSA|⋅|QOG|⋅2|I|⋅|I|!)<br />assignments<br />edge permutations<br />
    19. 19. Experimental results<br />19<br />Simulation- and matching-based edit distance implemented in tool RAChEL<br />Dynamic programming exploits structure of the problem <br />Most results within few seconds<br />Exceptions have near-worst-case structure/formulas<br />Repairing Automata forChoreographies by Editing Labels<br />
    20. 20. 20<br />edit actions can be mapped back to original service<br />result can be influenced by adjusting label similarities <br />Fixing the example with Rachel<br />
    21. 21. 21<br />choreographies can be fixed using the edit distance<br />can help to only change little partsof the scapegoat<br />prototype shows that fixing of real-life processesworks(tool + slides at<br />Open questions:<br />Which service to fix?<br />What about cyclic or nondeterministic services?<br />How does the mapping backto BPEL really work?<br />Can we support more elaborate edit actions?<br />Can heuristics help to improve performance? <br />Take home points<br />Thank you!<br />Any questions?<br />
    22. 22. 22<br />[TACAS2006] Oleg Sokolsky, SampathKannan, and Insup Lee. Simulation-based graph similarity. In TACAS 2006, volume 3920 of LNCS, pages 426–440. Springer, 2006.<br />[WS-FM2007] Niels Lohmann, Oliver Kopp, Frank Leymann, and Wolfgang Reisig. Analyzing BPEL4Chor: Verification and participant synthesis. In WS-FM 2007, volume 4937 of LNCS, pages 46–60. Springer, 2008.<br />[ATPN2007] Niels Lohmann, Peter Massuthe, and Karsten Wolf. Operating guidelines for finite-state services. In ICATPN 2007, volume 4546 of LNCS, pages 321-341. Springer, 2007.<br />References<br />