[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler
Fine with me. -----Original Message----- From: Assaf Arkin [mailto:arkin@intalio.com] Sent: Tuesday, September 30, 2003 3:44 PM To: edwink@collaxa.com Cc: Satish Thatte; wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue 36 - Multiple instances of event handler Then unless anyone objects, I would restructure it as two different proposals with a common base. arkin Edwin Khodabakchian wrote: >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]