scispace - formally typeset
Search or ask a question
Proceedings ArticleDOI

A Tool for Choreography Analysis Using Collaboration Diagrams

TL;DR: This paper presents a tool that checks the realizability of interactions specified by the given collaboration diagram, verifies the LTL properties of the interactions specifiedBy automatically converting it to a state machine model, and synthesizes peer state machines that realize the set of interactions specify by thegiven collaboration diagram.
Abstract: Analyzing interactions among peers that interact via messages is a crucial problem due to increasingly distributed nature of current software systems, especially the ones built using the service oriented computing paradigm. In service oriented computing, interactions among peers participating to a composite service involve message exchanges across organizational boundaries in a distributed computing environment. In order to build such systems in a reliable manner, it is necessary to develop techniques for analysis and verification of interactions among services. Collaboration diagrams provide a convenient visual model for modeling service interactions. In this paper, we present a tool that 1) checks the realizability of interactions specified by the given collaboration diagram, 2) verifies the LTL properties of the interactions specified by the given collaboration diagram by automatically converting it to a state machine model, and 3) synthesizes peer state machines that realize the set of interactions specified by the given collaboration diagram.

Summary (2 min read)

1 Introduction

  • Service oriented computing provides technologies that enable multiple organizations to integrate their businesses over the Internet.
  • Collaboration diagrams (called communication diagrams in [20]) provide a convenient visual formalism for specifying the choreography among the services participating to a composite service [6].
  • The fourth components converts the collaboration diagram automaton to the input language of the Web Service Analysis Tool (WSAT) [11] (a tool developed for checking realizability web service choreography specifications) to check a different set of realizability conditions.
  • The authors contributions in this paper can be summarized as follows: 1) Extending the semantics for a single collaboration diagram given in [6] to collaboration diagram sets and graphs, with increasing expressive power.
  • 3) A translator for converting the collaboration diagram automaton to a Promela model, enabling LTL model checking using the Spin model checker [13].

2 Formal Model

  • Note that, messages can always be converted to this form by concatenating each message with tags its sender and its receiver.
  • For each message m ∈ M , the sender and the receiver ofm must be linked, i.e.,(send(m), recv(m)) ∈ L. In a collaboration diagram, each message send event has a unique sequence label.
  • In addition to the implicit ordering defined by the sequence numbers, it is possible to explicitly state the events that should precede an evente by listing their sequence labels (followed by the symbol “/”) before the sequence label of the evente.
  • It is not possible to specify this choreography using collaboration diagram sets, however by allowing the concatenation of choreographies specified by different collaboration diagrams, the authors can specify such choreographies.
  • As with the collaboration diagram sets, to simplify their presentation,the authors assume that the collaboration diagrams in a collaboration diagram graph only differ in their event sets and dependency relations.

3 Automata Construction

  • Figure 3 shows an automaton automatically constructed from the collaboration diagram shown in Figure 2.
  • The authors define the transition relationδ as follows:.
  • The initial state corresponds to the whole event setE = {1, 2, A1, A2, B1, B2} meaning that initially all the events have to be executed, and the final state corresponds to the empty set meaning that there are no more events to be executed.
  • Based on the above construction, the number of states generated for a collaboration diagramC with the event set E could be2|E| in the worst case.

4 Synthesizing Peer Implementations

  • The authors model the behaviors of peers that participate to a composite web service as concurrently executing finite state machines that interact via messages [10, 12].
  • In fact, one can obtain the peer state machines by projecting the transitions of the collabor - tion diagram automata to the peers.
  • The set of conversations generated by the peer state machines shown in Figure 4 is exactly the choreography specified by the collaboration diagram automaton in Figure 3 and the collaboration diagram in Figure 2.
  • The authors formalize the realizability problem as follows.
  • The realizability condition in [6] can only be used in determining realizability of a single collaboration diagram and results on realizability of collaboration diagrams are not directly applicable to collaboration diagrams.

6 Implementation and Experiments

  • The authors implemented the techniques described above in their collaboration diagram analysis and verification tool.
  • Using the dependency graph, the authors create the collaboration diagram automaton based on the construction given in Section 3.
  • For each example, the authors checked the realizability first.
  • The realizability condition from [6] identified remaining five collaboration diagrams as realizable.
  • The unrealizable examples the authors discussed above are unrealizable under the concurrent execution semantics they defined in Section 4.

7 Conclusions

  • In this paper the authors discussed choreography specification with collaboration diagrams.
  • The authors defined three classes of collaboration diagrams with increasing expressive power: single collaboration diagrams, collaboration diagram sets and collaboration diagram graphs.
  • The authors presented techniques for realizability, synthesis and verification and they implemented these techniques in a toolset.
  • The authors experimental results indicate that realizability analysis, synthesis andverification of choreographers specified using collaboration diagrams can be done efficiently.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

