• Save
Fixing Choreographies using Graph Similarities
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Fixing Choreographies using Graph Similarities

on

  • 542 views

Workshop presentation given by Niels Lohmann on June 12, 2008 in London, Great Britain at the 3rd European Young Researchers Workshop on Service Oriented Computing (YR-SOC 2008).

Workshop presentation given by Niels Lohmann on June 12, 2008 in London, Great Britain at the 3rd European Young Researchers Workshop on Service Oriented Computing (YR-SOC 2008).

Statistics

Views

Total Views
542
Views on SlideShare
542
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Fixing Choreographies using Graph Similarities Presentation Transcript

  • 1. Fixing  Choreographies using  Graph  Similarities Niels  Lohmann YR-­‐SOC  2008  ▪  London  ▪  12  June  2008 http://service-­‐technology.org/yrsoc2008 UNIVERSITÄT ROSTOCK
  • 2. a  deadlock  in  a  choreography How can we avoid this? What went wrong? Who is to blame? 2 http://thisboyissmooth.wordpress.com/2008/02/12/sistemas-operativos-e-deadlocks/
  • 3. State-­‐of-­‐the-­‐art  choreography  analysis   1. translate  BPEL  choreography  into  formal  model 2. check  for  deadlocks 3. if  deadlock  found:  choose  a  "scapegoat"  participant  remove  it  from  the  choreography  synthesize  a  corrected  version  (if  possible)  retranslate  synthesized  participant  back  to  BPEL Full  tool  support  available!  [WS-­‐FM2007] 3
  • 4. Problem  with  that  approach • the  synthesized  service  is  built  independently  from  the  scapegoat  gives  no  information  what  was  changed  is  correct,  yet  might  not  cover  the  original  intention 4
  • 5. Example  choreography send offer Customer rejection send send receive booking payment confirmation Travel Agency receive receive send booking payment ticket order send offer receive offer rejection ✓ send confirmation Airline send refusal 5
  • 6. ✗ Example  choreography send offer Customer rejection send send receive booking payment confirmation Travel Agency receive receive send booking payment ticket order send offer receive offer rejection send confirmation Airline send refusal 6
  • 7. Fix  the  customer  service ✗ send offer rejection send send receive booking payment confirmation scapegoat send offer rejection ✓ send offer rejection better  choice send booking send payment receive confirmation receive refusal ✓ 7
  • 8. Setting • given:  a  service  (the  scapegoat)  a  set  of  candidates • find:  the  candidate  that  is  most  similar  to  the  scapegoat  …without  sequentially  checking  all  candidates   8
  • 9. Operating  Guidelines  in  a  Nutshell !rejection ! ?offer ! !payment ! !booking !rejection • automaton ?offer ?offer !payment !booking annotated !rejection ! !payment ! !booking ?offer ?offer ! !booking !booking ?offer ! !payment with  Boolean !rejection !payment !booking ?offer !payment formulae !booking !payment ?offer ! (?confirmation " ?refusal) ?offer !payment ?offer !booking ?refusal ?confirmation ?confirmation " ?refusal ?offer • characterizes  all ?confirmation ?refusal ?offer partners  [ATPN2007] send offer Customer rejection final send send receive booking payment confirmation • partner  iff Travel Agency receive receive send booking payment ticket order send  simulated  by  OG offer receive offer rejection  fulfilling  the send confirmation Airline annotations send refusal • many  applications  (service  discovery,  testing,  …) 9
  • 10. OG  characterizes  all  possible  corrections !rejection ! ?offer ! !payment ! !booking !rejection ?offer !payment !booking ?offer !rejection ! !payment ! !booking ?offer ! !booking ?offer ! !payment ?offer !booking !rejection !payment !booking ?offer !payment !booking !payment ?offer ! (?confirmation " ?refusal) ?offer !payment ?offer !booking ?refusal ?confirmation ?confirmation " ?refusal ?offer ?confirmation ?refusal ?offer final and  2001  additional  candidates ?offer ?offer !booking !booking ?offer !rejection !rejection ✗ ✓ ✓ !payment !payment !rejection ?confirmation ?confirmation ?refusal 10
  • 11. Setting  (refined) • given:  a  service  automaton  (the  scapegoat)  an  operating  guideline  characterizing  all  candidates • find:  the  candidate  that  is  most  similar  to  the  scapegoat  …without  sequentially  checking  all  candidates   11
  • 12. Graph  edit  distance • a  measure  to  compare  graphs:  edit  distance =  no.  of  needed  actions  to  achieve  graph  isomorphism b modify  b  to  a a a 0,5 a d d add  c  branch d c 0,7 d c e e e delete  e  branch 0,3 • maybe  associated  with  a  cost  function 12
  • 13. Graph  edit  distance  vs.  behavior !c !a ?b high  edit  distance low  edit  distance equivalent  behavior !a ?b  unsimilar  behavior ?b !c ?b !a !a high  edit  distance !c unsimilar  behavior 13
  • 14. Simulation-­‐based  graph  similarity • Idea:  find  a  similarity  that  respects  simulation a a b c b c d d d • compare  two  states  and  find  best  transitions w.r.t.  successor  states    [TACAS2006] 14
  • 15. Simulation-­‐based  graph  similarity • Mismatches  are  treated  with  stuttering  steps a a b c b c e d ε f • penalize  stuttering  by  label  similarity  function • choose  best  pairs  by  maximizing  label  similarity 15
  • 16. Simulation-­‐based  graph  similarity • label  similarity  function  defines  an  edit  distance  (a,a)   ➙  keep  a a a  (e,d)   ➙  change  e  to  d b c b c  (ε,x)   ➙  insert  x e d ε  (f,ε)   ➙  delete  f f • values  can  be  derived  from  semantic  Web  information  (!€,!$)  or  (?receipt,?confirmation)  rather  high  (!login,?invoice)  rather  low 16
  • 17. Simulation  and  OG  matching • Simulation  is  only  one  part  of  the  OG  matching !rejection ! ?offer ! !payment ! !booking !rejection ?offer !payment !booking ?offer ?offer !rejection ! !payment ! !booking ?offer ! !booking ?offer ! !payment ?offer !booking !rejection !payment !booking ?offer !payment !booking !booking !payment ?offer ! (?confirmation " ?refusal) !rejection ?offer !payment ?offer !payment !booking ?refusal ?confirmation ?confirmation " ?refusal ?offer ?confirmation ?confirmation ?refusal ✗ ?offer final • next  step:  make  edit  distance  aware  of  formulas 17
  • 18. Respect  formulas • instead  of  comparison  with  the  OG's  structure… • compare  with  satisfying  assignments  of  the  formula (!a ! !b) " ?c !a !d !a !d !a !d !b ?c !b ?c !b ?c !b ?c !a !d !a ?c ?c !b ?c • worst-­‐case  complexity:  O(|QSA|⋅|QOG|⋅2|I|⋅|I|!) assignments edge  permutations 18
  • 19. Experimental  results • Simulation-­‐  and  matching-­‐based  edit  distance   implemented  in  tool  RACHEL • Dynamic  programming  exploits  structure  of  the  problem   service interface states  SA states  OG candidates time  (s) Running  Example 6 5 11 2003 0 Online  Shop 7 222 153  102033 4 Supply  Order 7 7 96  10733 1 Internal  Order 9 14 512 >  104932 195 Customer  Service 9 104 59  10108 3 Car  Rental 7 49 50  10144 6 Order  Process 8 27 44  10222 0 Purchase  Order 10 137 168 >  104932 391 • Most  results  within  few  seconds • Exceptions  have  near-­‐worst-­‐case  structure/formulas 19
  • 20. Fixing  the  example  with  Rachel send offer rejection send send receive booking payment confirmation receive refusal • edit  actions  can  be  mapped  back  to  original  service • result  can  be  influenced  by  adjusting  label  similarities   20
  • 21. Take  home  points • choreographies  can  be  fixed  using  the  edit  distance • can  help  to  only  change  little  parts  of  the  scapegoat • prototype  shows  that  fixing  of  real-­‐life  processes  works • Open  questions:  Which  service  to  fix?  What  about  cyclic  or  nondeterministic  services?  How  does  the  mapping  back  to  BPEL  really  work?  Can  we  support  more  elaborate  edit  actions?  Can  heuristics  help  to  improve  performance?   21
  • 22. See  more • Tool  demo JUN  "Tools4BPEL4Chor"  (Tomorrow  @  YR-­‐SOC)  tool  chain  (editor,  translation,  analysis…) 13 • Web  http://service-­‐technology.org/yrsoc2008  slides,  tools,  examples,  links • Conference  paper  @  Business  Process  Management  (BPM  2008)  full  definitions,  related  work,  … 22
  • 23. References • [TACAS2006]  Oleg  Sokolsky,  Sampath  Kannan,  and  Insup  Lee.   Simulation-­‐based  graph  similarity.  In  TACAS  2006,  volume  3920  of   LNCS,  pages  426–440.  Springer,  2006. • [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. • [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. • [BPM2008]  Niels  Lohmann.  Correcting  deadlocking  service   choreographies  using  a  simulation-­‐based  graph  edit  distance.  In   BPM  2008,  LNCS,  Springer,  2008.  In  Press. 23