[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, By correlation I mean the mechanism (some sort of correlationID) which allows you to "address them individually", as you say below, any time you want to interact again with a particular instance you created. Again, lacking such mechanism I have a hard time imagining a useful use case of indistinguishable multiple instances. Ugo > -----Original Message----- > From: Danny van der Rijn [mailto:dannyv@tibco.com] > Sent: Monday, April 19, 2004 1:38 PM > To: wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets > Mandatory? > > > ugo - > > i don't see these as necessarily correlated at all. unless > you're talking about the response being correlated with the > request, which i'm hoping that we are not requiring ourselves > to depend on correlation to do? > > danny > > ----- Original Message ----- > From: "Ugo Corda" <UCorda@SeeBeyond.com> > To: "Danny van der Rijn" <dannyv@tibco.com>; > <wsbpel@lists.oasis-open.org> > Sent: Monday, April 19, 2004 11:51 AM > 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/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. 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]