RE: [wsbpel] Re: completionHandler example

["Chris Keller" <chris.keller@active-endpoints.com>]

Satish,

I am also unsure of the point of failure to which you are eluding, but in
general support some of the concepts you are proposing.  I would suggest a
change to your recent proposed additions, completion and termination
handlers, to make it easier to add potentially more in the future (e.g.,
finally and user-defined events), without the introduction of new elements.
I suggest that we change the onEvent mechanism to deal more generically with
event types.  The additions you have proposed are essentially events
generated by scopes.  So the idea would be to allow onEvent to include a
type.  For example:

 <eventHandlers>
	<onEvent type="completion" ...> ... </onEvent>
 </eventHandlers>

The default type could be "message" (or "receive", pick a good name), which
is the current usage of onEvent.

Thoughts?

- Chris

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Monday, October 04, 2004 8:05 PM
To: Satish Thatte
Cc: wsbpeltc
Subject: [wsbpel] Re: completionHandler example

But Satish, that is exactly what my example does. Could you please be 
more specific in identifying the point of failure?
	Thanks,
		Yaron

Satish Thatte wrote:
> 
> 
> That doesn't work if you want to do cascading completions aka named
> completions.
> 
> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Thursday, September 30, 2004 11:17 AM
> To: Satish Thatte
> Cc: wsbpeltc
> Subject: Re: completionHandler example
> 
> I realize why putting the completion handler logic before the complete
> doesn't work but why doesn't putting it after the completion handler
> work?
> 
> scope
>     variables
>        variable name="MessageTrackerVariable"...
>     sequence
>        scope wrapper
>           flow
>              scope A_end_in_complete_to_wrapper
>                 ...
>              scope B_end_in_complete_to_wrapper
>                 ...
>              scope C_end_in_complete_to_wrapper
>                 ...
>        scope CompletionHandler
>           (Check MessageTrackerVariable and see if any cleanup is
> needed)
> 
> Because the exit point of a completed scope is always well defined can't
> 
> the completion handler logic be placed after the completed scope?
> 
>         Yaron
> 
> 
> Satish Thatte wrote:
>  >
>  >
>  > Yaron,
>  > 
>  > During the F2F you asked for a completionHandler example.  Here is my
>  > try with some explanations.  Please let me know if this makes sense to
> you.
>  >
>  > 
>  > Satish
>  > 
>  >
>  > The completionHandler is the common process logic required at all
> points
>  > of premature completion within a scope.  The only difference between
>  > copying it just before each occurrence of a <complete/> activity thus
>  >
>  > 
>  >
>  > <sequence>
>  >
>  >     <completionHandler logic>
>  >
>  >     <complete/>
>  >
>  > </sequence>
>  >
>  > 
>  >
>  > and the proposed completionHandler feature is that the
> completionHandler
>  > logic executes *after* termination of all activities in the
> prematurely
>  > completed scope.  Thus it is a pure macro if the prematurely completed
> 
>  > scope does not contain concurrent activities.  Many examples of the
> use
>  > of premature completion, e.g., completion of N out of M activities in
> a
>  > flow, do involve concurrency.  Consider a case where M suppliers had
>  > been contacted concurrently and the process was waiting for
> asynchronous
>  > responses (forgive the use of the word :-)) from them.  After at least
> N
>  > of them send responses the scope completes.  Suppose the conversation
>  > with each supplier is wrapped in a scope and a terminationHandler is
>  > used to inform a supplier whose conversation was forcibly terminated
>  > that their response is not needed.  But perhaps we did not or could
> not
>  > ensure that *exactly* N replies arrive because the race was too tricky
> 
>  > to control.  Thus it is possible that more than N responses arrived. 
>  > The completion handler could detect this situation, pick the N we
> really
>  > want and inform the rest that their responses have been rejected so
> that
>  > we exit the scope cleanly with exactly N accepted responses.
>  >
> 

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.