OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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]