[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Removing "compensating a process as a whole"
> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]