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)


Not sure what you are proposing here - Pi calc linked to WSDL with a
couple of your rules?

Please keep in mind that no matter what criteria you have for
minimality, it is extremely unlikely that the resulting "minimal feature
set" will be unique.  

I have heard people argue rather vociferously that links should be
dropped (rather than sequence).  This is clearly possible if you do all
intra and inter process synchronization uniformly through messaging,
letting the implementation optimize the intra-process case, rather the
way you are proposing that the implementation should optimize the
sequential case.

So where would that leave us?  My minimal set is better than yours
because "From an execution perspective I have a strict preferrence for
linking activities approach and always did"?

Satish

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Friday, June 20, 2003 9:23 AM
To: Satish Thatte
Cc: Ron Ten-Hove; Maciej Szefler; Eckenfels. Bernd;
wsbpel@lists.oasis-open.org
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.
>
>  
>
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.

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

> 
>
>Satish
>  
>





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