RE: [sca-bpel] Issue 11 - BPEL variable initialization and SCA properties

From
Mark Ford <>
Date
2007-12-12T20:10:18+00:00
ID
011b01c83cfa$f3102030$
Thread
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:] 

Sent: Wednesday, December 12, 2007 2:45 PM
To: Michael 
Rowley
Cc: 
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:] 
Sent: Wednesday, December 12, 2007 9:29 
AM
To: Mark Ford; Alex 
Yiu
Cc: 

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:] 
Sent: Tuesday, December 11, 2007 7:53 
PM
To: Michael Rowley; 'Alex Yiu'
Cc: 

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:] 
Sent: 
Thursday, November 01, 2007 5:58 PM
To: Alex Yiu; Mark Ford
Cc: 

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:] 
Sent: Tuesday, October 16, 2007 2:30 
PM
To: Mark Ford
Cc: ; 

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.

> 

> 

>