+1 to this approach, that is, allow the property settings
to flow in a single direction of composite to implementation. However, I think
the question remains that -- What rules, if any, can we specify for
generating the value of mustSupply for a property in a ComponentType without
assuming an ability to introspect the implementation code for any default values
of that property.
A simplification here may be to let the implementation
developer to decide the value of 'mustSupply' irrespective of whether the
implementation code provides default values or not. For example,
the Assembly spec could say that - Implementations SHOULD specify (via code
annotations, ComponentType side files, etc) whether a property value must
be supplied by a component using that implementation.
+1 to Mike Edwards' approach: treating SCA property
in a more generic way across different impl languages (Java/BPEL).
[Disclaimer: I have not read up SCA-Assembly most up-to-date spec
To simplify the interaction between a composite and a
component, the SCA property values should "flow"one way: from composite to
component. Allow default values from component flowing back to composite seems
complicating our life too much without a clear benefit use case.
believe that is an elaboration of Mike Edwards' "SCA cannot
Given that the assumption of SCA property values
"flowing" only one way, I think differentiating treatment of literal-variant
of BPEL from-spec may not be necessary. That is, regardless how a from-spec at
a variable declaration is used, I think it can be always overridden by SCA.
That can further simplify Michael Rowley's proposal.
that is an elaboration of Mike Edwards' "CAN be overridden via
This Mike Edwards's suggestion matches most programming
languages's semantics on default value of missing parameters: e.g. Pthyon and
If the SCA-Assembly text is not clear here, then a
clarification editing may be needed in SCA-Assembly
I note that the problem of implementations having
computed default values exists for many languages.
It can happen in Java too, for example. SCA
can't hope to be able to represent such beasts. Perhaps
we simply need to acknowledge that a) there
IS a default but b) SCA can't introspect it. It CAN
overridden via SCA.
Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great
Phone & FAX: +44-1962-818014 Mobile:
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:
<property name=”x” defaultValue=”$y”/>
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.
From: Mark Ford [mailto:firstname.lastname@example.org]
Sent: Tuesday, December 11, 2007 7:53 PM
Rowley; 'Alex Yiu'
RE: [sca-bpel] Issue 11 - BPEL variable initialization and SCA
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
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
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).
From: Michael Rowley [mailto:email@example.com]
Thursday, November 01, 2007 5:58 PM
To: Alex Yiu; Mark
RE: [sca-bpel] Issue 11 - BPEL variable initialization and SCA
I looked at the Property section of the Assembly
Specification. It looks like what is there is OK. Here it
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
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
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.”
From: Alex Yiu [mailto:firstname.lastname@example.org]
Tuesday, October 16, 2007 2:30 PM
To: Mark Ford
[sca-bpel] Issue 11 - BPEL variable initialization and SCA properties
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
> 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
> an SCA
Unless stated otherwise above:
United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6