It sounds like we should open an issue in the Assembly
TC. Assuming that happens, do we need to do anything here for resolving
the BPEL-11 issue?
-- Sanjay
From: Mike Edwards
[mailto:]
Sent: Thursday, Dec 13, 2007 5:37
AM
To: OASIS BPEL
Subject: RE: [sca-bpel] Issue 11 - BPEL
variable initialization and SCA properties
Folks,
The simplest thing is to say that "mustSupply" is not
used by default.
If it IS possible
to introspect the implementation, then it may be possible to examine whether
SCA MUST supply a value,
but without
this ability, it is best to say nothing. If the value is not supplied
when it must be supplied, an error will occur
relatively quickly, I assume.
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:
"Patil, Sanjay"
<>
13/12/2007 00:41
To
"Alex Yiu"
<>, Mike Edwards/UK/IBM@IBMGB
cc
"OASIS BPEL"
<>
Subject
RE: [sca-bpel] Issue 11 - BPEL
variable initialization and SCA
properties
+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
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
