[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler
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. >> >> >> >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]