Part Two: How to Create Our Own Composite
The SCA composite we used in our calculator application is defined in the file PojoCalculator.composite. This configuration file uses an XML-based format defined in the SCA Assembly Model specification.

Every SCA composite is composed of one or more components. A component is a piece of code that provides one or more services. A component may also rely on services provided by other components, which it indicates using references. (Components and composites can also have properties, but we won't cover them here. A property is simply a value that can be set in the definition of the component.)

Let's take a look at PojoCalculator.composite section by section. The overall picture of the composite looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:sample="http://sample"
name="Calculator" targetNamespace="http://sample"> 

This header is standard for an SCA Composite and indicates that it is an SCA 1.0 Composite and that it has the name "Calculator."

<component name="CalculatorServiceComponent">
<implementation.java class="pojoCalculator.PojoCalculatorServiceImpl"/>
<reference name="addService" target="AddServiceComponent"/>
<reference name="subtractService" target="SubtractServiceComponent"/>
<reference name="multiplyService" target="MultiplyServiceComponent"/>
<reference name="divideService" target="DivideServiceComponent"/>
</component> 

This <component> is the service we actually used in our SCA application. If we look back at the application code, the call to getService() included the name "CalculatorServiceComponent" as one of its arguments. The relationships between the POJOs are defined here. The component uses the <implementation.java> element to define the Java class that does the work. It also contains references to four other components. Those other components are defined here:

<component name="AddServiceComponent">
<implementation.java class="pojoCalculator.AddServiceImpl"/>
</component>
<component name="SubtractServiceComponent">
<implementation.java class="pojoCalculator.SubtractServiceImpl"/>
</component>
<component name="MultiplyServiceComponent">
<implementation.java class="pojoCalculator.MultiplyServiceImpl"/>
</component>
<component name="DivideServiceComponent">
<implementation.java class="pojoCalculator.DivideServiceImpl"/>
</component>
</composite> 

Each of these defines a component and the Java class that implements it.

At this point, we've defined the CalculatorServiceComponent and everything it needs to do its work. And with that, we are done defining our first SCA composite!

Wrapping Up
These examples can help to build real-world applications and composites.

The SCA application and the SCA composite we've built here are simple. If we're writing an SCA application, as we did in the first part of this article, things don't get any more complicated than this. Create the POJO and call its methods. If we're creating an SCA composite, however, we can do far more sophisticated things. We could add other implementation types, other protocols, and policies such as encryption and authentication to the definition of our composite. Despite that, the original application would still work.

If you're an application developer, writing an application with SCA means the code is simpler, there's less of it to write, and there's less of it to maintain. If you're an administrator, packaging your components with SCA gives you tremendous power and flexibility, allowing you to change how your components work without worrying how the applications that use them will be affected.

References

• Apache Tuscany

• Assembly Model—Defines the rules for the XML .composite files that describe SCA composites.



• SCA Java Common Annotations and APIs—Defines the Java annotations and programming interfaces for specifying how parts of a Java class or interface work in an SCA environment.



• SCA Java Component Implementation—Defines how Java code can be packaged as an SCA component.