[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
And you're also forgetting that autowire will not always be on in the
Domain. The resolution of this issue should not force it to be on.
However, I do agree that auto wire should be beefed up to enable selection
and matching expressions, but the use cases for it have nothing to do with
the kind of ease of use accelerators that Mike E is proposing.
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
"Michael Rowley"
<mrowley@bea.com>
To
03/13/2008 02:38 "Mike Edwards"
PM <mike_edwards@uk.ibm.com>,
<sca-assembly@lists.oasis-open.org>
cc
Subject
RE: [sca-assembly] ISSUE 5:
Component type allows to specify
wire targets on references:
PROPOSAL
I did not think that componentType/reference/binding was in question with
issue 5. I thought it was entirely about SCA wire targets.
Michael
From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Thursday, March 13, 2008 10:52 AM
To: sca-assembly@lists.oasis-open.org
Subject: RE: [sca-assembly] ISSUE 5: Component type allows to specify
wire targets on references: PROPOSAL
Michael,
Unfortunately, your proposal does not deal with what I think will be
one of the really
common cases.,
This is where a developer crafts a component with a reference that
uses a specific service.
Let's say it's one of those well known external web services like
Amazon or EBay. It seems
only too natural for the developer to want to mark the reference as:
a) a Web service
b) with the actual Web service endpoint target for the well-known
service
This could not be handled via Autowire as the target is clearly not
in the domain.
Is it only reference targets within the Domain that concern you as
being potentially harmful or
does this use case also strike you as problematic?
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>
To
13/03/2008 14:40 "Patil, Sanjay" <sanjay.patil@sap.com>,
"David Booz" <booz@us.ibm.com>,
<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 sympathetic to the use case, but like Sanjay I am uncomfortable
about including wire targets in component types. Unfortunately,
Sanjay's alternate approach to the use case also doesn't seem quite
right (I don't like instance specific information in the
implementation
or the component type).
I would prefer to handle this kind of use case with autowiring, or if
necessary, a beefed-up autowire capability.
I believe that in most cases, new implementations should be able to
be
directly deployed, without having to write any of those nasty pointy
brackets, because there will only be one service that offers the
interfaces that their references are looking for. Autowire will find
that.
If there are multiple services that offer the same interface, then
autowire should be extended so that it can choose the right one based
on
other criteria -- such as the one that is marked with "use me as the
default, if the client doesn't care".
If other people like that idea, I will try to flesh it out a bit
more.
Michael
-----Original Message-----
From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
Sent: Thursday, March 13, 2008 12:05 AM
To: David Booz; sca-assembly@lists.oasis-open.org
Subject: RE: [sca-assembly] ISSUE 5: Component type allows to specify
wire targets on references: PROPOSAL
Hi Dave,
One question from my side while Mike is still sleeping ...
<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>
Question: Why in the world do you need to generate a componentType
for
this use case of 'directly deploying a fully configured
implementation'?
I thought you wanted to directly deploy a fully configured
implementation because pointy brackets may hurt and bleed, right? So
just go ahead and deploy the fully configured implementation. Why
bother
about generating a componentType (which would have pointy brackets)?
-- Sanjay
> -----Original Message-----
> From: David Booz [mailto:booz@us.ibm.com]
> Sent: Wednesday, Mar 12, 2008 20:26 PM
> To: sca-assembly@lists.oasis-open.org
> Subject: RE: [sca-assembly] ISSUE 5: Component type allows to
> specify wire targets on 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
>
>
>
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC
that
> generates this mail. You may a link to this group and all
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
>
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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]