OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Sure.  And why don't you actually do it along with the other clarification since you have the pen?

________________________________

From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Wed 10/22/2003 3:27 PM
To: Satish Thatte; 'Wsbpel@Lists. Oasis-Open. Org (E-mail)'
Subject: RE: [wsbpel] Do we need the createInstance attribute?



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?

> -----Original Message----- 
> From: Satish Thatte [mailto:satisht@microsoft.com] 
> Sent: Tuesday, October 21, 2003 11:51 PM 
> To: ygoland@bea.com; Wsbpel@Lists. Oasis-Open. Org (E-mail) 
> Subject: RE: [wsbpel] Do we need the createInstance attribute? 
> 
> 
> We could certainly get rid of the createInstance attribute as you say 
> but in general we are tending to keep some redundant annotations as a 
> way of expressing intent, to be enforced and checked by static 
> analysers. 
> 
> As for the offending potentially misleading sentence it was meant to 
> draw attention to the multiple start activities case.  But of 
> course it 
> could be improved to be less misleading. 
> 
> Satish 
> 
> -----Original Message----- 
> From: Yaron Goland [mailto:ygoland@bea.com] 
> Sent: Monday, October 20, 2003 4:49 PM 
> To: Wsbpel@Lists. Oasis-Open. Org (E-mail) 
> Subject: [wsbpel] Do we need the createInstance attribute? 
> 
> Section 11.4 states "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." 
> 
> If I understand this sentence correctly then the following is 
> illegal in 
> BPEL: 
> 
> <process> 
>    <flow> 
>       <receive portTypeA createInstance="yes".../> 
>       <receive portTypeB createInstance="no".../> 
>    </flow> 
> </process> 
> 
> If that is the case then can't we just get rid of the createInstance 
> attribute since it is redundant? In other words, if an activity is an 
> initial activity then it must, by definition, be a createInstance 
> activity. 
> 
> Also, if the previous example is illegal in BPEL then I think the 
> following sentence from section 11.4 could be misleading: "It is 
> permissible to have the createInstance attribute set to "yes" 
> for a set 
> of concurrent initial activities." 
> 
> This sentence implies that there are times when it is legal to have 
> concurrent initial activities where createInstance is equal to no. 
> 
>       Thanks, 
>               Yaron 
> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]