[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Example for how compensation relates to WS-T (BA)
Assaf, I think that we all agree that although this might be clear in a few people's mind, there is room for interpretation and for the sake of interoperability the spec needs further clarification on that specific subject. I am suggesting that we start by defining a simple example as a way to identifying the areas that need further clarification within the spec. Edwin > > -----Original Message----- > From: Assaf Arkin [mailto:arkin@intalio.com] > Sent: Friday, June 20, 2003 12:41 PM > To: edwink@collaxa.com > Cc: 'Satish Thatte'; 'Yuzo Fujishima'; wsbpel@lists.oasis-open.org > > Suppose you have some process A that performs some operation > and supports compensation through its process-level > compensation handler. > (The topic of discussion is process-level compensation > handlers, not scope-level compensation handlers, which are > covered in the appendix) > > You have some process B that performs an activity called X. > Activity X invokes process A and so process B may later on > decide to invoke A's compensation handler. Assume you would > want to use WS-TX to do that. > Interoperability means that two systems would understand how > it works and do it in the same manner (barring any other differences). > > What would the compensation handler for activity X look like? > > Let's say A is never compensated unless there is a > compensation handler for activity X. The compensation handler > for activity X does not need to do anything, so it contains > an <empty> activity. According to the current spec, if the > compensation handler includes an <empty> activity then > nothing would happen. So there needs to be a clarification > that some work would indeed happen and that this compensation > handler may actually throw a fault (if A returns 'faulted'). > > Another implementation may decide that to compensate A you > need to invoke the default compensation handler for X. So if > X has a compensation handler containing <empty> it would not > invoke A's compensation handler, but if it has no > compensation handler then A gets compensated using WS-TX. You > can use the <empty> activity to prevent A from being > compensated (a good thing), but you can't interact with A > within X's compensation handler, which violates the need to > pass data to a compensation handler. > > Another possibility is for X's compensation handler to > explicitly send a compensation message to A. Unfortunately, X > doesn't know the participant or coordination addresses and so > can't pass them to A's WS-TX implementation. > > Considering the lack of clarification in the specification I > am very curious to see what such an example would look like. > > arkin > > > Edwin Khodabakchian wrote: > > >I suggest that we take one of the examples used by Satish in the F2F > >(travel > >procurement) and try to get down into the details of how exception > >management and compensation management would be implemented. > This will > >help us flush out the details of how BPEL and WS-Transaction > (BA) work together. > > > >If we decide that this is valuable, I volunteer to implement > the BPEL > >processes once the use case has been agreed on. > > > >Thoughts? > > > >Edwin > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]