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 SCA contribution graphic
shows composites in an sca-contribution.xml file
in an SCA domain.
Figure 1. SCA contribution
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 Feature Pack for SCA 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 feature pack 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.