THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Panel | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
Purpose of this guide is to help you understand the high level concepts in SCA so that you can build a simple application. For more details on SCA please refer to the various specifications available at www.osoa.org.
Column | | width | 50%
|
| Section |
|---|
| Anchor | ||||
|---|---|---|---|---|
|
SCA is an executable model for assembly of services into business solutions. It simplifies component programming model for implementation of business services that can be implemented in any language. The key benefits of SCA are:
- Loose Coupling: Components integrate with other components without needing to know how other components are implemented. Components can be easily invoked either synchronously or asynchronously.
- Flexibility: Components can easily be replaced by other components. It also provides the flexibility to create solutions using existing services (bottom up) or model the business and develope the solution (top down).
- Productivity: It enables you to focus on your business logic rather than be slowed with concerns about infrastructure. SCA simplifies development experience for all developers (including J2EE and Integration Developers), integrators and application deployers
Now let's get into description of SCA building blocks.
| Anchor | ||||
|---|---|---|---|---|
|
The basic building block for SCA is a component implementation. 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
A component implementation is described by the following attributes:
- Services: This describes Services describe the function this type of component provides
- References are : This describes the 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)
- : This defines configuration parameters that can controls how the program logic can behave. For example, what currency to use.
- Intent policies: This describes assumptions on how the component will behave. There are two types of policies.
- Implementation policy- Impact the behavior of an implementation. For example, transaction, monitor and logging
- Interaction policy - defines how the components behave with one another. For example, security.
A typical component implementation can be illustrated as:
The 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, 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; 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.
.
| Anchor | ||||
|---|---|---|---|---|
|
A component is an instance of a configured component implementation. More than one component can use the same implementation. A component lives in a composite that is described next.
| Anchor | ||||
|---|---|---|---|---|
|
...
Individual components like those above can be used on their own, or they can be grouped together to form in a composite components. A composite is a type of component whose implementation is not code but an aggregation of other one or more components co-operating to provide Services as a whole. Think of composite as a solution, for example credit check composite. A composite can also be used within a larger solution, for example credit check can be part of a order processing composite. A composite has the same charactersitics as a component. It provides Services, has References to other dependencies, and can be configured using Properties and can have intent policies in just the same way as an individual components can. In the example below, you see a calculator composite which consists of 5 components, a calculator service has references to four components:Add, Subtract, Multiply and Divide.
The typical implementation of a composite is described using XML defined by the SCA Assembly Specification (known as SCA 
The assembly or wiring is defined in .composite file through Service 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
example, calculator.composite would define that calculator component references the other four components.
| Anchor | ||||
|---|---|---|---|---|
|
...
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 composite, with its configuration information, gets packaged into a deployable unit called a contribution which gets contributed to the domain. Artifacts may be shared between contributions, for example Java classes, XSD files, WSDL files,etc.
An SCA Domain represents a complete runtime configuration, potentially distributed over a
series of interconnected runtime nodes. Domain configuration is the overall configuration for service dependencies, properties, policies. A domain is a logical view of the running applications or a coherent grouping of components that are working together, connected to each other using SCA wiring. A composite gets 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 . However, 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:
...
one is not concerned with all this. The code is packaged and made available for deployment. Tuscany SCA Java supports contributions in the form of JAR or filesystem.
Below is an example of domain with two contributions.
...