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

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