RE: [wsbpel] implicite links of the runtime engine

["Yaron Y. Goland" <ygoland@bea.com>]

So Spake Assaf
> 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.

+1

The group needs to clearly and consistently decide on the question - Are
BPEL executable processes an execution engine or a programming language?

Only with clarity on that issue can we hope to resolve issues like this one.

		Yaron

> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Saturday, June 21, 2003 7:59 PM
> To: Jim Webber
> Cc: fred.carter@amberpoint.com; 'Ron Ten-Hove';
> wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] implicite links of the runtime engine
>
>
> 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
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>