A Tool for Choreography Analysis Using Collaboration Diagrams
Tevfik Bultan Chris Ferguson
University of California Santa Barbara
{bultan,fergy}@cs.ucsb.edu
Xiang Fu
Hofstra University
Xiang.Fu@hofstra.edu
Abstract
Analyzing interactions among peers that interact via
messages is a crucial problem due to increasingly dis-
tributed nature of current software systems, especially the
ones built using the service oriented computing paradigm.
In service oriented computing, interactions among peers
participating to a composite service involve message ex-
changes across organizational boundaries in a distributed
computing environment. In order to build such systems in a
reliable manner, it is necessary to develop techniques for
analysis and verification of interactions among services.
Collaboration diagrams provide a convenient visual model
for modeling service interactions. In this paper, we present
a tool that 1) checks the realizability of interactions speci-
fied by the given collaboration diagram, 2) verifies the LTL
properties of the interactions specified by the given collab-
oration diagram by automatically converting it to a state
machine model, and 3) synthesizes peer state machines that
realize the set of interactions specified by the given collab-
oration diagram.
1 Introduction
Service oriented computing provides technologies that
enable multiple organizations to integrate their businesses
over the Internet. Typical execution behavior in such a dis-
tributed system involves a set of autonomous peers inter-
acting with each other through messages. Choreography
specification languages, such as the Web Services Choreog-
raphy Description Language (WS-CDL), are used for spec-
ification of such interactions. A choreography specification
identifies the global ordering of the messages exchanged
among the peers participating to a composite service. We
call such message sequences conversations, i.e., a choreog-
raphy specification identifies the set of allowable conversa-
tions for a composite web service.
Collaboration diagrams (called communication dia-
grams in [20]) provide a convenient visual formalism for
specifying the choreography among the services (peers)
participating to a composite service [6]. Characterization of
Realizability
Analyzer
Dependency
Graph
Constructor
Automata
Constructor
Conversation
Protocol
Translator
Collaboration
Diagrams
Realizability
Analysis
with WSAT
Promela
Translator
LTL Model
Checking
with SPIN
Peer
Synthesizer
Figure 1. A tool for choreography analysis
interactions using a global view, as collaboration diagrams
allow us to do, can lead to specification of choreographies
that may not be implementable. Hence, using collaboration
diagrams for choreographyspecification leads to the follow-
ing realizability problem: Given a choreography specifica-
tion, is it possible to nd a set of distributed peers which in-
teract exactly according to the choreography specification.
If a collaboration diagram is realizable, then we can check
the properties of the interactions among the peers by inves-
tigating the possible message orderings allowed by the col-
laboration diagram.
In this paper we present a toolset for verification and
analysis of choreographies specified using collaboration di-
agrams. As shown in Figure 1, our tool consists of six
components: The first component constructs a dependency
graph for the events in the input collaboration diagram. The
second component checks the realizability of the input col-
laboration diagram by checking a set of conditions on this
dependency graph. The third component converts the col-
laboration diagram to a finite state automaton such that the
language accepted by the automaton is equal to the set of in-
teractions specified by the input collaboration diagram. The
fourth components converts the collaboration diagram au-
tomaton to the input language of the Web Service Analysis
Tool (WSAT) [11] (a tool developed for checking realiz-
ability web service choreography specifications) to check
a different set of realizability conditions. The fifth com-
ponent converts the collaboration diagram automaton to a
Promela specification in order to check LTL properties us-
ing the Spin model checker [13]. Finally, the sixth compo-
1

