Re: [wsbpel] implicite links of the runtime engine

[Assaf Arkin <arkin@intalio.com>]

Jim Webber wrote:

>Guys,
>
>  
>
>>My counter argument is that you need to build support for serializing 
>>activities that synchronize through links. It's not an easy task, but 
>>you'll have to do it anyway. If you already spent the time 
>>making flows 
>>work properly, might as well use that piece of code in all 
>>cases. If you 
>>write it once and use it all over the place then there's a good ROI 
>>argument in favor of using <flow> as much as possible. Less code to 
>>develop, less test cases, etc. At least from an execution perspective.
>>    
>>
>
>After having hand written BPEL scripts, and intending to do so in future
>(because sometimes you just have to do things for yourself), I would plead
>the case for keeping useful bits of syntactic sugar like <flow>. For those
>of us who will be writing BPEL by hand (and I might be a minority of one
>here) other constructs like <macro> or <procedure> would be very welcome
>too.
>
>The point is, although I can see that tools are really useful in this arena,
>there will always be cases where tools aren't applicable. Given that BPEL
>hasn't been used much so far, it is premature to start optimising away
>features that I (for one) might rely on!
>  
>
Optimization is not necessarily about removing features but reducing 
cost. If the language is intended purely for an engine, then you remove 
the redundant constructs for which you have to develop documentation, 
code, test cases, etc. If the language is also used for XML authoring 
then you actually introduce more constructs to make XML authoring easy 
-- another form of optimization.

So if we made a conscious decision to support authoring I do think we 
need <sequence> and also something of the like of <procedure>. But I 
think we're better off if we have one standardized way to write macros 
that we can use in a variety of specifications, including but not just BPEL.

arkin

>Jim
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>  
>