[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] implicite links of the runtime engine (was: Implicit <sequence> macro)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]