[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]