OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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 Thatte wrote:

>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.
>  
>
If we are to venture down this road, then why not embrace Pict (or one 
of its cousins), and stop trying to reinvent the wheel? :-)

>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.  
>
I suspect a bit of a misunderstanding here. The issue about <sequence> 
that Bernd Eckenfels brought up has served to introduce a broader issue: 
what principles do we use to decide, consistently, which features are 
"in" and which are "out" of BPEL? BPEL is supposed to be an execution 
language (witness the E), yet we have features that are modelling 
oriented, and are useless in an execution language. This is important, 
not so much for the existing proposed features, but for all the 
additions and changes that doubtless will soon come.

We need a clear focus and direction, and I, for one, hope that this 
issue will help the TC define them.

-Ron




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]