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