[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Removing "compensating a process as a whole"
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]