nent synthesizes a set of state machines that generate ex-
actly the set of interactions specified by the collaboration
diagram automaton. We collected a set of collaboration
diagrams from the literature and analyzed them using this
toolset. Our experiments indicate that realizability analysis,
LTL model checking and synthesis for collaboration dia-
grams is very efficient and can easily be used in practice.
Our contributions in this paper can be summarized as
follows: 1) Extending the semantics for a single collabo-
ration diagram given in [6] to collaboration diagram sets
and graphs, with increasing expressive power. 2) An algo-
rithm for converting collaboration diagrams/sets/graphs to
an automaton that accepts the same set of conversations. 3)
A translator for converting the collaboration diagram au-
tomaton to a Promela model, enabling LTL model checking
using the Spin model checker [13]. 4) Implementing the re-
alizability check for single collaboration diagrams from [6].
5) A translator for converting the collaboration diagram au-
tomaton to a Conversation Protocol, enabling realizability
check for collaboration diagram sets/graphs using the re-
alizability analysis for conversation protocols implemented
in Web Service Analysis Tool [11]. 6) A peer synthe-
sis algorithm for generating state machine implementations
for peers for realizable collaboration diagrams/sets/graphs
by projecting the collaboration diagram automaton to each
peer participating to the collaboration. 7) Experiments with
several collaboration diagrams from the literature.
Related Work Message Sequence Charts (MSCs) pro-
vide another visual model for specification of interactions
in distributed systems. MSC model has also been used in
modeling and verification of web services [8]. However,
collaboration diagrams provide a global view of interactions
where as MSCs provide a local view. The realizability prob-
lem for MSCs [2] have been studied before. However as we
mentioned above, the type of interactions specified by col-
laboration diagrams and MSCs are different.
There has been work on formalizing choreography spec-
ifications using process algebras [7,16]. Our work is com-
plementary to work on formalizing semantics of choreog-
raphy specification languages. Our focus in this paper is
formal visual representations that can be used by service
developers to visualize their designs.
There has been earlier work on using various UML dia-
grams in modeling differentaspects of service compositions
(for example [3, 18]). Specification and analysis of web
service interactions using conversation protocols has been
investigated [10,12]. In this paper, we investigate the rela-
tionship between the collaboration diagrams and the conver-
sation protocols using the collaboration diagram semantics
from [6]. A complementary approach to the one presented
here is discussed in [17], where realizability of collabora-
tion diagrams is analyzed using process algebra encodings.
However, compared to these earlier works, in this paper we
extend the collaboration diagram semantics to collaboration
diagrams sets and collaboration diagram graphs which have
more expressive power.
2 Formal Model
We assume that a choreography specification consists of
a finite set of peers P , and a finite set of messages M. Each
message m M has a unique sender and a unique receiver
denoted by send (m) P and recv (m) P , respectively.
Note that, messages can always be converted to this form
by concatenating each message with tags its sender and its
receiver.
A conversation σ is a sequence of messages exchanged
among the peers that participate to a composite web service,
i.e., σ M
. A choreography C is a set of conversations,
i.e., C M
.
scheduler:
FactoryScheduler
manager:
FactoryJobManager
oven:Oven robot:Robot
1: start
1/B1:startRobot
B2:completedRobot
1/A1:startOven
A2:completedOven
A2,B2/2:completed
1:start
1/A1:startOven
A2:completedOven
1/B1:startRobot
B2:completedRobot
A2,B2/2:completed
Figure 2. A collaboration diagram (top) and its depen-
dency relation (bottom)
Figure 2 shows an example collaboration diagram from
the UML 1.3 specification.The diagram consists of four
peers Scheduler, Manager, Oven, Robot. The edges that
connect the boxes shows the links between the peers. A link
between two peers indicate that they can send each other
messages. In collaboration diagrams, message send events
are shown as arrows drawn over the links. The direction of
the arrow indicates the sender and the receiver (the arrow
points to the receiver). Each send event is marked with a
sequence label. The sequence labels specify the ordering of
the message send events.
Formally, a collaboration diagram C =
(P, L, M, E, D) consists of a set of peers P , a set of
links L P × P , a set of messages M , a set of message
2

send events E and a dependency relation D E × E
among the message send events [6]. For each message
m M, the sender and the receiver of m must be linked,
i.e., (send(m), recv(m)) L.
In a collaboration diagram, each message send event has
a unique sequence label. Each sequence label consists of a
possibly empty prefix followed by a sequence number. The
numeric ordering of the sequence numbers defines an im-
plicit total ordering among the message send events with
the same prefix. Each prefix represents a message thread
where each message thread refers to a set of messages that
have a total ordering and that can be interleaved arbitrarily
with other messages. For example, event A2 can occur only
after the event A1, but B1 and A2 do not have any implicit
ordering. In addition to the implicit ordering defined by the
sequence numbers, it is possible to explicitlystate the events
that should precede an event e by listing their sequence la-
bels (followed by the symbol “/”) before the sequence label
of the event e. For example if an event e is marked with
“B2,C3/A2” then A2 is the sequence label of the event e ,
and the events with sequence labels B2, C3 and A1 must
precede e. Also, message send events can be marked to be
conditional, denoted as a suffix “[condition]”, or iterative,
denoted as a suffix “*[condition]”, where condition is writ-
ten in some pseudocode.
Formally, the set of send events E is a set of tuples of the
form (l, m, r) where l is the label of the event, m M is
a message, and r {1, ?, ∗} is the recurrence type. We de-
note the size of the set E with |E| and for each event e E,
e.l, e.m, and e.r denote the unique sequence label, the mes-
sage and the recurrence type for event e, respectively. Each
event e E denotes a message send event where the peer
send(e.m) sends a message e.m to the peer recv(e.m). The
recurrence type r {1, ?, ∗} determines if the send event
corresponds to a single message send event (r = 1), a con-
ditional message send event (r =?), or an iterative message
send event (r = ).
The dependency relation D E × E denotes the or-
dering among the message send events where (e
1
, e
2
) D
means that e
1
has to occur before e
2
. The bottom of the
Figure 2 shows the dependency graph for the the collabora-
tion diagram shown at the top. We assume that there are no
circular dependencies, i.e., the dependency graph (E, D),
where the send events in E form the vertices and the depen-
dencies in D form the edges, should be a directed acyclic
graph (dag). Given a dependency relation D E × E
let pred (e) denote the predecessors of the event e where
e
pred(e) if there exists a set of events e
1
, e
2
, . . . , e
k
where k > 1, e
= e
1
, e = e
k
, and for all i [1..k 1],
(e
i
, e
i+1
) D. We assume that there are no redundant de-
pendencies in D (i.e., it is the transitive reduction). We call
e
an immediate predecessor of e if (e
, e) D. We call
an event e
I
with pred(e
I
) = an initial event of D and an
event e
F
where for all e E e
F
6∈ pred(e) a final event of
D.
Given a collaboration diagram D = (P, L, M, E, D)
we denote the choreography defined by D as C(D) where
C(D) M
. A conversation σ = m
1
m
2
. . . m
n
is in C(D),
i.e., σ C(D), if and only if σ M
and there exists a cor-
responding matching sequence of message send events γ =
e
1
e
2
. . . e
n
such that: 1) for all i [1..n] m
i
= e
i
.m and
e
i
E; 2) for all i, j [1..n] (e
i
, e
j
) D i < j; 3) for
all e E (for all i [1..n] e
i
6= e) (e.r = e.r =?);
and 4) for all e E if there exists i, j [1..n] such that
i 6= j e
i
= e
j
then e
i
.r = . The first condition above
ensures that each message in the conversation σ is equal
to the message of the matching send event in the event se-
quence γ. The second condition ensures that the ordering
of the events in the event sequence γ does not violate the
dependencies in D. The third condition ensures that if an
event does not appear in the event sequence γ then it must
be either a conditional event or an iterative event. Finally,
the fourth condition states that only iterative events can be
repeated in the event sequence γ.
Collaboration Diagram Sets Without the conditional or
iterative events, a single collaboration diagram with a sin-
gle message thread specifies a single conversation. The
conditional and iterative events and message threads in-
troduce nondeterminism to collaboration diagrams, en-
abling specification of multiple conversations with a sin-
gle collaboration diagram. However, the level of nonde-
terminism in a single collaboration diagram is still quite
limited. For example, assume that we have three mes-
sages m
1
,m
2
and m
3
sent from one peer to another peer
and we would like to specify the following choreography
{m
1
m
2
m
3
, m
3
m
1
m
2
}. It is not possible to specify this
simple choreography using a single collaboration diagram.
However, it is possible to specify each conversation in this
choreography using a separate collaboration diagram. So,
the choreography we want to describe is the union of the
choreographies of two different collaboration diagrams.
We define a collaboration diagram set as S =
{D
1
, D
2
, . . . , D
n
} where n is the number of collabora-
tion diagrams in S and each D
i
is in the form D
i
=
(P, L, M, E
i
, D
i
), i.e., the collaboration diagrams in a col-
laboration diagram set only differ in their event sets and de-
pendencies. (we can always convert a set of collaboration
diagrams to this form without changing their interaction sets
by replacing the individual peer, link and message sets by
their unions.) We define the set of interactions defined by a
collaboration diagram set as C(S) =
S
D∈S
C(D).
Collaboration Diagram Graphs Although collaboration
diagrams sets increase the expressiveness of collaboration
diagrams, they still have an important limitation. It is not
possible to specify looping behaviors using collaboration
3

