OSOA Home

The SCA collaboration got a lot of feedback both from within and outside suggesting the need to further simplify the SCA assembly model. From the feedback it was clear that making the SCA assembly model fully recursive would be key to achieve further simplification.

"Recursive" basically means that assemblies can be nested inside other "higher-level" assemblies. Having a fully recursive assembly model promotes the reuse of assemblies. It also allows for successive decomposition of service implementations in top-down design of solutions.

In the SCA V0.9 assembly model specification, a module contained amongst other things a set of components that were implemented by "atomic" component implementations, e.g. Java POJO, BPEL process, and so on. There was no support at the module assembly level for components that were implemented by another assembly.

Looking at the system assembly level, the V0.9 specification had components that were implemented by modules. But instead of naming them just components they are named module components, and they had no extensible implementation type concept as existed for components at the module assembly level.

So, in the SCA 1.0 Assembly model, three things have been done to simplify the model:

1. have only components independent of which level of the assembly hierarchy is involved
2. components can either be implemented by simple implementations or by assemblies
3. give a name to assemblies that does not use the term "module" or "system": composite is the name chosen.

Allowing components to be implemented by simple implementations or by composites opens some further opportunities for simplification. Both atomic implementations and composites should use the same terminology and provide the same capability to define their configurable aspects (i.e. services, references, and properties). This is achieved by renaming entry point to service, external service to reference, and to allow for properties to be defined for composites in a first class way.

In the V0.9 specification, both module assemblies and system assemblies had the concept of building up the assemblies out of a set of partial assemblies. These were called module fragments on the module level and subsystems on the system level. In the latest model this is realized by another form of usage of composites. It is the use of a composite by including it into another composite, which means textual inclusion of the contents of a composite into the composite including it. Composites used for inclusion in this way do not have to be implementations - they can contain any set of elements, which are the contributed to the composites which include them.

Summary of Model Changes

The following table summarizes the model changes by showing the new model next to old model. It can be clearly seen how making the assembly model fully recursive simplified the model by reducing the number of concepts.

The New Model in Action

In the following we show the new recursive assembly model in action using a variation of the Big Bank sample, described in a white paper published with the SCA 0.9 specification (see the BigBank Example document).

Development Assembly

The variation of the sample is to implement the AccountDataServiceComponent of the bigbank.Account composite using another composite instead of a POJO. The following shows the assembly diagrams of the two composites bigbank.Account and bigbank.Accountdata. The latter implementing the AccountDataServiceComponent of the former.

 
The following snippet shows the definition of the bigbank.Account composite. It defines an AccountDataServiceComponent that uses the bigbank.Accoundata composite for its implementation. It also shows how to define a property for a composite and how the composite property is used to set a property of a component, here on the AccountServiceComponent. This example also shows that an entry point in the composite is now called a service and that an external service is called a reference. The way that the configuration of component properties and references is spelled in XML is also simplified to remove the use of the v: namespace that caused confusion in the V0.9 specification.

<composite 	  xmlns="http://www.osoa.org/xmlns/sca/1.0"
                  xmlns:bb="http://bigbank.com"
                  targetNamespace="http://bigbank.com"
                  name="bigbank.account">

	<service name="accountService" promote="AccountServiceComponent">
		<interface.java interface="services.account.AccountService"/>
		<binding.ws port="... #wsdl.endpoint(AccountService/AccountServiceSOAP)"/>
	</service>

	<property name="currency" type="xsd:string">USD</property>

	<component name="AccountServiceComponent">
		<implementation.java class="services.account.AccountServiceImpl" />
		<property name="currency" source="$currency"/>
		<reference name="accountDataService" target="AccountDataServiceComponent"/>
		<reference name="stockQuoteService" target="StockQuoteService"/>
	</component>

	<component name="AccountDataServiceComponent">
		<implementation.composite name="bb:bigbank.AccountData"/>
	</component>

	<reference name="StockQuoteService"
                promote="AccountServiceComponent/stockQuoteService">
		<interface.java interface="services.stockquote.StockQuoteService"/>
		<binding.ws port="...#wsdl.endpoint(StockQuoteService/StockQuoteServiceSOAP)"/>
	</reference>

</composite>

The following snippet shows the definition of the bigbank.AccountData composite.

<composite 	xmlns="http://www.osoa.org/xmlns/sca/1.0"
                targetNamespace="http://bigbank.com"
		name="bigbank.AccountData">

	<service name="accountdataService" promote="AccountData">
		<interface.java interface="services.accountdata.AccountDataService"/>
	</service>

	<component name="AccountData">
		<implementation.java class="services.accountdata.AccountDataImpl"/>
	</component>

</composite>

Deployment Assembly

The following assembly diagram shows the configuration of our bigbank.account composite into an SCA domain. We configure an implementation (in our sample the bigbank.Account composite) into an SCA domain by creating another composite with a component that uses that implementation. The created composite is added to the domain by inclusion. The domain itself works just like a composite and its configuration is built up through the inclusion of other composites.

Note: In many cases implementations come with the entire configuration to make them a ready usable component in an SCA domain. SCA provides a direct way for deployment of these implementations. 

The following snippet shows the definition of the bigbank.AccountManagement composite that creates a configured instance of the bigbank.Account composite shown earlier. It shows how the currency property is set, and also how the endpoint address of the stock quote web service used is overridden.

<composite	xmlns="http://www.osoa.org/xmlns/sca/1.0"
                xmlns:bb="http://bigbank.com"
                targetNamespace="http://bigbank.com"
	      	name="bigbank.AccountManagement">

	<component name="bigbank.Account">
		<implementation.composite name="bb:bigbank.Account" />
		<property name="currency">EURO</property>
		<reference name="stockQuoteService">
			http://www.eurosq.com/SQService
		</reference>
	</component>

</composite>

The following snippet shows the definition of the bigbank.Client composite that creates a configured instance of the bigbank.Webclient composite. For details on the bigbank.Webclient composition see the BigBank Example document.. The accountService reference of the bigbank.Webclient component is wired to the accountService of the bigbank.Account component.

<composite	xmlns="http://www.osoa.org/xmlns/sca/1.0"
                xmlns:bb="http://bigbank.com"
                targetNamespace="http://bigbank.com"
	      	name="bigbank.Client">

	<component name="bigbank.Webclient">
		<implementation.composite name="bb:bigbank.Webclient" />
		<reference name="accountService" target="bigbank.account/accountService"/>
	</component>

</composite>