Hi Najeeb,
We are just dealing with initialization at the time of variable
declaration.
Static analysis of generic assignment of variables (e.g. some where in
a subsequent flow / sequence) does not buy us much benefits. Hence, it
should be out of scope for this issue.
As BPEL is a Turing complete language, to trace which assign that first
touches a variable will be difficult in most cases, and impossible for
all cases.
Thanks!
Regards,
Alex Yiu
Najeeb Andrabi wrote:
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.
>
>
>
