OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote


I think I get this -- just trying to poke around to see what might break
;-)  Do we actually say that initiate="no" is disallowed when
createInstance="yes"?  Couldn't find any such statement. 


 

-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com] 
Sent: Monday, November 01, 2004 7:42 AM
To: Vinkesh.Mehta@commerceone.com
Cc: Satish Thatte; curbera@us.ibm.com; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote

Vinky,
 
Correct, although I want to reiterate that I do not mean to make an
argument for a "feature" allowing activities preceding the
createInstance activity. That feature is the subject of issue 82. The
scope of 168 is the create-instance mechanism and process evaluation
semantics. I struck the restriction from 6.4 and 11.4 because it was no
longer required to explain the process of instance creation and because
it /suggested/ a special treatment for createInstance activities that
was inconsistent with my proposal. While my inclination would be to do
without the restriction, I would not be opposed to reinstating it using
language that either asserts the restriction without explanation or
explains the restriction in some other way (one way that comes to mind
is the removal of the createInstance attribute). 

This may seem like nitpicking, but my goal is to have a clean separation
between "evaluation semantics"--how the process is evaluated for each
instance--and the instance creation mechanism. The proposal to 168 makes
it possible to explain how a process /instance/ is evaluated without
mentioning the "createInstance" attribute. Essentially, I'm arguing that
the mechanism of instance creation should be exogenous to the core BPEL
model (lest we let in an unruly elephant).

-maciej


On Sun, 2004-10-31 at 10:23, Vinkesh.Mehta@commerceone.com wrote:
> Maciej, 
> 
> I think I now understand. The actual processing of the
createInstance='yes' message can occur anywhere in the BPEL process. It
could be the first <activity>. Or you could potentially execute your
complete BPEL process before you ever get to processing the
createInstance='yes' receive. 
> 
> So you could even define a valid process that executes successfully
but never reaches the <receive> to consume/dequeue this message. The
"elephant" will have to cleanup these "partially-processed" messages
from the queue when the process instance completes. 
> 
> I think this feature does allow creation of some new kinds of flow
semantics. And if this is the semantics that gets approved then it
should be explained more explicitly. Because intuitively (at least for
me) the readers will link createInstance='yes' receive activity as
something that should only occur at the beginning of a process. 
> 
> At this time we do not have a need for this feature. But using this
semantics makes the validation and execution simpler. 
> 
> regards,
> -Vinky
>  
> 
> -----Original Message-----
> From: Maciej Szefler [mailto:mbs@fivesight.com]
> Sent: Friday, October 29, 2004 7:50 PM
> To: Satish Thatte
> Cc: Francisco Curbera; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote
> 
> 
> Satish,
> In the process, "r2" is the createInstance activity. r2 expects an
> invocation on operation "z". "invoke bpel.z()" in this trace
represents
> the partner making just such an invocation on the BPEL process. 
> 
> I'm not sure what you mean by private invocation: this is a normal
> "partner invokes BPEL process" scenario.
> 
> As for i1 "occurring" before "r2", this was the point of the exercise:

