sca-bpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [sca-bpel] Issue 11 - BPEL variable initialization and SCA properties
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS BPEL" <sca-bpel@lists.oasis-open.org>
- Date: Thu, 13 Dec 2007 13:36:37 +0000
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: mike_edwards@uk.ibm.com
"Patil, Sanjay"
<sanjay.patil@sap.com>
13/12/2007 00:41
|
To
| "Alex Yiu" <alex.yiu@oracle.com>,
Mike Edwards/UK/IBM@IBMGB
|
cc
| "OASIS BPEL" <sca-bpel@lists.oasis-open.org>
|
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:alex.yiu@oracle.com]
Sent: Wednesday, Dec 12, 2007 14:37 PM
To: Mike Edwards
Cc: OASIS BPEL; ALEX.YIU@oracle.com
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: 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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]