OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



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

"Michael Rowley" <mrowley@bea.com>

12/12/2007 17:28


To
"Mark Ford" <mark.ford@active-endpoints.com>, "Alex Yiu" <alex.yiu@oracle.com>
cc
<sca-bpel@lists.oasis-open.org>
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: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]