Composite Inclusion

SCA provides a way for developers to work independently on subsets of a single composite. For example, your company asks developer 1 to define one component, asks developer 2 to define a second and third, and asks developer 3 to define a composite service and a set of wires. Although each developer works in a separately named composite, the SCA runtime merges the definitions at deployment time. The benefit is ease of development because the different personnel are not dependent on access to the most recent version of a shared definition.

Composite inclusion relies on include elements such as the ones shown in Listing 9.14.

Listing 9.14: include elements for composite inclusion

 <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"             targetNamespace="http://www.ibm.com/HighlightInsurance"             xmlns:highlight="http://www.ibm.com/HighlightInsurance"             name="QuoteComposite"             requires="confidentiality">    <include name="highlight:QuoteComposite01" />    <include name="highlight:QuoteComposite02" />    <include name="highlight:QuoteComposite03" /> </composite> 

The SCA runtime removes each include element and substitutes the text from the named composite definition. The SCA runtime does not retain the composite element start and end tags from any of the included definitions. Policy intents specified in those tags are present at run time only if those intents were also specified in elements that are retained - for example, in the composite element of the including definition.

The combined text integrates well at deployment time only if the division of labor is carefully planned.