[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 23 - implicite links of the runtime engine
I proposed the following change to the Issue 23 to Peter, this might make my point clear. It is not a dead snake for me. But I am happy with keeping sequence, as long as we actualyl clarify the redundancy: Title: Rationale for sequence vs. flow Description: The spec contains a <sequence> construct, which totally can be replaced by a <flow> with explicite links between contained activities. This may be possible confusing the readers (wondering if they missed anything). So eighter the redundancy needs to be removed or explained. - remove <sequence> construct -or- - add rationale to explain it is syntactical suggar -----Original Message----- From: Edwin Khodabakchian [mailto:edwink@collaxa.com] Sent: Wednesday, June 25, 2003 7:38 PM To: 'Frank Leymann' Cc: wsbpel@lists.oasis-open.org Subject: RE: [wsbpel] implicite links of the runtime engine (was: Implicit <sequence> macro) +1. Based on the customer/developer feedback we have collected, support for block-structured and graph-structured is a plus. It is all about congruence: what you think is what you code. Sometime you think of a process as a sequence, sometime as a set of activities interlinked/interdependant. We have had developers use BPEL for more than 6 months and never heard a complain regarding the use of sequence versus link. I feel like we are playing with a dead snake. Edwin > > -----Original Message----- > From: Frank Leymann [mailto:LEY1@de.ibm.com] > Sent: Wednesday, June 25, 2003 10:25 AM > To: Assaf Arkin > Cc: Eckenfels. Bernd; Maciej Szefler; Ron Ten-Hove; Satish > Thatte; wsbpel@lists.oasis-open.org > > > I completely disagree that this is an academic exercise! As > Satish points out correctly, the combined block-structured > and graph-structured nature of BPEL is a high-value feature > of BPEL - real-world customers fall into one of these camps > and you have hard problems convincing a "block-oriented" > customer that graph-oriented is the right way to go and vice > versa. A combined language like BPEL is in fact very > pragmatic by ending this discussion and being able to focus > on features and functions. > > Regards, > Frank > > ------------------- > Frank Leymann, Distinghuished Enineer > IBM Software Group > Member, IBM Academy of Technology > > Phone 1: +49-7031-16 39 98 > Phone 2: +49-7056-96 50 67 > Mobile: +49-172-731 5858 > ----------------- > > > > > > To: Satish Thatte <satisht@microsoft.com> > cc: Maciej Szefler <mbs@fivesight.com>, Ron Ten-Hove > <Ronald.Ten-Hove@Sun.COM>, "Eckenfels. Bernd" > <B.Eckenfels@seeburger.de>, wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] implicite links of the runtime engine (was: > Implicit <sequence> macro) > > > Satish Thatte wrote: > > >The merger of the block structured and graph oriented > control regimes > >is actually a unique and useful characteristic of BPEL in > that it puts > >to bed a perennial debate in this area. I think the cost in feature > >overhead is pretty minimal for that benefit. > > > > > That's a good academic excercise. > > Now, as far as a usable specification goes ... > > arkin > > >Satish > > > > > > > > --------------------------------------------------------------------- > 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]