A Service Component Architecture (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>
The product 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 that the product does not support.
Information about support for SCA contributions follows:
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,
you 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.
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 that 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
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.