sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: AW: [sca-assembly] ISSUE 5: Component type allows to specify wire targets on references: PROPOSAL
- From: "Barack, Ron" <ron.barack@sap.com>
- To: "Mike Edwards" <mike_edwards@uk.ibm.com>, <sca-assembly@lists.oasis-open.org>
- Date: Thu, 13 Mar 2008 16:19:35 +0100
Hi Mike,
In this use-case, why would the programmer use SCA rather
than whatever means the technology offers to access web services? For
example, I'd expect a java component to use JAX-WS here, not SCA. What
benefits does SCA bring to the use-case?
Ron
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]