[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)
Satish, This seems complicated enough already to me from the point of view of generating an operating environment where tracking behaviour at runtime is non-trivial already! Can you elaborate on the "But I doubt it would satisfy most members of the TC as the specification we produce". ???? So what would be the compelling use cases that would need something else? Or is it the other way around - that issues requiring interoperability across systems die an ugly death on things like spawn and recursion (maybe these features can only be used internally?). Thanks, DW. ============================================== Message text written by "Satish Thatte" >Popping up a level, the basic point is that minimality is in the eye of the beholder. Why stop with eliminating sequence? Links can be emulated by message based synchronization. Concurrency (flow) can be emulated by a spawn feature, using message passing to emulate shared state. In the end we have message passing including port reference passing, spawn, some notion of abstraction (declaration) and some form of recursion and not much else, i.e., the pi calculus. Pi is provably able to emulate everything including XML data. But I doubt it would satisfy most members of the TC as the specification we produce. There is some element of judgment involved in deciding what is minimal enough for BPEL -- emulation is not a conclusive argument. I am sure none of you will disagree at this level, although the only argument I have heard for eliminating sequence so far is that it can be emulated with flow and links. Satish <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]