[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 37 - Proposal for vote
I'll be at the f2f. Let's talk there.
Paco
"Satish Thatte"
<satisht@microsof To: Francisco Curbera/Watson/IBM@IBMUS, "Alex Yiu" <alex.yiu@oracle.com>
t.com> cc: "Alex Yiu" <alex.yiu@oracle.com>, "Dieter Koenig1" <dieterkoenig@de.ibm.com>,
"Yuzo Fujishima" <fujishima@bc.jp.nec.com>, "Nickolas Kavantzas"
06/19/2004 11:33 <nickolas.kavantzas@oracle.com>, "Furniss, Peter" <Peter.Furniss@choreology.com>,
AM <wsbpel@lists.oasis-open.org>, "Yaron Y. Goland" <ygoland@bea.com>
Subject: RE: [wsbpel] Issue 37 - Proposal for vote
Paco,
I really don't get why the proposed resolution has these implications that
you are concerned about. Are you coming to the F2F? If not, is someone
else who is able to explain this in person?
Satish
________________________________
From: Francisco Curbera [mailto:curbera@us.ibm.com]
Sent: Sat 6/19/2004 7:55 AM
To: Alex Yiu
Cc: Alex Yiu; Dieter Koenig1; Yuzo Fujishima; Nickolas Kavantzas; Furniss,
Peter; Satish Thatte; wsbpel@lists.oasis-open.org; Yaron Y. Goland
Subject: Re: [wsbpel] Issue 37 - Proposal for vote
I am aware of issue 96; my problem is that the proposed resolution of 37
seems to assume a particular resolution for it: that transport and
middleware correlation mechanisms will somehow become visible - even in an
opaque form - to the process definition. This may or may not be the right
solution, but is certainly a deviation from the status quo.
So it seems that your proposed text is making the resolution of 37
dependent on the resolution of 96; this would be a mistake, since I believe
37 can close w/o taking this dependency. If, however, you believe that
resolution for 37 requires an assumption on the outcome of 96 then this
needs to be explicitly stated and a resolution for 96 put voted before 37
is closed.
Paco
Alex Yiu
<alex.yiu@oracle. To: Satish Thatte
<satisht@microsoft.com>
com> cc: Francisco
Curbera/Watson/IBM@IBMUS, Dieter Koenig1 <dieterkoenig@de.ibm.com>,
Yuzo Fujishima
<fujishima@bc.jp.nec.com>, Nickolas Kavantzas
06/18/2004 03:29
<nickolas.kavantzas@oracle.com>, "Furniss, Peter"
<Peter.Furniss@choreology.com>,
PM
wsbpel@lists.oasis-open.org, "Yaron Y. Goland" <ygoland@bea.com>, Alex Yiu
<alex.yiu@oracle.com>
Subject: Re: [wsbpel] Issue
37 - Proposal for vote
I would concur Satish here. It's better to discuss that part of the
business under Issue 96.
An opaque / container-managed CS is still a CS. That CS still needs to
be initiated (implicitly / automatically by the container) before
certain in-bound activities.
In Issue 96, I guess we need to discuss whether an opaque /
container-managed CS can be used / added to an in-bound activity
implicitly / automatically without any explicit code in the BPEL.
A side note: If both initiation and usage of an opaque CS are always
implicit, then the opaque CS behavior may not need to be documented in
the spec. That is one viewpoint on opaque CS.
Regards,
Alex Yiu
Satish Thatte wrote:
>Paco,
>
>We are supposed to address this in Issue 96. So it seems to be a
separable discussion and there is no implication here that implicit
correlation is excluded. Perhaps we can make that clearer in the proposed
resolution.
>
>Satish
>
>________________________________
>
>From: Francisco Curbera [mailto:curbera@us.ibm.com]
>Sent: Fri 6/18/2004 6:46 AM
>To: Alex Yiu
>Cc: Alex Yiu; Dieter Koenig1; Yuzo Fujishima; Nickolas Kavantzas; Furniss,
Peter; Satish Thatte; wsbpel@lists.oasis-open.org; Yaron Y. Goland
>Subject: Re: [wsbpel] Issue 37 - Proposal for vote
>
>
>
>
>
>
>
>I am not really comfortable requiring correlation in any case. I think the
>assumption is that if the process definition does not provide an explicit
>means for process instance identification in an inbound activity then the
>message will not get there. The fact is that there are multiple mechanisms
>out there that people use to relate messages to ongoing precesses: session
>cookies, dedicated per-instance addresses, message headers, etc. Business
>level correlation may or may not be required for this task. Requiring the
>use of this mechanism unconditionally will likely lead to the definition
of
>unnecessary and meaningless correlation sets which will only clutter the
>process definition.
>
>Otherwise I'd give the proposed resolution a +1.
>
>Paco
>
>
>
>
>
> Alex Yiu
> <alex.yiu@oracle. To: "Furniss, Peter"
<Peter.Furniss@choreology.com>
> com> cc: Satish Thatte
<satisht@microsoft.com>, wsbpel@lists.oasis-open.org, Yuzo
> Fujishima
<fujishima@bc.jp.nec.com>, Dieter Koenig1 <dieterkoenig@de.ibm.com>, "Yaron
> 06/16/2004 06:02 Y. Goland"
<ygoland@bea.com>, Nickolas Kavantzas <nickolas.kavantzas@oracle.com>, Alex
> PM Yiu <alex.yiu@oracle.com>
> Subject: Re: [wsbpel]
Issue 37 - Proposal for vote
>
>
>
>
>
>
>Hi, Peter,
>
>After reading your email, I also did a similar exercise over the
>6-combination. I get a similar set of answers.
>
>I agree with Satish that a set of concise rules may be perferred over an
>explicit all permutation table in the spec.
>
>I think quite a few of 6 cases semantics are inferred / covered by the
>existing text in the spec and new text in the proposal ... Still I tend to
>agree with your exercise findings ... We may to extract a bit of your
>exercise result to put into the proposal text:
>
>Furniss, Peter wrote:
>
> process: createInstance=yes, correlation : initiate = no - this is
> impossible, since the correlation set can't have been initiated
> previously, as there was no previously for this process.
>
> RULE: For an inbound activity with createInstance=no, there must be
> at least one correlation set with initiate=no to allow the message
to
> be routed to the appropriate process instance. There may be other
> correlation sets with yes or rendezvous:
>
>
>I do like the generalized version of your RULE (quoted above) better. It
>covers both "yes" or "rendezvous" cases. I think we may want to somehow
>incorporate that into the text of Issue 37 proposal.
>
>The illegal case of createInstance="yes" and initiate="no" is kind of
>covered by the specification text. (A CS used in a start activity must be
>un-initialized, and initiate="no" pattern will definitely trigger a
runtime
>fault)
>
>But, it might worth a highlight, since static analysis can detect such an
>illegal case.
>(may be for Issue 84)
>
>
>Thanks!
>
>
>Regards,
>Alex Yiu
>
>
>Furniss, Peter wrote:
> I was thinking of just something informational - in which case I
> guess it shouldn't be in the spec proper. Let's see if I've got it
> right:
>
> process: createInstance=yes, correlation : initiate = yes - the
> normal first activity of a process. If present, there will normally
> (always ?) be only one activity with this - if outbound, the process
> must in fact be initiated by some opaque event and this activity is
> the first explicit. There may be multiple correlation sets on the
> activity, all initiate = yes
>
> process: createInstance=yes, correlation : initiate = rendezvous -
> there will be at least two activities with this, for the same
> correlation set. (all inbound ?). the process is a true rendezvous,
> where the correlation set information is known to several parties
and
> whose message arrives first is indeterminate - but once one has
> arrived, the other's message is routed to the same, already running
> process
>
> process: createInstance=yes, correlation : initiate = no - this is
> impossible, since the correlation set can't have been initiated
> previously, as there was no previously for this process.
>
> RULE: For an inbound activity with createInstance=no, there must be
> at least one correlation set with initiate=no to allow the message
to
> be routed to the appropriate process instance. There may be other
> correlation sets with yes or rendezvous:
>
> process: createInstance=no, correlation : initiate = yes - a new
> correlation set is created in an existing process - as in a
> "hand-over" of correlation sets (e.g. each message in a multi-step
> conversation has a message id of its own, but references the message
> id to which it is replying)
>
> process: createInstance=no, correlation : initiate = rendezvous- the
> normal first activity of a process. a sort of nested rendezvous, i
> think, where the entities that are trying to meet up are already
> using the same process. like raising an agenda topic in a committee
-
> once one person has raised it, any further contributions are linked
> into that item, though any of those contributions could have raised
> the subject if they had arrived first.
>
> process: createInstance=no, correlation : initiate = no- the normal
> use of a correlation set to tie together the elements of a
> conversation.
>
>
> I think the statement about the yes;yes and yes;rendezvous cases may
> be rules too (stopping in yes;rendezvous *before* the (all inbound?)
> bit - on second thoughts, I believe you could have outbound
> activities, or a mix.
>
> Peter
>
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: 16 June 2004 21:56
> To: Furniss, Peter; Alex Yiu
> Cc: wsbpel@lists.oasis-open.org; Yuzo Fujishima; Dieter Koenig1;
> Yaron Y. Goland; Nickolas Kavantzas
> Subject: RE: [wsbpel] Issue 37 - Proposal for vote
>
> I like your clarification on "the rule would seem to be just the
> first half of that sentence". I am afraid that listing all
> permutations would simply make it look like an arbitrary table
though
> -- hard to remember. Let us see if we can state the rules in a
> concise way per your suggestion.
>
>
> From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
> Sent: Wed 6/16/2004 5:15 AM
> To: Alex Yiu
> Cc: wsbpel@lists.oasis-open.org; Yuzo Fujishima; Satish Thatte;
> Dieter Koenig1; Yaron Y. Goland; Nickolas Kavantzas
> Subject: RE: [wsbpel] Issue 37 - Proposal for vote
>
>
> Once I'd got myself straight on start activities
> (createInstance="yes"),
> I understood. It might be worth
> including something brief on what the 6 possible combinations of
> createInstance (for the process) and initiate
> (for a correlation set) mean (createInstance="yes", initiate="no"
> would
> be illegal, if I've got it right). Doesn't the
> rule about non-start inbound activities needing at least one
> initiate="no" correlation set apply when there is a
> initiate="yes" as well ? (In fact, the rule would seem to be just
> the
> first half of that sentence).
>
> Presumably the multi-start example gets revised with this.
>
> Peter
>
> > -----Original Message-----
> > From: Alex Yiu [mailto:alex.yiu@oracle.com]
> > Sent: 15 June 2004 22:38
> > To: Alex Yiu
> > Cc: wsbpel@lists.oasis-open.org; Yuzo Fujishima; Satish
> > Thatte; Dieter Koenig1; Yaron Y. Goland; Nickolas Kavantzas
> > Subject: Re: [wsbpel] Issue 37 - Proposal for vote
> >
> >
> >
> > Uploaded the HTML file to www.oasis-open.org website.
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.p
> > hp/7281/Issue_37_Proposal_Draft.html
> >
> > Regards,
> > Alex Yiu
> >
> >
> > Alex Yiu wrote:
> >
> > >
> > > Hi, all,
> > >
> > > Here is the latest revised proposal for vote for Issue 37.
> Satish,
> > > Yaron, Dieter, Yuzo, Nick and I worked together on this
proposal.
> > >
> > > The "initiate" attribute becomes a tri-value switch. And,
> > the proposal
> > > provides details of the semantics of different cases.
> > >
> > > Thanks!
> > >
> > >
> > > Regards,
> > > Alex Yiu
> > >
> >
> >
> >
> > To unsubscribe from this mailing list (and be removed from
> > the roster of the OASIS TC), go to
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> > ave_workgroup.php.
> >
> >
>
>
>
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.
>
>
>
>
>
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]