Re: [wsbpel] Issue - 151 - Allow a new process instance to be createdby "pick onAlarm until"

["Yaron Y. Goland" <ygoland@bea.com>]

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/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. 
> 
> 
> 
> 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. 
> 
>