[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior
i'm thinking along the lines of: - once a BPEL engine receives a message that doesn't create an instance, how long should it wait for a some process to get to a <receive> before deciding to drop the incoming message. easily specifiable on the receive, but we seem to not want to do that, for some reason. - can a <receive> specify that it should be the ONLY recipient of a message, in cases where it could make sense to deliver to more than one process? - if there are 2 or more processes waiting on the same message, and it's an HTTP request/reply message, what happens? i might be able to come up with others, but at least you get the gist of my thinking. danny ----- Original Message ----- From: "Yaron Goland" <ygoland@bea.com> To: "'Danny van der Rijn'" <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org> Sent: Thursday, October 23, 2003 5:47 PM Subject: RE: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior > I tried to think through what requirements you could write regarding the > BPEL engine's message routing behavior that would allow for some meaningful > level of portability without unnecessarily limiting the BPEL engine > implementation's behavior. I am sorry to say I could only come up with two: > > A BPEL process instance MUST only be created if it is delivered a message > that matches the local address, transport, partner endpoint reference, > portType and operation of one of the BPEL process definition's > createInstance activities. > > A BPEL process instance MUST only receive messages that match the address, > transport, partner endpoint reference, portType, operation and correlation > set requested by a receive or pick that is active in the process instance. > > Note that the endpoint reference MAY be a 'match any' wildcard. > > Are there more? > > Yaron > > > -----Original Message----- > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > Sent: Wednesday, October 22, 2003 9:54 AM > > To: wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior > > > > > > satish - > > > > i'm not advocating legislating cross-instance behavior. i'm > > trying to point > > out that the spec doesn't legislate ANY engine behavior > > (except for the > > routing behavior that can be inferred from startInstance, > > correlation sets, > > and the like). so the behavior that i specified might be the > > completely > > valid choice of an implementor. in short, i'm saying that > > for question #2, > > all the spec says is that the receive is no longer active. > > and it stops > > there. > > > > while i may be beating a dead horse, i believe that i still > > see it moving > > out of the corner of my eye. > > > > danny > > > > ----- Original Message ----- > > From: "Satish Thatte" <satisht@microsoft.com> > > To: "Danny van der Rijn" <dannyv@tibco.com>; > > <wsbpel@lists.oasis-open.org> > > Sent: Tuesday, October 21, 2003 11:31 PM > > Subject: RE: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior > > > > > > Danny, > > > > While I understand your concern here, trying to legislate > > cross-instance > > behavior is a bad idea IMO because there is no end to the > > cases - and as you > > know many pub/sub delivery mechanisms take delivery to > > multiple (in this > > case service instance) destinations in their stride .. So I > > prefer to leave > > cross-instance behavior to the platform to determine. I > > expect different > > usage patterns will require different answers to many of > > those questions. > > > > Satish > > > > -----Original Message----- > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > Sent: Tuesday, October 21, 2003 4:06 PM > > To: wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior > > > > for the 2nd question, another possibility is that while the > > receive is no > > longer active (how could it be?) the engine could enforce that the > > correlation set can only exist in one instance, thereby not > > delivering the > > message to instance P1, but also not creating another > > instance. at such > > time as P1 completes, it might instantiate another instance > > and deliver it > > to that. > > > > not specifying any engine behavior leads us into messes like this.. > > > > ----- Original Message ----- > > From: "Yaron Goland" <ygoland@bea.com> > > To: "'Satish Thatte'" <satisht@microsoft.com> > > Cc: "'Ugo Corda'" <UCorda@SeeBeyond.com>; "'Eckenfels. Bernd'" > > <B.Eckenfels@seeburger.de>; <wsbpel@lists.oasis-open.org> > > Sent: Tuesday, October 21, 2003 3:33 PM > > Subject: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior > > > > > > > Satish, > > > I wanted to get your opinion on the following three questions: > > > > > > Question 1 - Is my description of multi-start activity > > behavior in BPEL as > > > given below accurate? > > > Question 2 - Are start activities on process instances > > perpetually active? > > > Question 3 - Are multi-start activities allowed to wait on the same > > > portType, operation and correlation set? > > > > > > Question 1 - Is my description of multi-start activity > > behavior in BPEL as > > > given below accurate? > > > > > > <process> > > > ... > > > <flow> > > > <receive partnerLink="P1" portType="A" createInstance="yes" > > > operation="foo" variable="A"> > > > <correlations><correlation set="c" > > initiate="yes"/></correlations> > > > </receive> > > > <receive partnerLink="P2" portType="A" createInstance="yes" > > > operation="bar" variable="B"> > > > <correlations><correlation set="c" > > initiate="yes"/></correlations> > > > </receive> > > > </flow> > > > </process> > > > > > > Time 0 - Message Mfoo arrives on operation foo. A new BPEL process > > instance > > > P1 is created. P1 initializes correlation set c using Mfoo. > > > > > > Time 1 - Message Mbar arrives on operation bar. > > > > > > A very careful reading of section of section 6.4 will pick out the > > sentence > > > "...When a message is received by such an activity, an > > instance of the > > > business process is created if it does not already > > exist..." The apparent > > > implication of this sentence is that rather than creating a > > new process > > > instance Mbar, because it matches correlation set c, will > > actually be > > routed > > > to instance P1. > > > > > > Although a naive reading of the BPEL specification would > > lead the reader > > to > > > believe that a bpws:correlationViolation fault should be > > thrown since the > > > second receive to which Mbar will be delivered explicitly tries to > > initiate > > > correlation set c which was already initiated at Time 0 in > > this case no > > > fault is thrown because any multi-start activities executed > > after the > > first > > > multi-start activity in a process instance will behave as > > if the initiate > > > attribute was set to No. > > > > > > Therefore the result is that at Time 1 Mbar will be delivered to the > > second > > > receive of process instance P1. > > > > > > Question 2 - Are start activities on process instances > > perpetually active? > > > > > > <process> > > > ... > > > <flow> > > > <receive partnerLink="P1" portType="A" createInstance="yes" > > > operation="foo" variable="A"> > > > <correlations><correlation set="c" > > initiate="yes"/></correlations> > > > </receive> > > > <wait../> <!-- Will wait for 10 hours--> > > > </flow> > > > </process> > > > > > > Imagine the following timeline: > > > > > > T0 - Message Mfoo arrives for operation foo causing the new process > > instance > > > P1 to be created, the message is passed to the receive and > > correlation set > > c > > > is initiated. > > > T1 - The receive activity completes > > > T2 - Message Mfoo2 arrives for operation foo and matches > > the correlation > > set > > > c. Process instance P1 is still active because the wait > > activity hasn't > > > expired yet. > > > > > > What happens to message Mfoo2? > > > > > > I can think of at least two likely outcomes: > > > #1 - A start activity can only be called once so > > effectively P1 > > has > > > no receive outstanding waiting for a message on operation foo with > > > correlation set c. Therefore a new process instance will be > > created to > > > handle Mfoo2. > > > #2 - A start activity is perpetually active > > therefore Mfoo2 will > > be > > > sent to P1 and the receive will be executed for a second time. > > > > > > Question 3 - Are multi-start activities allowed to wait on the same > > > portType, operation and correlation set? > > > > > > The following is a copy of my first example with the change that the > > > partnerLinks on the two start activities are identical. Section 11.4 > > > explicitly forbids the following but some of your comments > > made me think > > > that you thought this is legal if the activities involved > > are all start > > > activities. I wanted to get clarification - do you believe > > this example is > > > legal BPEL? > > > > > > <process> > > > ... > > > <flow> > > > <receive partnerLink="P" portType="A" createInstance="yes" > > > operation="foo" variable="A"> > > > <correlations><correlation set="c" > > initiate="yes"/></correlations> > > > </receive> > > > <receive partnerLink="P" portType="A" createInstance="yes" > > > operation="bar" variable="B"> > > > <correlations><correlation set="c" > > initiate="yes"/></correlations> > > > </receive> > > > </flow> > > > </process> > > > > > > Thanks, > > > Yaron > > > > > > > -----Original Message----- > > > > From: Satish Thatte [ mailto:satisht@microsoft.com > > > <mailto:satisht@microsoft.com> ] > > > > Sent: Monday, October 20, 2003 7:22 PM > > > > To: ygoland@bea.com > > > > Cc: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org > > > > Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set > > > > More Than > > > > Once > > > > > > > > > > > > The assumptions here in the context of the original > > > > discussion were that both receives use the same correlation > > > > set and hence this is a special case of the "multiple start > > > > activities" example. In which case the single instance will > > > > receive both identically correlated messages. All this is > > > > saying is that there is no requirement in the multiple start > > > > activities case to have two distinct portType/partnerLink > > > > attributes for the multiple receives. So in the case of a > > > > trade settlement example the buy-side and sell-side entities > > > > may use two different operations on the same portType. > > > > > > > > Does that help? > > > > > > > > Satish > > > > > > > > -----Original Message----- > > > > From: Yaron Goland [ mailto:ygoland@bea.com > > <mailto:ygoland@bea.com> ] > > > > Sent: Monday, October 20, 2003 5:10 PM > > > > To: Satish Thatte > > > > Cc: 'Ugo Corda'; 'Eckenfels. Bernd'; wsbpel@lists.oasis-open.org > > > > Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set > > > > More Than Once > > > > > > > > So if we have: > > > > <process> > > > > <flow> > > > > <receive portType="A" createInstance="yes" > > > > operation="foo" variable="A"/> > > > > <receive portType="A" createInstance="yes" > > > > operation="bar" variable="B"/> > > > > </flow> > > > > </process> > > > > > > > > then isn't it impossible to ever have a situation in which a > > > > single process instance receives messages on both receives? > > > > > > > > For example, if a message comes in for operation foo then a > > > > new instance will be created to handle it. If a message comes > > > > in for operation bar then a new and separate instance will be > > > > created. So we now have two separate instances. > > > > > > > > What's confusing me is your comment in the original example > > > > that: "You get one instance with the two messages in two > > variables." > > > > > > > > I'm having trouble seeing how we can have a single instance > > > > that received both messages. > > > > > > > > Thanks for taking the time to help clarify this for me, > > > > > > > > Yaron > > > > > > > > > -----Original Message----- > > > > > From: Satish Thatte [ mailto:satisht@microsoft.com > > > <mailto:satisht@microsoft.com> ] > > > > > Sent: Monday, October 20, 2003 4:43 PM > > > > > To: ygoland@bea.com > > > > > Cc: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org > > > > > Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set > > > > > More Than > > > > > Once > > > > > > > > > > > > > > > I fortunately didn't specify operations or message types, > > > > > just used the same port ;-) But you are right that this > > > > > would not work if the operations were the same. > > > > > > > > > > Satish > > > > > > > > > > -----Original Message----- > > > > > From: Yaron Goland [ mailto:ygoland@bea.com > > <mailto:ygoland@bea.com> ] > > > > > Sent: Monday, October 20, 2003 4:24 PM > > > > > To: Satish Thatte > > > > > Cc: 'Ugo Corda'; 'Eckenfels. Bernd'; wsbpel@lists.oasis-open.org > > > > > Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set > > > > > More Than Once > > > > > > > > > > I'm confused about this example: > > > > > > <process> > > > > > > <flow> > > > > > > <receive portTypeA initial="yes" variable=A/> > > > > > > <receive portTypeA initial="yes" variable=B/> > > > > > > </flow> > > > > > > ... > > > > > > </process> > > > > > > > > > > Section 11.4 states "A business process instance MUST NOT > > > > > simultaneously enable two or more receive activities for the > > > > > same partnerLink, portType, operation and correlation > > > > > set(s)." I am not aware of any exception made for initial > > > > > activities. Therefore wouldn't the previous example be > > > > > illegal assuming that the operation (which isn't specified) > > > > > is the same for both receives? I'm having trouble > > > > > understanding how a single message could, as you state > > > > > "...get one instance with the two messages in two variables." > > > > > > > > > > I appreciate any help you can give in clarifying the issue, > > > > > > > > > > Thanks, > > > > > > > > > > Yaron > > > > > > > > > > > -----Original Message----- > > > > > > From: Satish Thatte [ mailto:satisht@microsoft.com > > > <mailto:satisht@microsoft.com> ] > > > > > > Sent: Thursday, October 16, 2003 9:02 PM > > > > > > To: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org > > > > > > Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set > > > > > > More Than > > > > > > Once > > > > > > > > > > > > > > > > > > The specification does not prevent something like > > > > > > <process> > > > > > > <flow> > > > > > > <receive portTypeA initial="yes" variable=A/> > > > > > > <receive portTypeA initial="yes" variable=B/> > > > > > > </flow> > > > > > > ... > > > > > > </process> > > > > > > > > > > > > You get one instance with the two messages in two variables. > > > > > > It also does not currently prevent > > > > > > > > > > > > <process> > > > > > > <flow> > > > > > > <receive portTypeA initial="yes" variable=A/> > > > > > > <receive portTypeA initial="yes" variable=A/> > > > > > > </flow> > > > > > > ... > > > > > > </process> > > > > > > > > > > > > Although one of the two messages will be lost to the process > > > > > > instance which receives them. I think it is unnecessary to > > > > > > eliminate this by restriction. There are many useless things > > > > > > people can do with a notation as powerful as BPEL and it is > > > > > > not possible to eliminate all of them by making more rules. > > > > > > > > > > > > Satish > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ugo Corda [ mailto:UCorda@SeeBeyond.com > > > <mailto:UCorda@SeeBeyond.com> ] > > > > > > Sent: Thursday, October 16, 2003 7:05 PM > > > > > > To: Eckenfels. Bernd; wsbpel@lists.oasis-open.org > > > > > > Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set > > > > > > More Than Once > > > > > > > > > > > > Yes, what is an implementation supposed to do in the last two > > > > > > cases below? It does not seem to make sense to create a > > > > > > second instance with the same correlation value, so it's not > > > > > > possible to throw a fault on a second instance. Should a > > > > > > fault be thrown on the first instance? > > > > > > > > > > > > Ugo > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Eckenfels. Bernd [ mailto:B.Eckenfels@seeburger.de > > > <mailto:B.Eckenfels@seeburger.de> ] > > > > > > > Sent: Thursday, October 16, 2003 4:30 AM > > > > > > > To: wsbpel@lists.oasis-open.org > > > > > > > Subject: RE: [wsbpel] Issue - 37 - Initiating > > Correlation Set > > > > > > > More Than > > > > > > > Once > > > > > > > > > > > > > > > > > > > > > if you receive 2 messages with the same correlation key to > > > > > > > the same port, the first one will create a new instance, the > > > > > > > second one is the problem. On the other hand, it will be > > > > > > > allowed to receive a message on a different port, with the > > > > > > > same correlationb key. > > > > > > > > > > > > > > I am refering to the auction example: > > <process><flow><receive > > > > > > > portA initial="yes"/><receive portB initial="yes" /></flow> > > > > > > > > > > > > > > in this example > > > > > > > > > > > > > > message cor=a port=a > > > > > > > message cor=a port=b > > > > > > > > > > > > > > is allowed, also: > > > > > > > > > > > > > > message cor=a port=a > > > > > > > message cor=a port=b > > > > > > > > > > > > > > but not: > > > > > > > > > > > > > > message cor=a port=a > > > > > > > message cor=a port=a > > > > > > > > > > > > > > or > > > > > > > > > > > > > > message cor=a port=b > > > > > > > message cor=a port=b > > > > > > > > > > > > > > right? > > > > > > > > > > > > > > Mit freundlichen Grüßen > > > > > > > Bernd Eckenfels > > > > > > > Chief Architect > > > > > > > -- > > > > > > > SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany > > > > > > > Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256 > > > > > > > mailto:b.eckenfels@seeburger.de > > mailto:b.eckenfels@seeburger.de> - > > > http://www.seeburger.de <http://www.seeburger.de> > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Satish Thatte [ mailto:satisht@microsoft.com > > > <mailto:satisht@microsoft.com> ] > > > > > > > Sent: Tuesday, October 14, 2003 11:54 PM > > > > > > > To: Eckenfels. Bernd; wsbpel@lists.oasis-open.org > > > > > > > Subject: RE: [wsbpel] Issue - 37 - Initiating > > Correlation Set > > > > > > > More Than > > > > > > > Once > > > > > > > > > > > > > > > > > > > > > A createInstance receive activity cannot be in a loop since > > > > > > > second iteration on it would not be an initial > > activity. How > > > > > > > would it receive a second message? > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Eckenfels. Bernd [ mailto:B.Eckenfels@seeburger.de > > > <mailto:B.Eckenfels@seeburger.de> ] > > > > > > > Sent: Tuesday, October 14, 2003 8:48 AM > > > > > > > To: wsbpel@lists.oasis-open.org > > > > > > > Subject: RE: [wsbpel] Issue - 37 - Initiating > > Correlation Set > > > > > > > More Than Once > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > B) References to already initialized correlation set are > > > > > > > treated as if initiate="no" > > > > > > > > regardless of the specified value. > > > > > > > > -- Only for start activities. > > > > > > > > > > > > > > If we have 2 start activities with "initiate=Yes" and on the > > > > > > > same correlation set, then the first activity will add a new > > > > > > > correlation entry, and the second one is allowed to receive > > > > > > > in the same correlation. But neigter the initial receive nor > > > > > > > the second receive is allowed to receive another message for > > > > > > > that correlation set? No? > > > > > > > > > > > > > > Mit freundlichen Grüßen > > > > > > > Bernd Eckenfels > > > > > > > Chief Architect > > > > > > > -- > > > > > > > SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany > > > > > > > Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256 > > > > > > > mailto:b.eckenfels@seeburger.de > > mailto:b.eckenfels@seeburger.de> - > > > http://www.seeburger.de <http://www.seeburger.de> > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Yuzo Fujishima [ mailto:fujishima@bc.jp.nec.com > > > <mailto:fujishima@bc.jp.nec.com> ] > > > > > > > Sent: Tuesday, October 14, 2003 8:22 AM > > > > > > > To: Satish Thatte; wsbpel@lists.oasis-open.org > > > > > > > Subject: Re: [wsbpel] Issue - 37 - Initiating > > Correlation Set > > > > > > > More Than > > > > > > > Once > > > > > > > > > > > > > > > > > > > > > Satish, > > > > > > > > > > > > > > Thank you for the comment. > > > > > > > > > > > > > > As far as I understand, your opinion is very close > > to, if not > > > > > > > the same as, my proposal > > > > > > > (please note the last line): > > > > > > > > > > > > > > B) References to already initialized correlation set are > > > > > > > treated as if initiate="no" > > > > > > > regardless of the specified value. > > > > > > > -- Only for start activities. > > > > > > > > > > > > > > Below is my another try to capture the idea: > > > > > > > > > > > > > > B') It is allowed to define a process definition such that > > > > > > > multiple start activities > > > > > > > initiate the same correlation set(s). In such case, only the > > > > > > > start activity that actually > > > > > > > created the process instance initiates the correlation > > > > > > > set(s). For the remaining > > > > > > > start activities, the correaltion set(s) is (are) treated as > > > > > > > if initiate="no". > > > > > > > For all other cases, a bpws:correlationViolation fault is > > > > > > > thrown if an activity tries > > > > > > > to initiate an already-initiated correlation set. > > > > > > > > > > > > > > What do you think? > > > > > > > (I welcome rephrasing.) > > > > > > > > > > > > > > Yuzo Fujishima > > > > > > > NEC Corporation > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Satish Thatte" <satisht@microsoft.com> > > > > > > > To: "Yuzo Fujishima" <fujishima@bc.jp.nec.com>; > > > > > > > <wsbpel@lists.oasis-open.org> > > > > > > > Sent: Monday, October 13, 2003 1:06 PM > > > > > > > Subject: RE: [wsbpel] Issue - 37 - Initiating > > Correlation Set > > > > > > > More Than Once > > > > > > > > > > > > > > > > > > > > > Yuzo, > > > > > > > > > > > > > > After thinking about this again, my opinion is that > > we should > > > > > > > stick with the intent of the original authors. I > > recognize the > > > > > > > similarity with the multiple start activities but there is > > > > > > > also a crucial difference. In the case of multiple start > > > > > > > activities, the > > > > > > > multiple initiations of the correlation are > > unavoidable since > > > > > > > there is no other way to achieve the rendezvous of > > the multiple > > > > > > > non-deterministically ordered activation messages. In the > > > > > > > cases where instance creation is not involved, there must > > > > > > already be a > > > > > > > known correlation for the message to be delivered to the > > > > > > > instance and hence it is not a case of > > > > > > > rendezvous-by-correlation. I cannot > > > > > > > think of real examples where multiple initiations of a > > > > > > > correlation set would be meaningful other than in the > > > > > multiple start > > > > > > > activities case. I therefore have to agree with Yaron that > > > > > > > this is most likely to arise as a process design error. > > > > > > > > > > > > > > Satish > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > From: Yuzo Fujishima [ mailto:fujishima@bc.jp.nec.com > > > <mailto:fujishima@bc.jp.nec.com> ] > > > > > > > Sent: Sat 9/27/2003 2:02 AM > > > > > > > To: wsbpel@lists.oasis-open.org > > > > > > > Subject: Re: [wsbpel] Issue - 37 - Initiating > > Correlation Set > > > > > > > More Than Once > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Here is my summary of our discussion on Issue 37 at the last > > > > > > > F2F meeting: > > > > > > > > > > > > > > Issue 37: What will happen if a correlation set is initiated > > > > > > > more than once > > > > > > > during the lifetime of the > > corresponding scope? > > > > > > > > > > > > > > The intent of the original authors was (Satish) > > > > > > > A) bpws:correlationViolation fault is always thrown > > > > > > > -- for executable processes and the situation > > is marked > > > > > > > as "undefined" > > > > > > > for abstract processes. > > > > > > > > > > > > > > My comment was: > > > > > > > A is somewhat incompatible with the interpreation of the > > > > > > > Mulitple Start Activities > > > > > > > example described in the specification document. > > > > > > > > > > > > > > My proposal was: > > > > > > > B) References to already initialized correlation set are > > > > > > > treated as if initiate="no" > > > > > > > regardless of the specified value. > > > > > > > -- Only for start activities. (This line was > > added today.) > > > > > > > > > > > > > > Danny's proposal/comment: (Please correct if wrong) > > > > > > > C) We may introduce an attribute value > > initiate="yesIfNotYet" > > > > > > > or the like. > > > > > > > > > > > > > > Somebody's proposal/comment (Sorry I forgot who)(Please > > > > > > > correct if wrong) > > > > > > > D) Remove initiate attribute completely. > > Correlation sets are > > > > > > > initialized > > > > > > > at the first use. > > > > > > > > > > > > > > Yaron's comment: (Please correct if wrong) > > > > > > > Tolerating multiple initialization may raise the > > > > > > > possibility of the user's > > > > > > > making inadvertent mistakes. > > > > > > > > > > > > > > Yuzo Fujishima > > > > > > > NEC Corporation > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > <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 > > > <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 > > > <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 > > > <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 > > > <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 > > > <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 > > > <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_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_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_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_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]