Issue - 43 - Setting up Periodic Alarms

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

Following up on the conversation at the F2F meeting from last week,

The alarm event handler provides a mechanism to perform asynchronous, 
concurrent, timed activity along with its associated scope activity. The alarm 
event handler mechanism, unlike the timeout alarm in a pick construct, is not 
associated with the message event handler, but instead defines an asynchronous 
timed activity that is performed concurrently with its associated scope activity.

The alarm event handler mechanism was probably introduced to enable performing 
of an asynchronous, concurrent, timed activity along with an associated scope 
activity. By opening up the existing alarm handler to be triggered 
periodically, it serves to perform asynchronous, concurrent, timed, periodic, 
*background* activities along with an associated scope activity.

As cited in the issue,
http://lists.oasis-open.org/archives/wsbpel/200307/msg00155.html, the seed use
case that originally motivated this line of thinking, is the ability to perform 
concurrent periodic background activities along with a primary scope activity. 
Examples of such periodic background activities are: process state monitoring, 
health monitoring, data caching - state synchronization, etc.

This may also serve to model the in-multi-out message exchange pattern. For 
example, a partner query such as "provide an update of ticket availability 
periodically each hour for the next 10 hours" may be modeled using this facility.

As was noted in the F2F conversation, these use cases may also be modeled as a 
parallel activity using a flow construct. This would use a concurrent thread of 
execution that uses a wait or a pick construct inside a while loop. One 
different though is that these recurrent activities, though periodic, would get 
progressively delayed due to the delay in scheduling the wait action and 
activity execution, and thus may not be considered as truly timed activities.

Thanks.