> the /message/ msg#1 from our partner (when our partner does "invoke
> bpel.z()") /occurs/ (is sent) before any activities are /activated/
> (i.e. "invoke bpel.z()" / msg#1 /occurs/ before "i1"). This is because
> there is no process instance to speak of until after msg#1 is sent!
> However, the message (msg#1) is only /consumed/ when "r2" is
/activated/
> and "r2" is /activated/ after "i1" is /activated/. This is because
> activation is determined by the structure of the process and our
process
> states that "i1" precedes "r2" in the <sequence>. 
> 
> The summary of the time-line (some steps are omitted):
> 1) Partner wants to invoke z() on the BPEL process, sends msg#1
> 2) The "elephant" gets the msg#1 from partner
> 3) A new BPEL process instance is created because the "elephant" knows
> that a message on z() is used to create new instances (elephant
analyzed
> the BPEL process definition).
> 4) i1 is activated ("literal" is sent to partner and msg#3" is
received
> as the response)
> 5) r2 is activated (finally /consuming/ msg#1)
> 
> I hope that is clear enough. The other way of looking at this is in
> terms of communication queues joining the two partners. Process
instance
> creation can be thought of as being triggered by an /enqueue/
operation
> while <receive>s perform a /dequeue/ operation:
> 1) partner: plink1.tobpel.enqueue(msg#1)
> 2) BPEL: new instance is created (triggered by (1))
> 3) BPEL: i1 is activated...
>    BPEL: plink1.topartner.enqueue(literal)
>    partner: plink1.topartner.dequeue(): literal
>    partner: plink1.tobpel.enqueue(msg#3)
>    BPEL: plink1.tobpel.dequeue(): msg#3
> 4) BPEL: r2 is activated
>    BPEL: plink1.tobpel.dequeue(): msg#1
> 
> Hope that makes sense: I'm running out of ways of phrasing it.
> -maciej
> 
> 
> On Fri, 2004-10-29 at 15:58, Satish Thatte wrote:
> > I am confused by invoke bpel.z() -- is this some private activation
> > notion?  How did you get a trace in which i1 occurred before the
message
> > for r2 was processed?
> > 
> > -----Original Message-----
> > From: Maciej Szefler [mailto:mbs@fivesight.com] 
> > Sent: Wednesday, October 27, 2004 3:46 PM
> > To: Satish Thatte
> > Cc: Francisco Curbera; wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote
> > 
> > Satish,
> > 
> > I'm not exactly what you mean by protocol paradox, but I'll give it
a
> > go. The case you alluded to, with one partner and the following
process:
> > 
> > <sequence name="s1" >
> > <assign tovar="k"> litral </>
> > 
> > <invoke name="i1" plink="plink1" op="x" inVar="k" outVar="a" >
> >   <correlation cset="foo" initiate="yes" pattern="in"/>
> > </invoke>
> > 
> > <receive name="r1" plink="plink1" op="y" inVar="b">
> >   <correlation cset="foo" initiate="no" />
> > </receive>
> > 
> > <receive name="r2" var="c" plink="plink1" op="z"
createinstance="yes">
> >    <correlation initiate="yes" cset="bar" />
> > </receive>
> > 
> > </sequence>
> > 
> > would exhibit the following trace:
> > 
> > PARTNER                      BPEL PROCESS
> > ---------------------------------------------------------------
> >  
> >  Conversation#1
> > /
> > .
> > .
> > .
> > |
> > > invoke bpel.z()
> > | -------------msg#1--------> * new process 
> > |                           > seq s1
> > |                           > assign
> > |   Conversation#2          |  k=literal 
> > |  /                        < assign
> > |                           > invoke "i1" 
> > |  *  <------literal------- |
> > |  |                        |
> > |  | ----------msg#3------> |
> > |  |                        |  a := msg#3
> > |  |                        |  foo := {msg#3}
> > |  |                        < invoke "i1"
> > |  |                        |
> > |  |                        > receive "r1" 
> > |  > invoke bpel.y()        |
> > |  | ----------msg#4------> |
> > |  |                        |  b :=  msg#4
> > |  < invoke bpel.y()        < receive "r1"
> > |  |                        > receive "r2" (** CREATE INSTANCE **)
> > |  |                        |  
> > |  |                        |  c := msg#1
> > |  |                        |  bar := {msg#1}
> > |  .                        < receive "r2"
> > |  .                        < sequence s1
> > |                           |
> > .                           .
> > .                           .
> > .                           .
> > 
> > So even with only one partner you must have two unrelated
conversations
> > This is because the correlation set "bar" is not initialized with
the
> > key from msg#1 until the last step in the sequence. The partner has
no
> > way of associating the literal it receives from the BPEL with the
> > bpel.z() call it made previously (short of making an inference based
on
> > timing). Because there is no way to relate the two conversations
they
> > cannot be considered to be part of the same "protocol".
> > 
> > The one way I see of getting a "protocol paradox" in this
environment is
> > if "r2" had a non-initiate correlation on "foo", like so: 
> > <receive name="r2" var="c" plink="plink1" op="z"
createinstance="yes">
> >    <correlation initiate="yes" cset="bar" />
> >    <correlation initiate="no" cset="foo" />
> > </receive>
> > 
> > With the above, the instantiating message allocated to r2 would have
> > been allocated before the value of "foo" could be determined, most
> > likely rendering the correlation constraint unsatisfiable (unless by
> > some miracle the instantiating message happened to also match the
value
> > of "foo"). However, createInstance receives cannot have
non-initiating
> > correlations, so this paradox does not come up.
> > 
> > Does that make sense? 
> > 
> > -maciej
> > 
> > 
> > 
> > 
> > On Wed, 2004-10-27 at 12:22, Satish Thatte wrote:
> > > I am afraid we set ourselves up for some "protocol paradoxes" by
> > > eliminating these so-called irrelevant language.  Thus my question
in
> > > the parallel mail.  It would be interesting to actually show a
partner
> > > process that successfully communicated with that hypothetical
> > strangely
> > > instantiated process. 
> > > 
> > > 
> > >  
> > > 
> > > -----Original Message-----
> > > From: Maciej Szefler [mailto:mbs@fivesight.com] 
> > > Sent: Wednesday, October 27, 2004 10:19 AM
> > > To: Francisco Curbera
> > > Cc: Satish Thatte; wsbpel@lists.oasis-open.org
> > > Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote
> > > 
> > > Well that is one (not very flattering) way of putting it.  I don't
see
> > > this as a feature and have no interest in it as a feature. To me
this
> > > falls under the category of "exceptional language made
irrelevant".
> > I'd
> > > argue that in general there is merit in keeping a spec streamlined
and
> > > consistent. The gist of 168 is that by properly specifying the
> > > instantiation semantics we improve the consistency of the spec
which
> > > enables us to remove this particular exceptional language. So
unless
> > one
> > > of our goals is a spec with lots of ifs and buts, I fail to see
the
> > > merit of keeping it.
> > > 
> > > -maciej
> > > 
> > > 
> > > On Wed, 2004-10-27 at 11:14, Francisco Curbera wrote:
> > > > 
> > > > 
> > > > So is the rationale that because the new feature is really not
> > useful 
> > > > in any case it should be allowed?
> > > > 
> > > > Paco
> > > > 
> > > > 
> > > > 
> > > >
> > > 
> > > >                       Maciej Szefler
> > > 
> > > >                       <mbs@fivesight.co        To:       Satish
> > Thatte
> > > <satisht@microsoft.com>                                          
> > > >                       m>                       cc:
> > > wsbpel@lists.oasis-open.org
> > > 
> > > >                                                Subject:  RE:
> > [wsbpel]
> > > Issue - 168 - Proposal To Vote                                    
> > > >                       10/27/2004 09:59
> > > 
> > > >                       AM
> > > 
> > > >
> > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Satish,
> > > > 
> > > > The strikes in 6.4 and 11.4 are there because they the
prohibition 
> > > > they spell out is not necessary. From the point of view of a
process
> > 
> > > > designer, implicit data-dependency constraints make these
explicit 
> > > > constraints largely superfluous: it is hard to conceive a
process
> > that
> > > 
> > > > could do anything meaningful (besides initializing a variable
with a
> > 
> > > > literal value) before the instantiating message is received.
> > > > 
> > > > Also, leaving those restrictions there suggests that there is
some 
> > > > special ordering to or handling of the createInstance activities
> > once 
> > > > the new process instance is created. I specifically didn't want 
> > > > readers to fall under that impression.
> > > > 
> > > > Finally, there is nothing in the instantiation semantics I'm 
> > > > suggesting that makes these constraints technically necessary or

> > > > desirable (from an implementor's point of view).
> > > > 
> > > > -maciej
> > > > 
> > > > On Tue, 2004-10-26 at 00:03, Satish Thatte wrote:
> > > > > Maciej,
> > > > >
> > > > > I understand your correction to 13.5.3.  I am not seeing what
you 
> > > > > are trying to accomplish with the "strike"s in 6.4 and 11.4.
> > Please
> > > 
> > > > > help me out with a hint!
> > > > >
> > > > > Satish
> > > > >
> > > > >
> > > > >
> > ____________________________________________________________________
> > > > > __
> > > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> > > > > Sent: Wednesday, October 20, 2004 10:48 AM
> > > > > To: Danny van der Rijn; wsbpel@lists.oasis-open.org
> > > > > Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote
> > > > >
> > > > >
> > > > > If the instantiating receive is preceded, for instance, by an
> > invoke
> > > 
> > > > > using the same correlation set, I need to know how to handle
the 
> > > > > correlation set matching for the invoke.
> > > > >
> > > > > Ugo
> > > > >         -----Original Message-----
> > > > >         From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > > > >         Sent: Wednesday, October 20, 2004 10:36 AM
> > > > >         To: wsbpel@lists.oasis-open.org
> > > > >         Subject: Re: [wsbpel] Issue - 168 - Proposal To Vote
> > > > >
> > > > >
> > > > >         why does that matter?  the elephant in the room that
we
> > call
> > > > >         the "dispatcher"  has to deal with this stuff, but as
far
> > as
> > > > >         the process is concerned, it shouldn't care, should
it?
> > we
> > > > >         have avoided talking about the dispatcher at all, and
i
> > > would
> > > > >         think that this question falls into that domain.
> > > > >
> > > > >         danny
> > > > >
> > > > >         Ugo Corda wrote:
> > > > >         > Maciej,
> > > > >         > Thank you for the rewrite.
> > > > >         >
> > > > >         > I think you should also spell out what happens with
> > > respect to
> > > > >         > correlation set initialization. In other words, is
it
> > done
> > > 
> > > > > at
> > > > the time
> > > > >         > the new process is created, or at the time the
normal 
> > > > > execution
> > > > flow
> > > > >         > reaches the instantiating activity?
> > > > >         >
> > > > >         > Ugo
> > > > >         >
> > > > >         >
> > > > >         > > -----Original Message-----
> > > > >         > > From: Maciej Szefler [mailto:mbs@fivesight.com]
> > > > >         > > Sent: Wednesday, October 20, 2004 7:56 AM
> > > > >         > > To: Ugo Corda
> > > > >         > > Cc: wsbpel@lists.oasis-open.org
> > > > >         > > Subject: RE: [wsbpel] Issue - 168 - Proposal To
Vote
> > > > >         > >
> > > > >         > >
> > > > >         > > Ugo,
> > > > >         > > Sorry for the confusion, I've adjusted my proposal
> > > (basically
> > > > >         > > in my previous narrative
"createInstance=rendezvous"
> > > should
> > > > >         > > be read as "createInstance=yes and containing
> > > > >         > > initiate=rendezvous correlation set"). Adjusted
text:
> > > > >         > >
> > > > >         > >
> > > > >         > > I propose we adopt the "less magic" approach
described
> > > in the
> > > > >         > > issue description. This means that the semantics
of
> > > process
> > > > >         > > instantiation would be as follows:  1. The arrival
of
> > > message
> > > > >         > > that matches an activity marked with
> > createInstance=yes
> > > (and
> > > > >         > > not matching an existing process
> > > > >         > > instance) causes a new process instance to be
created.
> > > This
> > > > >         > > message is termed the "instantiating message" for
that
> > > > >         > > process instance. The createInstance=yes activity
that
> > > was
> > > > >         > > used to justify the instantiation is termed the
> > > > >         > > "instantiating activity" for that process
instance.
> > > > >         > >  2. Once a process instance is created, all its
> > > activities
> > > > >         > > are executed in the order dictated by the
structure of
> > 
> > > > > the
> > > > process.
> > > > >         > >  3. When a <receive> or <pick> activity with
> > > > >         > > createInstance=yes containing a initiate=yes
> > correlation
> > > is
> > > > >         > > executed, the message "received" will be the
> > > "instantiating
> > > > >         > > message" of the process instance.  4. When a
<receive>
> > > and
> > > > >         > > <pick> activity  with createInstance=yes
containing a
> > > > >         > > initiate=rendezvous correlation is executed, the
> > message
> > > > >         > > "received" will be either:
> > > > >         > >     a ) the "instantiating message" if said
activity
> > is
> > > the
> > > > >         > > "instantiating activity"
> > > > >         > >     b ) some other message matching the
correlation
> > key
> > > from
> > > > >         > > the "instantiating message" if said activity is
not
> > the
> > > > >         > > "instantiating activity"
> > > > >         > >
> > > > >         > > Key changes to text:
> > > > >         > > 6.4:
> > > > >         > > OLD: This is done by setting the createInstance
> > > attribute of
> > > > >         > > such an activity to "yes". When a message is
received
> > by
> > > such
> > > > >         > > an activity, an instance of the business process
is
> > > created
> > > > >         > > if it does not already exist (see Providing Web
> > Service
> > > > >         > > Operations and Pick).
> > > > >         > > NEW: This is done by setting the createInstance
> > > attribute of
> > > > >         > > such an activity to "yes". When a message that
matches
> > > such
> > > > >         > > an activity is received, an instance of the
business
> > > process
> > > > >         > > is created if it does not already exist (see
Providing
> > > Web
> > > > >         > > Service Operations and Pick).
> > > > >         > >
> > > > >         > > OLD: To be instantiated, each business process
must
> > > contain
> > > > >         > > at least one such "start activity." This must be
an
> > > initial
> > > > >         > > activity in the sense that there is no basic
activity
> > > that
> > > > >         > > logically precedes it in the behavior of the
process.
> > > > >         > > NEW: To be instantiated, each business process
must
> > > contain
> > > > >         > > at least one such "start activity." ----strike---
> > > > >         > >
> > > > >         > > 11.4:
> > > > >         > > OLD: A receive activity annotated in this way MUST
be
> > an
> > > > >         > > initial activity in the process, that is, the only
> > other
> > > > >         > > basic activities may potentially be performed
prior to
> > > or
> > > > >         > > simultaneously with such a receive activity MUST
be
> > > similarly
> > > > >         > > annotated receive activities.
> > > > >         > > NEW: -----strike----
> > > > >         > >
> > > > >         > >
> > > > >         > > 13.5.3:
> > > > >         > > OLD: If the event handler is associated with the
> > global
> > > > >         > > process scope, the event handler is enabled as
soon as
> > > the
> > > > >         > > process instance is created. The process instance
is
> > > created
> > > > >         > > when the first receive activity that provides for
the
> > > > >         > > creation of a process instance (indicated via the
> > > > >         > > createInstance attribute set to "yes") has
received
> > and
> > > > >         > > processed the corresponding message. This allows
the
> > > alarm
> > > > >         > > time for a global alarm event to be specified
using
> > the
> > > data
> > > > >         > > provided within the message that creates a process
> > > instance,
> > > > >         > > as shown in the following example:
> > > > >         > >
> > > > >         > > NEW: If the event handler is associated with the
> > global
> > > > >         > > process scope, the event handler is enabled as
soon as
> > > the
> > > > >         > > process instance is created.
> > > > >         > > Note: alarm time for a global alarm event /cannot/
be
> > > > >         > > specified using the data provided within the
message
> > > that
> > > > >         > > creates a process instance!
> > > > >         > >
> > > > >         > > On Tue, 2004-10-19 at 19:53, Ugo Corda wrote:
> > > > >         > >
> > > > >         > > > Maciej,
> > > > >         > > > I suggest you rewrite your initial proposal
keeping
> > > > >         > > >
> > > > >         > > "createInstance"
> > > > >         > >
> > > > >         > > > and "initiate" separate. Right now, you are
> > conflating
> > > 
> > > > > the
> > > > two (you
> > > > >         > > > are, for instance, talking about
> > > > >         > > >
> > > > >         > > "createInstance=rendezvous"), which
> > > > >         > >
> > > > >         > > > makes the proposed language confusing.
> > > > >         > > >
> > > > >         > > > Ugo
> > > > >         > > >
> > > > >         > > > P.S. Talking about rendezvous, shouldn't the two
> > > initial
> > > > >         > > >
> > > > >         > > receive's in
> > > > >         > >
> > > > >         > > > the Multiple Start Activities example (sec.
16.3.2)
> > > have
> > > > >         > > > initiate="rendezvous" instead of initiate="yes"?
> > > > >         > > >
> > > > >         > > >
> > > > >         > > > > -----Original Message-----
> > > > >         > > > > From: Maciej Szefler
[mailto:mbs@fivesight.com]
> > > > >         > > > > Sent: Tuesday, October 19, 2004 5:08 PM
> > > > >         > > > > To: Ugo Corda
> > > > >         > > > > Cc: wsbpel@lists.oasis-open.org
> > > > >         > > > > Subject: RE: [wsbpel] Issue - 168 - Proposal
To
> > Vote
> > > > >         > > > >
> > > > >         > > > >
> > > > >         > > > > Ugo,
> > > > >         > > > >
> > > > >         > > > > My understanding is that if in a process we
find
> > an
> > > > activity
> > > > >         > > > > with createInstance=yes / initiate=yes, then
that 
> > > > > must be
> > > > the
> > > > >         > > > > /sole/ createInstance activity in that
process.
> > > (11.4
> > > > >         > > > > suggests that only in the case of rendezvous
are
> > > multiple
> > > > >         > > > > createInstance activities permitted).
> > > > >         > > > >
> > > > >         > > > > With createInstance="yes" /
initiate="rendezvous"
> > we
> > > 
> > > > > can
> > > > have
> > > > >         > > > > multiple createInstance activities, but for
that 
> > > > > case we
> > > > have
> > > > >         > > > > (rendezvous) semantics (section 11.4 + Issue
37):
> > > > >         > > > > 1. all activities will synchronize on the same
> > > > correlation
> > > > >         > > > > set 2. there will be exactly one "winner"
activity
> > 
> > > > > that
> > > > sets
> > > > >         > > > > the correlation,
> > > > >         > > > > 3. all the other activities will "lose", and
> > respect
> > > the
> > > > >         > > > >
> > > > >         > > correlation.
> > > > >         > >
> > > > >         > > > > How the winner is chosen is out of scope, but
we 
> > > > > know
> > > > exactly
> > > > >         > > > > one winner will be chosen.
> > > > >         > > > >
> > > > >         > > > > -maciej
> > > > >         > > > >
> > > > >         > > > > On Tue, 2004-10-19 at 12:21, Ugo Corda wrote:
> > > > >         > > > >
> > > > >         > > > > > Maciej,
> > > > >         > > > > >
> > > > >         > > > > >
> > > > >         > > > > > > I think the rendezvous issue made
> > > > >         > > > > > > such cases technically illegal (i.e. you
can 
> > > > > only
> > > > have one
> > > > >         > > > > > > createInstance=yes activity).
> > > > >         > > > > > >
> > > > >         > > > > > I am not sure what you are referring to.
Could
> > you
> > > > >         > > > > >
> > > > >         > > please clarify?
> > > > >         > >
> > > > >         > > > > > Thank you,
> > > > >         > > > > > Ugo
> > > > >         > > > > >
> > > > >         > > > > >
> > > > >         > > > > > > -----Original Message-----
> > > > >         > > > > > > From: Maciej Szefler
> > [mailto:mbs@fivesight.com]
> > > > >         > > > > > > Sent: Tuesday, October 19, 2004 7:16 AM
> > > > >         > > > > > > To: Ugo Corda
> > > > >         > > > > > > Cc: wsbpel@lists.oasis-open.org
> > > > >         > > > > > > Subject: RE: [wsbpel] Issue - 168 -
Proposal
> > To
> > > Vote
> > > > >         > > > > > >
> > > > >         > > > > > >
> > > > >         > > > > > > Ugo,
> > > > >         > > > > > >
> > > > >         > > > > > > You are correct. Although, I think the 
> > > > > rendezvous
> > > > issue made
> > > > >         > > > > > > such cases technically illegal (i.e. you
can 
> > > > > only
> > > > have one
> > > > >         > > > > > > createInstance=yes activity). In the case
of
> > > > >         > > > > > > "createInstance=rendezvous", my first
instinct
> > > would
> > > > >         > > > > > >
> > > > >         > > be to say
> > > > >         > >
> > > > >         > > > > > > that processes with this ambiguity are
illegal
> > 
> > > > > and
> > > > should be
> > > > >         > > > > > > detected by static analysis.
> > > > >         > > > > > >
> > > > >         > > > > > > -maciej
> > > > >         > > > > > >
> > > > >         > > > > > > On Mon, 2004-10-18 at 18:49, Ugo Corda
wrote:
> > > > >         > > > > > >
> > > > >         > > > > > > > Maciej,
> > > > >         > > > > > > >
> > > > >         > > > > > > > What about the case where the
"instantiating
> > > > message"
> > > > >         > > > > > > >
> > > > >         > > > > matches more
> > > > >         > > > >
> > > > >         > > > > > > > than one activity marked with
> > > createInstance=yes?
> > > > Your
> > > > >         > > > > > > > proposed
> > > > >         > > > > > > > wording does not explicitly rule that
out,
> > but
> > > 
> > > > > in
> > > > such
> > > > >         > > > > > > >
> > > > >         > > > > a case the
> > > > >         > > > >
> > > > >         > > > > > > > concept of "instantiating activity"
would
> > > become
> > > > >         > > > > > > >
> > > > >         > > > > ambiguous, in the
> > > > >         > > > >
> > > > >         > > > > > > > sense that it would not be clear which
one
> > of
> > > those
> > > > >         > > > > > > >
> > > > >         > > > > > > activities could
> > > > >         > > > > > >
> > > > >         > > > > > > > be labeled that way.
> > > > >         > > > > > > >
> > > > >         > > > > > > > Ugo
> > > > >         > > > > > > >
> > > > >         > > > > > > >
> > > > >         > > > > > > > > -----Original Message-----
> > > > >         > > > > > > > > From: Maciej Szefler
> > > [mailto:mbs@fivesight.com]
> > > > >         > > > > > > > > Sent: Monday, October 18, 2004 11:22
AM
> > > > >         > > > > > > > > To: wsbpel@lists.oasis-open.org
> > > > >         > > > > > > > > Subject: [wsbpel] Issue - 168 -
Proposal
> > To
> > > Vote
> > > > >         > > > > > > > >
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > I propose we adopt the "less magic"
> > approach
> > > > described in
> > > > >         > > > > > > > > the
> > > > >         > > > > > > > > issue description. This means that the
> > > semantics
> > > > >         > > > > > > > >
> > > > >         > > of process
> > > > >         > >
> > > > >         > > > > > > > > instantiation would be as follows:  1.
The
> > > > >         > > > > > > > >
> > > > >         > > arrival of message
> > > > >         > >
> > > > >         > > > > > > > > that matches an activity marked with
> > > > >         > > > > > > > > createInstance=yes/rendezvous (and not

> > > > > matching
> > > > an
> > > > >         > > > > > > > >
> > > > >         > > > > > > existing process
> > > > >         > > > > > >
> > > > >         > > > > > > > > instance) causes a new process
instance to
> > > be
> > > > >         > > > > > > > >
> > > > >         > > created. This
> > > > >         > >
> > > > >         > > > > > > > > message is termed the "instantiating 
> > > > > message" for
> > > > that
> > > > >         > > > > > > > > process instance. The
> > > > >         > > > > > > > >
> > > > >         > > createInstance=yes/rendezvous activity
> > > > >         > >
> > > > >         > > > > > > > > that was used to justify the
instantiation
> > 
> > > > > is
> > > > termed the
> > > > >         > > > > > > > > "instantiating activity" for that
process
> > > > >         > > > > > > > >
> > > > >         > > instance.  2. Once
> > > > >         > >
> > > > >         > > > > > > > > a process instance is created, all its

> > > > > activities
> > > > are
> > > > >         > > > > > > > > executed in the order dictated by the 
> > > > > structure
> > > > of
> > > > >         > > > > > > > >
> > > > >         > > > > > > the process.
> > > >  >         > > > > > >
> > > > >         > > > > > > > >  3. When a <receive> or <pick>
activity
> > with
> > > > >         > > > > > > > > createInstance=yes is executed, the
> > message
> > > > >         > > > > > > > >
> > > > >         > > "received" will
> > > > >         > >
> > > > >         > > > > > > > > be the "instantiating message" of the
> > > process
> > > > >         > > > > > > > >
> > > > >         > > instance.  4.
> > > > >         > >
> > > > >         > > > > > > > > When a <receive> and <pick> activity
with
> > > > >         > > > > > > > > createInstance=rendezvous is executed,
the
> > > > message
> > > > >         > > > > > > > > "received" will be either:
> > > > >         > > > > > > > >     a ) the "instantiating message" if
> > said
> > > > >         > > > > > > > >
> > > > >         > > activity is the
> > > > >         > >
> > > > >         > > > > > > > > "instantiating activity"
> > > > >         > > > > > > > >     b ) some other message matching
the
> > > > >         > > > > > > > >
> > > > >         > > correlation key from
> > > > >         > >
> > > > >         > > > > > > > > the "instantiating message" if said
> > activity
> > > 
> > > > > is
> > > > not the
> > > > >         > > > > > > > > "instantiating activity"
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > Key changes to text:
> > > > >         > > > > > > > > 6.4:
> > > > >         > > > > > > > > OLD: This is done by setting the
> > > createInstance
> > > > >         > > > > > > > >
> > > > >         > > attribute of
> > > > >         > >
> > > > >         > > > > > > > > such an activity to "yes". When a
message
> > is
> > > > received by
> > > > >         > > > > > > > > such an activity, an instance of the 
> > > > > business
> > > > process is
> > > > >         > > > > > > > > created if it does not already exist
(see
> > > > Providing Web
> > > > >         > > > > > > > > Service Operations and Pick).
> > > > >         > > > > > > > > NEW: This is done by setting the
> > > createInstance
> > > > >         > > > > > > > >
> > > > >         > > attribute of
> > > > >         > >
> > > > >         > > > > > > > > such an activity to "yes". When a
message
> > > that
> > > > >         > > > > > > > >
> > > > >         > > matches such
> > > > >         > >
> > > > >         > > > > > > > > an activity is received, an instance
of
> > the
> > > > >         > > > > > > > >
> > > > >         > > business process
> > > > >         > >
> > > > >         > > > > > > > > is created if it does not already
exist
> > (see
> > > > >         > > > > > > > >
> > > > >         > > Providing Web
> > > > >         > >
> > > > >         > > > > > > > > Service Operations and Pick).
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > OLD: To be instantiated, each business

