[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 36 - Multiple instances of event handler
Satish Thatte wrote:
>Maciej,
>
>I seem to have misunderstood what we agreed at the recent F2F. I
>thought everyone present agreed including Assaf that we need the
>*semantics* of the two syntactic variants I described below. We didn't
>really discuss syntax in detail.
>
>Assaf, if you disagree please let us know.
>
>
mm1: Check Harvey's notes: In the F2F, it was discussed to make the
onMessage variable local to address when a single event handler gets two
messages. Questions remained about multiple instances of an event
handler (parallel or concurrent). In addition, there was an action to
break the more complex case on parallel or concurrent instances into a
separate issue.
>Satish
>
>-----Original Message-----
>From: Maciej Szefler [mailto:mbs@fivesight.com]
>Sent: Thursday, September 25, 2003 3:01 PM
>To: Satish Thatte
>Cc: wsbpel@lists.oasis-open.org
>Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler
>
>Satish wrote:
>
>
>>Hmm. This isn't how I was thinking of the alternatives.
>>Specifically,
>>what you are calling "copy" was not an alternative I had
>>thought of. I
>>was thinking of
>>
>>
>
>The "copy" semantics were the original solution proposed by Arkin at the
>last F2F.
>
>
>
>><catch faultName="qname"? faultVariable="ncname"? faultType="qname"?>
>> activity
>>
>>
>.
>.
>.
>
>
>>As mere syntactic variants with absolutely identical semantics.
>>
>>
>
>Yes, once you buy into the idea of not copying (this is the root of my
>objection), this boils down to syntactic variation.
>
>
>
>>I am uncomfortable with having to repeat the faultVariable name, check
>>that it occurs, force every catch and event handler to have
>>an outermost
>>scope (yes I knopw that a catch handler might not have fault variable
>>..)....
>>
>>
>
>Anywhere a variable is referenced we have to check that it occurs, it's
>just a matter of where we are checking (which scope); as for the
>repetition, the same repetition is present in the current version of the
>spec: my proposal does not alter the current BPEL syntax one bit, it
>merely changes the semantics. I do agree that the need (in most cases)
>to declare the outermost scope explicitly in order to get the typically
>desired result is awkward (here there is a revolutionary syntactical
>solution: eliminate the <scope> activity).
>
>
>
>>I don't see what all this syntactic addition is buying us except the
>>statement that variables can only be declared *syntactically* within
>>scopes.
>>
>>
>Again, these are not syntactic additions: what I am proposing is the
>syntactic status-quo with some changes to semantics. I really don't much
>care whether we keep the present syntax and adopt my proposed semantics,
>or modify the syntax so that event and fault variables are declared in
>the <onMessage> and <catch>elements; what I really don't want is the
>current syntax with the copy semantics.
>
>
>-maciej
>
>
>
>
>>
>>-----Original Message-----
>>From: Maciej Szefler [mailto:mbs@fivesight.com]
>>Sent: Thursday, September 25, 2003 9:12 AM
>>To: Satish Thatte
>>Cc: wsbpel@lists.oasis-open.org
>>Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler
>>
>>The differences in BPEL between copying and properly scoping the
>>variable would be as follows:
>>
>>-- SCOPING METHOD --
>><scope name="S">
>> <!-- no variables declared (none are used by this scope) -->
>> <eventHandler>
>> <onMessage variable="foo">
>> <!-- "foo" refers into the scope instantiated by the onMessage
>>(SE) -->
>> <scope name="SE">
>> <variable name="foo" />
>> <!-- "foo" is local to the scope in which it used -->
>> <activity-using-foo/>
>> </scope>
>> </onMessage>
>> </eventHandler>
>>
>> <faultHandlers>
>> <catch faultName="..." faultVariable="flt">
>> <scope name="SF1">
>> <variable name="flt" messageType="xx:fltType1" />
>> </scope>
>> </catch>
>> <catch faultName="..." faultVariable="flt">
>> <!-- the name "flt" can be reused, other "flt" was local to
>>scope "SF1" -->
>> <scope name="SF2">
>> <variable name="flt" messageType="xx:fltType2" />
>> </scope>
>> </catch>
>> </faultHandlers>
>></scope>
>>
>>-- COPY METHOD --
>><scope name="S">
>> <!-- variables used by event and fault handlers defined in
>>this scope
>> even though they are never initialized/used in this scope. -->
>> <variable name="foo" .... />
>>
>> <!-- different fault variable names need to be used for the
>> different fault types. -->
>>
>> <variable name="flt1" messageType="xx:fltType1" />
>> <variable name="flt2" messageType="xx:fltType2" />
>>
>> <eventHandler>
>> <onMessage variable="foo">
>> <scope name="SE">
>> <!-- no variables declared, although silently scope "SE" is
>> infused a new instance of variable "foo" from scope "S"
>> which hides scope "S"'s version of the variable -->
>>
>> ....
>> </scope>
>> </onMessage>
>> </eventHandler>
>>
>> <faultHandlers>
>> <catch faultName="..." faultVariable="flt1">
>> <scope name="SF1">
>> ..
>> </scope>
>> </catch>
>> <!-- again, second fault handler needs a different faultVariable
>>name,
>> to not clash with the first -->
>> <catch faultName="..." faultVariable="flt2">
>> <scope name="SF2">
>> ..
>> </scope>
>> </catch>
>> </faultHandlers>
>></scope>
>>
>>The big problem I see with the above "copy method" is that it requires
>>that variables are declared in a scope in which they do not belong.
>>Consider this similarl syntax for an analogy:
>>
>>method() {
>>
>> Exception1 ex1;
>> Exception2 ex2;
>> try {
>> foo();
>> } catch (ex1) {
>> ..
>> } catch (ex2) {
>> ..
>> }
>>}
>>
>>.. similar thing, variables defined in the wrong scope. The other
>>problem is the necessity of introducing "reproduce variable
>>from scope X
>>in scope Y (a child of X)" type language to the operational semantics;
>>this may not be that difficult but it just adds unnecessary
>>clutter. If
>>the forward reference thing scares people then I think the
>>suggestion of
>>adding a variable type attribute to the <onMessage> and
>><catch> elements
>>is, despite its faults, far superior to the copy method.
>>-maciej
>>
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: Satish Thatte [mailto:satisht@microsoft.com]
>>>Sent: Monday, September 22, 2003 5:41 PM
>>>To: Maciej Szefler; edwink@collaxa.com; Francisco Curbera
>>>Cc: wsbpel@lists.oasis-open.org
>>>Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler
>>>
>>>
>>>Maciej,
>>>
>>>Fault handlers can also be thought of as onFault event handlers in a
>>>sense (though they obviously have other consequences like failed
>>>completion of scope). We should at least be consistent
>>>
>>>
>>between fault
>>
>>
>>>handler and event handler syntax. Especially because fault
>>>names MAY be
>>>going away in WSDL 1.2 and if that happens they will become
>>>
>>>
>>even more
>>
>>
>>>similar.
>>>
>>>I don't have a strong preference for a specific syntax yet --
>>>could you
>>>post a couple of examples illustrating why the forward
>>>reference variant
>>>is better or simpler to understand?
>>>
>>>Satish
>>>
>>>-----Original Message-----
>>>From: Maciej Szefler [mailto:mbs@fivesight.com]
>>>Sent: Monday, September 22, 2003 7:12 AM
>>>To: edwink@collaxa.com; Francisco Curbera
>>>Cc: wsbpel@lists.oasis-open.org
>>>Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler
>>>
>>>I think you guys are trying to hard to map this into functional
>>>programming style. In the pass-by-value world, a functional argument
>>>merely exposes a variable declared inside the function scope to the
>>>calling scope (so it can be initialized by the caller); typing the
>>>argument in the function decleration is a notiational
>>>
>>>
>>convenience for
>>
>>
>>>the programmer so that he does not have to declare the
>>>
>>>
>>variables twice
>>
>>
>>>(ala old K&R style C declerations). From an operational
>>>
>>>
>>point of view
>>
>>
>>>there is no doubt that these variables are scoped within
>>>
>>>
>>the function
>>
>>
>>>(again, we're not talking about pass-by-reference aliases
>>>
>>>
>>here). Since
>>
>>
>>>we are not dealing with a functional language, it seems completely
>>>wrong-headed to me to be adding constructs that resemble functional
>>>notation simply because they are familiar. Lets not make this more
>>>complicated than it needs to be: we have everything we need to make
>>>onMessage behave like it should simply by specifying (in the
>>>operational
>>>semantics) which scope the name is resolved in. There is no
>>>reason to be
>>>afraid of a "forward reference" to a variable declared in the child
>>>scope: this is a rather antiquated and inappropriately applied
>>>prejudice. There is nothing that could be simpler or more natural in
>>>this context. The proposed alternatives, "copying" the variable, or
>>>"typing" the variable in the onMessage element are
>>>
>>>
>>round-about ways of
>>
>>
>>>getting the same result (that the variable name is resolved in the
>>>onMessage activity's scope). The "copying" option is bad because it
>>>makes us declare a variable in a scope in which it is completely
>>>unnecessary, and then adds complexity by forcing the
>>>
>>>
>>implementation to
>>
>>
>>>duplicate the variable in the correct scope. The "typing"
>>>option is bad
>>>because it attempts to introduce functional syntax in a
>>>
>>>
>>non-functional
>>
>>
>>>language, it needlessly adds more attribute elements to the
>>>syntax, and
>>>most importantly it further complicates implementation by
>>>
>>>
>>providing an
>>
>>
>>>alternative way of declaring variables within a scope.
>>>
>>>I would also disagree with the suggestion that parallel
>>>
>>>
>>event handling
>>
>>
>>>is unnecessary; I find this to be one of the most important
>>>features of
>>>the event handling mechanism, without it there is no way to do
>>>long-running request processing against a single BPEL
>>>
>>>
>>process instance
>>
>>
>>>like "request notification when process is half filled" or
>>>"handle bids
>>>from many suppliers". Granted there may be problems in implementing
>>>these uses cases in any case, but eleminating parallel
>>>
>>>
>>event handling
>>
>>
>>>will certainly make them impossible.
>>>
>>>-maciej
>>>
>>>-----Original Message-----
>>>From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
>>>Sent: Sun 9/21/2003 3:27 PM
>>>To: 'Francisco Curbera'
>>>Cc: Maciej Szefler; wsbpel@lists.oasis-open.org
>>>Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler
>>>
>>>
>>>
>>> +1. adding messageType to onMessage would be enough. But there
>>>is a side
>>> effect. We need to differentiate pick/onMessage and
>>>eventHandlers/onMessage.
>>> Meaning we need a new name for eventHandlers/onMessage
>>> Edwin
>>>
>>> > -----Original Message-----
>>> > From: Francisco Curbera [mailto:curbera@us.ibm.com]
>>> > Sent: Sunday, September 21, 2003 10:00 AM
>>> > To: edwink@collaxa.com
>>> > Cc: 'Maciej Szefler'; wsbpel@lists.oasis-open.org
>>> > Subject: RE: [wsbpel] Issue 36 - Multiple instances of event
>>>handler
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > It seems that the intended semantics we want to attach to the
>>> > variable attribute in onMessage corresponds to that of an
>>> > argument in a funcion/method declaration. That is, the
>>> > variable is declared by its appearing in the onMessage
>>> > statement itself; we are only missing the "type"
>>> > statement.
>>> >
>>> > I guess this is also consistent with the catch model Edwin
>>>mentions.
>>> >
>>> > Paco
>>> >
>>> >
>>> > This is consistent with the
>>> >
>>> >
>>> >
>>> >
>>>
>>> > "Edwin
>>> >
>>>
>>> > Khodabakchian" To:
>>> > "'Maciej Szefler'" <mbs@fivesight.com>,
>>> > <wsbpel@lists.oasis-open.org>
>>> > <edwink@collaxa.c cc:
>>> >
>>>
>>> > om> Subject: RE:
>>> > [wsbpel] Issue 36 - Multiple instances of event handler
>>>
>>> >
>>> >
>>>
>>> > 09/19/2003 03:25
>>> >
>>>
>>> > PM
>>> >
>>>
>>> > Please respond to
>>> >
>>>
>>> > edwink
>>> >
>>>
>>> >
>>> >
>>>
>>> >
>>> >
>>> >
>>> >
>>> > This reverse scope resolution seems a little bit black magic
>>> > to me. It we decide not to go down the path of serialization
>>> > because of sync performance issue, I think that we should
>>> > look at the syntax of catch. This will create the need to
>>> > have a separate syntax for onMessage in eventHandlers and
>>> > onMessage in pick. But it could be a good thing.
>>> > Edwin
>>> >
>>> > > -----Original Message-----
>>> > > From: Maciej Szefler [mailto:mbs@fivesight.com]
>>> > > Sent: Friday, September 19, 2003 10:24 AM
>>> > > To: wsbpel@lists.oasis-open.org
>>> > > Subject: [wsbpel] Issue 36 - Multiple instances of event
>>>handler
>>> > >
>>> > > Per the discussion at the face-to-face. My original though
>>>here was
>>> > > the the implicit scoping present in the BPEL syntax was
>>>responsible
>>> > > for this problem because it did not allow us to declare the
>>>message
>>> > > variable in the "most local" scope of the onMessage
>>> > handler. I won't
>>> > > go into too much detail because as Satish pointed it out
>>> > this premise
>>> > > is valid only if onMessage were an activity, and it is not.
>>> > >
>>> > > So, although I still think the syntax is still a bit
>>> > confusing as to
>>> > > scopes and activities (a <scope> is an activity without an
>>>implicit
>>> > > scope, and all other activity have an implicit scope,
>>> > except that in
>>> > > the implicit scope you cannot define variables, and
>>> > correlation sets,
>>> > > etc...), it is not responsible for this problem.
>>> > >
>>> > > Which brings me to the proposed solution; I still don't like
>>>it.
>>> > > Saying that a "copy" of the input variable in the onMessage
>>> > handler is
>>> > > made for each instance of the handler sounds like a hack,
>>> > and confuses
>>> > > the operational semantics. I think what we are trying to
>>> > say here is
>>> > > that the /name/ of the input message variable is /resolved/
>>> > not in the
>>> > > scope that contains the event handler, but in the scope of
>>>the
>>> > > activity started by the onMessage event. For example:
>>> > >
>>> > > <scope name="S">
>>> > > <!-- no variables declared -->
>>> > > <eventHandler>
>>> > > <onMessage variable="foo">
>>> > > <scope name="SE">
>>> > > <variable name="foo" />
>>> > > ....
>>> > > </scope>
>>> > > </onMessage>
>>> > > </eventHandler>
>>> > > </scope>
>>> > >
>>> > > In the above case because the name "foo" is evaluated in
>>> > the scope of
>>> > > the activity specified for the onMessage event, multiple
>>> > instances of
>>> > > the event will not use the same variable instance. In the
>>>following
>>> > > case:
>>> > >
>>> > > <scope name="S" >
>>> > > <variable name="foo" />
>>> > > <eventHandler>
>>> > > <onMessage variable="foo">
>>> > > <activityX>
>>> > > </onMessage>
>>> > > </eventHandler>
>>> > > </scope>
>>> > >
>>> > > the variable "foo" will be shared by all instances of the
>>>onMessage
>>> > > event handler, as the implicit scope of "activityX"
>>> > > does not define the "foo" variable and so we'll go to the
>>> > parent scope
>>> > > to resolve it, leading to resolution in scope "S" which is
>>>shared.
>>> > >
>>> > > I believe adopting the above language is cleaner in terms of
>>> > > operational semantics: fundamentally if the variable is used
>>>in the
>>> > > event handler it should not be declared in an enclosing
>>>scope, its
>>> > > like using a global variable to pass an argument to a
>>>function. the
>>> > > price is having to declare a scope as the activity for the
>>> > onMessage
>>> > > event (although if we could define a <variable> in the
>>> > implicit scope
>>> > > of an activity this would not be necessary).
>>> > >
>>> > > -maciej
>>> > >
>>> > >
>>> > > > -----Original Message-----
>>> > > > From: jevdemon@microsoft.com
>>>[mailto:jevdemon@microsoft.com]
>>> > > > Sent: Friday, September 19, 2003 10:23 AM
>>> > > > To: wsbpel@lists.oasis-open.org
>>> > > > Subject: [wsbpel] Groups - f2f-notes-9-18.doc uploaded
>>> > > >
>>> > > >
>>> > > > The document f2f-notes-9-18.doc has been submitted by John
>>>Evdemon
>>> > > > (jevdemon@microsoft.com) to the OASIS Web Services
>>> > Business Process
>>> > > > Execution Language TC document repository.
>>> > > >
>>> > > > Document Description:
>>> > > > Sid's notes from yesterday morning. Consider these to be
>>>"draft"
>>> > > > minutes...
>>> > > >
>>> > > > Download Document:
>>> > > >
>>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.p
>>> > > hp/3565/f2f-notes-9-18.doc
>>> > > >
>>> > > > View Document Details:
>>> > > >
>>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/document.p
>>> > > > hp?document_id=3565
>>> > > >
>>> > > >
>>> > > > PLEASE NOTE: If the above links do not work for you, your
>>>email
>>> > > > application may be breaking the link into two pieces. You
>>> > > may be able
>>> > > > to copy and paste the entire link address into the
>>> > address field of
>>> > > > your web browser.
>>> > > >
>>> > > > -OASIS Open Administration
>>> > > >
>>> > > >
>>> > > > To unsubscribe from this mailing list (and be removed from
>>> > > the roster
>>> > > > of the OASIS TC), go to
>>> > > >
>>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
>>> > > ave_workgroup.php.
>>> > >
>>> > >
>>> > > To unsubscribe from this mailing list (and be removed from
>>> > the roster
>>> > > of the OASIS TC), go to
>>> > >
>>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
>>> > > ave_workgroup.php.
>>> > >
>>> > >
>>> >
>>> >
>>> > To unsubscribe from this mailing list (and be removed from
>>> > the roster of the OASIS TC), go to
>>> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
>>> > ave_workgroup.php
>>> > .
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>To unsubscribe from this mailing list (and be removed from
>>>the roster of
>>>the OASIS TC), go to
>>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
>>>ave_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/le
>>ave_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_workgroup.php.
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]