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: 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, 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]