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:
OF2AEE542F.17DACA1B-ON802573AF.00620C12-802573AF.00629E57@uk.ibm.com"
type="cite">
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: mike_edwards@uk.ibm.com
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.
>
>
>
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
|