[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] ISSUE 51: Composite Completeness
Comments below inline. I agree with the spirit and intent of the proposal.
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
Scott Vorthmann
<scottv@tibco.com
> To
Michael Rowley <mrowley@bea.com>
02/19/2008 11:24 cc
AM <sca-assembly@lists.oasis-open.org>
Subject
[sca-assembly] ISSUE 51: Composite
Completeness
http://www.osoa.org/jira/browse/ASSEMBLY-51
On Feb 19, 2008, at 7:16 AM, Michael Rowley wrote:
>
> RAISER: Michael Rowley
>
> TARGET: SCA Assembly Specification (WD02) section 6.5 “Using
> Composites as Component Implementations”.
>
> DESCRIPTION:
>
> There are a few problems with this section:
> 1) The description of the “completeness contract” does not say
> anything about component references for a complete composite. It
> should state requirements such as the fact that @target, if present,
> must refer to a service within the same composite,
<dab> If it doesn't have a target, is not promoted, no autowire and no
wiredByImpl, and no binding with @uri, it's an error. </dab>
> and the fact that
> every multiplicity 1..1 or 1..n reference must be wired.
<dab> Unless you have autowire enabled.</dab>
> Neither of
> these requirements are true for deployment composites, or composites
> used by inclusion (i.e. incomplete composites).
> 2) Line 1730 says that composite services “must be wired”. We
> no longer talking about wiring for this scenario, but refer to it as
> promotion instead.
+1
> 3) Line 1732 says “if services are left unwired, the
> implication is that some exception will occur at runtime if the
> service is invoked.” This seems to contradict the “must” in the
> previous sentence. If the previous sentence is really a “must”,
> then a deployment error should occur.
+1
> 4) (Minor) Line 1726 says “the composite must have at least
> one service or at least one reference. A component with no services
> and no references is not meaningful in terms of SCA, since it cannot
> be wired to anything – it neither provides nor consumes any
> services.” It is not true that it is not meaningful. SCA can cause
> the component to be deployed, even if it can’t wire anything into or
> out of it. Legacy technology of the components (or at least non-SCA
> technology) may be used for providing and using services, and since
> we want to be an integration technology, we should allow for these
> kinds of scenarios.
+1
>
> PROPOSAL:
>
> Change the requirements of a complete composite to the following:
> • Each service offered by the composite must promote some
component
> service that is within the composite.
> • Every wire target specified in the composite (specified
through
> reference/@target or wire/target) must refer to a service within the
> same composite in which the wire is present.
> • Every reference with a multiplicity of 1..1 or 1..n must be
wired
> (according to the various rules for specifying wires listed in
> section 3.0.1 [issue 6]).
>
> We may want to consider moving this section about completeness to
> immediately follow section 3.0.1, since “completeness” is primarily
> about making sure that the requirements of section 3.0.1 are true
> about a stand-alone composite (i.e. not included into another
> composite or the domain).
>
>
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]