diagram sets. The only looping construct in collaboration
diagrams/sets is the iterative event that specifies the repeti-
tion of a single event. Assume that we have two messages
m
1
and m
2
exchanged among two peers and we would like
to specify the following choreography (m
1
m
2
)
, i.e., zero
or more repetitions of the message sequence m
1
m
2
. This
could be a typical request/acknowledgement sequence for
example, which can be repeated arbitrary many times. It is
not possible to specify this choreography using collabora-
tion diagram sets, however by allowing the concatenation
of choreographies specified by different collaboration dia-
grams, we can specify such choreographies.
A collaboration diagram graph G = (v
s
, Z, V, O) is a
directed graph which consists of a set of vertices V , a set of
directed edges O V × V , an initial vertex v
s
V , a set
of final vertices Z V , where each vertex in v V is a
collaboration diagram v = (P, L, M, E
v
, D
v
). As with the
collaboration diagram sets, to simplify our presentation, we
assume that the collaboration diagrams in a collaboration
diagram graph only differin their event sets and dependency
relations.
Given a collaboration diagram graph G = (v
s
, Z, V, O)
we define the set of interactions defined by G as C(G). The
interactions of a collaboration diagram graph is defined as
the concatenation of the interactions of its vertices on a path
that starts from the initial vertex and ends at a final vertex.
Formally, an interaction σ M
, is in the interaction set of
G, i.e., σ G, if and only if σ = σ
1
σ
2
. . . σ
n
where for all
i [1..n] σ
i
M
and there exists a path v
1
, v
2
, . . . , v
n
in G such that v
1
= v
s
, v
n
Z, for all i [1..n 1]
(v
i
, v
i+1
) O and for all i [1..n] σ
i
C(v
i
).
As the two simple examples we discussed above demon-
strate, collaboration diagram sets are strictly more powerful
than single collaboration diagrams, and collaboration dia-
gram graphs are strictly more powerful than collaboration
diagram sets.
3 Automata Construction
Figure 3 shows an automaton automatically constructed
from the collaboration diagram shown in Figure 2. The lan-
guage accepted by this automaton is exactly the choreogra-
phy specified by the collaboration diagram in Figure 2.
Given a collaboration diagram D = (P, L, M, E, D),
the corresponding collaboration diagram automaton A
D
=
(M, T, s, F , δ) is a nondeterministic FSA where M is a set
of messages such that for each m M recv(m) P
and send (m) P , T is the finite set of states, s T
is the initial state, F T is the set of final states, and
δ T × (M {ǫ} ) × T is the transition relation. A col-
laboration diagram automaton has two types of transitions:
(1) (t
1
, m, t
2
) denotes a message transmission where mes-
sage m is sent from peer send(m) to peer recv (m), and (2)
(t
1
, ǫ, t
2
) denotes an ǫ-transition.
A1:startOven
B1:startRobot
{1,2,A1,A2,B1,B2}
{2,A1,A2,B1,B2}
1:start
{2,A2,B1,B2} {2,A1,A2,B2}
{2,B1,B2}
{2,A1,A2}
A2:completedOven
{2,A2,B2}
B1:startRobot
{2,B2}
{2}
B2:completedRobot
{2,A2}
2 : completed
A1:startOven
A1:startOven
B1:startRobot
B2:completedRobot
A2:completedOven
A2:completedOven
B2:completedRobot
Figure 3. Automata construction
We define the choreography C(A) defined by the col-
laboration diagram automaton A is the language accepted
by A, i.e., C(A) M
and σ C(A) if and only if
σ = m
1
, m
2
, . . . , m
n
where for all i [1..n] m
i
M
and there exists a path t
1
, t
2
, . . . , t
n
, t
n+1
in A such that
t
1
= s, t
n+1
F , and for all i [1..n] (t
i
, m
i
, t
i+1
) δ.
Collaboration Diagram Automaton Construction
Given a collaboration diagram D = (P, L, M, E, D), we
want to automatically construct a collaboration diagram
automaton A
D
= (M, T, s, F, δ) such that C(D) = C(A
D
).
We define the set of states of A
D
as T = 2
E
, i.e., the set
of states of A
D
is the power sets of the event set of the
collaboration diagram D. The initial state is defined as
s = E. The set of final states are defined as F = {∅}. We
define the transition relation δ as follows: For each state
S E, if there exists an event e S such that for all
(e
, e) D e
6∈ S, then
e = (l, m, 1) (S, m, S \ {e}) δ,
e = (l, m, ?) {(S, m, S \{e}), (S, ǫ, S \{e})} δ,
e = (l, m, ) {(S, m, S), (S, ǫ, S \ {e} )} δ.
Each state in the automaton represents a set of events that
need to be executed. Given a state E, if there is an event
e E which does not have any of its predecessors in E,
then we add a transition from E to E {e} to represent
the execution of the send event e. If e is an iterative event,
then we add a self loop to E to represent arbitrary number of
sends. For iterative and conditional events, we also generate
ǫ-transitions.
Figure 3 shows the collaboration diagram automaton
automatically constructed from the collaboration diagram
shown in Figure 2 based on the above construction. The
initial state corresponds to the whole event set E =
{1, 2, A1, A2, B1, B2} meaning that initially all the events
4

