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 24: textual sca:include not sufficient



http://www.osoa.org/jira/browse/ASSEMBLY-24

On Nov 7, 2007, at 6:54 AM, Blohm, Henning wrote:

> TARGET:
>
> Assembly Specification, section "Using Composites through Inclusion"
>
> DESCRIPTION:
>
> SCA's include mechanism for SCDL artefacts is described as a  
> textual inlining of the included composite's body into the  
> including composite.
>
> That leads to a set of problems:
>
> a) XML name spaces are ignored
>
> An included composite may make use of namespace prefices that  
> become meaningless (or change meaning) when considered within the  
> including composite.
>
> b) artefact resolution moves to the includer
>
> On the one hand SCDL artefacts may be re-used across contributions  
> (see SCA deployment) and SCA's domain concept relies on inclusion  
> to implement a cross-contribution assembly mechanism, on the other  
> hand many SCDL declarations refer to artefacts that may not be  
> resolvable within the includer's resolution scope.
>
> For example, implementation type declarations such as  
> <implementation.java/>, <implementation.bpel/>,  
> <implementation.spring/> refer to artefacts such as Java classes,  
> bpel process descriptions, and application context XML files, that  
> may not resolvable across contributions and much less on the domain.
>
> PROPOSAL:
>
> Describe sca:include over the assembly model of SCA rather than a  
> textual operation - similarly to how <implementation.composite/> is  
> described today.
>
> For example (simplified and using terminology that requires more  
> explanation)
>
> All services, references, properties, and component elements of the  
> included composite lead to services, references, properties, and  
> component elements by the same name (resp.) in the including  
> composite. Any other content of the included composite is ignored.  
> Resulting component elements are opaque to the includer, that is,  
> all artefact resolution required to evaluate the component  
> declaration must be performed in the resolution scope of the  
> included composite. This algorithm is recursively applied in a  
> depth-first traversal.
>
>



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