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>
13/03/2008 14:40
|
To
|
"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