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 - Proposal to vote - Multiple instances of event handler


My 2 cents on the options.

The advantage of Assaf's option 1 is minimality and consistency with
"pick".  

The disadvantage is that we now have a variable declaration where the
type is specified externally.  

Related issue regarding broken catch syntax (issue 68) will raise this
problem again: when the fault name is missing the type must be
specified.  

I prefer the regularity of always declaring the type when you declare a
variable, whether within <variables> or catch handlers or event
handlers.

An advantage of option 2 is redundancy that is an aid to static
checking, along the same lines as the createInstance attribute on an
initial receive.  

Satish

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Tuesday, September 30, 2003 7:51 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue 36 - Proposal to vote - Multiple instances of
event handler

Proposal to resolve issue 36.

The semantics of event handler would be changed to allow the variable
used to capture the input message to be treated local to the event
handler instance:

1. The name of the variable is given in the variable attribute.

2. The variable type must be the same as the type of the input message
defined by referenced operation.

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.

 From that base proposal we have to options that we should vote on:

Option 1:

1. Retain the element name onMessage

2. The variable type is derived from the message type used as input by
the referenced operation

Option 2:

1. Rename eventHandler/onMessage to eventHandler/onEvent

2. The attribute messageType specifies the variable type by referencing
the message type definition using its QName.

arkin






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_workgr
oup.php.





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