Quick Guide to SCA

SCA Component

The basic building block for SCA is a component. When you're writing code for SCA, you are typically writing code that will either be the implementation of a component or will be used by such an implementation.

An SCA component follows the Inversion of Control design pattern with Tuscany providing the controlling framework. A typical component can be illustrated as:

where

• Services describe the function this type of component provides
• References are dependencies this type of component has in order to function
• Properties define configuration parameters for this type of component
• Intents describe assumptions this type of component has on how it will be used
• and Implementation is some code that actually does the work (i.e. what a developer writes)

The implementation of a component can be in any language that is suitable for the user, for example BPEL for business processes or XSL-T for transformations or Ruby for scripting or pure Java. How the services, references, properties and intents are defined for an implementation is specific to that particular implementation type.

SCA Composite

Individual components like those above can be used on their own, or they can be grouped together to form composite components. A composite is a type of component whose implementation is not code but an aggregation of other components co-operating to provide Services as a whole. A composite provides Services, has References to other dependencies, and can be configured using Properties in just the same way as individual components can.

The typical implementation of a composite is described using XML defined by the SCA Assembly Specification (known as SCA Component Definition Language or SCDL).
add more information and a diagram

SCA Contribution

SCA Domain

The implementations of components above, either individual or composite, all form reusable units that can be run multiple times in different environments (in much the same way as you have multiple instances of a Java class). A component or composite becomes instantiated when it is actually used in an SCA environment. This is done by using it as part of the assembly of an SCA Domain.

SCA Domains can vary in size from the very small to the very large:

• a very small domain could be one within a test environment inside an IDE
• a medium sized domain could be a single server or small cluster supporting a single application
• a large domain could describe all the services within a department or company

A domain is a logical view of running applications or a coherent grouping of components that are working together, connected to each other using SCA wiring. In a large domain there may be all sorts of policies about where components can run and how they connect to each other or to external services. However, during development one is not concerned with all this. The code is packaged and made available for deployment. Tuscany provides some build-time tools to help with packaging. For example, a war Maven plugin to package a self contained web application.

place holder for text

you develop an app and package it as a contribution. The app may consist of one or more composites.
Contribution is an installable piece. So, you then install the contribution and then activate the deployed composites in the contribution. The SCA domain is the logical view of running applications that can span multiple SCA runtimes.