RE: [wsbpel] Re: [wsbpel-spec-edit] Editing team issue - EventHandler und Concurrency?

Let us discuss next week.  Pls put it on your list -- now that you are
back to taking charge :-)

-----Original Message-----
From: Yaron Y. Goland [mailto:] 
Sent: Monday, February 28, 2005 4:35 PM
To: Satish Thatte
Cc: Francisco Curbera; Dieter Koenig1; ;

Subject: Re: [wsbpel] Re: [wsbpel-spec-edit] Editing team issue -
EventHandler und Concurrency?

It seems like we just can't agree on what this language will do. I'm not

sure what else to do at this point but to say that I object to its 
inclusion and ask that this be opened as an issue in the TC.
	Thanks,
		Yaron

Satish Thatte wrote:
> Exactly.  Thanks Paco.  I meant to reply but it slipped  through the
> many cracks.
> 
> -----Original Message-----
> From: Francisco Curbera [mailto:]
> Sent: Monday, January 24, 2005 10:37 PM
> To: 
> Cc: Dieter Koenig1; Satish Thatte; ;
> 
> Subject: Re: [wsbpel] Re: [wsbpel-spec-edit] Editing team issue -
> EventHandler und Concurrency?
> 
> I think Satish was referring to engine managed EPRs, not correlations.
> As I
> understand 139 it is about how the engine will manage the binding of
> partner links. This is somewhat related but different and much more
> generic
> than the problem Dieter raised: the possible violation of the "at most
> one"
> outstanding request constraint by concurrently executing event
handlers.
> 
> Paco
> 
> 
> 
> 
>  
> 
>                       "Yaron Y. Goland"
> 
>                       <>        To:       Dieter
Koenig1
> <>
> 
>                                                cc:       Satish Thatte
> <>, Francisco Curbera/Watson/IBM@IBMUS,
> 
>                       01/21/2005 06:48
> , 
> 
>                       PM                       Subject:  Re: [wsbpel]
> Re: [wsbpel-spec-edit] Editing team issue -  EventHandler und
> Concurrency?   
>                       Please respond to
> 
>                       ygoland
> 
>  
> 
> 
> 
> 
> 
> Huh? Where did engine managed correlations come from? Please review my
> letter on 1/20/2005 included below. It states, I thought, quite
clearly
> exactly what issue I thought you may be addressing and explains why I
> object to the currently proposed language. No where in there did I
mean
> to address or even imply anything about engine managed correlations.
> 
>              Now I'm just confused,
> 
>                          Yaron
> 
> Dieter Koenig1 wrote:
>  >
>  >
>  >
>  > This is correct, it was not meant to be linked to 139.
>  > Kind Regards
>  > DK
>  >
>  >
>  >
>  >
> 
>  >              "Satish Thatte"
> 
>  >              <satisht@microsof
> 
>  >              t.com>
> To
>  >                                        <>
> 
>  >              20.01.2005 14:39
> cc
>  >                                        "Francisco Curbera"
> 
>  >                                        <>,
> 
>  >
> <-open.
>  >                                        org>,
> 
>  >
<>,
> 
>  >                                        Dieter
> Koenig1/Germany/IBM@IBMDE
> 
>  >
> Subject
>  >                                        RE: [wsbpel] Re:
> [wsbpel-spec-edit]
>  >                                        Editing team issue -
> EventHandler
> 
>  >                                        und Concurrency?
> 
>  >
> 
>  >
> 
>  >
> 
>  >
> 
>  >
> 
>  >
> 
>  >
>  >
>  >
>  >
>  > My understanding is that there was no intent to address 139 (engine
>  > managed EPRs etc).  Dieter and Paco, please confirm.
>  >
>  > -----Original Message-----
>  > From: Yaron Y. Goland [mailto:]
>  > Sent: Thursday, January 20, 2005 1:12 PM
>  > To: Satish Thatte
>  > Cc: Francisco Curbera; ;
>  > 
>  > Subject: Re: [wsbpel] Re: [wsbpel-spec-edit] Editing team issue -
>  > EventHandler und Concurrency?
>  >
>  > If I understand your point you are saying that what you want to
> clarify
>  > is that each instance of an event handler is unique in the sense
that
>  > any variables defined inside of the event handler is independent
from
>  > those defined in any other event handlers? I did not get this
>  > distinction from the proposed text.
>  >
>  > This would be different than issue 139 which addresses the
uniqueness
> of
>  >
>  > the partnerLink that received the message that triggered an event
>  > handler instance.
>  >
>  > If in fact the distinction I draw above accurately describes your
>  > intentions then I would ask that the proposed text to be re-written
to
>  > more forcefully point out this difference.
>  >
>  >              Thanks,
>  >
>  >                          Yaron
>  >
>  > Satish Thatte wrote:
>  >  > This text only applies to partnerLink decls local to the event
>  > handler,
>  >  > which can only be initialized independently in individual copies
of
>  > the
>  >  > handler if initialization is dynamic (i.e., not part of
> deployment).
>  >  > Satish
>  >  >
>  >  >
>  >  > -----Original Message-----
>  >  > From: Yaron Y. Goland [mailto:]
>  >  > Sent: Wednesday, January 12, 2005 1:41 PM
>  >  > To: Francisco Curbera
>  >  > Cc: ;
> 
>  >  > Subject: [wsbpel] Re: [wsbpel-spec-edit] Editing team issue -
>  >  > EventHandler und Concurrency?
>  >  >
>  >  > This is issue 139. In fact, the proposed language is probably
80%
> of
>  > the
>  >  >
>  >  > resolution to issue 139.
>  >  >
>  >  > The proposed text would need to be a little more clear about how
> the
>  >  > partnerLink is copied though. For example, if a partnerLink has
a
>  > value
>  >  > for partnerRole when the event handler is created does the copy
of
> the
>  >  > partnerLink in an event handler instance inherit that
partnerRole
>  > value?
>  >  >
>  >  >         Yaron
>  >  >
>  >  > Francisco Curbera wrote:
>  >  >  > Dieter raised the following problem with the text of Section
>  > 13.5.7:
>  >  >  >
>  >  >  > *--
>  >  >  >
>  >  >  > It seems that there are conflicting statements in WS-BPEL
spec
>  > section
>  >  >  > 13.5.7. "Concurrency Considerations" (for event handlers).
>  >  >  >
>  >  >  > Consider an event handler with a request-response operation.
The
>  >  >  > "constraint that there can be at most one outstanding
> synchronous
>  >  > request
>  >  >  > on a given partner link at a given port type and operation"
> implies
>  >  > that a
>  >  >  > second request has to be rejected with a standard fault
>  >  >  > "conflictingRequest" as long as a first request is being
> processed.
>  >  >  >
>  >  >  > This does not fit to the other statement "individual onEvent
> event
>  >  > handlers
>  >  >  > are permitted to have several simultaneously active
instances".
>  >  >  >
>  >  >  > *--
>  >  >  >
>  >  >  > After a short mail discussion between Dieter, Satish and
myself
> we
>  >  > agreed
>  >  >  > that this looked like a text clarification more than a real
> issue,
>  > and
>  >  > that
>  >  >  > it would be better for the editor's team to handle is. The
> proposed
>  >  > change
>  >  >  > would affect the second paragraph in Section 13.5.7 would be
as
>  > shown
>  >  >  > below. If nobody objects (please speak up!) I would like to
have
>  > this
>  >  >  > directly handled by the editor's team.
>  >  >  >
>  >  >  > -> Change from:
>  >  >  >
>  >  >  > Note that, unlike onAlarm event handlers, individual onEvent
> event
>  >  > handlers
>  >  >  > are permitted to have several simultaneously active
instances.
> A
>  >  > private
>  >  >  > copy of all process data and control behavior defined within
an
>  > event
>  >  >  > handler is provided to each instance of an event handler.
This
>  >  > includes
>  >  >  > the behavior of links defined within an event handler.  Each
>  > instance
>  >  > of
>  >  >  > the event handler must independently evaluate the status of
the
>  > link
>  >  > as
>  >  >  > needed.
>  >  >  >
>  >  >  > -> To:
>  >  >  >
>  >  >  > Note that, unlike onAlarm event handlers, individual onEvent
> event
>  >  > handlers
>  >  >  > are permitted to have several simultaneously active
instances.
> The
>  >  > presence
>  >  >  > of multiple simultaneous active instances of the same event
> handler
>  > is
>  >  > not
>  >  >  > considered to violate the constraint regarding outstanding
>  > synchronous
>  >  >  > requests stated before, because each instance of the event
> handler
>  > is
>  >  >  > executed within its own private environment. A private copy
of
> all
>  >  > process
>  >  >  > data and control behavior defined within an event handler is
>  > provided
>  >  > to
>  >  >  > each instance of an event handler.  This includes all
variables,
>  >  >  > correlation sets and partnerLinks declared in scopes local to
an
>  > event
>  >  >  > handler as well as the behavior of links defined and used
within
> an
>  >  > event
>  >  >  > handler.  Each instance of the event handler must
independently
>  >  > evaluate
>  >  >  > the status of links local to the handler as needed.  Note
that
>  > links
>  >  > are
>  >  >  > not permitted to cross an event handler boundary (see Section
>  > 12.5).
>  >  >  >
>  >  >
>  >  > 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
> 
>  > .
>  >
>  >
>  >
>  >
>  > 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
> .
>  >
> 
>