[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 151 - Allow a new process instance to be created by "pick onAlarm until"
Ok, your example is fine with me. (I was afraid that what was being proposed was to do without explicitly specifying a "WakeUp" operation and corresponding receive). As I mentioned at the beginning, my proposal is not about preventing using the approach exemplified by your example below, but to give a chance, if process developers so wish, to explicitly specify the concept of a repeated activation by leveraging the onAlarm construct. The latter approach would also allow the developer to avoid having to specify a portType and associated operation and messages for the sole purpose of specifying this particular type of instantiation semantics. Ugo > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Thursday, July 29, 2004 11:39 AM > To: Ugo Corda > Cc: Eckenfels. Bernd; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 151 - Allow a new process > instance to be created by "pick onAlarm until" > > > What I and a number of other people are saying is that we are > fine with > something along the lines of: > > process > ... > flow > receive partnerLink="CoolPartner" operation="doSomething" \ > createInstance="Yes" > ... > receive partnerLink="JustMe" operation="WakeUp" \ > createInstance="Yes" > ... > ... > > In other words, the time based WakeUp message would have to > be received > on a partnerLink. But that partnerLink can be defined to only have a > 'myRole' so no magic is needed beyond the magic used to receive any > start message. > > The real magic is 'who sent the WakeUp message'? I and others are > arguing that we believe that the sender and their > configuration should > occur outside of the BPEL process itself. The basis for the argument > being that the configuration for the timing for when the > WakeUp message > should be sent will almost certainly be deployment specific and > therefore there is no real benefit and quite possibly real harm to > putting the information in BPEL. > > Yaron > > Ugo Corda wrote: > > > > > > > I find this suggestion more acceptable than what a few people have > > been > > talking about (if I understood it well), i.e. process > instances being > > launched by a deployment mechanism without any sort of partner-link > > indication in the process itself. > > > > Right now the spec says: "The only way to instantiate a business > > process > > in BPEL4WS is to annotate a receive activity with the > createInstance > > attribute set to "yes" (see Pick for a variant)". Again, if > I understood > > previous comments correctly, what is being asked for seems > to be to have > > business processes instantiated "by magic" without any such > annotation > > being provided in the process itself and without any > > port-types/partner-links being defined for receiving such > instantiating > > messages. Or did I miss something? > > > > Ugo > > > > > -----Original Message----- > > > From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de] > > > Sent: Thursday, July 29, 2004 6:29 AM > > > To: wsbpel@lists.oasis-open.org > > > Subject: RE: [wsbpel] Issue - 151 - Allow a new process > > > instance to be created by "pick onAlarm until" > > > > > > > > > Hello, > > > > > > I would suggest each BPEL runtime system can define its own > > > "TimeEvent" message/port, and you simply receive from it. > > > Correlating to the right event can be done in two ways: > > > > a) the engine generates a port for each of its schedulers > > > b) multiple process definitions can concurrently receive that > > > initial message and the engine is told by the scheduler to > > > which instance the event is routed. > > > > > > Both do not require any changed to the BPEL spec, however the > > > b) option which is nicer is somewhat violating the "multiple > > > concurrent receive case". > > > > > > Mit freundlichen Grüßen > > > Bernd Eckenfels > > > Chief Architect > > > -- > > > SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany > > > Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256 > > > mailto:b.eckenfels@seeburger.de - http://www.seeburger.de > > > > > > > > > -----Original Message----- > > > From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] > > > Sent: Wednesday, July 28, 2004 10:42 PM > > > To: ygoland@bea.com; Ron Ten-Hove; Prasad Yendluri > > > Cc: wsbpel@lists.oasis-open.org > > > Subject: Re: [wsbpel] Issue - 151 - Allow a new process > > > instance to be created by "pick onAlarm until" > > > > > > > > > Yaron Y. Goland wrote: > > > > > > > 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. > > > > > > mm1: Ron/Yaron/Prasad, then do you have a proposal? Thanks. [1] > > > > > > [1] Came up on BPEL requirements call today. :-D > > > > > > >> Issue 151: *Links:* Ugo Corda, 22 Jul 2004 > > > >> > > > <http://lists.oasis-open.org/archives/wsbpel/200407/msg00165.h > > tml> > > >> 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 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_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]