have to be executed, and the final state corresponds to
the empty set meaning that there are no more events to
be executed. In the initial state, only event 1 is enabled
since event 1 has no predecessors in the dependency graph
shown in Figure 2 (i.e., it is an initial event). Hence,
there is one one transition from the initial state to the state
{2, A1, A2, B1, B2} labeled with the message start, corre-
sponding to the execution of event 1. Note that, in state
{2, A1, A2, B1, B2} events A1 and B1 are both enabled
since their only predecessor in the dependency graph is
event 1 and event 1 is not in {2, A1, A2, B1, B2}, mean-
ing that it has already been executed. Hence, there are two
transitions from the {2, A1, A2, B1, B2} , one for event A1
and one for event B1.
Based on the above construction, the number of states
generated for a collaboration diagram C with the event set
E could be 2
|E|
in the worst case. This worst case is real-
ized only if C has |E| threads, i.e., the number of states is
exponential in the number of threads.
Automaton Construction for Collaboration Diagram
Sets The above construction algorithm can be extended
to collaboration diagram sets as follows. Given a collabo-
ration diagram set S = {D
1
, D
2
, . . . , D
n
} where n is the
number of collaboration diagrams in S and each D
i
is in
the form D
i
= (P, L, M, E
i
, D
i
) we want to construct an
automaton A
S
= (M, T, s, F, δ) such that C(A
S
) = C(S).
For each D
i
S construct the corresponding collabora-
tion diagram automaton A
D
i
= (M, T
i
, s
i
, F
i
, δ
i
) where
C(D
i
) = C(A
D
i
) using the construction defined above. Let
A
S
= (M, T, s, F, δ). We define the set of states of A
S
as
T = {s}
S
D
i
∈S
T
i
, i.e., the set of states of A
S
consists of
a start state s and the power sets of the event sets of the col-
laboration diagrams that are in S. Each state in the automa-
ton after the start state represent a set of events that need to
be executed. If there exists an E
i
such that E
i
= , then
F = {s, ∅}, otherwise F = {∅}. We define the transition
relation δ as follows: δ = (
S
D
i
∈S
(s, ǫ, E
i
))(
S
D
i
∈S
δ
i
)).
The automaton A
S
first nondeterministically chooses one
of the collaboration diagrams in the collaboration diagram
set and then transitions to the initial state of the correspond-
ing collaboration diagram automaton.
Recall that, the number of states in a collaboration di-
agram automaton A
D
i
generated from a collaboration di-
agram D
i
is exponential in the number of threads in D
i
.
If we determinize the automaton A
S
, then the number of
states will also be exponential in |S|, i.e., the number of
collaboration diagrams in the collaboration diagram set.
Automaton Construction for Collaboration Diagram
Graphs Next, we show that given a collaboration diagram
graph G = (v
s
, Z, V, O) where each v V is a collabora-
tion diagram v = (P , L, M , E
v
, D
v
), we can construct an
automaton where A
G
= (M , T , s, F , δ), such that C(G) =
C(A
G
).
First, for each vertex v V of G, construct an automa-
ton A
v
= (M , T
v
, s
v
, F
v
, δ
v
) using the construction given
above for translating collaboration diagram sets to automata
(each vertex v corresponds to a singleton collaboration di-
agram set) such that C(v) = C(A
v
). Then for A
G
= (M,
T , s, F , δ) we have T =
S
vV
T
v
, i.e., the set of states of
A
G
is the union of the states of the automata constructed for
each vertex of G. We define the initial state of A
G
as the ini-
tial state of the automaton constructed for the initial vertex
v
s
, i.e., s = s
v
s
. The final states of A
G
are the union of the
final states of the automata constructed for vertices v Z,
i.e, F =
S
vZ
F
v
.
The transitions of A
G
include all the transitions of the
automata constructed for all the vertices, i.e., δ
S
vV
δ
v
.
Additionally we add some ǫ-transitions to δ as follows. For
each edge (v, v
) O, where A
v
= (M, T
v
, s
v
, F
v
, δ
v
) and
A
v
= (M , T
v
, s
v
, F
v
, δ
v
) are the automata constructed
for v and v
, respectively, δ includes an ǫ-transition from
each final state of A
v
to the initial state of A
v
, i.e., δ
S
(v,v
)O,sF
v
(s, ǫ, s
v
).
4 Synthesizing Peer Implementations
We model the behaviors of peers that participate to
a composite web service as concurrently executing finite
state machines that interact via messages [10, 12]. We as-
sume that the machines interact with asynchronous mes-
sages where each finite state machine has a single FIFO in-
put queue, and the messages are delivered reliably i.e., no
message loss or reordering during transmission.
Formally, given a set of peers P = {p
1
, . . . , p
n
}
that participate in a collaboration, the peer state machine
for the peer p
i
P is a nondeterministic FSA A
i
=
(M
i
, T
i
, s
i
, F
i
, δ
i
) where M
i
is the set of messages that are
either received or sent by p
i
, T
i
is the finite set of states,
s
i
T is the initial state, F
i
T is the set of final states,
and δ
i
T
i
× ({!, ?} × M
i
{ǫ}) × T
i
is the transition re-
lation. A transition τ δ
i
can be one of the following three
types: (1) a send-transition of the form (t
1
, !m, t
2
) which
sends out a message m M
i
from peer p
i
= send (m) to
peer recv(m) that appends the message to the end of the in-
put queue of the receiver recv(m), (2) a receive-transition
of the form (t
1
, ?m, t
2
) which receives a message m M
i
from peer send(m) to peer p
i
= recv(m) that removes the
message at the head of the input queue of the peer p
i
, and
(3) an ǫ-transition of the form (t
1
, ǫ, t
2
).
A run of a set of peers is a sequence of transitions exe-
cuted by the peers. A complete run is one such that at the
end of the run each peer is in a final state and each FIFO
queue is empty. The corresponding sequence of messages
induced from the send transitions of a complete run is called
a conversation (see [12] for the detailed formal definition).
The choreography C(A
1
, . . . , A
n
) of a set of peer state ma-
5

