[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 43 - Setting up Periodic Alarms
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]