[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?
Even if we rule out singletons, we should still clarify what happens when multiple instances exist at the same time as a consequence of multiple messages being sent to the initial <receive>. If no correlationSet exists to distinguish the various instances, what happens to successive messages (non instantiating) sent to the instances? Do all the instances get a copy the message? Is it implementation-defined? Ugo > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Friday, August 13, 2004 11:00 AM > To: Ugo Corda > Cc: Ron Ten-Hove; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 120 - What are the semantics > when an initial <receive> has no correlation set? > > > 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_wor > >> kgroup.php. > >> > >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]