Citations
More filters
Journal ArticleDOI
25 Jan 2012
TL;DR: The proposed realizability check is implemented and experiments show that it can efficiently determine therealizability of 1) web service choreographies, 2) Singularity OS channel contracts, and 3) UML collaboration (communication) diagrams.
Abstract: Since software systems are becoming increasingly more concurrent and distributed, modeling and analysis of interactions among their components is a crucial problem. In several application domains, message-based communication is used as the interaction mechanism, and the communication contract among the components of the system is specified semantically as a state machine. In the service-oriented computing domain such communication contracts are called "choreography" specifications. A choreography specification identifies allowable ordering of message exchanges in a distributed system. A fundamental question about a choreography specification is determining its realizability, i.e., given a choreography specification, is it possible to build a distributed system that communicates exactly as the choreography specifies? Checking realizability of choreography specifications has been an open problem for several years and it was not known if this was a decidable problem. In this paper we give necessary and sufficient conditions for realizability of choreographies. We implemented the proposed realizability check and our experiments show that it can efficiently determine the realizability of 1) web service choreographies, 2) Singularity OS channel contracts, and 3) UML collaboration (communication) diagrams.

151 citations


Cites background or methods from "A Tool for Choreography Analysis Us..."

  • ...All these specifica tions were first automatically translated to conversation protoc ls (in the conversation protocol format of the Web Service Analysis To ol) using the translators described in [15], [34], and [7], resp ectively....

    [...]

  • ...We have also experimentally evaluated our approach by checking the realizability of Singularity channel contracts [12], web service choreographies [37] and collaboration diagrams [7]....

    [...]

  • ...Collaboration diagrams (called communication diagrams in [36]) provide a convenient visual formalism for specifying the in teractions among the participants of a distributed system [7, 8]....

    [...]

