[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?
Danny, I think you are really arguing in favor of multiple parallel instances with some form of engine-managed correlation, as you describe in your cases 1,2,3 below (this would correspond to issue 96). I have no problem with that. My singleton discussion was rather about cases where any correlation mechanism is completely absent. Ugo > -----Original Message----- > From: Danny van der Rijn [mailto:dannyv@tibco.com] > Sent: Monday, April 19, 2004 10:20 AM > To: Ugo Corda; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets > Mandatory? > > > marked with DV2 > > ----- Original Message ----- > From: "Ugo Corda" <UCorda@SeeBeyond.com> > To: "Danny van der Rijn" <dannyv@tibco.com>; > <wsbpel@lists.oasis-open.org> > Sent: Friday, April 16, 2004 4:44 PM > Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets > Mandatory? > > > Responses below again. > > > -----Original Message----- > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > Sent: Friday, April 16, 2004 4:09 PM > > To: wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets > > Mandatory? > > > > > > responses inline, marked with <DV> > > > > ----- Original Message ----- > > From: "Ugo Corda" <UCorda@SeeBeyond.com> > > To: "Danny van der Rijn" <dannyv@tibco.com>; > > <wsbpel@lists.oasis-open.org> > > Sent: Friday, April 16, 2004 3:56 PM > > Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets > > Mandatory? > > > > > > Danny, > > Please see my responses below. > > > > Ugo > > > > > -----Original Message----- > > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > > Sent: Friday, April 16, 2004 3:41 PM > > > To: wsbpel@lists.oasis-open.org > > > Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets > > > Mandatory? > > > > > > > > > i'm concerned that such a difference of opinion exists on > > such a basic > > > part of the spec. i think that that largely derives from > the fact > > > that the spec says little or nothing about how different process > > > instance relate to each other. > > > > > > > I agree. > > > > > my understanding is that in the case Ugo describes, a different > > > instance is created for each incoming message to the initial > > > instance-starter that has no correlations. > > > > > > > I cannot think of a useful use case that would justify the > creation of > > all these undistinguishable instances. It also would imply > that each > > individual subsequent message (not directed to the start activity) > > would have to be broadcast to all instances (since there is > no way to > > distinguish them) and, again, I have trouble thinking of a use case > > where that would make sense. > > > > <DV> i can think of many such cases. maciej already > pointed one out - > > make me a pizza. another one might be "fire off the build > process for > > my product." in either case, *if* there are subsequent messages, > > which isn't always the case, then the process will come up with a > > correlation ID to send back to the initiator. the case of > "subsequent > > message (not directed to the start activity) would have to be > > broadcast to all instances" is what i think this issue was about in > > the first place. non-initial receives are > > *required* to have correlations, precluding any routing being > > done by address, say. which i also think is wrong. </DV> > > > > <UC> The concept of having separate instances makes sense if > I want to address them individually after they are initiated > (and in order to do that I need some correlation ID). If I > don't need to do that, why would I need to care about > instances? If I say "make me a pizza", I then want to know > which one is my pizza among the many coming out, so I need a > correlation ID. So, again, in my mind it only makes sense to > have multiple instances with correlation sets or singletons > with no correlation sets</UC> > > <DV2> So you want to address them individually. Why does > that addressing > *have* to come from the initial request? It could come in a > response (1), it could just be a request/response (2) . Or > it might not need to be addressable at all (3, possibly a > special case of (2)). an example of each of these: > > 1) addressable element comes in the response: i'd like to > start a long-running conversation. please assign me an ID so > we can continue to have the conversation. > > 2) please return the current inventory of the part number > referenced in the request > > 3) please return the value of your system clock > > 2) and 3) look a lot like event handlers, but i don't see a > requirement that they be written in the context of a > different process. > > > > > > When there are no existing instances, the first message > > directed to > > > > that activity would instruct the BPEL processor to > > instantiate one. > > > > Once that happens, the flow of execution would go past > that start > > > > activity, and any additional incoming message directed to > > that same > > > > activity would just get dropped to the floor because > the targeted > > > > activity is not active and ready to get it > > > > > > it wasn't "active and ready" before that message was > recieved (if i > > > understand your interpretation correctly). > > > > > > > In a way it was. Think about the correlation case. The start > > activities for all the existing instances are not active > any more (the > > flow of execution has gone past them), but we should think of those > > same start activities in the process "template" as being active and > > ready in case messages are directed to them with new correlation > > values that do not belong to any existing instances. > > > > <DV> exactly my point. so why wouldn't the active and ready start > > activity in the non-correlation case start another > activity? it seems > > to me that in your argument, one case has the "active and ready" > > activity being in the "template" (correlation sets), while > the other > > has it in the instantiated process (non-correlation) and therefore > > another instance isn't started. </DV> > > <UC> The argument I was making is that, in the case a > correlation set exists, I have to distinguish between start > activities in existing instances and start activities in > future instances (with correlation values different than > existing instances). Only the latter are active and ready. In > the case of a singleton, there is either one existing > instance or no instance at all. So, adapting the previous > rule to this special case, if there is an existing instance > the start activity is inactive (and there will be no new > instances until that existing instance terminates - a message > sent to that start activity would behave like a message > having a correlation value identical to an existing instance: > it would be dropped). If there are no existing instances, the > start activity is active. </UC> > > <DV2> this argument sounds a bit circular to me. but in any > case, i think we've proved that either interpretation is > defensible. now we have to figure out which one is desired, > and make the spec reflect that. > > my preference is to allow the parallel instances, since yaron > and others have shown how singletons can be implemented using > parallel instances, but i don't think it's possible to allow > parallel instances if the singleton interpretation is used. > i'll open an issue. <DV2> > > > > > > > (and the BPEL engine would have no reason to > > > > create a new instance, since there is no correlation set > > that would > > > > distinguish it from the already existing instance). > > > > > > you're saying that every <process> that has a starter with no > > > correlations MUST be a singleton. that certainly isn't my > > > interpretation. however, my interpretation doesn't allow for a > > > process to say that it's a singleton. > > > > > > it seems to me that in the current spec, whether a process is a > > > singleton or not is completely implementation defined. so > > we either > > > need to pin it down in the spec on way or another, or point > > out that > > > it's implementation-specific. > > > > > > danny > > > > > > ----- Original Message ----- > > > From: "Ugo Corda" <UCorda@SeeBeyond.com> > > > To: <ygoland@bea.com> > > > Cc: <wsbpel@lists.oasis-open.org> > > > Sent: Friday, April 16, 2004 2:36 PM > > > Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets > > > Mandatory? > > > > > > > > > I can also think of how the single start activity would > > work even in > > > cases where it does not have restricted access. > > > > > > When there are no existing instances, the first message > directed to > > > that activity would instruct the BPEL processor to > instantiate one. > > > Once that happens, the flow of execution would go past that start > > > activity, and any additional incoming message directed to > that same > > > activity would just get dropped to the floor because the targeted > > > activity is not active and ready to get it (and the BPEL > > engine would > > > have no reason to create a new instance, since there is no > > > correlation set that would distinguish it from the > already existing > > > instance). > > > > > > Ugo > > > > > > > -----Original Message----- > > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > > Sent: Friday, April 16, 2004 2:21 PM > > > > To: Ugo Corda > > > > Cc: wsbpel@lists.oasis-open.org > > > > Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets > > > > Mandatory? > > > > > > > > > > > > Far from there being anything wrong with the case you > > > describe, it is, > > > > in fact, quite common and even has a name - a singleton service. > > > > > > > > But couldn't one trivially implement a singleton service by > > > creating a > > > > BPEL with a single start activity which is access > > restricted so that > > > > only the admin can call it? The admin would then call the start > > > > activity exactly one time. That would guarantee that > > there was only > > > > one instance of the service. > > > > > > > > I admit that it would be nice to have a way to mark a > > service as a > > > > 'singleton' but given that there is a work around I'm not > > sure it's > > > > worth providing a dedicated short cut. > > > > > > > > Yaron > > > > > > > > Ugo Corda wrote: > > > > > > > > > > > > > > Hmm, this requirement for correlation sets sounds > > > surprising to me > > > > > too. I would have thought that, when a process is instantiated > > > > that does not > > > > > have a correlation set defined, a single instance of that > > > > process would > > > > > exist. All messages would be sent to that single > > instance. No new > > > > > instances would be created until that existing instance > > > > terminates. I > > > > > don't fully understand what would be wrong with the > > > scenario I just > > > > > described. > > > > > > > > > > Ugo > > > > > > > > > > -----Original Message----- > > > > > *From:* ws-bpel issues list editor > > > > > [mailto:peter.furniss@choreology.com] > > > > > *Sent:* Thursday, April 15, 2004 10:58 AM > > > > > *To:* wsbpel@lists.oasis-open.org > > > > > *Subject:* [wsbpel] Issue - 118 - When are > Correlation Sets > > > > > Mandatory? > > > > > > > > > > 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 - 118 - When are Correlation Sets Mandatory? > > > > > > > > > > *Status:* open > > > > > *Categories:* Correlation > > > > > *Date added:* 15 Apr 2004 > > > > > *Submitter:* Yaron Y. Goland <mailto:ygoland@bea.com> > > > > > *Date submitted:* 15 April 2004 > > > > > *Document:* BPEL Specification > > > > > *Description:* It wasn't until Satish explicitly > > > > pointed it out to > > > > > me that I finally understood that all Picks and > > > > Receives MUST have > > > > > at least one correlation set defined on them with > > > > "initiate = 'no'" > > > > > unless the pick/receive is a start activity. I had > > > > always assumed > > > > > that the system was allowed to implicitly route > > > > messages based on > > > > > URL but that is in fact wrong. All routing criteria > > > > MUST be explicit > > > > > and MUST be specified by a correlation set. This also > > > > means that it > > > > > is always illegal to have a pick or receive which does > > > > not have at > > > > > least one correlation set on it. > > > > > > > > > > Normative Change - The schemas for pick and receive > > > > make correlation > > > > > sets optional. That would appear to be wrong. > > > > > > > > > > Also, I'm unclear about what assumptions we make > > > > regarding invoke, > > > > > specifically, is there a requirement to have a > > correlation set > > > > > defined on pattern="in" on an invoke? This is kind > > of a tricky > > > > > issue. If a synchronous transport is being used then > > > > there may not > > > > > be any explicit information available to mark the > > response for > > > > > correlation purposes. In that case do we allow the > > > > correlation set > > > > > for the response to be left off or do we require > > > > programmers to use > > > > > issue 96 : Engine-managed correlation sets <#Issue96>? > > > > > > > > > > Also note, that the WSDL 1.1 spec quite clearly > states that > > > > > request/responses do not have to be sent over > > > > synchronous transports > > > > > so there may be values we could use for correlation > > > > sets. In other > > > > > words, the situation is inconsistent. In some cases a > > > > > request/response uses a synchronous transport and in > > > > other cases it > > > > > could be using an asynchronous transport with some > > > message based > > > > > correlation. Do we want to distinguish these cases or > > > > do we want to > > > > > just say that we presume that any time a > > > > request/response pattern is > > > > > used there is some correlation mechanism implicitly > > > known to the > > > > > engine and therefore correlation sets are always > > > optional on the > > > > > incoming message? Reply has the same issue as responses > > > > on invokes. > > > > > *Changes:* 15 Apr 2004 - new issue > > > > > > > > > > To comment on this issue, please follow-up to this > > > > announcement on > > > > > the 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 - 118 - > > > > [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_work > > > > > group.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/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/le > ave_workgr > oup.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/le ave_workgr oup.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_workgr oup.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_workgr oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]