OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]