DissertationDOI
01 Jan 2010
TL;DR: The communication protocol of the service is focused on and the design of correct service compositions can be systematically supported and an algorithm is presented to deduce local service descriptions from the choreography which—by design—conforms to the specification.
Abstract: Service-oriented computing (SOC) is an emerging paradigm of system design and aims at replacing complex monolithic systems by a composition of interacting systems, called services. A service encapsulates self-contained functionality and offers it over a well-defined, standardized interface. This modularization may reduce both complexity and cost. At the same time, new challenges arise with the distributed execution of services in dynamic compositions. In particular, the correctness of a service composition depends not only on the local correctness of each participating service, but also on the correct interaction between them. Unlike in a centralized monolithic system, services may change and are not completely controlled by a single party. We study correctness of services and their composition and investigate how the design of correct service compositions can be systematically supported. We thereby focus on the communication protocol of the service and approach these questions using formal methods and make contributions to three scenarios of SOC. The correctness of a service composition depends on the correctness of the participating services. To this end, we (1) study correctness criteria which can be expressed and checked with respect to a single service. We validate services against behavioral specifications and verify their satisfaction in any possible service composition. In case a service is incorrect, we provide diagnostic information to locate and fix the error. In case every participating service of a service composition is correct, their interaction can still introduce problems. We (2) automatically verify correctness of service compositions. We further support the design phase of service compositions and present algorithms to automatically complete partially specified compositions and to fix incorrect compositions. A service composition can also be derived from a specification, called choreography. A choreography globally specifies the observable behavior of a composition. We (3) present an algorithm to deduce local service descriptions from the choreography which—by design—conforms to the specification. All results have been expressed in terms of a unifying formal model. This not only allows to formally prove correctness, but also makes results independent of the specifics of concrete service description languages. Furthermore, all presented algorithms have been prototypically implemented and validated in experiments based on case studies involving industrial services.

48 citations

Journal ArticleDOI
TL;DR: A novel approach for choreography analysis that is completely automated under the support of the developed tool and the Process Analysis Toolkit (PAT) tool.
Abstract: Choreography-driven microservice composition has provided a better way to integrate components in the Cyber-physical-Social System (CPSS). Choreography is a global contract that specifies interactions among microservices participating in a composite service. After modeling a choreography, a problem arises here is whether the choreography specification at design time can be implemented correctly by generated microservices that interact with each other via exchanging messages. In this paper, we propose a novel approach for choreography analysis. Specifically, a choreography is specified using a Labeled Transition Systems (LTSs); then, the microservices participating in a composite service can be generated from the given choreography via projection and $\varepsilon $ -remove; finally, the analysis of the choreography can be checked for both synchronous and asynchronous compositions using refinement checking. Our approach is completely automated under the support of our developed tool and the Process Analysis Toolkit (PAT) tool.

22 citations


Cites background or methods from "A Tool for Choreography Analysis Us..."

  • ...In the asynchronous composition, the interactions among microservices depend on the order the send and receive actions as well as the size of the buffers associated with each microservice [29]....

    [...]

  • ...In [29], Bultan presented a tool for checking the realizability of collaboration diagrams under the support of the Web Service Analysis Tool (WSAT) [30]....

    [...]

  • ...A large number of approaches have been proposed to analyze choreographies based on various formalisms such as automata-theory [26]–[29], process algebras [33], [34], and Petri nets [35], [36]....

    [...]

Book ChapterDOI
05 Dec 2011
TL;DR: This work investigates decidability issues under the synchronous and asynchronous communication models, and shows undecidability whereas the other two problems are decidable with reasonable complexity.
Abstract: A service choreography defines a set of permitted sequences of message events as a specification for the interaction of services. Realizability is a fundamental sanity check for choreographies comparable to the notion of soundness for workflows. We study several notions of realizability: partial, distributed, and complete realizability. They establish increasingly strict conditions on realizing services. We investigate decidability issues under the synchronous and asynchronous communication models. For partial realizability, we show undecidability whereas the other two problems are decidable with reasonable complexity.

15 citations

Proceedings ArticleDOI
01 Oct 2018
TL;DR: This paper provides a direct formal operational semantics for both BPMN collaboration and choreography diagrams, and formalises the conformance concept by means of two relations defined on top of the semantics.
Abstract: The BPMN 2.0 standard is nowadays largely used to model distributed informative systems in both academic and industrial contexts. The notation makes possible to represent these systems from different perspectives. A local perspective, using collaboration diagrams, to describe the internal behaviour of each component of the systems, and a global perspective, using choreography diagrams, where the interactions between system components are highlighted without exposing their internal structure. In this paper, we propose a formal approach for checking conformance of collaborations, representing possible system implementations, with respect to choreographies, representing global constraints concerning components' interactions. In particular, we provide a direct formal operational semantics for both BPMN collaboration and choreography diagrams, and we formalise the conformance concept by means of two relations defined on top of the semantics. To support the approach into practice we have developed the C 4 tool. Its main characteristic is to make the exploited formal methods transparent to systems designers, thus fostering a wider adoption of them in the development of distributed informative systems. We illustrate the benefits of our approach by means of a simple, yet realistic, example concerning a traveling scenario.

14 citations

