Re: [wsbpel] Removing "compensating a process as a whole"

["Mark Little" <mark.little@arjuna.com>]

> Or is there some minimal requirement from the spec without which
> interoperability is not possible? If the spec doesn't at least
> investigate that minimum requirement, then interoperability would not be
> possible. To do that the spec needs to at least acknowledge that WS-TX
> or a similar protocol is one option for performing compensation.

+1. I don't think we can or should mandate a specific compensation option
like BAs at this stage. It's early days and who knows what other
mechanisms/techniques might find favour in the future. As you say, it should
be possible to define BAs as one possible option without precluding other
possibilities. BPEL+BA interoperability with another BPEL+BA system is
required, as would BPEL+X to BPEL+X, but not necessarily the cross-product.
If someone really wants to do a BPEL+X to BPEL+BA then let them figure out
the bridging problems.

>
> When you do that certain issues arise which needs to be clarified, non
> of which requires a wholesale rewrite of the specification. But we can't
> resolve these issues unless we make a point that we would address
> interoperability when BPEL is used in combination with WS-TX.

We should write the spec. such that WS-Tx is an *option* and allow other
protocols that define the same type of semantic/functionality can replace
this (as above). The issue of interoperability at this level then becomes
componentised, i.e., as I mentioned above, we should be able to define an
abstract notion of a BPEL+FOO, where FOO is the compensation protocol and
show that WS-Tx/BA is one implementation of FOO and if you use it here is
how you get interoperability. Then when (if) someone comes along with
another FOO, they do the same (show how it maps, show interoperability
requirements, ...) and (hopefully) add it to an appendix of the spec. (if
that's allowed).

> Incidentally, doing so would clarify one of the most common uses of a
> compensation handler at the process level, which is not apparent from
> the current reading of the spec.
>
> Again, what we both have in mind may be well and good and actually work,
> but if it's not written down then it won't help interoperability on a
> large scale.
>
> arkin
>
> >Satish

Mark.