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] Attempt to Understand BPEL Multi-Start Behavior


I agree with the rules Yaron states and can't think of any others either.  

I disagree with Danny in that "the spec says is that the receive is no longer active" seems sufficient to specify instance behavior.  What else could we say without precluding some interesting cross instance case that someone might want to allow?

Satish

-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com] 
Sent: Thursday, October 23, 2003 5:47 PM
To: 'Danny van der Rijn'; wsbpel@lists.oasis-open.org
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]