NEW ISSUE: textual sca:include not sufficient

["Blohm, Henning" <henning.blohm@sap.com>]

Title: NEW ISSUE: textual sca:include not sufficient

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.