[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Allowing a new process instance to be created by "pick onAlarm until"
Dieter, Please see below. Ugo > -----Original Message----- > From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] > Sent: Thursday, July 22, 2004 11:44 PM > To: wsbpel@lists.oasis-open.org > Subject: [wsbpel] Allowing a new process instance to be > created by "pick onAlarm until" > > > > > > > Ugo, so far, all onAlarm specifications are associated with a > process instance or an active scope in a process instance. > This would be different from all other cases where the > instance comes into existence first before timer-driven > behavior is processed. > Sure, but that could also be said of activities in general: activities expect an instance to already exist, except when used to create an instance ;-). > A possible scenario would be having two picks (rendezvous) > with createInstance="yes" and onAlarm. The "first" message > would create a new instance (on that pick, the onAlarm is > ignored), and the "second" message must arrive in time before > the onAlarm on the other pick goes off. I don't fully understand your scenario. What would the first message be about and who would send it? (Please keep in mind my use case: periodical activation of the process). > > Kind Regards > DK > > > > > > "Ugo Corda" > > <UCorda@SeeBeyond > > .com> > To > > <wsbpel@lists.oasis-open.org> > 22.07.2004 23:36 > cc > > > > Subject > [wsbpel] Allowing a > new process > instance to be created > by "pick > onAlarm until" > > > > > > > > > > > > > > > > > > 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. > > Unless somebody shows me that the idea does not make sense, > I'll file a formal issue for it. > > Ugo > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]