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






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_workgroup.php
.
>         >
>         >
>         >
>         To unsubscribe from this mailing list (and be removed from the
>         roster of the OASIS TC), go to
 >
 http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
 .


#### 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]