+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.
-- Sanjay
From: Alex Yiu [mailto:]
Sent: Wednesday, Dec 12, 2007 14:37 PM
To: Mike
Edwards
Cc: OASIS BPEL;
Subject: Re:
[sca-bpel] Issue 11 - BPEL variable initialization and SCA
properties
Hi,
+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
version.]
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.
[I
believe that is an elaboration of Mike Edwards' "SCA cannot
introspect".]
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.
[I believe
that is an elaboration of Mike Edwards' "CAN be overridden via
SCA".]
This Mike Edwards's suggestion matches most programming
languages's semantics on default value of missing parameters: e.g. Pthyon and
PL/SQL ;-)
If the SCA-Assembly text is not clear here, then a
clarification editing may be needed in SCA-Assembly
TC.
Thanks!
Regards,
Alex Yiu
Mike Edwards
wrote:
Folks,
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
be
overridden via SCA.
Yours, Mike.
Strategist -
Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly
TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great
Britain.
Phone & FAX: +44-1962-818014 Mobile:
+44-7802-467431
Email:
"Michael Rowley" <>
12/12/2007 17:28
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.
>
>
>
Unless stated otherwise above:
IBM
United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
