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

[Assaf Arkin <arkin@intalio.com>]

Yuzo,

I would recommend not using an event handler but rather a pick. The
event handler is enabled for the lifetime of the process before you
reach a point where compensation is possible. However, you can replace
the wait with a pick that either waits for a compensation request
(received only once) or gives up after some time-out. That's consistent
with your suggestion for writing a compensation handler using the
available set of constructs.

But there two issues that would arise as per the current specification:

1. Currently the specification does not allow you to perform
compensation from outside a compensation handler, so you can't invoke
compensation on enclosed scopes. Clearly you would want to do that from
the compensating activity that follows the base activity.

2. For management purposes there's a value in determining that the
process has reach the 'completed' case after which it can only be
compensated or discarded. Structuring activities in this manner would
work, but would not give a management tool visibility into the process
state.

So there's some benefit to the structuring mechanism. I bet we can
either resolve these two issues and do away with the process
compensation handler, or resolve the two issues you raised and define
how companstation is invoked and how it can expire. Any ideas?

arkin


Yuzo Fujishima wrote:

>I would like to propose that we remove the concept of
>"compensating a process as a whole".
>
>>From 6.4: 
>  If a compensation handler is specified for the business
>  process as a whole (see Compensation Handlers), a business
>  process instance can be compensated after normal completion by
>  platform-specific means. This functionality is enabled by
>  setting the enableInstanceCompensation attribute of the
>  process to "yes".
>
>Rationale 1: "compensating a process as a whole" introduces
>uncertainties into the specification. These uncertainties leaves
>the feature hardly usable in my opinion.
>
>  Uncertainty 1: how to request compensating a completed process
>  instance is undefined.
>
>  Uncertainty 2: how long a process instance remains
>  "compensatable" is undefined. It should be natural to expect
>  that after some time the data of a completed process is
>  removed from the system (to save disk space, etc). Thereafter
>  compensation cannot be performed.
>
>Rationale 2: There already is an easier and clearer way of
>achieving the same effect without incurring the uncertainties
>described in Rationale 1. By cofiguring a process as follows,
>you can clearly express:
>  * how to initiate compensation of the process "body", and
>  * the deadline of initiating compensation after the completion
>    of the process "body".
>
>  <process>
>    <eventHandlers>
>      if a certain message is received, compensate.
>    </eventHandlers>
>    <sequence>
>      <scope>
>       ... compensation handler ...
>       ... the "body" of the process ...
>      </scope>
>      <wait ... until some desired time ... />
>    </sequence>
>  </process>
>
>Merits:
>* Clearer and more flexible semantics.
>* An execution engine can immediately remove data for a
>  completed process instance.
>
>I would love to hear your comments.
>
>Yuzo Fujishima
>NEC Corporation
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>  
>