RE: [wsbpel] Do we need the createInstance attribute?

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

I agree with Danny that 11.4 and 6.4 both need to be cleaned up. I added an
editorial task to myself to clean up the language around createInstance so
as to make it clear that:

	#1 - All initial activities MUST be start activities (e.g. receive or pick)
	#2 - All start activities MUST have a createInstance attribute
	#3 - Point out that createInstance is only there to make the spec more
readable and is, strictly speaking, redundant.

I don't believe we need to open an issue for this one since both #1 and #2
are already mandated by the spec, just not in a particularly readable way.

		Yaron

> -----Original Message-----
> From: Danny van der Rijn [mailto:dannyv@tibco.com]
> Sent: Thursday, October 23, 2003 10:16 AM
> To: Wsbpel@Lists. Oasis-Open. Org (E-mail)
> Subject: Re: [wsbpel] Do we need the createInstance attribute?
>
>
> this is dealt with in 11.4:
>
> In addition, receive activities play a role in the lifecycle
> of a business
> process. 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). The default
> value of this
>
> attribute is "no". A receive activity annotated in this way MUST be an
> initial activity in the
>
> process, that is, the only other basic activities may potentially be
> performed prior to or
>
> simultaneously with such a receive activity MUST be similarly
> annotated
> receive activities.
>
>
>
> could probably be made more clear, but at least its there.
> something else
> that is there, but could be made much more clear is the
> following definition
> of instance creators (also there above) from 6.4
>
>
>
> To be instantiated, each business process must contain at
> least one such
> "start activity."
>
> This must be an initial activity in the sense that there is no basic
> activity that logically
>
> precedes it in the behavior of the process.
>
>
>
> my objection is that what is a "basic" activity and what is a
> "structured"
> activity is defined solely (i think) by what section of the
> doc they appear
> in.  that seems pretty weak to me, and hard to read unless
> you understand
> that.
>
> ----- Original Message -----
> From: "Satish Thatte" <satisht@microsoft.com>
> To: "Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM>; <ygoland@bea.com>
> Cc: "Wsbpel@Lists. Oasis-Open. Org (E-mail)"
> <wsbpel@lists.oasis-open.org>
> Sent: Thursday, October 23, 2003 10:02 AM
> Subject: RE: [wsbpel] Do we need the createInstance attribute?
>
>
> Good point.  We need clarity on whether all initial
> activities must (A)
> be receives or picks and assuming that (B) must have
> createInstance set
> to "yes".
>
> I expect there are various opinions on this ..
>
> Satish
>
>
> -----Original Message-----
> From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
> Sent: Thursday, October 23, 2003 8:54 AM
> To: ygoland@bea.com
> Cc: Satish Thatte; 'Wsbpel@Lists. Oasis-Open. Org (E-mail)'
> Subject: Re: [wsbpel] Do we need the createInstance attribute?
>
> Yaron Goland wrote:
>
> >I think an editorial change that describes 'createInstance'
> as a marker
> of a
> >start activity, explains that it is redundant and then
> describes why it
> is
> >there anyway should do nicely. Can we add that to the list you are
> >maintaining of things for the editors to do?
> >
> Does this really answer the original question you posed? Is the sample
> process fragment you supplied considered illegal?
>
> I can easily imagine someone trying to exploit such a "feature" if it
> was not explicitly banned. Borrowing from your example:
>
> <process>
>    ...
>    <flow>
>       <receive partnerLink="A" createInstance="yes".../>
>       <receive partnerLink="B" createInstance="no".../>
>    </flow>
> </process>
>
> This could be used by partner B as a kind of polling
> mechanism to see if
>
> partner A has done his thing yet. Kind of an event handler for process
> instances that don't exist. Useful for non-deterministic (parallel)
> sections of a choreography.
>
> Do we wish to support this usage, or ban it? I think we need some
> explicit wording one way or the other.
>
> -Ron
>
>
>
>
>
> 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.