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

["Frank Leymann" <LEY1@de.ibm.com>]

Bi-simulation is of interest whenever you want to substitute one process by
another, e.g. when you want to change partners, or if you compose process
models in a modular fashion.  Then, "equivalence" is important in order to
avoid impact on your own process or the other moduls.

But it is my assessment too, that simulation is more important short term
than bi-simulation:  For example, being able to check automatically that an
"internal" process "implements" a "public" process is of importance.  This
is the Walmart example mentioned in another mail.  "Implementation" here
means in a nutshell being able to send and consume messages in the same
possible orders than the public process (this is why many people call this
a "view" on the internal process, i.e. the externally observable behavior
of the internal process).

"Composability" too is of importance, but not only for abstract processes
but for executable processes too. This will especially support creating
process models in a modular fashion.

As a side comment:  Algorithmic support for the above is worked on in the
research community for so-called "well-formed cyclic" process models, i.e.
something that is basically a DAG with loops.  Another indicator that
arbitrary cycles should be avoided - they are intractable. And we should
protect our customers to hurt themselves  ;-)

Regards,
Frank

-------------------
Prof. Dr. Frank Leymann, Distinguished Engineer
IBM Software Group
Member, IBM Academy of Technology

Phone 1:  +49-7031-16 39 98
Phone 2:  +49-7056-96 50 67
Mobile:  +49-172-731 5858
-----------------





To:    "Maciej Szefler" <mbs@fivesight.com>, "Satish Thatte"
       <satisht@microsoft.com>, "Assaf Arkin" <arkin@intalio.com>
cc:    "Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM>, "Eckenfels. Bernd"
       <B.Eckenfels@seeburger.de>, <wsbpel@lists.oasis-open.org>
Subject:    RE: [wsbpel] implicite links of the runtime engine (was:
       Implicit <sequence> macro)


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

---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org