3 Replies Latest reply on May 31, 2008 9:09 AM by marklittle

    To finalize, or not to finalize, that is the question

    objectiser

      Finalization is a mechanism within WS-CDL to optionally determine how a sub-session should be processed before being closed.

      After a choreography instance has successfully completed, it MAY need to provide finalization actions that confirm, cancel or otherwise modify the effects of its completed actions.


      If no finalizers have been defined for a sub-choreography, then it will automatically be closed after completion.

      This mechanism can be used to implement a form of compensation for extended transactions. The finalizer is invoked (or performed) against the information state used by the sub-session being finalized.

      Apart from this final point, the finalization mechanism is essentially two separate 'performs' of sub-choreographies - one for the actual sub-choreo and one for the selected finalizer (which is basically just another sub-choreo).

      Rather than complicating the conversation based ESB actions with this additional mechanism, I would like to propose that we just use the single 'perform' construct, and solve the shared state issue another way. This can be achieved by:

      a) binding the same set of variables to the second 'finalizer' child session - this may also require any non-observable state information to be cached by custom code in the initial sub-choreo, to enable the 'finalizer' child session to retrieve it

      b) enable the 'finalizer' child session to access the first child session by navigating via the parent session.

      Although high level abstractions (such as finalization) are useful at a description level, they may over-complicate the implementation constructs - therefore I think we should initially use the single 'PerformAction'.

      Comments?