> > > > > process
> > > > must
> > > > >         > > > > > > > >
> > > > >         > > > > contain at
> > > > >         > > > >
> > > > >         > > > > > > > > least one such "start activity." This
must
> > 
> > > > > be an
> > > > initial
> > > > >         > > > > > > > > activity in the sense that there is no
> > basic
> > > > >         > > > > > > > >
> > > > >         > > activity that
> > > > >         > >
> > > > >         > > > > > > > > logically precedes it in the behavior
of
> > the
> > > > process.
> > > > >         > > > > > > > > NEW: To be instantiated, each business
> > > process
> > > > >         > > > > > > > >
> > > > >         > > must contain
> > > > >         > >
> > > > >         > > > > > > > > at least one such "start activity."
> > > ----strike---
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > 11.4:
> > > > >         > > > > > > > > OLD: A receive activity annotated in
this 
> > > > > way
> > > > MUST be
> > > > >         > > > > > > > >
> > > > >         > > > > an initial
> > > > >         > > > >
> > > > >         > > > > > > > > activity in the process, that is, the
only
> > 
> > > > > other
> > > > basic
> > > > >         > > > > > > > > activities may potentially be
performed 
> > > > > prior to
> > > > or
> > > > >         > > > > > > > > simultaneously with such a receive
> > activity
> > > MUST
> > > > >         > > > > > > > >
> > > > >         > > be similarly
> > > > >         > >
> > > > >         > > > > > > > > annotated receive activities.
> > > > >         > > > > > > > > NEW: -----strike----
> > > > >         > > > > > > > >
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > 13.5.3:
> > > > >         > > > > > > > > OLD: If the event handler is
associated
> > with
> > > the
> > > > >         > > > > > > > >
> > > > >         > > > > global process
> > > > >         > > > >
> > > > >         > > > > > > > > scope, the event handler is enabled as
> > soon 
> > > > > as
> > > > the process
> > > > >         > > > > > > > > instance is created. The process
instance
> > is
> > > > >         > > > > > > > >
> > > > >         > > created when the
> > > > >         > >
> > > > >         > > > > > > > > first receive activity that provides
for
> > the
> > > > >         > > > > > > > >
> > > > >         > > creation of a
> > > > >         > >
> > > > >         > > > > > > > > process instance (indicated via the
> > > > createInstance
> > > > >         > > > > > > > >
> > > > >         > > > > attribute set
> > > > >         > > > >
> > > > >         > > > > > > > > to "yes") has received and processed
the
> > > > >         > > > > > > > >
> > > > >         > > > > corresponding message.
> > > > >         > > > >
> > > > >         > > > > > > > > This allows the alarm time for a
global 
> > > > > alarm
> > > > event to be
> > > > >         > > > > > > > > specified using the data provided
within
> > the
> > > > message that
> > > > >         > > > > > > > > creates a process instance, as shown
in
> > the
> > > > >         > > > > > > > >
> > > > >         > > following example:
> > > > >         > >
> > > > >         > > > > > > > > NEW: If the event handler is
associated
> > with
> > > the
> > > > >         > > > > > > > >
> > > > >         > > > > global process
> > > > >         > > > >
> > > > >         > > > > > > > > scope, the event handler is enabled as
> > soon 
> > > > > as
> > > > the process
> > > > >         > > > > > > > > instance is created.
> > > > >         > > > > > > > > Note: alarm time for a global alarm
event
> > > > /cannot/ be
> > > > >         > > > > > > > > specified using the data provided
within
> > the
> > > > message that
> > > > >         > > > > > > > > creates a process instance!
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > On Mon, 2004-10-04 at 17:14, ws-bpel
> > issues 
> > > > > list
> > > > editor
> > > > >         > > > > > > > > wrote:
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > This issue has been added to the
wsbpel 
> > > > > issue
> > > > list with
> > > > >         > > > > > > > > >
> > > > >         > > > > > > a status
> > > > >         > > > > > >
> > > > >         > > > > > > > > > of
> > > > >         > > > > > > > > > "received". The status will be
changed
> > to
> > > > >         > > > > > > > > >
> > > > >         > > "open" if the TC
> > > > >         > >
> > > > >         > > > > > > > > accepts it
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > as identifying a bug in the spec or 
> > > > > decides it
> > > > should
> > > > >         > > > > > > > > >
> > > > >         > > > > > > be accepted
> > > > >         > > > > > >
> > > > >         > > > > > > > > > specially. Otherwise it will be
closed 
> > > > > without
> > > > further
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > consideration
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > (but will be marked as
"Revisitable")
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > > The issues list is posted as a
Technical
> > > > Committee
> > > > >         > > > > > > > > >
> > > > >         > > > > > > document to the
> > > > >         > > > > > >
> > > > >         > > > > > > > > > OASIS WSBPEL TC pages on a regular
> > basis. 
> > > > > The
> > > > current
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > edition, as a TC
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > document, is the most recent version
of 
> > > > > the
> > > > document
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > entitled  in the
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > "Issues" folder of the WSBPEL TC
> > document
> > > list
> > > > >         > > > > > > > > >
> > > > >         > > - the next
> > > > >         > >
> > > > >         > > > > > > > > posting as a
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > TC document 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.
Issue - 
> > > > > 168 -
> > > > Semantics
> > > > >         > > > > > > > > >
> > > > >         > > > > > > of instance
> > > > >         > > > > > >
> > > > >         > > > > > > > > > creation
> > > > >         > > > > > > > > > Status: received
> > > > >         > > > > > > > > > Date added: 4 Oct 2004
> > > > >         > > > > > > > > > Categories: State management
> > > > >         > > > > > > > > > Date submitted: 30 September 2004
> > > > >         > > > > > > > > > Submitter: Maciej Szefler
> > > > >         > > > > > > > > > Description: Discussions of issue 81
:
> > Are
> > > > start
> > > > >         > > > > > > > > >
> > > > >         > > > > > > activities that
> > > > >         > > > > > >
> > > > >         > > > > > > > > > aren't createInstance activities
legal?
> > 
> > > > > have
> > > > brought
> > > > >         > > > > > > > > >
> > > > >         > > > > > > to light a
> > > > >         > > > > > >
> > > > >         > > > > > > > > > certain deficiency of clarity in the
> > > current
> > > > >         > > > > > > > > >
> > > > >         > > specification
> > > > >         > >
> > > > >         > > > > > > > > > with
> > > > >         > > > > > > > > > respect to issue of instance
creation.
> > The
> > > > present spec
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > makes various
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > vague and somewhat contradictory 
> > > > > statements as
> > > > to how
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > createInstance
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > activities should be handled.
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > > On the one hand, the spec suggests
that
> > > process
> > > > >         > > > > > > > > >
> > > > >         > > creation
> > > > >         > >
> > > > >         > > > > > > > > > is
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > "implicit"
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > and that the createInstance flag is
> > merely
> > > 
> > > > > an
> > > > annotation
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > that defines
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > which message events cause an
instance
> > to 
> > > > > be
> > > > created
> > > > >         > > > > > > > > >
> > > > >         > > > > > > and that once
> > > > >         > > > > > >
> > > > >         > > > > > > > > > created the process instance
processes
> > all
> > > > activities
> > > > >         > > > > > > > > >
> > > > >         > > > > > > in the same
> > > > >         > > > > > >
> > > > >         > > > > > > > > > manner largely oblivious to the
value of
> > > that
> > > > >         > > > > > > > > >
> > > > >         > > annotation.
> > > > >         > >
> > > > >         > > > > > > > > > On the other hand, the spec
restricts
> > the 
> > > > > set
> > > > of
> > > > >         > > > > > > > > > activities
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > that are
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > "initial" activities, and
establishes
> > > > exceptional
> > > > >         > > > > > > > > > semantics
> > > > >         > > > > > > > > > (for process-level event handlers)
that
> > > could
> > > > >         > > > > > > > > >
> > > > >         > > be construed
> > > > >         > >
> > > > >         > > > > > > to imply that
> > > > >         > > > > > >
> > > > >         > > > > > > > > > createInstance activities are
actually
> > > > activated before
> > > > >         > > > > > > > > >
> > > > >         > > > > > > any other
> > > > >         > > > > > >
> > > > >         > > > > > > > > > activities, irrespective of their
actual
> > > > location in
> > > > >         > > > > > > > > >
> > > > >         > > > > > > the process.
> > > > >         > > > > > >
> > > > >         > > > > > > > > > I posit that the former
interpretation 
> > > > > provides
> > > > a
> > > > >         > > > > > > > > >
> > > > >         > > > > concise and
> > > > >         > > > >
> > > > >         > > > > > > > > > manageable view of the instance
creation
> > > > process. By
> > > > >         > > > > > > > > > making
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > the spec
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > consistent with it we can define
> > execution
> > > > >         > > > > > > > > >
> > > > >         > > semantics of a
> > > > >         > >
> > > > >         > > > > > > > > > single process instance without
> > reference 
> > > > > to
> > > > instance
> > > > >         > > > > > > > > > creation. We
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > can handle
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > instance creation simply and
separately
> > by
> > > > stipulating
> > > > >         > > > > > > > > > that
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > a process
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > instance is created when a message
event
> > > that
> > > > >         > > > > > > > > >
> > > > >         > > would match
> > > > >         > >
> > > > >         > > > > > > > > one of the
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > createInstance activities is
received. 
> > > > > This
> > > > message
> > > > >         > > > > > > > > >
> > > > >         > > > > event is
> > > > >         > > > >
> > > > >         > > > > > > > > > "allocated" to that activity, so
that
> > when
> > > that
> > > > >         > > > > > > > > >
> > > > >         > > activity
> > > > >         > >
> > > > >         > > > > > > > > > is
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > actually
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > activated (in the normal course of
> > process
> > > > instance
> > > > >         > > > > > > > > >
> > > > >         > > > > > > evaluation) it
> > > > >         > > > > > >
> > > > >         > > > > > > > > > will receive the said event.
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > > The major implication of this model
on
> > > > execution
> > > > >         > > > > > > > > >
> > > > >         > > > > > > semantics is the
> > > > >         > > > > > >
> > > > >         > > > > > > > > > elimination of the notion of
"initiate"
> > > > activities.
> > > > >         > > > > > > > > >
> > > > >         > > > > > > This concept
> > > > >         > > > > > >
> > > > >         > > > > > > > > > becomes unnecessary. One might
object on
> > 
> > > > > the
> > > > basis that
> > > > >         > > > > > > > > >
> > > > >         > > > > > > without the
> > > > >         > > > > > >
> > > > >         > > > > > > > > > initiate activity restrictions the
> > > following
> > > > >         > > > > > > > > >
> > > > >         > > > > process would be
> > > > >         > > > >
> > > > >         > > > > > > > > > perfectly legal:
> > > > >         > > > > > > > > >    <sequence>
> > > > >         > > > > > > > > >      <invoke .../>
> > > > >         > > > > > > > > >      <receive createInstance="yes"
.../>
> > > >  >         > > > > > > > > >    </sequence>
> > > > >         > > > > > > > > > Such a process certainly seems
> > > objectionable.
> > > > >         > > > > > > > > >
> > > > >         > > However, the
> > > > >         > >
> > > > >         > > > > > > > > details of
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > normal execution semantics would
make
> > such
> > > 
> > > > > a
> > > > process
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > unlikely. That is
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > to say, the <invoke> would need to
use a
> > > > message
> > > > >         > > > > > > > > >
> > > > >         > > > > > > variable (for the
> > > > >         > > > > > >
> > > > >         > > > > > > > > > request), and that variable could
not
> > have
> > > been
> > > > >         > > > > > > > > >
> > > > >         > > > > > > initialized unless
> > > > >         > > > > > >
> > > > >         > > > > > > > > > some activity preceded the <invoke>.
One
> > 
> > > > > might
> > > > then
> > > > >         > > > > > > > > >
> > > > >         > > > > > > object with the
> > > > >         > > > > > >
> > > > >         > > > > > > > > > following:
> > > > >         > > > > > > > > >    <sequence>
> > > > >         > > > > > > > > >      <receive createInstance="no" ..
> > > > var="foo"/>
> > > > >         > > > > > > > > >      <invoke ... inVar="foo"/>
> > > > >         > > > > > > > > >      <receive createInstance="yes"
..>
> > > > >         > > > > > > > > >    </sequence>
> > > > >         > > > > > > > > > However, in this process the first
> > receive
> > > is
> > > > >         > > > > > > > > >
> > > > >         > > > > invalid unless a
> > > > >         > > > >
> > > > >         > > > > > > > > > correlation set is used. But in
order to
> > 
> > > > > use
> > > > the
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > correlation set, it
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > first needs to be initialized, and
the
> > > only way
> > > > >         > > > > > > > > >
> > > > >         > > to do that
> > > > >         > >
> > > > >         > > > > > > > > is with an
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > invoke or a receive/pick that
precedes
> > it,
> > > so
> > > > >         > > > > > > > > >
> > > > >         > > you're back
> > > > >         > >
> > > > >         > > > > > > > > to needing a
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > <receive> to precede the <invoke>.
This 
> > > > > receive
> > > > would
> > > > >         > > > > > > > > >
> > > > >         > > > > > > have to have
> > > > >         > > > > > >
> > > > >         > > > > > > > > > createInstance="yes" lest it run
into
> > the 
> > > > > same
> > > > problem.
> > > > >         > > > > > > > > >
> > > > >         > > > > > > But if this
> > > > >         > > > > > >
> > > > >         > > > > > > > > > receive had createInstance="yes"
then
> > the
> > > same
> > > > >         > > > > > > > > >
> > > > >         > > > > > > annotation on the
> > > > >         > > > > > >
> > > > >         > > > > > > > > > second <receive> would be invalid.
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > > Now, one might get cleverer still
and
> > > object
> > > > >         > > > > > > > > >
> > > > >         > > based on the
> > > > >         > >
> > > > >         > > > > > > > > > following somewhat convoluted
process:
> > > > >         > > > > > > > > >    <sequence>
> > > > >         > > > > > > > > >      <assign>
> > > > >         > > > > > > > > >         <copy>
> > > > >         > > > > > > > > >            <to variable="foo"/>
> > > > >         > > > > > > > > >            <from> literal </from>
> > > > >         > > > > > > > > >         </copy>
> > > > >         > > > > > > > > >      </assign>
> > > > >         > > > > > > > > >      <invoke ... inVar="foo">
> > > > >         > > > > > > > > >         <correlation name="cset1"
> > > > initiate="yes"
> > > > >         > > > > > > > > >
> > > > >         > > > > pattern="in"/>
> > > > >         > > > >
> > > > >         > > > > > > > > >      </invoke>
> > > > >         > > > > > > > > >      <receive createInstance="no"
..>
> > > > >         > > > > > > > > >         <correlation name="cset1"
> > > initiate="no"
> > > > />
> > > > >         > > > > > > > > >      </receive>
> > > > >         > > > > > > > > >      <receive createInstance="yes"
..>
> > > > >         > > > > > > > > >    </sequence>
> > > > >         > > > > > > > > > However the above construct would
result
> > 
> > > > > in ALL
> > > > process
> > > > >         > > > > > > > > >
> > > > >         > > > > > > instances
> > > > >         > > > > > >
> > > > >         > > > > > > > > > having the same correlation set
value,
> > > which
> > > > >         > > > > > > > > >
> > > > >         > > does not make
> > > > >         > >
> > > > >         > > > > > > > > any sense.
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > But one could still object by
changing
> > the
> > > > pattern to
> > > > >         > > > > > > > > >
> > > > >         > > > > > > "out" on the
> > > > >         > > > > > >
> > > > >         > > > > > > > > > invoke, and asserting that the
partner
> > > > generates
> > > > >         > > > > > > > > >
> > > > >         > > > > unique output
> > > > >         > > > >
> > > > >         > > > > > > > > > messages for each invocation thereby

