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] 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:
Message
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.
>
>




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