WAS v8.5 > WebSphere applications > SCA composites > SCA composites
SCA contributions
A SCA contribution contains artifacts that are needed for an SCA domain. Contributions are sometimes self-contained, in that all of the artifacts necessary to run the contents of the contribution are found within the contribution itself. However, the contents of the contribution can make one or many references to artifacts that are not contained within the contribution. These references might be to SCA artifacts, or to other artifacts, such as Web Services Description Language (WSDL) files, XSD files, or to code artifacts such as Java class files.
The following graphic shows composites in an sca-contribution.xml file in an SCA domain.
An SCA contribution is typically described in a contribution file, named sca-contribution.xml in the META-INF directory. The contribution file for a helloworldws composition unit follows:
- <?xml version="1.0" encoding="ASCII"?> <contribution xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:ns="http://helloworld"> <deployable composite="ns:helloworldws"/> </contribution>
WAS v8.5 supports contributions, as described in Chapter 1.10 of SCA Assembly Specification 1.0. The assembly specification defines the contribution metadata model to describe the runnable components for a given contribution, as well as the exported definitions and imported definitions to help resolve artifact dependencies across multiple contributions. See "Unsupported SCA specification sections" for information on parts of Chapter 1.10 the product does not support.
Information about support for SCA contributions follows:
- Preconditions or inputs
- Postconditions or outputs for JAR packaged applications
- Postconditions or outputs for WAR packaged applications
- Contribution scenarios
- Scenarios for mapping multiple deployable composites to a composition unit
- Notes and limitations
Preconditions or inputs
One SCA contribution, including multiple deployable composites, and with import or export definitions.
Postconditions or outputs for JAR packaged applications
- After successful creation of an SCA contribution as an asset,
we can do the following:
- Create a business-level application, add the asset as a composition unit, and start and stop the application.
- Target each deployable composite to a different server or cluster.
- Delete the deployable composites individually.
- Support import or export namespace:
- WSDL can be defined in another contribution. Use <import name = "name_ space"/> to declare dependencies.
- Schema XSD can be defined in another contribution. Use <import
name = "name_space"/> to declare dependencies
- Use <export name="name_space"/> to make WSDL or XSD available to other contributions.
- Composite for recursive model can be defined in another contribution.
- Support import.java and export.java package name:
- The Java package can be in another contribution. Use <import.java
name="java_ package_ name"> to declare dependencies.
- Use <export.java name="java_ packages"> to make Java packages available to other contributions.
- The Java package can be in another contribution. Use <import.java
name="java_ package_ name"> to declare dependencies.
Postconditions or outputs for WAR packaged applications
Successful installation of a WAR module with a single deployable composite in the contribution.
Contribution scenarios
- There are multiple runnable deployable composites in a contribution. One extreme case is there is no runnable for the contribution, so the contribution is used as a shared library for resources and classes.
- Declare an import or export namespace for resource resolution, such as WSDL, XSD, and composite definition.
- Declare import.java and export.java for classLoader dependencies.
- Support artifact resolution for contributions targeted on the same server.
- Support artifact resolution for contributions targeted to a different server or cluster in a multiple-server environment.
- Support partial updating of an installed contribution (asset). This support includes any updating other than a change to the sca-contribution.xml file. You should be able to restart the composition unit that has the assets as a dependent. Updating the archive attribute of an implementation.jee element in the component section of a composite is not supported.
Scenarios for mapping multiple deployable composites to a composition unit
- Scenario 1:
- When a contribution does not contain the sca-contribution.xml file, it can contain a deployable composite under the META-INF/sca-deployables directory.
The composite file must be named default.composite.
The default.composite file is automatically the deployable composite.
- When creating a composition unit, because this composite is automatically the deployable composite, we do not see the console page to select the deployable composite.
- After composition unit creation, each composition unit is mapped to one composite.
- When a contribution does not contain the sca-contribution.xml file, it can contain a deployable composite under the META-INF/sca-deployables directory.
The composite file must be named default.composite.
The default.composite file is automatically the deployable composite.
- Scenario 2:
An asset can contain an sca-contribution.xml file that has zero-to-many (0…n) deployable composites:
- Use sca-contribution.xml deployable composites to create 0…n deployable units with the deployable composite's QName as the deployable unit name.
- The asset is tagged as an SCA asset.
- During asset creation, each deployable composite is identified
as a deployable unit.
- When creating a composition unit, we can select only one deployable
unit. For SCA composition units, we cannot select multiple deployable
composites. This is different from non-SCA business-level applications,
for which we can select multiple deployable units.
- Start or stop targets the deployable unit's composite.
- If the composition unit is created as a shared library, or no deployable unit is selected, the default deployable unit is used:
- View or edit is not available for the composition unit.
- Start or stop is not available for the composition unit.
Notes and limitations
Currently this topic focuses on JAR-packaged SCA applications. For WAR-packaged applications support is provided for only a single deployable composite in the contribution.
Related concepts:
Unsupported SCA specification sections
SCA components
SCA in WAS: Overview
Related
Specify bindings in an SCA environment