[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 120 - What are the semantics when an initial<receive> has no correlation set?
Section 6.5: "If exactly one start activity is expected to instantiate the process, the use of correlation sets is unconstrained. This includes a pick with multiple onMessage branches; each such branch can use different correlation sets or no correlation sets." 118 dealt primarily with non-start activities. Thanks, Yaron Danny van der Rijn wrote: > > > yet according to issue 118, from which this issue sprang, it is illegal > to have a receive that doesn't have a correlation set. > > Yaron Y. Goland wrote: > > > It occurs to me that we can break this problem down a little more. > > > > One can trivially imagine a web service that consists of exactly one > > request/response pair that receives a message, processes it, sends a > > response and exits. Such a webservice would have no need to use > > correlation sets. Therefore I think we can be sure that at a minimum > > we want to make it possible to define a BPEL that has a single start > > activity with no correlation set that doesn't create a singleton. > > > > What this argues to me is that the default interpretation of a BPEL > > with a start activity with no correlation set is that it is not a > > singleton. > > > > Therefore what 120 really should be about is - do we want to > > intentionally add an attribute or other mechanism to specify that a > > BPEL process is intended to be a singleton? > > > > We already know we can simulate a singleton in BPEL by having an > > instance with a start activity that is only known to the deployment > > environment and then having all subsequent messages sent to the single > > BPEL instance. But I readily admit that this is a less than clean > > solution. It is best when possible to directly express one's semantics. > > > > So I think we can then rephrase the issue once again to - Is it worth > > defining explicit singleton behavior in BPEL 2.0 (or whatever we call > > it)? > > > > To which, given our other priorities, I think the answer is no. But I > > realize that my answer is just a matter of opinion. > > > > Just my two cents, > > > > Yaron > > > > Ugo Corda wrote: > > > >> > >> I think the term "semantics" was used here primarily to refer to the > >> expected behavior in case a second message is sent to the same > >> <receive> at the time an instance is already active (see Issue 118 > >> discussions). Should the second message be understood as creating a > >> new instance, or should it be seen as a message sent to a singleton > >> instance (and therefore dropped since the corresponding <receive> is > >> not active at that time)? As I remember from the issue 118 > >> discussions, use cases can be made for both interpretations. > >> > >> Ugo > >> > >> -----Original Message----- > >> *From:* Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] > >> *Sent:* Thursday, August 12, 2004 11:16 AM > >> *To:* wsbpel@lists.oasis-open.org > >> *Subject:* Re: [wsbpel] Issue - 120 - What are the semantics > when an > >> initial <receive> has no correlation set? > >> > >> It seems to me that we can't actually read too much into the fact > >> that an initiating <receive> activity doesn't initiate a > correlation > >> set at the same time. Two possibilities come to mind: > >> > >> * The process is actually very simple, and doesn't need > >> correlation (ie, it has no other <receive> activities). > >> * The process initiates the correlation set in a later <invoke> > >> activity. > >> So it seems that it would be inappropriate to infer any special > >> semantics to the <receive> in question. > >> > >> -Ron > >> > >> ws-bpel issues list editor wrote: > >> > >>> This issue has been added to the wsbpel issue list. The issues > >>> list is posted as a Technical Committee document to the OASIS > >>> WSBPEL TC pages > >>> <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a regular > >>> basis. The current edition, as a TC document, is the most recent > >>> document with the title in the "Issues" folder of the WSBPEL TC > >>> document list > >>> > <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> > >>> - the next posting will include this issue. The list editor's > >>> working copy, which will normally include an issue when it is > >>> announced, is available at this constant URL > >>> <http://www.choreology.com/external/WS_BPEL_issues_list.html>. > >>> > >>> > >>> Issue - 120 - What are the semantics when an initial <receive> > >>> has no correlation set? > >>> > >>> *Status:* open > >>> *Categories:* Correlation <#category_correlation> > >>> *Date added:* 19 Apr 2004 > >>> *Submitter:* Danny van der Rijn <mailto:dannyv@tibco.com> > >>> *Date submitted:* 19 April 2004 > >>> *Description:* when an initial <receive> has no correlation set > >>> should the instance be singleton, or be allowed to have multiple > >>> instances outstanding in parallel? > >>> *Changes:* 19 Apr 2004 - new issue > >>> > >>> To comment on this issue, please follow-up to this announcement on > >>> the wsbpel@lists.oasis-open.org > >>> <mailto:wsbpel@lists.oasis-open.org> list (replying to this > >>> message should automatically send your message to that list), or > >>> ensure the subject line as you send it *starts* "Issue - 120 - > >>> [anything]" or is a reply to such a message. > >>> > >>> To add a new issue, see the issues procedures document (but the > >>> address for new issue submission is the sender of this > >>> announcement). > >>> > >>> 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. > > > > > > > > > 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]