<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Realizability of Interaction Models</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Gero Decker</string-name>
          <email>gero.decker@hpi.uni-potsdam.de</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Hasso-Plattner-Institute, University of Potsdam</institution>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>In scenarios where a set of independent business partners engage in complex conversations, interaction models are a means to specify the allowed interaction behavior from a global perspective. Atomic interactions serve as basic building blocks and behavioral dependencies are de ned between them. The notion of realizability centers around the question whether there exist a set of roles that collectively realize the speci ed behavior. This notion has been studied in the literature in different avors. This paper aims at providing an overarching framework for realizability.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        Conversation models, as presented in [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ], are a formalism for interaction models.
They are nite state automata with an alphabet R M R. R denotes the set
(A,τ,A)
      </p>
      <p>s1
(A,τ,A)
(C,y,D)
(b)</p>
      <p>(C,z,D)
of roles and M the set of message types. The 3-tuple (s; m; r) then describes the
sender, the type and the receiver of a message.</p>
      <p>Figure 1 illustrates a number of sample interaction models. States are
depicted by circles and the transitions by arrows. The initial state is targeted by
an arrow without source state and the nal state is denoted by a double-circle.</p>
      <p>Figure 1(a) shows the example described in the introduction. It is not possible
to nd interacting roles that exactly show the speci ed behavior. Nevertheless,
it would be possible to nd interacting roles that show a subset of the speci ed
behavior: Imagine two roles A and B that interact and roles C and D simply do
nothing. In this case, however, a conversation would not terminate properly, as
the nal state cannot be reached.</p>
      <p>Figure 1(b) shows a choice between two interactions. Similarly to the previous
example, A and B cannot know whether C and D have already interacted and
vice versa. In contrast to the previous example, we can nd roles that collectively
realize a subset of the speci ed behavior with proper termination. Imagine again
that only roles A and B interact while C and D do nothing. However, we are
not able to nd a set of roles that realize a subset of the behavior where all
interactions from the conversation model are reachable.</p>
      <p>Similarly to the rst example, the enablement dependency between the AB
interaction and the CD interaction is the problem in Figure 1(c). As a solution,
C could wait for the message from B before interacting with D. That way,
the resulting behavior would be a properly terminating subset of the initially
speci ed behavior.</p>
      <p>Figure 1(d) shows an example containing a non-deterministic choice. This
conversation model represents that A should internally be able to decide whether
B will interact with C later on. However, B cannot observe this decision as in
any case it will get a message x from A. As A does not have any control over the
BC interaction, the decision whether this interaction takes place or not will be
independent form A's initial choice. When only considering the possible traces
of the conversation model we can easily create roles that collectively produce
exactly the same traces. The main di erence is that B or C can decide whether
the nal interaction takes place or not in the realization. We see that considering
the branching structure is crucial whenever the ownership of (and the moment
of) choices is of importance. It might be argued that local choices are irrelevant
in choreographies. This might be true if choreographies are considered to be a
collection of mere interaction sequences. However, from a business perspective it
makes a major di erence who makes a branching decision. Therefore, this should
be re ected in the formal model as well.</p>
      <p>Figure 1(e) shows a cyclic example containing a choice between an AB
interaction and a CD interaction, similarly to the second example. The di erence
here is that by expanding the cycle to a sequence, we can at least nd roles that
realize a subset of the behavior.</p>
      <p>Finally, Figure 1(f) shows an example that is perfectly realizable in a
synchronous world, where C can block B until it has interacted with A. However,
when considering an asynchronous world, where message sending and receiving
do not happen in one step, the order of the send activities would not conform
to the order of interactions in the conversation model.
3</p>
    </sec>
    <sec id="sec-2">
      <title>Dimensions of Realizability</title>
      <p>The examples from the previous section show that we need to distinguish di
erent dimensions of realizability. The following three dimensions apply.
Complete behavior vs. subset of behavior. Choreographies de ne constraints and
obligations of the roles involved. Constraints apply as the choreography
enumerates all allowed interactions in every conversation state, obligations apply as a
nal state must be reached which is only possible through the execution of the
given interactions.</p>
      <p>In this context, we can either demand that it must be possible to carry
