Re: [wsbpel] RE: completionHandler example

["Yaron Y. Goland" <ygoland@bea.com>]

Indeed, but this begs the question - are there compelling use cases 
where real world programmers are likely to use intermediate completion 
logic with named completion?

I'm having trouble coming up with use cases I think are compelling 
enough to add yet another type of handler to BPEL scopes. Could you 
please share with us your use cases that made it clear to you that 
adding a new type of scope handler is justified?

	Thanks,

		Yaron

Satish Thatte wrote:
> 
> 
> I was too cryptic.  Cascading completion handlers are not a necessity.
> I was simply pointing out that any time the scope you are completing is
> intermediate, i.e., is not the named scope in named completion, writing
> any completion logic sequentially following the occurrence of that scope
> will not work.  Thus the "logic sequentially following the occurrence of
> that scope" method is too fragile (what if someone adds a new completion
> activity inside my scope?).
> 
> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Thursday, September 30, 2004 2:16 PM
> To: Satish Thatte
> Cc: wsbpeltc
> Subject: Re: [wsbpel] RE: completionHandler example
> 
> Doesn't this strike you as a bit complex? How many programmers are ever
> going to use a cascading completion set? Is the usage large enough that
> it justifies adding yet another type of handler to BPEL?
> 
> The use case for named completion is pretty obvious given that in BPEL
> you really can't do anything without declaring a scope so named
> completion is a necessity. But I'm having trouble seeing most or even a
> significant number of users implementing code that not only uses named
> completion but has a cascading set of completion handlers as well.
> 
> Could you help me understand the use cases that are likely to occur in
> real world code?
> 
>         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_workgr
> oup.php.
>  >
>  >
>