RE: [wsbpel] Issue - 151 - Allow a new process instance to be created by "pick onAlarm until"

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

I was refering to the pick alarm case.
 
I think Ron's comments are the most succinct in articulating the concerns I have.

________________________________

From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Thu 7/29/2004 7:31 AM
To: Satish Thatte; ygoland@bea.com; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 151 - Allow a new process instance to be created by "pick onAlarm until"



Not sure what you mean by "only once"? We have already introduced
Periodic Alarms (issue 43).

Ugo

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Wednesday, July 28, 2004 10:25 PM
> To: ygoland@bea.com; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 151 - Allow a new process
> instance to be created by "pick onAlarm until"
>
>
> I don't get the use case.  No one is going to deploy a
> process to be activated only once at a specific time.  This
> defeats the whole notion of activation -- you might as well
> start a daemon using some other scheduling mechanism in the
> deployment environment.
> 
> Also agree with the comments by Yaron.
>
> ________________________________
>
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Wed 7/28/2004 9:16 AM
> To: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 151 - Allow a new process
> instance to be created by "pick onAlarm until"
>
>
>
> I just wanted to go on the record as saying that I believe
> this feature is an issue for deployment/configuration and
> therefore out of scope for BPEL. I want to echo Ron's
> comments that process designers more often than not are not
> in a position to know what actual values should be used and
> therefore this is something that should be set at deployment
> time by the deployment admin.
>
>                 Thanks,
>
>                         Yaron
>
> ws-bpel issues list editor wrote:
> >
> >
> > This issue has been added to the wsbpel issue list. The
> issues list is
> > posted as a Technical Committee document to the OASIS
> WSBPEL TC pages
> > <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a regular
> > basis. The current edition, as a TC document, is the most recent
> > version of the document entitled ** in the "Issues" folder of the
> > WSBPEL TC document list
> >
> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> -
> > the next posting as a TC document will include this issue. The list
> > editor's working copy, which will normally include an issue
> when it is
> > announced, is available at this constant URL
> > <http://www.choreology.com/external/WS_BPEL_issues_list.html>.
> >
> >
> >     Issue - 151 - Allow a new process instance to be
> created by "pick
> >     onAlarm until"
> >
> > *Status:* open
> > *Categories:* State management <#category_state_management> *Date
> > added:* 26 Jul 2004
> > *Submitter:* Ugo Corda <mailto:UCorda@SeeBeyond.com>
> > *Date submitted:* 23 July 2004
> > *Description:* Currently the spec does not allow a Pick with
> > createInstance=yes when alarms are specified. I don't see a good
> > rationale for having this restriction in the case onAlarm
> specifies a
> > particular time for the associated activities to occur
> ("until" case).
> >
> > Relaxing this restriction would be useful when we want a process
> > instance to start at a particular time, possibly on a
> periodical base.
> > An alternative way of achieving the same effect would be by
> defining a
> > receive from a "partner" representing the deployment
> environment, and
> > having the environment itself send a message at the
> appropriate time.
> > But I think it would be more clear if we use the pick-onAlarm
> > construct instead.
> > *Links:* Ugo Corda, 22 Jul 2004
> >
> <http://lists.oasis-open.org/archives/wsbpel/200407/msg00165.html>   
> > Dieter Koenig1, 23 Jul 2004
> >
> <http://lists.oasis-open.org/archives/wsbpel/200407/msg00170.html>   
> > Dieter Roller, 23 Jul 2004
> >
> <http://lists.oasis-open.org/archives/wsbpel/200407/msg00171.html>   
> > Ugo Corda, 23 Jul 2004
> >
> <http://lists.oasis-open.org/archives/wsbpel/200407/msg00174.html>   
> > Ugo Corda, 23 Jul 2004
> >
> <http://lists.oasis-open.org/archives/wsbpel/200407/msg00175.html>   
> > Ron Ten-Hove, 23 Jul 2004
> >
> <http://lists.oasis-open.org/archives/wsbpel/200407/msg00183.html>   
> > Prasad Yendluri, 23 Jul 2004
> >
> <http://lists.oasis-open.org/archives/wsbpel/200407/msg00184.html>   
> > Prasad Yendluri, 23 Jul 2004
> > <http://lists.oasis-open.org/archives/wsbpel/200407/msg00184.html>
> > *Changes:* 26 Jul 2004 - new issue
> >
> > To comment on this issue, please follow-up to this
> announcement on the
> > wsbpel@lists.oasis-open.org list (replying to this message should
> > automatically send your message to that list), or ensure
> the subject
> > line as you send it *starts* "Issue - 151 - [anything]" or
> is a reply
> > to such a message. If you want to formally propose a resolution,
> > please start the subject line "Issue - 151 - Proposed resolution",
> > without any
> > Re: or similar.
> >
> > To add a new issue, see the issues procedures document (but the
> > address for new issue submission is the sender of this
> announcement).
> >
> > 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_work
> > group.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/le
ave_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_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.