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 - 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]