Re: [wsbpel] Issue - 43 - Setting up Periodic Alarms

[Ram Jeyaraman <Ram.Jeyaraman@Sun.COM>]

Satish Thatte wrote:
> Ram,
> 
> I believe process state monitoring, health monitoring, data caching seem
> like implementation-level rather than model level features to me.

Thanks for the comments, Satish. It is possible that these extended usages may 
likely be handled at an implementation-level. On the other hand, opening up the 
  onAlarm event handler to provide periodic alerts would help model such 
extended usages in a more intimate way, leveraging the internal state of the 
process instance, which is otherwise not easily accomplished.

> You did not give an evaluation of the concurrent thread option and what
> you think the priority of such a feature is from the perspective of
> frequency of use (we obviously can't encode every design pattern into a
> BPEL feature :-)).  My own gut feeling is that this type of periodic
> action will not be common at the business process level. 

While the concurrent thread option may be used for performing recurrent 
activities, it is hard to model a periodic alert mechanism, since the time 
duration of each alert activity is non-deterministic, and hence may potentially 
delay the execution of subsequent alerts. On the other hand, the periodic alert 
option has the advantage that subsequent alerts are unaffected by the time 
duration of a particular alert activity, and such alerts may be executed in 
parallel.

Regarding the priority of such a feature with respect to frequency of use, i 
agree that it may indeed be few and far between, at the moment. Thanks.