[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] ISSUE 5: Component type allows to specify wire targetson references: PROPOSAL
some quick answers while Mike is sleeping.....<dab> like this </dab>
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
"Patil, Sanjay"
<sanjay.patil@sap
.com> To
"Mike Edwards"
03/12/2008 05:43 <mike_edwards@uk.ibm.com>, "OASIS
PM 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>
<dab> In general, I agree very strongly with your distinction. However,
the proposal is specifically and explicitly setting that aside to enable
some use cases which are not part of the general usage. This is about
enabling early adopters who are a) technically advanced (and therefore can
also see that they are trampling on the distinction you are making) and b)
are trying to dig in and get something running quickly. Dogmatically
forcing them into the general case will inhibit adoption. I'm usually the
one that cries "simplicity first" when we start straying out of the 80%
use cases. FWIW, I think this case is worth enabling because it will
foster adoption of the technology. </dab>
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>
<dab> Agree, but this is about the implementor being able to play all the
roles in a quick and easy manner. This is not about a clean
implementation, </dab>
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>
<dab> It's the same person in this case. </dab>
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>
<dab> No, absolutely not....this is really an argument for another day
(and another thread) and I'll not go further here. </dab>
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>)
<dab> If you had such an implementation and then generated a componentType
from it, would it not look exactly as this proposal describes? </dab>
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>
<dab> l think we could make those elements optional compliance points.
</dab>
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>
<dab> ah...a ray of light. This would make a fully configued composite
(which is an implementation) different from a fully configured Java
implementation. </dab>
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>
To
11/03/2008 18:50 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]