Here is some additional food for thought: http://rodin.cs.ncl.ac.uk/Publications/Coleman-ExaminingBPEL.pdf A Process is made up of States, Transitions, and Transition Events. A Transition is used to move from one State to another State. During the course of that Transition, you may invoke many Transition Events that may need to be carried out (sequentially or parallel). Two scenarios may require the need to 'compensate': 1) During the execution of your Transition Event(s), you encounter a problem (business rule or exception) that prevents the Transition from completing to the new State. 2) A situation occurs that requires the need to move a Task backwards in the Process. This could be as simple as user moving a Task forward by mistake. Additionally, it could involve multiple Transitions and States. In both of these scenarios, you need the ability to 'compensate' for the Transition Events that have already occurred. It is not ideal to create additional Transitions for every possible scenario. Additionally, this functionality should not be treated as a fault, but it may be the response to a fault. Proposed Solution: Suppose a Transition had knowledge of all the Transition Events that are in progress, completed, or failed. The Transition could have a reverse() method that could cycle through the Transition Events and determine which ones needed to be handled. It would then call a rollback() method on each Transition Event, as necessary. The rollback() method would perform the most appropriate action to compensate for changes that already occurred. When I refer to the 'most appropriate action', I mean that whoever codes the Transition Event execution, would also define what should occur on a rollback(). You can't use a standard mechanism to handle this. It is just too process-specific and requires knowledge of your logic. In scenario 1 (above), the Transition would never complete or get to the new State. It would just call the rollback() method on each of the Transition Events (that had occurred). When all appropriate rollback() methods were called, the Transition's reverse() method could return a boolean indicating whether all the rollback() methods completed successfully or not. In scenario 2 (above), the reverse() method of the Transition would be called and all Transition Event rollback() methods would be called. Again, the reverse() method would return a boolean indicating if all the rollback() methods were successful. If the reverse() method returned true, then the State of the Task would be changed to the previous State. I haven't thought through the implications of guard conditions that may be dependent on variables that have changed. Furthermore, the order of Transition Events, that did not occur sequentially, could be problematic. These issues may just have to be the responsibility of the logic within each rollback() method. Please let me know if this idea has merit or is riddled with holes. Thanks in advance, - Steve View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964461#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...