OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler


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]