[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: No Subject
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]