> > > > > yielding
> > > > unique
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > correlation keys.
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > But even this very brink of the edge
> > case
> > > > forces us to
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > change nothing
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > in the semantics. The only
significant
> > > > >         > > > > > > > > >
> > > > >         > > implication is that
> > > > >         > >
> > > > >         > > > > > > > > in certain
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > unlikely circumstances, the
> > implementation
> > > > might have to
> > > > >         > > > > > > > > > handle <invoke>s and
non-createInstance
> > > > >         > > > > > > > > >
> > > > >         > > <receive> before it
> > > > >         > >
> > > > >         > > > > > > > > > has a
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > chance to
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > offload the createInstance message
to
> > the
> > > > >         > > > > > > > > >
> > > > >         > > > > > > createInstance <receive>
> > > > >         > > > > > >
> > > > >         > > > > > > > > > (i.e. it needs to provide a "memory"
for
> > > the
> > > > >         > > > > > > > > >
> > > > >         > > message that
> > > > >         > >
> > > > >         > > > > > > > > created the
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > instance). The only plausible use
case
> > for
> > > 
> > > > > this
> > > > kind of
> > > > >         > > > > > > > > >
> > > > >         > > > > > > behavior
> > > > >         > > > > > >
> > > > >         > > > > > > > > > is
> > > > >         > > > > > > > > > for initialization of static
content.
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > > Finally, adopting uniform execution 
> > > > > semantics
> > > > would
> > > > >         > > > > > > > > >
> > > > >         > > > > lead us to
> > > > >         > > > >
> > > > >         > > > > > > > > > elimination of the exceptional
language
> > in
> > > 
> > > > > the
> > > > spec that
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > requires that
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > process-level alarm handlers can use
> > data 
> > > > > that
> > > > would
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > normally only be
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > valid after a receive activity
> > completes. 
> > > > > This
> > > > is not so
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > onerous, as
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > it is possible to move a
process-level 
> > > > > event
> > > > handler
> > > > >         > > > > > > > > >
> > > > >         > > > > > > into a scope
> > > > >         > > > > > >
> > > > >         > > > > > > > > > following the initial receives.
> > > > >         > > > > > > > > > Changes: 4 Oct 2004 - new issue
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > >
> > > > >         > >
> > > >
____________________________________________________________________
> > > > >         > >
> > > > >         > > > > > > > > __
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > To comment on this issue (including
> > > whether it
> > > > >         > > > > > > > > >
> > > > >         > > should be
> > > > >         > >
> > > > >         > > > > > > > > > accepted), 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 -
168
> > -
> > > > >         > > > > > > > > >
> > > > >         > > [anything]" or
> > > > >         > >
> > > > >         > > > > > > > > > is
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > a reply to
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > such a message. If you want to
formally 
> > > > > propose
> > > > a
> > > > >         > > > > > > > > >
> > > > >         > > > > > > resolution to an
> > > > >         > > > > > >
> > > > >         > > > > > > > > > open issue, please start the subject
> > line
> > > > "Issue - 168
> > > > >         > > > > > > > > >
> > > > >         > > > > > > - Proposed
> > > > >         > > > > > >
> > > > >         > > > > > > > > > resolution", without any Re: or
similar.
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > > > To add a new issue, see the issues 
> > > > > procedures
> > > > document
> > > > >         > > > > > > > > > (but
> > > > >         > > > > > > > > > the address for new issue submission
is
> > > the
> > > > >         > > > > > > > > >
> > > > >         > > sender of this
> > > > >         > >
> > > > >         > > > > > > > > announcement).
> > > > >         > > > > > > > >
> > > > >         > > > > > > > > > Choreology Anti virus scan completed
> > > > >         > > > > > > > > >
> > > > >         > > > > > > > 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_wo
> > > > >         > >
> > > > >         > > > > > > rk
> > > > >         > > > > > >
> > > > >         > > > > > > > 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/leave_wo
> > > > >         > >
> > > > >         > > > > rk
> > > > >         > > > >
> > > > >         > > > > > 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/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/leave_work
> > > > group.php
> > > >  .
> > > > 
> > > > 
> > > > #### signature.asc has been removed from this note on October
27,
> > 2004
> > > 
> > > > by Francisco Curbera
> > > > 
> > > > 
> > > 
> > 
> > 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]