[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Human editable BPEL?
We should have this discussion more systematically but in general, neither conversation IDs nor instance IDs are sufficient. The "multi-start activities" example is one kind of use case, where rendezvous occurs at activation hence before the creation of any instance ID. Consider also multiway conversations, especially those where A-->B-->C-->A types of communication loops occur. What these need are mechanisms for carrying context and "infecting" the right instances with the context -- WS-Coordination has this as a general mechanism. The scope of such a coordination does not in general coincide with the lifetime of a process instance. You can think of correlation sets as a "poor man's context" mechanism. But I agree with the goal of reducing the scope of explicit correlation if possible, but that would mean dependency on some specific context mechanisms for two-way conversations and multi-way coordination. I would hate to see us create some sort of meta model for context that has to be mapped to concrete coordination layers. Too much complexity. -----Original Message----- From: Ugo Corda [mailto:UCorda@SeeBeyond.com] Sent: Sat 6/14/2003 5:24 PM To: Satish Thatte Cc: wsbpel@lists.oasis-open.org Subject: RE: [wsbpel] Human editable BPEL? That seems to say that you either have conversation IDs at the transport level, or you need message-based correlations. It does not seem to address the case where instanceIDs are used at the application level (e.g. leveraging the WS-Addressing mechanism, as hinted somewhere else in the spec). Am I misreading the paragraph? Ugo > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Saturday, June 14, 2003 2:09 PM > To: Ugo Corda; Martin Chapman; Greg Ritzinger; ygoland@bea.com; > Gnosis_@compuserve.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Human editable BPEL? > > > The first paragraph in 10.1 is what I would point to. > > -----Original Message----- > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > Sent: Sat 6/14/2003 12:58 PM > To: Satish Thatte; Martin Chapman; Greg Ritzinger; > ygoland@bea.com; Gnosis_@compuserve.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Human editable BPEL? > > > > In my note I was referring more to the rationale for > choosing one approach over another. In the case of > correlation, for instance, the spec presents rationale for > why you need correlation at all, but not for why BPEL chose > the message-based approach over the correlationID approach > (or at least I was not able to find a clear explanation of > that in the current spec). > > Ugo > > > -----Original Message----- > > From: Satish Thatte [mailto:satisht@microsoft.com] > > Sent: Friday, June 13, 2003 10:32 PM > > To: Martin Chapman; Ugo Corda; Greg Ritzinger; > ygoland@bea.com; > > Gnosis_@compuserve.com > > Cc: wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Human editable BPEL? > > > > > > Thank you Martin. I did think that there is quite a > bit of rationale > > given in the spec for most of the "interesting" features like > > properties > > and correlation, and, at a higher level, abstract > processes. It might > > be useful to have a separate document that states > requirements and > > rationale but it would be great to have specific > issues and questions > > that people think need to be addressed in such a document. > > > > Satish > > > > > > -----Original Message----- > > From: Martin Chapman [mailto:martin.chapman@oracle.com] > > Sent: Friday, June 13, 2003 10:10 AM > > To: Ugo Corda; Greg Ritzinger; ygoland@bea.com; > Gnosis_@compuserve.com > > Cc: wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Human editable BPEL? > > > > but surely the best way to deal with this is to raise > an issue or > > introduce > > a new requirement. > > Thats where the pros and cons can be discussed. > > In the particular case of correllations, I think the > spec gives enough > > rationale. > > > > Martin. > > > -----Original Message----- > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > > > Sent: Friday, June 13, 2003 9:59 AM > > > To: Greg Ritzinger; ygoland@bea.com; Gnosis_@compuserve.com; > > > martin.chapman@oracle.com > > > Cc: wsbpel@lists.oasis-open.org > > > Subject: RE: [wsbpel] Human editable BPEL? > > > > > > > > > At least it would be very useful to have a document > on rationales > > > which describes why certain things are done in one > particular way > > > out of other possible alternatives. > > > > > > Just to give an example, BPEL's current correlation > mechanism is > > > based on message contents (see CorrelationSets). It > could be done > > > instead using a correlationID abstract from actual message > > > contents (and in fact it seems that the current > spec hints at > > > that as a future development based on > WS-Addressing). What is the > > > rationale for the current choice? What are the pros and cons > > > compared to other solutions? etc. > > > > > > Ugo > > > > > > > -----Original Message----- > > > > From: Greg Ritzinger [mailto:GRitzinger@novell.com] > > > > Sent: Friday, June 13, 2003 8:11 AM > > > > To: ygoland@bea.com; Gnosis_@compuserve.com; > > martin.chapman@oracle.com > > > > Cc: wsbpel@lists.oasis-open.org > > > > Subject: RE: [wsbpel] Human editable BPEL? > > > > > > > > > > > > > > > > If we are to review, fix and possibly change the > BPEL spec, then I > > > > believe we need its companion requirements spec. It would > > be nice to > > > > know why something was put into BPEL before we attempt to > > change or > > > > remove it. > > > > > > > > Greg > > > > > > > > >>> "Martin Chapman" <martin.chapman@oracle.com> > 6/12/2003 5:32:15 > > PM > > > > >>> > > > > IMHO the requirements are pretty simple; review > the 1.1 spec, fix > > any > > > > bugs, > > > > resolve ambiguities, and > > > > if you want new stuff or if you want to make radical > > changes propose > > > > new > > > > requirements. > > > > I trust the originators of the spec itself to > have done the > > > > "meta" requirements exercise, for which BPEL4WS > 1.1 is the result. > > > > > > > > Martin. > > > > > > > > > -----Original Message----- > > > > > From: David RR Webber - XML ebusiness > > > > [mailto:Gnosis_@compuserve.com] > > > > > > > > > Sent: Thursday, June 12, 2003 9:34 AM > > > > > To: Yaron Y. Goland > > > > > Cc: wsbpel@lists.oasis-open.org > > > > > Subject: RE: [wsbpel] Human editable BPEL? > > > > > > > > > > > > > > > Yaron, > > > > > > > > > > There's another aspect to this - BPEL is it > seems primarily > > > > > intended to be used internally - with only a > subset of the logic > > > > > being shared externally. > > > > > > > > > > But what if that logic (that you built in your > IDE GUI) is not > > > > > readable - or causes undesirable results - in > the IDE GUI > > > > > of Product X - used by your partner? Or your partners > > > > > BPEL fragment causes bad results on your system? But > > > > > the models look just lovely! > > > > > > > > > > You need to look at the raw XML to figure out > why - and more > > > > > to the point - interoperablity between products > requires a > > > > > simpler subset. > > > > > > > > > > Broken record - if we get back to the > requirements - and if > > > > > interoperability in this way is a key requirement - then > > > > > simpler syntax, and also levels of conformance, are the > > > > > way to go. > > > > > > > > > > Alternately you could just duck this whole > issue by using > > > > > something like BPSS to do the external coupling across > > > > > processes. > > > > > > > > > > But we're still waiting for that unnamed > graduate student to > > > > > produce for us the definative list of > requirements - so we > > > > > can be crystal clear on all this. What was his > name again? > > > > > > > > > > Thanks, DW. > > > > > =================================================== > > > > > Message text written by "Yaron Y. Goland" > > > > > > > > > > > I remember in the late 1980s when everyone > argued that source > > > > > code was dead > > > > > and all programs would be written using UIs. > > > > > > > > > > I remember the early 1990s when everyone argued that no > > one would > > > > ever > > > > > directly author HTML. > > > > > > > > > > I also remember the late 1990s when everyone > (myself included =( > > > > )argued > > > > > that it didn't matter if XML was human editable > since everyone > > would > > > > use > > > > > tools. > > > > > > > > > > It's funny how often everyone is wrong. > > > > > > > > > > Just a thought, > > > > > Yaron > > > > > < > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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 > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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]