[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 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.
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]