[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bpel] Issue 11 - BPEL variable initialization and SCA properties
Michael Rowley wrote: > > > I think it is meant to be informative to a user (as opposed to the > runtime). The runtime will use whatever default value is in the > implementation, irrespective of what the generated component type says. I would like to modify the above stmt a bit: The runtime will use whatever default value is in the implementation. The component type, if it specifies the default value, MUST/SHOULD be the same as the value used by the runtime. It should be consistent. I.e., If the CT specifies the default value then it is the same as the runtime, but if the CT does not specify the default value it does not necessarily mean that the runtime does not have one. -Anish -- > This means that the property value in the component type can be a best > effort – include a value if you can pull out a value that would make > sense within a component type document. > > > > Michael > > > > > > ------------------------------------------------------------------------ > > *From:* Mark Ford [mailto:mark.ford@active-endpoints.com] > *Sent:* Wednesday, December 12, 2007 3:10 PM > *To:* 'Najeeb Andrabi'; Michael Rowley > *Cc:* sca-bpel@lists.oasis-open.org > *Subject:* RE: [sca-bpel] Issue 11 - BPEL variable initialization and > SCA properties > > > > I'm a little confused as to the purpose of default-property-value in the > assembly spec. Is this value supposed to convey what the default is > within the implementation if no value is provided by the configuration? > If this is the case, then I agree with Najeeb and I better understand > Michael Rowley's desire to treat expressions differently than literals. > > > > However, it's not clear to me that this is what the > default-property-value is supposed to convey. My first reading of it was > that it was the value used if the composite didn't supply a value and > not necessarily a value that was introspected from the implementation. > > > > > > ------------------------------------------------------------------------ > > *From:* Najeeb Andrabi [mailto:nandrabi@tibco.com] > *Sent:* Wednesday, December 12, 2007 2:45 PM > *To:* Michael Rowley > *Cc:* sca-bpel@lists.oasis-open.org > *Subject:* RE: [sca-bpel] Issue 11 - BPEL variable initialization and > SCA properties > > Hi Michael, > > I think it impossible to determine which initialization > expression initializes the variable in case of complex BPEL process > having conditional/concurrent flows with multiple initialization > expression of the same variable. In my view, we should state that “if > the literal value can be determined by static analysis of the process > then it will be represented as the default value in the component type > for the process” > > > > Thanks, > > Najeeb > > > > > > ------------------------------------------------------------------------ > > *From:* Michael Rowley [mailto:mrowley@bea.com] > *Sent:* Wednesday, December 12, 2007 9:29 AM > *To:* Mark Ford; Alex Yiu > *Cc:* sca-bpel@lists.oasis-open.org > *Subject:* RE: [sca-bpel] Issue 11 - BPEL variable initialization and > SCA properties > > > > > > The key question, for me, is whether the component type should show > non-literal default values. Imagine reading a component type definition > that looks like this: > > > > <componentType> > > <property name=”x” defaultValue=”$y”/> > > </componentType> > > > > In this example, I’m assuming that BPEL had an initialization expression > for “x” that assigns it to the value of the “y” BPEL variable. If you > copy this into the component type, the component type makes no sense, > because there is no way to resolve “y”. > > > > That is why I said that only literals can be used by the component type > of a BPEL process. > > > > Michael > > > > > > ------------------------------------------------------------------------ > > *From:* Mark Ford [mailto:mark.ford@active-endpoints.com] > *Sent:* Tuesday, December 11, 2007 7:53 PM > *To:* Michael Rowley; 'Alex Yiu' > *Cc:* sca-bpel@lists.oasis-open.org > *Subject:* RE: [sca-bpel] Issue 11 - BPEL variable initialization and > SCA properties > > > > The mustSupply text from the assembly specification below SHOULD use the > capitalized words from RFC 2119. It would be better to say that the > default-property-value MUST NOT be provided when mustSupply="true". > > > > That said I think the treatment of BPEL variable initialization should > be the same regardless of the form of the from-spec. If I understand > your proposal, you would treat an expression from-spec differently than > a literal from-spec. > > > > After reviewing the Assembly spec a little, I'm inclined to suggest that > any value from the component overrides the initialization from-spec for > the variable in the BPEL. This seems consistent with the goal of > allowing the configuration of an implementation with externally set data > values. (Section 6.1 of the Assembly spec). > > > > - Mark > > > > ------------------------------------------------------------------------ > > *From:* Michael Rowley [mailto:mrowley@bea.com] > *Sent:* Thursday, November 01, 2007 5:58 PM > *To:* Alex Yiu; Mark Ford > *Cc:* sca-bpel@lists.oasis-open.org > *Subject:* RE: [sca-bpel] Issue 11 - BPEL variable initialization and > SCA properties > > > > > > I looked at the Property section of the Assembly Specification. It > looks like what is there is OK. Here it is: > > > > */mustSupply (optional) /*– whether the property value must be supplied > by the component that uses the implementation – when mustSupply="true" > the component must supply a value since the implementation has no > default value for the property. A default-property-value should only be > supplied when mustSupply="false" (the default setting for the mustSupply > attribute), since the implication of a default value is that it is used > only when a value is not supplied by the using component. > > > > It says that a default value should be only be supplied when mustSupply > is false, but it _/doesn’t/_ say that a default value MUST be supplied. > > > > Perhaps we could add the following to the SCA BPEL spec at line 357 (in > the paragraph that describes the meaning of sca:property=”yes”): > > > > “If the variable has an initialization expression (a /from-spec/) then > that becomes the default value for the variable in cases where the SCA > component does not provide a value for that property. If a value /is/ > provided for the property, the expression is not evaluated. If the > from-spec is a literal value, where it has the following form: > > > > <from><literal>literal value</literal></from> > > > > then the literal value will be represented as the default value in the > component type for the process. Any other kind of initialization > expression will not be represented in the component type.” > > > > Michael > > > > > > -----Original Message----- > From: Alex Yiu [mailto:alex.yiu@oracle.com] > Sent: Tuesday, October 16, 2007 2:30 PM > To: Mark Ford > Cc: sca-bpel@lists.oasis-open.org; ALEX.YIU@oracle.com > Subject: [sca-bpel] Issue 11 - BPEL variable initialization and SCA > properties > > > > > > Issue entered. > > http://www.osoa.org/jira/browse/BPEL-11 > > > > Regards, > > Alex Yiu > > > > Mark Ford wrote: > >> TARGET: SCA Client and Implementation Model Specification for WS-BPEL > >> > >> TITLE: BPEL variable initialization and SCA properties > >> > >> DESCRIPTION: Is the target variable allowed to have an initialization > >> defined within the BPEL process and if so, is this initialization ignored? > >> It seems like the initialization should be allowed but not executed in the > >> case where a process is packaged as an SCA and the property is provided by > >> the component. It's probably also worth pointing out that the variable > must > >> be an element or type variable. Message variables cannot be initialized by > >> an SCA property. > >> > >> > >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]