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