|
There's nothing to it. Really. Seriously, one of the main goals of Tuscany and SCA is to avoid imposing rules and requirements on how people write applications. We want to let people write application code the way they want without being concerned about the environment in which it will be used. After all, writing code to handle plumbing just gets in the way of writing the interesting stuff. So basically, you write the code for interesting bits, and Tuscany provides the environment that lets it run.
As a result of that, this guide does not actually contain a lot of gory details on how to write an application for SCA. What it does contain is a description of the information that Tuscany uses to figure out how to run your code, the things that it can handle, and the things that it can't. As part of that it provides guidelines and best practices that you can use to make your code easier for others to use or that allow it to run in more places. This guide also describes the different environments that Tuscany supports (such as command line clients or web applications) and how to package up applications to run in them.
Components
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)
Although the Tuscany runtime is written in Java, the implementation of a component can be in other languages some of which may be more suitable to the form of implementation than Java code (for example, BPEL for business processes or XSL-T for transformations). How the services, references, properties and intents are defined for an implementation is specific to that particular implementation type; Tuscany provides several including:
- Java for POJO style components
- JUnit
 for integration testing of SCA components
- Spring for integrating Spring components
- JavaScript for components written in JavaScript
Please see each sub-section for detailed information on implementing components in any of these languages.
Composites
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). For information on how this is used in Tuscany, please see:
>> Comment: Is this a good place to talk about wires? We talk about wires in the next section for the first time and it is out of context
Domain Assemblies
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 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 self-defining - it is what it is. It is really just 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 but during development the goal is to make that Someone Else's Problem as all that baggage really just gets in the way of writing code.
Making it Someone Else's Problem though does mean that at some point you need to hand them the implementations that you have been developing. This generally goes better if the code being handed over has been well tested and packaged up nicely (sometimes with a bow on it). Tuscany provides some build-time tools to help with this:
| 
