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

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

Understood.  This example was merely a postulation to see if that is what
Ram was looking for and not an example of intended BPEL functionality.

So that begs the original question:

Is onAlarm a time out function as stated in section 13.5.2:
"The onAlarm tag marks a timeout event. The for attribute specifies the
duration after which the event will be signaled. The clock for the duration
starts at the point in time when the associated scope starts. The
alternative until attribute specifies the specific point in time when the
alarm will be fired. Exactly one of these two attributes must occur in any
onAlarm event."

or something more?

Ben



----- Original Message ----- 
From: "Satish Thatte" <satisht@microsoft.com>
To: "Ben Bloch" <ben_b54@hotmail.com>; "Ram Jeyaraman"
<Ram.Jeyaraman@Sun.COM>; <wsbpel@lists.oasis-open.org>
Sent: Tuesday, September 23, 2003 11:07 AM
Subject: RE: [wsbpel] Issue - 43 - Setting up Periodic Alarms


Note that BPEL cannot model "item 7<5 for an inventory monitoring tool"
inside a process -- this is a KPI alert coming from outside, and thus an
onMessage event not an onAlarm one.  We are only talking about periodic
timer events to model behavior based on internal state.

________________________________

From: Ben Bloch [mailto:ben_b54@hotmail.com]
Sent: Tue 9/23/2003 3:42 AM
To: Satish Thatte; Ram Jeyaraman; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 43 - Setting up Periodic Alarms



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.




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.