out the complete behavior speci ed in the choreography. Or, a subset of the
behavior might already be su cient. Here, the follow-up question is what a valid
subset would be. For instance, proper termination of conversations might be a
basic criterion. Furthermore, reachability of all interactions from the original
choreography might also be demanded.</p>
      <p>Communication model. Synchronous communication could be assumed, where
sending and receiving of messages must happen at the same time. Two avors
are possible in this context: it might be allowed that a sender blocks until the
receiver is ready to receive the message. Alternatively, the conversation fails if a
role can only send in a given state without any other role being able to receive
the message.</p>
      <p>In asynchronous settings, message send and receive do not happen in one
step. Here, message bu ers are introduced for storing the incoming messages.
We might assume that there is only one queue, e.g. with FIFO message delivery,
or that there is a bu er where any incoming message can be received from.</p>
      <p>The order of interactions is of central importance. However, especially in the
case of asynchronous communication, there are di erent options of what ordering
relationships to consider. For instance, only the ordering of send transitions
might be considered, or the ordering of receive transitions or the ordering of
communication transitions within the individual roles might be of importance.
Equivalence notion. Having agreed on what ordering relationships to consider,
it is important to choose an equivalence notion for comparing the original
choreography and the collective behavior of the roles. Here, trace-based techniques
can be applied. This is su cient when dealing with deterministic behavior in the
choreography and the roles. Branching structures are of relevance in the presence
of non-determinism. Here, bisimulation-like techniques can be used.</p>
      <p>In order to formally capture the di erent notions of realizability we need
to introduce the following concepts. C denotes the set of all choreographies
(also with silent transitions). R denotes the set of all role behavior models.</p>
      <p>: }(R) ! C is a function that composes a choreography out of a set of role
behavior models. C C is a binary relation on choreographies.</p>
      <p>Please note that heavily depends on the communication model chosen
and, in the case of asynchronous communication, the ordering relationships to
be considered. In the special case of considering the order of communication
transitions within a role, depends on the role under investigation. depends
on whether the complete or only a subset of the behavior is demanded and it
also depends on the equivalence notion chosen.</p>
      <p>De nition 1 (Realizability). A choreography c 2 C is realizable, i there
