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 targets on references: PROPOSAL
- From: "Peshev, Peter" <peter.peshev@sap.com>
- To: "Graham Charters" <CHARTERS@uk.ibm.com>
- Date: Fri, 14 Mar 2008 18:32:41 +0100
Hi
Graham,
IMO if there is another XML file called componentType
which basically duplicates the SCDL configuration in another syntax, and the
componentType can serve as SCDL replacement, that's not much of a simplicity ,
but only brings confusion what is the difference between the two.
Just thinking loudly (I may be ashamed afterwards) , for
such "quick-n-dirty" usecases that we want
to merge the data - how about offering the possibility to define
the componentType tag (without any configurations, targets,etc.)
inside the SCDL, the configurations should still be done via the existing
concept of components & composites, and adding recommendation that a
best practice is to keep them apart as separate artifacts.
About
the "new annotations for java" route and reusing existing metadata. First,
supplying an SCA target as in the issue 5
text is hardly existing metadata, that's something that the SCA
brought, so we will need new annotation and
concept. While bringing new functionality we should
try to keep balance between the existing
number of annotations, the overall complexity and decide on case by case
basis. When I am looking at the
existing 30 annotations in org.osoa.java I am already feeling they are too much already.
Personally, I would be happy to drop some of them (especially some
conversational & callback oriented), and add something some like
@Reference(defaultTarget="goshko"). But that's a discussion for another
TC
Best
Regards
Peter
Hi Peter, I've added some comments
below in <gcc></gcc>
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
"Peshev, Peter"
<peter.peshev@sap.com> wrote on 13/03/2008 18:53:18:
> Hi
Graham,
>
> Just to make sure I understand, basically you are
saying -- SCA is too
> complex to be used by some developers, so let's
allow SCA without SCA
> SCDL artifacts to appease those people by
allowing "quick-n-dirty" fully
> configured components. Right
?
<gcc> Partly. It's not just
some developers, it's some scenarios where the flexibility and role distinctions
(and how they are burned into the programming model) actually get in the way of
them achieving their goal. There's also the 'mandatory' use of XML as part
of that.</gcc>
>
> If
yes, how exactly are you planning to provide this "quick-n-dirty"
>
configuration of SCA.
> -- By componentType side files in XML
format, which I would say are
> equally complex to SCDL-s
>
-- By introducing introspection rules for different technologies
and
> how they could generate the new fully configured componentType.
Probably
> that would result to new constructs in the respective
implementation
> types (new annotations for java, etc.).
<gcc>I think it's the latter, and I
also think that's business-as-usual for SCA. When defining an
implementation type, I think it's good to re-use existing metadata through some
existing introspection capability. Some technologies support this, and
some don't, in which case we can describe them with an XML componentType or add
some introspection capability to the technology (the C++ spec did this, open
source PHP SCA did this, etc...). We've already gone down the "new
annotations for java" route with the SCA Java
annotations.</gcc>
>
> Btw, IMHO if something went too complex and developers
refuse to use it
> , we should simplify it, instead of adding new
capabilities and another
> layer of complexity in the specs.
>
<gcc>I totally agree with the
first part, regarding simplifying, what I don't understand is how this is really
another layer of complexity. It follows the SCA model (the definition for
services, references, properties, bindings, etc.), it just allows the
information to be specified in a single artefact, but still be re-used in a full
SCA assembly without having to re-declare everything. It's up to each
implementation type to choose whether they support that approach.
</gcc>
> Best Regards
>
Peter
>
> ________________________________
>
>
From: Graham Charters [mailto:CHARTERS@uk.ibm.com]
> Sent: Thursday, 13.
March 2008 17:16
> To: Patil, Sanjay
> Cc: 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 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
>
>
>
>
>
>
>
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]