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

["Satish Thatte" <satisht@microsoft.com>]

Ram,

I believe process state monitoring, health monitoring, data caching seem
like implementation-level rather than model level features to me.

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. 

Satish

-----Original Message-----
From: Ram Jeyaraman [mailto:Ram.Jeyaraman@Sun.COM] 
Sent: Sunday, September 21, 2003 4:25 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 43 - Setting up Periodic Alarms

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.


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.