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