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] Resolution to issue 10 - Implicit compensation Handler


The problem I was referring to was: even if you KNEW the completion
order by some magic of shared data, there is no way to write custom
handlers to do anything except depth-first traversal (either sequential
or parallel) of the tree of compensation handlers, because no control
dependencies across non-nested compensation handlers are allowed in
explicit models.  Whereas the proposal I made for default compensation
order enables a certain amount of breadth-first traversal with implied
control dependencies across non-nested compensation handlers.

Satish

-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com] 
Sent: Friday, December 12, 2003 9:46 AM
To: Satish Thatte; 'Sid Askary'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation
Handler

Hum.... I'm not sure what you mean. I put some thoughts below as to what
I think you might mean but I'm guessing I missed the particular scenario
you are discussing. Could you please expand on your point about custom
handlers not being able to do what default handlers can do?

	Thanks,

			Yaron

P.S. The default compensation handler has two magical abilities - it can
compensate all sub-scopes even if they aren't named and it can do so in
the reverse order in which they were created (with some sort of tie
breaking algorithm).

For a custom compensation handler to replicate the "call compensation on
all sub-scopes' behavior it must be able to find all its sub-scopes
which only requires that they all be named. That is kind of a pain but
doesn't seem too onerous. The spec even provides for the special
sub-case where you have a sub-scope contained in a loop. Section 13.3
says "If a scope being compensated by name was nested in a loop, the
instances of the compensation handlers in the successive iterations are
invoked in reverse order."

So I would say that the custom compensation handlers can safely pass the
bar of 'call compensate on all sub-scopes', you just need to make sure
they are all named.

The second bar, the ability to call compensation handlers in the reverse
order in which they were completed, is impossible to pass for custom
compensation handlers in cases where a flow without links is involved
since it is impossible to know at design time when the flows will finish
at run time. One possible, deeply nasty, solution to this problem is to
stick links into the last activities in the flows so as to force a
certain completion order but I suspect that rather misses the point. I
can imagine how we could solve this problem but it seems like more
trouble than it is worth. What's the use case?

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Thursday, December 11, 2003 5:26 PM
> To: ygoland@bea.com; Sid Askary; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation
> Handler
> 
> 
> Sid and Yaron,
> 
> My main concern with my own proposal is the fact that the default
> behavior cannot be achieved with custom handlers, which is a 
> fault in my
> proposal.  Someone (cannot recall who) brought that up during the face
> to face and it gave me pause.  Need to think about that some more.  In
> the mean while let us wait for Peter's comments.
> 
> Satish
> 
> -----Original Message-----
> From: Yaron Goland [mailto:ygoland@bea.com] 
> Sent: Thursday, December 11, 2003 3:42 PM
> To: 'Sid Askary'; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation
> Handler
> 
> +1
> 
> > -----Original Message-----
> > From: Sid Askary [mailto:saskary@nuperus.com]
> > Sent: Tuesday, December 09, 2003 1:46 PM
> > To: wsbpel@lists.oasis-open.org
> > Subject: [wsbpel] Resolution to issue 10 - Implicit 
> > compensation Handler
> > 
> > 
> > Satish,
> > As I said, I think your solution (the reverse temporal order) 
> > is a good one.  I think I have a simple compromise: that we 
> > add a sentence to the effect that 
> > 
> > " Note: Sole reliance on implicit compensation handlers as a 
> > programming construct or as a means of defining default 
> > system behavior is not recommended."
> > 
> > This may address both the "programmatic" (Yaron's) and 
> > default behavior (my own) assumptions.   
> > 
> > Not sure about Peter's concern.
> > 
> > - Sid.
> > 
> > 
> > 
> > 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_workgr
oup.php.






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