References
More filters
Book
05 Oct 2004
TL;DR: This book focuses on executable processes and comes back to abstract processes in Chapter 4, which can be used to replace sets of rules usually expressed in natural language, which is often ambiguous.
Abstract: processes are rarely used. The most common scenario is to use them as a template to define executable processes. Abstract processes can be used to replace sets of rules usually expressed in natural language, which is often ambiguous. In this book, we will first focus on executable processes and come back to abstract processes in Chapter 4. 21 This material is copyright and is licensed for the sole use by Encarnacion Bellido on 20th February 2006 Via Alemania, 10, bajos, , Palma de Mallorca, Baleares, 07006

3,772 citations

Book
01 May 2011
TL;DR: The SPIN Model Checker as mentioned in this paper is used for both teaching software verification techniques, and for validating large scale applications, and it has been estimated that up to three-quarters of the $400 billion spent annually to hire programmers in the United States is ultimately spent on debugging.
Abstract: The SPIN Model Checker is used for both teaching software verification techniques, and for validating large scale applications. The growing number of users has created a need for a more comprehensive user guide and a standard reference manual that describes the most recent version of the tool. This book fills that need. SPIN is used in over 40 countries. The offical SPIN web site, spinroot.com receives between 2500 and 3000 hits per day. It has been estimated that up to three-quarters of the $400 billion spent annually to hire programmers in the United States is ultimately spent on debugging

2,530 citations

Journal ArticleDOI
TL;DR: This paper considers how the mechanism for composing services in Self-Serv is based on two major concepts: the composite service and the service container.
Abstract: Self-Serv aims to enable the declarative composition of new services from existing ones, the multiattribute dynamic selection of services within a composition, and peer-to-peer orchestration of composite service executions. Self-Serv adopts the principle that every service, whether elementary or composite, should provide a programmatic interface based on SOAP and the Web Service Definition Language. This does not exclude the possibility of integrating legacy applications, such as those written in CORBA, into the service's business logic. To integrate such applications, however, first requires the development of appropriate adapters. The paper considers how the mechanism for composing services in Self-Serv is based on two major concepts: the composite service and the service container.

582 citations


"A Tool for Choreography Analysis Us..." refers background in this paper

  • ...There has been earlier work on using various UML diagrams in modeling different aspects of service compositions (for example [3, 18])....

    [...]

Proceedings ArticleDOI
06 Oct 2003
TL;DR: A model-based approach to verifying Web service compositions for Web service implementations supports verification against specification models and assigns semantics to the behavior of implementation model so as to confirm expected results for both the designer and implementer.
Abstract: In this paper, we discuss a model-based approach to verifying Web service compositions for Web service implementations. The approach supports verification against specification models and assigns semantics to the behavior of implementation model so as to confirm expected results for both the designer and implementer. Specifications of the design are modeled in UML (Unified Modeling Language), in the form of message sequence charts (MSC), and mechanically compiled into the finite state process notation (FSP) to concisely describe and reason about the concurrent programs. Implementations are mechanically translated to FSP to allow a trace equivalence verification process to be performed. By providing early design verification, the implementation, testing, and deployment of Web service compositions can be eased through the understanding of the differences, limitations and undesirable traces allowed by the composition. The approach is supported by a suite of cooperating tools for specification, formal modeling and trace animation of the composition workflow.

476 citations


"A Tool for Choreography Analysis Us..." refers methods in this paper

  • ...MSC model has also been used in modeling and verification of web services [8]....

    [...]

Proceedings ArticleDOI
01 Jun 2000
TL;DR: A formal framework within which one can derive implied MSCs is described, and polynomial-time algorithms for implication, realizability, and synthesis are provided.
Abstract: Software designers draw Message Sequence Charts for early modeling of the individual behaviors they expect from the concurrent system under design. Can they be sure that precisely the behaviors they have described are realizable by some implementation of the components of the concurrent system? If so, can one automatically synthesize concurrent state machines realizing the given MSCs? If, on the other hand, other unspecified and possibly unwanted scenarios are "implied" by their MSCs, can the software designer be automatically warned and provided the implied MSCs? In this paper we provide a framework in which all these questions are answered positively. We first describe the formal framework within which one can derive implied MSCs, and we then provide polynomial-time algorithms for implication, realizability, and synthesis. In particular, we describe a novel algorithm for checking deadlock-free (safe) realizability.

259 citations


"A Tool for Choreography Analysis Us..." refers background in this paper

  • ...Related Work Message Sequence Charts (MSCs) provide another visual model for specification of interactions in distributed systems....

    [...]

  • ...However, collaboration diagrams provide a global view of interactions where as MSCs provide a local view....

    [...]

  • ...The realizability problem for MSCs [2] have been studied before....

    [...]

  • ...However as we mentioned above, the type of interactions specified by collaboration diagrams and MSCs are different....

    [...]

Frequently Asked Questions (1)
Q1. What are the contributions mentioned in the paper "A tool for choreography analysis using collaboration diagrams" ?

In this paper, the authors present a tool that 1 ) checks the realizability of interactions specified by the given collaboration diagram, 2 ) verifies the LTL properties of the interactions specified by the given collaboration diagram by automatically converting it to a state machine model, and 3 ) synthesizes peer state machines that realize the set of interactions specified by the given collab-