exists a set of roles r1; : : : ; rn 2 R such that (r1; : : : ; rn) c.
4</p>
    </sec>
    <sec id="sec-3">
      <title>Related Work</title>
      <p>
        Realizability checking for conversation models was presented in [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. Here, the
notion of realizability does not consider branching structures in the
conversation models and focuses on trace equivalence between the collective behavior
of the roles and the original conversation model. Asynchronous communication
is considered where each role has one FIFO queue for all incoming messages.
Realizability is broken down to three requirements. (1) Synchronous compatible
condition: The conversation model is projected to the di erent roles, which are
then interconnected under the assumption of synchronous communication (called
the syn-con guration). The condition for each state in the syn-con guration is
that whenever a role is ready to send a message there must be another role that
is ready to receive this message. (2) Autonomous condition: It is demanded for
each role projection that there is no state where the role is ready to send and
to receive a message. Rather, in each state the role projection is either ready to
send one out of a set of messages or ready to receive one out of a set of message.
Furthermore, it must not be possible to send or receive message in a nal state.
(3) Lossless join condition: The join of the role projections must show exactly
the same behavior as the original conversation model. Realizability for message
sequence charts was studied in [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ].
      </p>
      <p>
        The notion of local enforceability was rst introduced in [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]. Here, only a
subset of behavior is demanded as well as the reachability of all interactions from
the original choreography. Enforceability checking is carried out using structural
rules rather than considering the state space. Synchronous communication was
assumed. Realizability and local enforceability was also studied in the context of
interaction Petri nets in [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]. Again, synchronous communication is assumed and
proper termination and reachability of all interactions is demanded. In contrast
to the previous work on local enforceability, enforceability checking is done using
the state space. Realizability is de ned based on branching bisimulation.
      </p>
      <p>
        The notion of desynchronizability investigates whether a choreography that
is realizable under the assumption of synchronous communication properly
terminates under the assumption of asynchronous communication (with one bu er
per message type) [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ].
5
      </p>
    </sec>
    <sec id="sec-4">
      <title>Realizability Checking</title>
      <p>
        Similarly to the approaches in [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] and [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] we construct the role projections for
every role in a conversation model and then study the composition of these
projections. As [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] does not consider branching structures, role projection is
based on minimal nite state automata containing only those interactions where
the particular role is involved in.
      </p>
      <p>
        As we want to preserve the branching structure we carefully need to consider
the observability of choices within each role. We construct the role behavior for
a role r in a similar way like in the operating guidelines approach [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]. (a) Start
with the initial state s = s0 and create a new node n. (b) Determine those states
that can be reached from s without involvement of r. All these states are added
to node n. (c) Identify all transitions with involvement of r that originate in
one of the states belonging to n. For each transition label (s; m; r) determine if
there is already a node n0 corresponding to all states s0 that are reachable via
transitions with label (s; m; r). If such an n0 does not exist, create it. For every
s0 and n0 continue with step (b).
      </p>
      <p>The nodes and their connections are the resulting role projection cr for r.
The initial node n becomes the initial state of cr and all nodes containing nal
states become nal states of cr. Figures 2(a) and 2(b) illustrate this for roles B
and C and the conversation model from Figure 1(d).</p>
      <p>An exception to rule (c) applies to all those cases where several transitions
with the same label originate in the same state. In this case, di erent nodes must
be identi ed / created. If multiple states belonging to the same node have several
transitions with the same label (s; m; r), nodes must be identi ed / created for
the di erent combinations.
6</p>
    </sec>
    <sec id="sec-5">
      <title>Conclusion</title>
      <p>This paper motivated di erent dimensions for realizability and investigated role
projection for those realizability notions that are based on bisimulation. Here,
the branching structures must be considered carefully in order to cater for the
moment of observability of choices. Composition of role projections for di erent
communication models was outside of the scope of this paper due to the space
restrictions. Also the binary relation for comparing the composition and the
original conversation model was not covered.</p>
      <p>
        The work presented in this paper is based on conversation models.
Interaction Petri nets [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] are an alternative formalism for interaction models with
concurrency. It is desirable to preserve concurrency as much as possible during
role projection. Therefore, future work will center around an approach, where
transformation rules similar to those presented in [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] are applied.
      </p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <given-names>Business</given-names>
            <surname>Process Modeling Notation</surname>
          </string-name>
          ,
          <year>V1</year>
          .1.
          <string-name>
            <surname>Technical</surname>
            <given-names>report</given-names>
          </string-name>
          , OMG,
          <year>Jan 2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <given-names>R.</given-names>
            <surname>Alur</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Etessami</surname>
          </string-name>
          , and
          <string-name>
            <given-names>M.</given-names>
            <surname>Yannakakis</surname>
          </string-name>
          .
          <article-title>Inference of message sequence charts</article-title>
          .
          <source>In ICSE</source>
          , pages
          <volume>304</volume>
          {
          <fpage>313</fpage>
          , New York, NY, USA,
          <year>2000</year>
          . ACM.
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <given-names>G.</given-names>
            <surname>Decker</surname>
          </string-name>
          and
          <string-name>
            <given-names>A.</given-names>
            <surname>Barros</surname>
          </string-name>
          .
          <article-title>Interaction Modeling using BPMN</article-title>
          .
          <source>In CBP, number 4928 in LNCS</source>
          , pages
          <volume>206</volume>
          {
          <fpage>217</fpage>
          ,
          <string-name>
            <surname>Brisbane</surname>
          </string-name>
          , Australia,
          <year>September 2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <given-names>G.</given-names>
            <surname>Decker</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Barros</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F. M.</given-names>
            <surname>Kraft</surname>
          </string-name>
          , and
          <string-name>
            <given-names>N.</given-names>
            <surname>Lohmann</surname>
          </string-name>
          .
          <article-title>Non-desynchronizable service choreographies</article-title>
          .
          <source>In ICSOC, LNCS</source>
          , Sydney, Australia,
          <year>Dec 2008</year>
          . Springer Verlag.
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <given-names>G.</given-names>
            <surname>Decker</surname>
          </string-name>
          ,
          <string-name>
            <given-names>O.</given-names>
            <surname>Kopp</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Leymann</surname>
          </string-name>
          , and
          <string-name>
            <given-names>M.</given-names>
            <surname>Weske</surname>
          </string-name>
          .
          <article-title>BPEL4Chor: Extending BPEL for Modeling Choreographies</article-title>
          .
          <source>In ICWS</source>
          , pages
          <volume>296</volume>
          {
          <fpage>303</fpage>
          ,
          <string-name>
            <surname>Salt</surname>
            <given-names>Lake City</given-names>
          </string-name>
          , Utah, USA,
          <year>July 2007</year>
          . IEEE Computer Society.
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <given-names>G.</given-names>
            <surname>Decker</surname>
          </string-name>
          and
          <string-name>
            <given-names>M.</given-names>
            <surname>Weske</surname>
          </string-name>
          .
          <article-title>Local Enforceability in Interaction Petri Nets</article-title>
          .
          <source>In BPM, number 4714 in LNCS</source>
          , pages
          <volume>305</volume>
          {
          <fpage>319</fpage>
          ,
          <string-name>
            <surname>Brisbane</surname>
          </string-name>
          , Australia,
          <year>September 2007</year>
          . Springer Verlag.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <given-names>X.</given-names>
            <surname>Fu</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Bultan</surname>
          </string-name>
          , and
          <string-name>
            <given-names>J.</given-names>
            <surname>Su</surname>
          </string-name>
          .
          <article-title>Conversation protocols: A formalism for speci cation and analysis of reactive electronic services</article-title>
          .
          <source>Theoretical Computer Science</source>
          ,
          <volume>328</volume>
          (
          <issue>1- 2</issue>
          ):
          <volume>19</volume>
          {
          <fpage>37</fpage>
          ,
          <string-name>
            <surname>November</surname>
          </string-name>
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <given-names>N.</given-names>
            <surname>Kavantzas</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Burdett</surname>
          </string-name>
          , G. Ritzinger, and
          <string-name>
            <given-names>Y.</given-names>
            <surname>Lafon</surname>
          </string-name>
          .
          <source>Web Services Choreography Description Language Version</source>
          <volume>1</volume>
          .0,
          <string-name>
            <given-names>W3C</given-names>
            <surname>Candidate Recommendation</surname>
          </string-name>
          .
          <source>Technical report</source>
          ,
          <year>November 2005</year>
          . http://www.w3.org/TR/ws-cdl-
          <volume>10</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <given-names>N.</given-names>
            <surname>Lohmann</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Massuthe</surname>
          </string-name>
          , and
          <string-name>
            <given-names>K.</given-names>
            <surname>Wolf</surname>
          </string-name>
          .
          <article-title>Operating guidelines for nite-state services</article-title>
          .
          <source>In ICATPN</source>
          , volume
          <volume>4546</volume>
          <source>of LNCS</source>
          , pages
          <volume>321</volume>
          {
          <fpage>341</fpage>
          ,
          <string-name>
            <surname>Siedlce</surname>
          </string-name>
          , Poland, June 2007. Springer Verlag.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>J. M. Zaha</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          <string-name>
            <surname>Dumas</surname>
          </string-name>
          , A. ter
          <string-name>
            <surname>Hofstede</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          <string-name>
            <surname>Barros</surname>
            , and
            <given-names>G.</given-names>
          </string-name>
          <string-name>
            <surname>Decker. Service Interaction</surname>
          </string-name>
          <article-title>Modeling: Bridging Global and Local Views</article-title>
          .
          <source>In EDOC</source>
          , pages
          <volume>45</volume>
          {
          <fpage>55</fpage>
          ,
          <string-name>
            <surname>Hong</surname>
            <given-names>Kong</given-names>
          </string-name>
          ,
          <year>Oct 2006</year>
          . IEEE Computer Society.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>