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