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

[Assaf Arkin <arkin@intalio.com>]

Assaf Arkin wrote:

> 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.
>>
>>  
>>
> Indeed some forms of "simplicity" actually introduces a lot of 
> complexity ;-)
>
>> 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'm going to start by disagreeing for a second and see what the 
> consequences are.
>
> Just as a reminder, my criteria is to "reduce the complexity of the 
> specification while allowing interoperability/portability" (without 
> which you don't really need a standard, do you?).
>
> If you go all the way to pi-calculus you end up with a situtation 
> where two systems may decide to use different WSDL operations or 
> construct different messages for the same process definition since 
> there is no interpretations of how names/actions should be mapped to 
> WSDL. So to answer Edwin's question, you lose interoperability , you 
> might as well have no spec.

^== Sorry, it was David's question, I was looking at the wrong e-mail 
header ;-)


>
> Or, you can formalize the manner in which WSDL operations are used 
> with a pi-calculus like definition, but then you need to add further 
> rules to the specification. Off the top of my head I can think of 
> two/three rules and I can ensure you they are more complex than the 
> definition of sequence. So while turning the language from a 
> high-level model to a low-level model, you would significantly 
> increase the complexity of the specification.
>
> So here's a very simple criteria for accepting/rejecting constructs 
> that would accept the removal of <sequence> but would clarify exactly 
> why you would not attempt to take <flow> out of existence.
>
> Does this help?
>
> arkin
>