OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: NEW ISSUE: Composite Completeness


 

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, and the fact that every multiplicity 1..1 or 1..n reference must be wired.  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.

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.

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.

 

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).

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]