RE: Re: [wsbpel] Issue - 1 - Permeability of scopes

["Satish Thatte" <satisht@microsoft.com>]

Goran,
 
First let me say that I understand your misgivings.  This is a complex interaction of features and there is no "obvious" answer and I for one am definitely willing to rethink the ideas.
 
But there is a subtle point regarding scopes-as-source that you seem to have missed.  You wrote
 
> If the intent is that an enclosing scope, serializable or not, compensatable or not, reversible or not, or 
> whatever, must complete successfully before the control link is evaluated, 
> then the SCOPE SHOULD BE THE SOURCE FOR THE CONTROL LINK.

However, consider a scope that has a fault handler that does not rethrow the fault.  Now a link leaving the (non permeable) scope would have a status of "true" if the scope completes successfully and "false" if the fault handler is invoked to suppress a fault.  However, if the scope is the source, the status would be "true" regardless of the fault.  This distinction matters.  In fact the whole "dead path elimination" pattern is based on it.
 
If the meaning of the proposed notion of "reversible" is not clear, let me restate it:  a reversible scope has explicit or implicit fault/compensation behavior attached, whereas a non-reversible scope is effectively non-existent as far as fault/compensation behavior is concerned.
 
As far as the motivation for non-permeability, the assumption was that a link expresses a control dependency that has some business reason behind it -- the performance of B2 is dependent on the successful completion (and presumably results) of A3 in your example.  If A3 is compensated then the "contract" that the link expresses would be violated.  Now suppose we think of a link as a "message like" signal.  I hasten to add that I am not advocating intra process messages (issue 52) just making a point about cross process messaging.  We do allow external messages to be sent that may trigger dependent behavior in another process or service.  When there is a fault in the sending process the compensation for such a message send should presumably send a compensating message (a debit for a credit etc).  This is exactly cascading compensation behavior since the compensating message may cause a cascade of such messages.  What we are trying to avoid is a requirement for emulating that sort of cascading compensation behavior intra-process.
 
Some people have said that we should think of links the same way as we think of shared data.  I disagree with this because shared data creates a problem of interference which we chose to solve using serializable scopes, but sharing obviously does not express dependency, since the order in which shared interfering activities are performed is not deterministic.
 
I understand that you are thinking of serializable scopes as analogous to ACID transactions because of their "isolation like" properties.  This is not unreasonable and other people have made the same analogy.  However, we do not have any notion of "abort" that is externally provided so I do not understand how the "ACID transactions have no fault handlers" comment applies here.  We do not assume any specific fault handler behavior for serializable scopes.  So I guess I completely missed your point there unless you are objecting to my proposal that serializable scopes should be always reversible.  The motivation for that suggestion is precisely a point you had brought up a while ago -- if we do not make the compensation handler of a serializable scope also (separately) serializable then scopes nested inside have no consistent serializability environment.  Of course your suggested remedy of making serializable scope leaf scopes has other problems in our context that I would be happy to discuss separately.
 
Reagrds,
 
Satish

________________________________

From: GORAN.OLSSON@ORACLE.COM [mailto:GORAN.OLSSON@ORACLE.COM]
Sent: Wed 4/28/2004 3:21 PM
To: Satish Thatte; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 1 - Permeability of scopes



Satish,

Regarding Tailored Scopes

The presentation on Tailored Scopes by you (and Dieter and Frank) and the minutes from the F2F discussions on the subject triggered some thoughts. My basic thinking is that introduction of non-permeable, or reversible, scopes make the semantics of the seemingly simple concept control links overly complex.

My understanding is that control links are there for ordering activities, or groups of activities, that otherwise would be performed in parallel, or in an undefined order, because they are located in different fingers of a flow. This is a very simple rule, activity B2, the control link target, in scope B will execute only when Activity A3, the control link source, in scope A has completed successfully. It does not matter if activity A3 in some future time is compensated because of an invocation of scope A?s fault or compensation handler. That is why the activity A3 is the source for the control link.

If the intent is that an enclosing scope, serializable or not, compensatable or not, reversible or not, or whatever, must complete successfully before the control link is evaluated, then the SCOPE SHOULD BE THE SOURCE FOR THE CONTROL LINK.

This is all provided for in the spec as it presently reads. It would be a mistake to introduce additional concepts to limit functionality that is already there.

I realize that serializability is presently poorly defined in the BPEL4WS spec and that much is left to the implementer. I still find it disturbing to compare serializable scopes with ACID transactions and control links with transaction protected resources and assume that exceptions could cause cascading rollbacks of control link semantics unless the control inks were forced to be evaluated after the completion of a serializable (or reversible, whatever that means) scope. For one thing, an ACID transaction has no fault handler. When an ACID transaction fails and rollbacks there are no fault handler options, there is only one defined fault handler: all operations on protected resources are rolled back and operations on unprotected  resources (i.e. log files, printed paper, etc?) are unaffected.  When an activity in a BPEL scope throws an exception an implicit or explicit fault handler is invoked. Whatever recovery or ?rollback? that happens depends on the logic in the fault handler for that particular fault.
I think it t is a mistake to assume any specific fault handler behavior for serializable scopes. I also think, even if that is the case, that control links should be considered unprotected resources.

Having said this, if implementers still want to prevent control links to fire until a the enclosing serializable scope ha successfully completed, then I suggest that they should make illegal control links sources by an activity in the serializable scope and only allow control links sourced by the scope itself.

This is conceptually simple and, at least to me, easier to understand.

Thanks, Goran