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)


There is a big difference in degree between emulation of sequence with flow and emulation of XML using pi calculus. For one BPEL does not express pi, so to do so would involve expanding the spec (whereas eliminating sequence reduces the spec). Second, for the purposes of business processes, where the notion of structured data is integral to the definition, it is only natural to not have to model XML data using a slew of pi processes: doing so would unnecessarily complicate the implementation of the BPEL engines and make direct reporting against process state impossible (while eliminating sequence marginally simplifies implementation, and has no impact on direct reporting capabilities). This philosophy amounts to "as simple as possible, keeping in mind the problem domain".

-Maciej Szefler

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Friday, June 20, 2003 10:43 AM
> To: Ron Ten-Hove
> Cc: Maciej Szefler; Assaf Arkin; Eckenfels. Bernd;
> wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] implicite links of the runtime engine (was:
> Implicit <sequence> macro)
> 
> 
> 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
> 
> 	-----Original Message----- 
> 	From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] 
> 	Sent: Fri 6/20/2003 7:58 AM 
> 	To: Satish Thatte 
> 	Cc: Maciej Szefler; Assaf Arkin; Eckenfels. Bernd; 
> wsbpel@lists.oasis-open.org 
> 	Subject: Re: [wsbpel] implicite links of the runtime 
> engine (was: Implicit <sequence> macro)
> 	
> 	
> 
> 	Satish Thatte wrote:
> 	
> 	>All true, except for the simple matter of analyzing 
> the implications of
> 	>concurrency for access to shared data or being able to 
> recognize the
> 	>patterns where concurrency is absent and thus 
> concurrency control is not
> 	>required.  In particular, if a sequence has incoming 
> and outgoing links,
> 	>and is now replaced with a flow with links itself, I 
> submit that
> 	>recovering the original pattern and its simple inexpensive
> 	>implementation would be challenging. 
> 	>
> 	This type of analysis should be done, regardless of 
> whether <sequence>
> 	is used. Further, it is not that difficult to 
> distinguish sequential
> 	chains of activities, if one models the process as a (suitably
> 	annotated) DAG, rather than an XML tree.
> 	
> 	(Control of concurrent access to process instance state 
> is a topic we
> 	need to delve into separately. Is there such a thing as 
> a "safe" BPEL
> 	process, in this regard? Can we create a formal 
> semantics of execution
> 	to aid in verifying safety properties?)
> 	
> 	>
> 	>In other words, we would be raising the bar for 
> implementers of both
> 	>tools and runtime engines, especially if we expect 
> them to cater to the
> 	>prejudices of those who prefer the "block structured" 
> approach rather
> 	>than the "linking activities" approach that Assaf 
> seems to like these
> 	>days.
> 	>
> 	I'm not sure I understand this final comment. 
> Eliminating <sequence>
> 	does not change the basic topology of such process graphs.
> 	
> 	As for "raising the bar" for implementors: I'd issue 
> the standard word
> 	of warning about "premature optimization." As a 
> colleague of mine is
> 	fond of saying, we have to paint the dragon before we 
> can slay it.
> 	
> 	Cheers,
> 	-Ron
> 	
> 	
> 	
> 
> 


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