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 - 53 - Final end of scopes ( was RE: [wsbpel] Issue 3 -- proposal for discussion)


Absent the use of enableInstanceCompensation shouldn't it be up to the
process itself to decide how long its compensation handlers stay active?

For example, many airlines do not allow you to cancel or rebook a flight
less than 24 hours before the flight is scheduled to leave. Therefore a
process that represents that booking is free to terminate itself and its
compensation handlers 23 hours and 59 minutes before the flight is to leave
since no compensation is possible.

Another example is if a process that is handling a purchase order receives a
message confirming that the order has been delivered and that the process
may not terminate.

In many if not most cases processes are able to self terminate, including
getting rid of their compensation handlers, without having an explicit
coordination protocol. It is true that there is always an implicit
coordination protocol (e.g. the 24 hour deadline or receiving the 'all is
well' message) but in most cases that implicit protocol seems more than
sufficient.

This is not to say that there isn't a role for explicit coordination
protocols, it is simply to argue that providing for support for explicit
coordination protocol probably shouldn't be at the top of our stack of
priorities.

	Just my two Euros,

		Yaron

> -----Original Message-----
> From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
> Sent: Monday, October 13, 2003 10:18 AM
> To: Harvey Reed; Satish Thatte; ygoland@bea.com;
> wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Issue - 53 - Final end of scopes ( was RE: [wsbpel]
> Issue 3 -- proposal for discussion)
> 
> 
> 
> This isn't really quite on issue 3, for which the main 
> following thread
> has covered the ground well, so I've changed the subject.
> 
> Concerning Harvey's last point, that could be the role of a 
> coordination
> or business transaction protocol, telling the scope that it should now
> be irrevocably finalised, one way or the other.
> 
> The proposals we made at Redmond we limited the business transaction /
> coordination protocol control to process level, rather than 
> digging into
> the scope structure.  I'd assumed (and wondered about the wisdom) that
> otherwise all scopes stay open and potentially compensatable (or
> finalizable = confirmable/cancellable) until the process 
> exits. However,
> if the process itself has enableInstanceCompensation then, absent a
> coordination protocol, its compensationHandlers must stay available
> until the sun goes cold. 
> 
> 
> Peter
> 
> > -----Original Message-----
> > From: Harvey Reed [mailto:hreed@sonicsoftware.com] 
> > Sent: 08 October 2003 21:31
> > To: 'Satish Thatte'; ygoland@bea.com; wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] Issue 3 -- proposal for discussion
> > 
> > 
> > Interesting, this exact point came up today in a meeting with 
> > our engineers. The question was whether there was a way to 
> > tell the persistent image of a scope that it can go away. 
> > 
> > Presumably, all scopes have to remain available until the 
> > outermost scope completes. I can't visualize how we could 
> > reliably and selectively kill "uneeded" scopes.
> > 
> > ++Harvey
> > 
> > 
> > 
> > -----Original Message-----
> > From: Satish Thatte [mailto:satisht@microsoft.com] 
> > Sent: Wednesday, October 08, 2003 4:26 PM
> > To: ygoland@bea.com; wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] Issue 3 -- proposal for discussion
> > 
> > Yaron,
> > 
> > It should be fairly straightforward to detect which non-local 
> > variables are actually used in compensation handlers and 
> > persist only those.  What you are suggesting is an extra 
> > annotation that allows additional verification of intent via 
> > redundancy.  Seems OK though a bit onerous, and nothing at 
> > all to do with cost.  Do other people have opinions?
> > 
> > The bigger issue for cost is detecting when a scope snapshot 
> > is no longer needed because there is no "path" left to invoke 
> > it.  In other words, snapshot GC.
> > 
> > Satish
> > 
> > -----Original Message-----
> > From: Yaron Goland [mailto:ygoland@bea.com] 
> > Sent: Wednesday, October 08, 2003 1:10 PM
> > To: Satish Thatte; wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] Issue 3 -- proposal for discussion
> > 
> > Is one of the practical consequences of proposal 2 that all 
> > scope variables must be persisted when the scope successfully 
> > completes if
> > either:
> > 	A) The scope has a non-default compensation handler or
> > 	B) The scope's variables are 'visible' from a scope 
> > with a non-default compensation handler (e.g. imagine if S1 
> > and S3 had compensation handlers but S2 just had a default 
> > compensation handler. In that case S2 would still need to 
> > persist its variables since they would be 'visible' from S3)?
> > 
> > Doesn't this seem a bit expensive? BPEL processes can run for 
> > months or even years, building up lots of scopes all of whose 
> > variables would have to be persisted. 
> > 
> > Might it not be more economical to include an attribute that 
> > can be included on variable declarations to define which 
> > variables should be available for use by compensation handlers? 
> > 
> > Couldn't static analysis then catch cases where a 
> > compensation handler attempts to access a variable which has 
> > not been marked as being available for compensation handlers?
> > 
> > 	Thanks,
> > 
> > 			Yaron
> > 
> > > -----Original Message-----
> > > From: Satish Thatte [mailto:satisht@microsoft.com]
> > > Sent: Wednesday, October 08, 2003 7:07 AM
> > > To: wsbpel@lists.oasis-open.org
> > > Subject: RE: [wsbpel] Issue 3 -- proposal for discussion
> > > 
> > > 
> > > One more time - this time with a more accessible JPEG 
> > picture courtesy 
> > > of Sid Askary.
> > > 
> > > Better formatted version of the same mail ..
> > > 
> > > BPEL currently specifies that a compensation handler lives in
> > > a snapshot
> > > world in which the state of the associated scope and all enclosing
> > > scopes has been preserved as it was when the associated scope 
> > > completed.
> > > There is an outstanding BPEL issue (Issue#3) that points out 
> > > that there
> > > is a need for compensation handlers to affect and be 
> affected by the
> > > "current state of the world".  
> > > 
> > > Proposal #1: The proposal on the table has been to add 
> inbound and 
> > > outbound parameters to compensation handlers to allow invokers of 
> > > compensation to send data into and get data out of the 
> compensation 
> > > process.
> > > 
> > > Proposal #2:  Choreology put an alternative proposal on 
> the table. 
> > > Restated, it basically says that compensation handlers 
> > always see the 
> > > current state of the world.  The current state of the world for 
> > > completed scopes is their state as it was at the time of 
> > completion. 
> > > They are in suspended animation because their 
> compensation handlers 
> > > are still alive and therefore their execution may "continue" in
> > > compensation
> > > mode.  Thus for enclosing scopes the compensation handler 
> > either sees
> > > live state (if the scope is not completed) or the state of 
> > > the scope as
> > > it was when that scope completed.  
> > > 
> > > In the attached picture showing three nested scopes S1, S2
> > > and S3, their
> > > compensation handlers C1, C2, C3, and failure handlers F1 and 
> > > F2, we may
> > > have an error handling call stack F1->C2->C3.  In that case 
> > > C3 will see
> > > the state of S2 as it was when S2 completed.  However that is 
> > > also what
> > > C2 is seeing and C2 has called C3, therefore there is a 
> > consistency of
> > > visible state in the call stack.
> > > 
> > > The positives and negatives of these two proposals mirror
> > > each other.  A
> > > positive aspect of the second proposal is that parameters are 
> > > not needed
> > > for data flow to and from live state to compensation handlers, and
> > > compensation handlers with live state contact can be used 
> in default
> > > compensation, unlike the first proposal.  The negative 
> > aspect is that
> > > compensation handlers will now participate in concurrency 
> > > control issues
> > > relating to live state, and will need to use serializable 
> > scopes when
> > > they touch non-local state, again unlike the first proposal.  The
> > > concurrency control problem also has an impact on Issue#10 
> > which deals
> > > with serialization of compensation handlers.
> > > 
> > > On the whole, given the alternatives, the second alternative is 
> > > preferable, especially because it maintains default compensation 
> > > semantics.  I propose to resolve Issue 3 along the lines of the 
> > > Proposal #2.
> > > 
> > > Satish
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 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.
> 
> 
> 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.
> 
> 

<<attachment: winmail.dat>>



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