[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: execution engine or programming language?
Yaron, Is HTML an execution engine or a programming language? Edwin > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Tuesday, June 24, 2003 1:02 PM > To: Assaf Arkin; Jim Webber > Cc: fred.carter@amberpoint.com; 'Ron Ten-Hove'; > wsbpel@lists.oasis-open.org > > 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 > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]