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] Re: completionHandler example


??  You mean the parent of the completed scope?  Which has no access to
the data of the completed scope?

-----Original Message-----
From: Chris Keller [mailto:chris.keller@active-endpoints.com] 
Sent: Wednesday, October 06, 2004 11:39 AM
To: Satish Thatte
Cc: 'wsbpeltc'; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example

Right, that is why I said this event is caught by the parent scope.
 
-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Wednesday, October 06, 2004 2:31 PM
To: Chris Keller
Cc: wsbpeltc; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example

Don't you think it will be strange to say that the scope is finished,
existing events will be terminated, no new events will be accepted,
*except* for this special beast which we choose to call an event?  It is
also obviously different in having a very different "communication
channel".

-----Original Message-----
From: Chris Keller [mailto:chris.keller@active-endpoints.com] 
Sent: Wednesday, October 06, 2004 11:00 AM
To: Satish Thatte
Cc: 'wsbpeltc'; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example

I don't think we need any special pleading.  Since the current
specification
says even under termination a scope does not complete until all its
event
handlers have completed (either normally or abnormally via
forcedTermination). It seems the complete event is naturally the last
event
and doesn't need to cut in front or cancel them.  In fact one could
argue
that they must be caught by the parent scope's event handlers.

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Wednesday, October 06, 2004 1:32 PM
To: Chris Keller
Cc: wsbpeltc; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example

The reason I call it false economy is that one will have to do a bunch
of special pleading -- this event handler will cut in front of the queue
of all the other pending events and cancel them.  This event handler is
not really concurrent with the scope -- it only runs after the activity
in the scope has be completed (or forced to terminate). This event is
not external and has no communication channel.  Etcetera.  Reminiscent
of the special pleading for the forcedTermination fault handler.

-----Original Message-----
From: Chris Keller [mailto:chris.keller@active-endpoints.com] 
Sent: Wednesday, October 06, 2004 6:36 AM
To: Satish Thatte
Cc: 'wsbpeltc'; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example

I think that was already clear from your comments, but thanks for
helping
think this through anyway.  I believe in order to make informed
decisions
about proposals it is necessary to look at it from different angles.  As
you
would expect I disagree with your false economy statement and rather
think
of it from the standpoint of "practical extensibility".  Given that
extensible typed events and a mechanism for handling them have already
proven to be useful in so many applications.

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Wednesday, October 06, 2004 12:58 AM
To: Chris Keller
Cc: wsbpeltc; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example

To be clear I am not really endorsing this, but it is interesting and
instructive to think through -- as a concrete resolution I am afraid
this is
false economy of the same sort that we are likely to end up having to
reverse in the case of the forcedTermination "fault handler".

________________________________

From: Satish Thatte
Sent: Tue 10/5/2004 9:53 PM
To: Chris Keller
Cc: 'wsbpeltc'; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example


I imagine that your idea is that an event would only be delivered to the
(implicitly or explicitly) named scope that is completed.  Intermediate
scopes would be summarily completed without any handlers.

________________________________

From: Chris Keller [mailto:chris.keller@active-endpoints.com]
Sent: Tue 10/5/2004 2:09 PM
To: Satish Thatte
Cc: 'wsbpeltc'; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example



Satish,

Right, we would still need the semantics you have described for
<complete/>,
this proposal was just an amendment to your proposal.  The <complete/>
would
still execute the termination of concurrent activities (which won't
terminate the scope as that causes a termination event).  The scope
would
then complete at which point the completion event takes place.  If the
user
executes <complete name="cancelOrder"/> then when the complete takes
place
the additional name field would be made available to the event
processing.
That way <eventHandlers><onEvent type="completion" name="cancelOrder">
...
</onEvent></eventHandlers> would execute.  The decision on which event
handler to call would have a precedence order like fault
handler/catch...

I guess the main thing I am thinking about here is making greater use of
the
event handler mechanisms where possible and not creating new scope
areas.
In the future this mechanism could be extended for user-defined event
types,
those types could be used for intra-process messaging/signaling :).
Although I don't think we should go that far in this version of the
spec.

- Chris

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Tuesday, October 05, 2004 3:06 PM
To: Chris Keller
Cc: wsbpeltc; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example

I am still missing something.  If <complete/> just generates an event,
then it doesn't complete the scope -- or do you mean that it does all of
the things like terminating concurrent activities that we talked about
earlier but instead of a completion handler we have an event handler
that can "subscribe" to this event?

Will think about your named completion ideas some more.

-----Original Message-----
From: Chris Keller [mailto:chris.keller@active-endpoints.com]
Sent: Tuesday, October 05, 2004 11:43 AM
To: Satish Thatte
Cc: 'wsbpeltc'; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example

Satish,

No, I don't mean we add a complete activity that gets called in the
event
handler, not sure how you read that in what I said.  My thinking is
instead
of adding new top level handlers to scopes we add new event types, which
can
be listened for in the scope/eventHandlers container.

In terms of completion handling my thinking was that scope completion
always
happens when no fault is thrown.  In the new case it is triggered
explicitly
by the addition of your new activity <complete/>.  Whether or not
someone
cares about the actual event which is generated by the completion is a
different story.  That is what is addressed by your completionHandler
and my
proposal to have completion be an event.

Named completion could be accomplished by the addition of a message or
name
attribute attribute to the complete activity you have suggested such as
<completion message="..."/>.   Then we use the either use the matching
mechanism of the message and event handler for the named type of event
(i.e.
completion in this case), since <onEvent> already includes an attribute
to
receive a message.  Or we add a new kind of matching for named events of
a
type (e.g., <onEvent type="completion" name="myname"/>).

- Chris

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Tuesday, October 05, 2004 2:16 PM
To: Chris Keller
Cc: wsbpeltc; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example

But how would the event handler force completion?  Do you mean we add a
complete activity that gets called in the event handler but only
completes the scope the handler is attached to?  IOW no completion
handler and no named completion?

-----Original Message-----
From: Chris Keller [mailto:chris.keller@active-endpoints.com]
Sent: Tuesday, October 05, 2004 7:14 AM
To: Satish Thatte
Cc: 'wsbpeltc'; ygoland@bea.com
Subject: RE: [wsbpel] Re: completionHandler example

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






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