RE: [wsbpel] implicite links of the runtime engine (was: Implicit <sequence> macro)

["Tony Andrews" <tandrews@microsoft.com>]

Wrt abstract processes, I believe what you most often are interested in
is whether a system of (two or more) abstract processes connected in a
specified way will communicate without getting "stuck" (i.e.
dead-locked) under all conditions (timeouts, error cases, etc).
Bisimilarity isn't relevant for this scenario.

Another question that will be interesting is whether an executable
process "conforms to" an abstract process that specifies some desired
behavior. In this case, bisimilarity is too strong a requirement because
an implementation may be in what one would think of informally as
conformance without actually being bisimilar to the specification. The
notion of "refinement", which can be stated in a completely rigorous
way, better suits the desired relationship in this case.

Tony

-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com] 
Sent: Wednesday, June 25, 2003 10:00 AM
To: Satish Thatte; Assaf Arkin
Cc: Ron Ten-Hove; Eckenfels. Bernd; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] implicite links of the runtime engine (was:
Implicit <sequence> macro)

I'd argue that the distinction between executable and abstract is really
quite small. Both executable and abstract process will be "executed",
either by a "real" machine implementing the physical side-effects of the
reductions implied by the process definition in the context of the
physical environment, or by a machine that attempts to determine the
bisimilarity of two BPEL processes. Consequently, I see the value of
constructs such as "sequence" to be unaffected by the abstractness of
the process. 

One could even make an argument (although I would not) that from the
perspective of manual inspection of BPEL process definitions, it is
better to NOT have <sequence>, simply because it is a bit harder to see
that concrete process <seq> A B C </seq> accurately implements abstract
process <seq><flow> A B </flow> C </seq>.


-Maciej Szefler