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

["Yuzo Fujishima" <fujishima@bc.jp.nec.com>]

Asaaf,

> 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.

I understand.

> 
> 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.

I've rewritten the example as follows. It should work now.

  <process>
   <faultHandlers>
      catch compensationRequested fault and compensate.
    </faultHandlers>
    <sequence>
      <scope>
       ... compensation handler ...
       ... the "body" of the process ...
      </scope>
      <pick>
        <onMessage...for compensation request...>
          <throw faultName="compensationRequested"/>
        </onMessage>
      </pick>
    </sequence>
  </process>

> 
> 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.

I agree that this can be a problem.

To solve the problem, we may need to formalize the concept of "body" of
the process such that a process instance can be in state
 "process as a whole=running, body=completed".
I don't like this idea very much, but nonetheless present it here to hopefully
promote the discussion. 

Yuzo

> 
> 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
> >  
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 
>