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

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

Thus quoth Ron Ten-Hove (~ 17-Jun-03 2:08 PM ~)...
>     If BPEL were to be strictly a modelling language, then the inclusion 
> of both <sequence> and <flow> would be justifiable from the modelling 
> perspective. Perhaps we can make this claim for abstract BPEL?
> 
>     On the other hand, "concrete" BPEL has a different purpose: it is an 
> /executable /description of a process. It may be appropriate for the TC 
> to create a formal semantics for the execution of each BPEL element, in 
> order that we may analyse and better understand what we are creating. 
> Even if we don't go as far as formalising the semantics, it is true that 
> the simpler the language, the easier it is to reason about. 

That may be true, but I think it's also the case that a specific, 
well-understood, definition is likely to engender greater acceptance. 
Having to "figure out" how to say "please do these things one after the 
other" seems odd.

"Simple things should be simple."  If the /Hello, world/ of BPEL 
requires a 2-star wizard (we'll reserve the 3 & 4 stars to other needs), 
then one could argue that we've failed.


>                                                             From this 
> perspective, it is entirely appropriate for Arkin to ask that the 
> <sequence> activity justify its existence, when equivalent structures 
> exist elsewhere
> 
>     So what is our rational moving forward? Is this (primarily) a 
> modelling language, or an executable artifact? Or are there better 
> criteria for resolving these issues?
I would further argue that the closer the modelling is to the 
implementation, the more likely they are to accomplish similar things.

Even if it's "executable" only, I'd argue as an implementer for 
process-type things in a previous life :-), that having an engine 
"knowing" that the intent is sequential may allow it to do a much better 
job resource-wise, without being a very sophisticated system (i.e. wider 
acceptance).
> 
> -Ron
> 
> Assaf Arkin wrote:
> 
>> 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.
Yes, but a convenience that most readers will expect.
>>
>> 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.
+1
>>>>   
>>>
>>>
>>> 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
>>
> 


-- 
Fred Carter / AmberPoint, Inc.

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