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

["Ben Bloch" <ben_b54@hotmail.com>]

Isn't the intention of onAlarm basically a timeout mechanism? If so, I
wouldn't think a repeating onAlarm out makes sense.

A common type of alarm is one that is fired when a threshold condition, as
measured by a monitor, is crossed (eg CPU utilization>80% for a system
monitoring tool, item 7<5 for an inventory monitoring tool) but it is my
understanding this is not the type that is intended here.  Ram, is this is
what you were thinking - eg the need for monitoring and associated alarm
facilities?

Ben


----- Original Message ----- 
From: "Satish Thatte" <satisht@microsoft.com>
To: "Ram Jeyaraman" <Ram.Jeyaraman@Sun.COM>; <wsbpel@lists.oasis-open.org>
Sent: Monday, September 22, 2003 8:33 PM
Subject: RE: [wsbpel] Issue - 43 - Setting up Periodic Alarms


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.




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_workgroup.php.