[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 37 - Proposal for vote
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]