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

[Fred Carter <fred.carter@amberpoint.com>]

+1
Thus quoth Satish Thatte (~ 19-Jun-03 11:18 AM ~)...
> 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.  
> 
> 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.
> 
> Satish
> 
> -----Original Message-----
> From: Maciej Szefler [mailto:mbs@fivesight.com] 
> Sent: Wednesday, June 18, 2003 9:46 AM
> To: Assaf Arkin; Eckenfels. Bernd
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] implicite links of the runtime engine (was:
> Implicit <sequence> macro)
> 
> +1, BPEL is an abstract virtual machine, it should have the minimum
> constructs necessary to express the universe of supported programs; if
> there is no "if-then-else" because "switch" has all the expressive power
> (and then some) of "if-then-else",  then there should not be a
> "sequenence" by the same reasoning. 
> 
> -Maciej
> 
> 
>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Tuesday, June 17, 2003 2:46 PM
>>To: Eckenfels. Bernd
>>Cc: wsbpel@lists.oasis-open.org
>>Subject: Re: [wsbpel] implicite links of the runtime engine (was:
>>Implicit <sequence> macro)
>>
>>
>>I agree.
>>
>>If the distinction was made between doings thing in order or in 
>>parallel, then I understand why you need two different 
>>activities. But 
>>we wouldn't need links or serializable scopes. Currently the flow 
>>activity covers all the cases from strictly serialized to strictly 
>>concurrent and all shades in between, making the sequence activity 
>>nothing more than a convinience. You need to support the 
>>complexity of 
>>synchronized activities to support the flow activity, that's not easy 
>>but if you have the capability you might as well use it all the way.
>>
>>So the sequence activity does need to justify its existence, and it 
>>needs a generic rational so we can decide what to do with 
>>other existing 
>>or proposed "simplifications" to the language.
>>
>>arkin
>>
>>Eckenfels. Bernd wrote:
>>
>>
>>>Hello Satish,
>>>
>>> 
>>>
>>>
>>>>I honestly don't think <sequence> needs to justify its existence.
>>>>Concurrency with synchronization can emulate sequentiality 
>>
>>but that is
>>
>>>>clearly a convoluted and expensive way to do the simplest kind of
>>>>orchestration.
>>>>   
>>>>
>>>
>>>This may be true from the standpoint of writing bpel by 
>>
>>hand, but for sure it is a non issue for implementation. 
>>Depending on your internal runtime data model, a sequence is 
>>only an additional complication, provided the fact, that you 
>>need to offer a implementation for flow, anyway. And since a 
>>sequence does not forbid to have links in and out, it also 
>>means your engine has to support the notion of 
>>synchronisation, anyway.
>>
>>>So we should make clear in the spec, that it is only a 
>>
>>shortcut, for skipping those links inside a sequential flow, 
>>but all other properties will apply, anyway.
>>
>>>Greetings
>>>Bernd
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>> 
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 
> 


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301