RE: [sca-assembly] ISSUE 5: Component type allows to specify wire targets on references: PROPOSAL

["Patil, Sanjay" <sanjay.patil@sap.com>]

comments/questions inline ...

---

From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Wednesday, Mar 12, 2008 4:42 AM
To: OASIS Assembly
Subject: RE: [sca-assembly] ISSUE 5: Component type allows to specify wire targets on references: PROPOSAL

Folks,

I'm finding it very hard to understand the logic behind the proposals below.  They seem to complicate the SCA model for no reason.

The proposal that I favour I think is a very simple one, that fits in well with the current structure of SCA and requires no new or special
constructs.  Basically, the model I see is one where an implementation has a componentType.   The componentType represents
the configurable aspects of the implementation - services, references, properties and the implementation itself (in the sense that
intents and policies can be configured on the implementation).  

<Sanjay> 

I think there is a distinction to be drawn between the configuration of Services/References and that of Properties. The declaration of Services/References by an implementation is in terms of business interfaces  (and intents, if necessary) and a typical implementation developer would rather keep the code independent of the binding/target used by the Services/References (isn't that  one of the main value propositions of SCA!). In other words, all the configurable aspects of Services/References are not within the purview of the implementation developer. OTOH, an implementation developer must understand the entire structure of Properties, the range of possible values that may be specified by the users of that implementation, etc. 

 

With the above distinction in mind, it would seem natural for implementations to provide defaults for Properties, but providing defaults for bindings/targets for Services/References in the implementations would be meddling with other roles (e.g. Deployer).

</Sanjay> 

I see it as being a very simple idea that the configurable aspects of an implementation may have default values for any of those
aspects.    

<Sanjay> I disagree with this generalization. See my previous comment. </Sanjay>

- That value can apply to a Property by the property having some value defined by the implementation.
- For a service, the default value may be a specific binding and a relative URI
- For a reference, the default value may include a specific binding and/or a specific target for the reference, (some URI)  

<Sanjay> By configuring a Property of an implementation, you are effecting certain behavior/update that is confined to that implementation. OTOH, by configuring a Reference with target/binding value, you are providing details which the implementation does not care about. </Sanjay>

When an implementation is used within a component, then the component can decide to configure any or all of the configurable
aspects of the implementation.  This is true whether or not there are default values for those aspects.  The component can get
exactly what it wants, for properties, for references and for services (other than any intents, of course, which cannot be overridden).

The neat thing about defaults, is that if the component writer is OK with the defaults present in the implementation, then it cuts down
the work required to configure the component - the component can simply use the default values. 
<Sanjay> You still need to check if the component writer is OK with the defaults. That is not such a neat thing IMO. The component writer now has to exercise extra caution in checking defaults for aspects that he/she would not have expected.</Sanjay>

 
I see the "completely configured implementation" as only an extreme case of these ideas - ie an implementation where all the
configurable aspects have default values supplied, so that, in effect *no* configuration is required from the using component
in order for the component to work. 
 <Sanjay> Don't you need to 'promote' the component Services/References in order to make them visible at the SCA Domain level? <Sanjay> 

 
This has the happy side effect of allowing a particular use case to work very neatly.  This is the "zero effort deployment" scenario,
where an implementation artifact such as a Java class or a PHP script can be given to a (suitable) runtime and that runtime can
instantiate the implementation as a domain-level component without the need for any further effort (ie no need to separately
supply deployment metadata), since everything necessary is defined in the implementation artifact.  The runtime would still
in SCA terms be creating a deployment time composite for that new component, but its contents are "trivial" in the sense that
all that is required is a component element with a name, using the supplied implementation. 
 <Sanjay> As I said in my email below, the use case of 'fully configured implementation' does not require specifying binding/target on References in the ComponentType. What you need is an ability for implementations to include information that would otherwise be part of deployable composites, and this issue belongs to the C&I specifications, IMO. </Sanjay>

I note that no-one is required to build a runtime that works this way.  A runtime can insist on the deployment of contributions
that do contain composites.  On the other hand, I'd prefer to see it possible to create a runtime that does not require such
metadata.  

<Sanjay> I disagree. Supporting your proposal would at the minimum require that a compliant assembly design time tool be aware of defaults in the implementations/ComponentType-side-files. </Sanjay>

Doing this in no way runs against the principles of SCA - and requires no changes to the model either.  If a using component
wants to use the same "fully configured implementation" in a new way, it is free to do so by configuring the implementation in
whatever way it chooses.  Simply supply a composite with a component containing the necessary configuration data. 
 <Sanjay> I would personally favor a simple model where by - a> when a 'fully configured implementation' is directly deployed,  its 'full configuration' is utilized as intended, b> when a 'fully configured implementation' is  used by a component (a corner case), the deployment specific configuration coming from that implementation is ignored (as it was really not intended for this case). </Sanjay>

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>

11/03/2008 18:50

To	Mike Edwards/UK/IBM@IBMGB, "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
cc
Subject	RE: [sca-assembly] ISSUE 5: Component type allows to specify wire targets on references: PROPOSAL

 
I am guessing that the rationale behind the following proposal to close the Issue 5 with no-action is - to allow for direct deployment of implementation artifacts without requiring creation of any SCDL files, etc. Assuming that as the target use case ....
 
I would like to note that supporting the above use case does not depend upon inclusion of deployment specific configuration (e.g. wire targets on references) in the ComponentType, since a simple solution to meet the use case would be to embed the deployment specific configuration directly in the implementation artifacts. Now an interesting question to answer would be - Is there a language-neutral SCA construct to represent the deployment specific configuration embedded in the implementation artifacts? Here are some of the possible answers IMO -
 
a> None - there is no need to separately represent the embedded configuration data as an SCA construct, since the goal of the use case is to avoid creation of any SCDL files, etc.
b> Composite  - Since the SCA model expects that it is a Composite that gets deployed to an SCA domain, it logical follows that the SCA construct to represent the deployment specific configuration embedded in an implementation artifact would also be a Composite (and not ComponentType)
 
So if at all we wanted to have an SCA construct that reflects the deployment specific configuration in a directly deployable implementation, we should focus on defining a mapping between a Composite and the implementation. Mapping of deployment specific configuration embedded in implementation artifacts to ComponentType is not necessary, and if allowed for whatever reasons, there are potential downsides as documented in the issue text [1].
 
In essence, I propose that we resolve Issue-5 by adopting the proposal specified in the issue text, which says: Change the schema so that wire targets cannot be specified.
 
Thanks,
Sanjay
 
 
[1] http://osoa.org/jira/browse/ASSEMBLY-5

---

From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Tuesday, Feb 12, 2008 4:12 AM
To: OASIS Assembly
Subject: [sca-assembly] ISSUE 5: Component type allows to specify wire targets on references: PROPOSAL


Folks,

PROPOSAL:  Close Issue 5 with no action.

This permits the component type of a component to contain wire targets on references.


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

---

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