sca-assembly message
[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
- From: Graham Charters <CHARTERS@uk.ibm.com>
- To: "Patil, Sanjay" <sanjay.patil@sap.com>
- Date: Thu, 13 Mar 2008 15:15:50 +0000
Hi Sanjay,
I'm not Dave, or Mike, but I'd like
to chip in ;-) . I think they've both covered most of the points
I would make, regarding easing adoption by making it quick to get started,
and the fact that a single person is performing multiple roles. Regarding
your questions:
> 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)?
I think this comes down to how these
fully configured implementations get re-used and reconfigured in a pointy
brackets world. Mike mentioned this in his response about not requiring
everything to be redeclared.
I think we have an opportunity here
to enable a broader community of developers, which can bring skills and
build assets to our SOA programming model. If we don't make it a
smooth progression from the "quick-n-dirty" fully configured
world to the world of SCDL, then I think we'll be limiting the applicability
of SCA, and helping persuade the "quick-n-dirty" folks to choose
another technology.
Regards,
Graham.
Graham Charters PhD CEng MBCS CITP
SWG AB Projects
IBM United Kingdom Limited, MP 146, Hursley Park, Winchester, SO21 2JN,
UK
Tel: (Ext) +44-1962-816527 (Int) 7-246527 (Fax)
+44-1962-818999
Internet: charters@uk.ibm.com
"Patil, Sanjay" <sanjay.patil@sap.com>
wrote on 13/03/2008 04:05:29:
>
> 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
>
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]