[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler
Sure. The incremental approach makes sense. I just wanted to highlight that the 2 additional proposal seem to only make sense when combined together: the purpose of the name change is to avoid having an optional (messageType attributes) and to re-enforce the fact that in one use of onMessage a new variable is declared and in another use of onMessage it is not. Edwin > -----Original Message----- > From: Assaf Arkin [mailto:arkin@intalio.com] > Sent: Tuesday, September 30, 2003 2:53 PM > To: edwink@collaxa.com > Cc: 'Satish Thatte'; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue 36 - Multiple instances of event handler > > If we start with one base proposal and include two additional > proposals that extend the base proposal, then first we make > life easier for everybody else because items 1 and 3-5 are > the same. So in a way they are voting first on items 1 and > 3-5, and then they vote on whether to add another change > (rename onMessage to onEvent) and separately on how they want > item 2 to work (from operation definition or using > messageType attribute). > > It also allows us to entertain more combinations, e.g. to > change onMessage to onEvent but not add messageType, or to > add messageType but retain onMessage to be consistent with > pick. But we can always role proposals 2 and 3 together and > so both changes have to be accepted in one package. > > arkin > > > Edwin Khodabakchian wrote: > > >Assaf, > > > >It seems that the 2 other proposals are really one > alternative proposal: > > > >PROPOSAL #2 (AKA EXPLICIT TYPING) > >1. eventHandlers/onMessage is renamed to > eventHandler/onEvent so that we > > can defined an extra attribute which explicitely declares the type > > of the variable > > > >2. the name of the variable is given in the > onEvent/@variable attribute > > > >3. the type of the varialbe is given in the onEvent/@messageType > >attribute > > > >4. the event handler activity declares a variable of that > name and type > > that is scoped to the event handler activity > > > >5. Upon receipt of the input message the event handler > > assigns the input message to the variable before proceeding > > to perform the event handler activity. > > > >6. Since the variable is scoped to that activity, two > > instances of the activity (whether executed seriallly or > > concurrently) do not operate on the same variable. > > > >The motivation for explicit typing reside in enhancing readability, > >type checking and consitency (see my previous email). > > > >Edwin > > > > > > > > > >>-----Original Message----- > >>From: Assaf Arkin [mailto:arkin@intalio.com] > >>Sent: Tuesday, September 30, 2003 2:12 PM > >>To: Satish Thatte > >>Cc: edwink@collaxa.com; wsbpel@lists.oasis-open.org > >>Subject: Re: [wsbpel] Issue 36 - Multiple instances of event handler > >> > >>To recap, my proposal is: > >> > >>1. The name of the variable is given in the onMessage/@variable > >>attribute. > >> > >>2. The variable type is the same as the type of the input message > >>defined by the operation referenced by onMessage. > >> > >>3. The event handler declares a variable of that name and > type that is > >>scoped to the event handler activity. > >> > >>4. Upon receipt of the input message the event handler assigns the > >>input message to the variable before proceeding to perform > the event > >>handler activity. > >> > >>5. Since the variable is scoped to that activity, two > instances of the > >>activity (whether executed seriallly or > >>concurrently) do not operate on the same variable. > >> > >>One proposal was to also change the name of onMessage to onAlert. > >>Another proposal was to add a messageType attribute that > indicates the > >>variable name and validate it against the operation input message > >>type. > >> > >>Are we at a point where we can vote on these proposals? > >> > >>arkin > >> > >> > >> > >>Satish Thatte wrote: > >> > >> > >> > >>>This is why I said "I hate to do this but .. " :-) > >>> > >>>So, onMessage and onAlarm for both pick and event handlers, > >>> > >>> > >>and onFault > >> > >> > >>>for fault handlers is OK with me as well. > >>> > >>>Satish > >>> > >>> > >>>-----Original Message----- > >>>From: Assaf Arkin [mailto:arkin@intalio.com] > >>>Sent: Friday, September 26, 2003 12:29 PM > >>>To: Satish Thatte > >>>Cc: edwink@collaxa.com; wsbpel@lists.oasis-open.org > >>>Subject: Re: [wsbpel] Issue 36 - Multiple instances of > event handler > >>> > >>>I would not mind covering these changes under issue 36, since we > >>>already > >>> > >>>discusses them in this thread. > >>> > >>>I also like onFault better than catch, but I don't understand the > >>>reason > >>> > >>>to have onMessage in pick and onEvent in fault handler. > >>> > >>> > >>Would we still > >> > >> > >>>call a time-event onAlarm in both cases? > >>> > >>>arkin > >>> > >>>Satish Thatte wrote: > >>> > >>> > >>> > >>> > >>> > >>>>I see. Your reasons are good. This and catch would > >>>> > >>>> > >>otherwise be the > >> > >> > >>>>only two places where variables are declared with types > implicitly > >>>>inferred from WSDL. Just as in the case of the > createInstance and > >>>>correlation initiation attributes, extra annotation is good > >>>> > >>>> > >>for static > >> > >> > >>>>checking and readability. I would then require the type in catch > >>>>handlers as well for the same reasons. > >>>> > >>>>I disagree that this can be done for inputVariable etc > since those > >>>>variables are not local to an invoke/receive. > >>>> > >>>>I hate to do this but I have to say I like the idea of > >>>> > >>>>A. Changing onMessage to onEvent in event handlers B. > >>>> > >>>> > >>Changing catch > >> > >> > >>>>to onFault in fault handlers > >>>> > >>>>I would encourage you to open a new issue unless Assaf > >>>> > >>>> > >>wants to fold > >> > >> > >>>>this into his proposal. > >>>> > >>>>Satish > >>>> > >>>>-----Original Message----- > >>>>From: Edwin Khodabakchian [mailto:edwink@collaxa.com] > >>>>Sent: Friday, September 26, 2003 12:01 PM > >>>>To: Satish Thatte; 'Assaf Arkin' > >>>>Cc: wsbpel@lists.oasis-open.org > >>>>Subject: RE: [wsbpel] Issue 36 - Multiple instances of > event handler > >>>> > >>>>We prefer explicit eventHandler/onMessage for the following "soft" > >>>>reasons: > >>>> > >>>>READABILITY - It makes it easier for a person reading the > >>>> > >>>> > >>.bpel file > >> > >> > >>>>to determine the type of all the variable without having > to browse > >>>>through WSDL files and/or separate artifact. > >>>> > >>>>TYPE CHECKING - The BPEL processor can actually perform checking > >>>> > >>>> > >>>> > >>>> > >>>between > >>> > >>> > >>> > >>> > >>>>the > >>>>declared type (and how it is used in the BPEL process) > and the type > >>>>defined in the WSDL. It you change the WSDL type, the > compiler can > >>>>actually > >>>> > >>>> > >>>> > >>>> > >>>spot > >>> > >>> > >>> > >>> > >>>>inconsistency. > >>>> > >>>>INCONSISTENCY - The same WSDL-based type inference that be > >>>> > >>>> > >>applied to > >> > >> > >>>>all inputVariable, outputVariable and variable. Which means > >>>> > >>>> > >>that the > >> > >> > >>>>messageType attribute of <variable> is redundant. -> there > >>>> > >>>> > >>is a small > >> > >> > >>>> > >>>> > >>>> > >>>> > >>>inconsistency. > >>> > >>> > >>> > >>> > >>>>For the following reasons we would prefer a explicit typing like: > >>>> > >>>><eventHandlers> > >>>> <onEvent variable="statusRequest" > >>>>messageType="fin:LoanProcessing" > >>>>...> > >>>> Activity > >>>> </onEvent> > >>>></eventHandlers> > >>>> > >>>>This is a rather small change: > >>>>1) rename onMessage to onEvent so that there is no confusion with > >>>>pick/onMessage > >>>>2) onEvent = existing onMessage + messageType > >>>> > >>>>Edwin > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Satish Thatte [mailto:satisht@microsoft.com] > >>>>>Sent: Friday, September 26, 2003 5:23 AM > >>>>>To: edwink@collaxa.com; Assaf Arkin > >>>>>Cc: wsbpel@lists.oasis-open.org > >>>>>Subject: RE: [wsbpel] Issue 36 - Multiple instances of > >>>>> > >>>>> > >>event handler > >> > >> > >>>>>Edwin, > >>>>> > >>>>>Can you share with us why you would prefer the explicit typing? > >>>>> > >>>>>Satish > >>>>> > >>>>>________________________________ > >>>>> > >>>>>From: Edwin Khodabakchian [mailto:edwink@collaxa.com] > >>>>>Sent: Thu 9/25/2003 9:58 PM > >>>>>To: 'Assaf Arkin'; Satish Thatte > >>>>>Cc: wsbpel@lists.oasis-open.org > >>>>>Subject: RE: [wsbpel] Issue 36 - Multiple instances of > >>>>> > >>>>> > >>event handler > >> > >> > >>>>> > >>>>>Assaf, > >>>>> > >>>>>Thank you for the clarification. This solves the > problem. It seems > >>>>>that the group is preferring an implicit type definition > >>>>> > >>>>> > >>inferred by > >> > >> > >>>>>the WSDL rather than an explicit typing through > messageType. It is > >>>>>not our preference but we can live with that. > >>>>> > >>>>>Also there is a small typo: the text below should refer to > >>>>>onMessage/@variable. > >>>>> > >>>>>Thank you, > >>>>> > >>>>>Edwin > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: Assaf Arkin [mailto:arkin@intalio.com] > >>>>>>Sent: Thursday, September 25, 2003 9:43 PM > >>>>>>To: Satish Thatte > >>>>>>Cc: Maciej Szefler; wsbpel@lists.oasis-open.org > >>>>>>Subject: Re: [wsbpel] Issue 36 - Multiple instances of > >>>>>> > >>>>>> > >>event handler > >> > >> > >>>>>>The outline of my proposal would be: > >>>>>> > >>>>>>1. The name of the variable is given in the > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>onMessage/@inputVariable > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>attribute. > >>>>>> > >>>>>>2. The variable type is the same as the type of the > input message > >>>>>>defined by the operation referenced by onMessage. > >>>>>> > >>>>>>3. The event handler declares a variable of that name and > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>type that is > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>scoped to the event handler activity. > >>>>>> > >>>>>>4. Upon receipt of the input message the event handler > >>>>>> > >>>>>> > >>assigns the > >> > >> > >>>>>>input message to the variable before proceeding to perform > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>the event > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>handler activity. > >>>>>> > >>>>>>5. Since the variable is scoped to that activity, two > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>instances of the > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>activity (whether executed seriallly or > >>>>>>concurrently) do not operate on the same variable. > >>>>>> > >>>>>>Comments? > >>>>>> > >>>>>>arkin > >>>>>> > >>>>>>Satish Thatte wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Wonderful. Since you are the champion, you get to propose > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>the solution! > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Cheers, > >>>>>>>Satish > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>-----Original Message----- > >>>>>>>From: Assaf Arkin [mailto:arkin@intalio.com] > >>>>>>>Sent: Thursday, September 25, 2003 8:51 PM > >>>>>>>To: Satish Thatte > >>>>>>>Cc: Maciej Szefler; wsbpel@lists.oasis-open.org > >>>>>>>Subject: Re: [wsbpel] Issue 36 - Multiple instances of > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>event handler > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>Satish, I perfectly agree with you. > >>>>>>> > >>>>>>>The "copy" as I understand it requires two variables to be > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>defined. My > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>proposal was for the event handler to declare a variable > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>that is local > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>to the event handler based on the message type and assign > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>the input > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>message to that variable. This does not require the > >>>>>>> > >>>>>>> > >>variable to be > >> > >> > >>>>>>>defined in the same (or enclosing) scope as the event > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>handler. From > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>what > >>>>>>> > >>>>>>>I can tell this requires no change to the syntax. > >>>>>>> > >>>>>>>And since Satish offered the catch/faultVariable as an > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>example, I think > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>there's a general rule here that could apply in more > >>>>>>> > >>>>>>> > >>than one case. > >> > >> > >>>>>>>arkin > >>>>>>> > >>>>>>>Satish Thatte wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Maciej, > >>>>>>>> > >>>>>>>>I seem to have misunderstood what we agreed at the > >>>>>>>> > >>>>>>>> > >>recent F2F. I > >> > >> > >>>>>>>>thought everyone present agreed including Assaf that > we need the > >>>>>>>>*semantics* of the two syntactic variants I described > >>>>>>>> > >>>>>>>> > >>below. We > >> > >> > >>>>>>>>didn't really discuss syntax in detail. > >>>>>>>> > >>>>>>>>Assaf, if you disagree please let us know. > >>>>>>>> > >>>>>>>>Satish > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>-- > >>>>>>"Those who can, do; those who can't, make screenshots" > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>----------------------------------------------------------- > >>>>> > >>>>> > >>---------- > >> > >> > >>>>>- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Assaf Arkin > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>arkin@intalio.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Intalio Inc. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>www.intalio.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>The Business Process Management Company > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>(650) 577 4700 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>This message is intended only for the use of the > >>>>>> > >>>>>> > >>Addressee and may > >> > >> > >>>>>>contain information that is PRIVILEGED and CONFIDENTIAL. > >>>>>>If you are not the intended recipient, dissemination of this > >>>>>>communication is prohibited. If you have received this > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>communication > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>in error, please erase all copies of the message and its > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>attachments > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>and notify us immediately. > >>>>>> > >>>>>> > >>>>>> > >>>>>>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_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]