[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote
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
> >
> >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]