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

[Mike Edwards <mike_edwards@uk.ibm.com>]

Folks,

Comments inline as <mje>
</mje>

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>

12/03/2008 21:43

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

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>


<mje>
My answer here is that
it depends on the usecase.

I can see it being
an advantage for smaller installations, where there is no separation of
roles (the developer is also the deployer),
to maintain everything
in one code artifact.

SCA still provides
the separation of concerns in that the code has a reference (or a service)
and the code is oriented towards the
business interface.


However, if the code
was originally created to target a specific service (I gave the example
of Ebay or Amazon in the F2F), then
it can be useful and
simpler for the developer to annotate the code with that specific service
as the target of a reference.
@WebService( uri="http://www.ebay.com/services/fooservice"
) ....

...this seems VERY
natural, as natural as it is to supply a default value for a property.
 There is no "meddling with other roles"
if in the simple case
one person does all the roles.

This does not detract
from the ability within SCA to take the same implementation and to reuse
it in a new context, where the 
target service is some
different service provided by someone else (or even a complex mediation
that maps to one or more
services).

However, it does permit
something really simple for the simple case.  All the configuration
is there in the code artifact and it
is possible to deploy
it without the need to supply any other metadata or to build any other
files.
</mje>


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>

<mje> Well, the
implementation cares a lot that the reference has some value - ie points
to some target. </mje>

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>

<mje>I find that
a surprising statement - if there are no defaults then the component writer
has to care about everything.  If they don't specify something, the
component is broken</mje>
 
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> 

<mje>No, you
don't.  Simply deploy a component at the Domain level - it has services
and it has references with targets.  Job done.  No promotion.
(that is how it works
today, no changes here....)</mje>
 
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>

<mje>
Why invent a load of
new mechanics to do this when the componentType offers all that is necessary
- and in a simple natural way?
</mje>

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>

<mje> 
But they have to be
able to read the componentType anyway today, like it or not - and that
includes introspection for some implementation types like Java</mje>

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>

<mje> I'm all
in favour of simple models ;-)

However, it does not
sound so simple to treat an implementation in two very different ways depending
on circumstances.

I think that dealing
with them in one straightforward fashion is simpler.  There are default
values and you can choose either
to use them or to override
them.

</mje>


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

---

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