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

[GORAN.OLSSON@ORACLE.COM]

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