The product supports deployment of many types of Service
Component Architecture (SCA) artifacts as composition units of business-level
applications. Typical artifacts include Java archive
(JAR) files, compressed .zip files, and web application
archive (WAR) files.
The following outlines the details about deployment of SCA artifacts:
Deployment of JAR or compressed files
- The product supports one composite file for each package. The
product determines which composite file to support using the following
process:
- The SCA deployment extension looks for the META-INF/sca-contribution.xml file,
gets the name of each deployable composite defined in the file, and
uses QName values to find the actual composite file names under any
directory for that composite. If more than one composite is found
in the sca-contribution.xml file, you can select
the composite to deploy.
- If there is no META-INF/sca-contribution.xml file
defined, the SCA deployment extension looks for a composite file in
the META-INF/sca-deployables directory.
- The product validates SCA composites for inconsistencies with
SCA specifications.
One specification requirement is that the names
of top-level components must be unique. Thus, the product validates
top-level component name uniqueness.
Tip: Top-level
components are also called domain components, with the top-level or
domain typically the cell on multiple-server installations and the
server scope on single-server installations.
The product
validates all composite files in a JAR or compressed file, regardless
of the file location in the archive or whether the sca-contribution.xml file
references the composite file. The product does not validate all services
and references.
The product writes warning and error messages
resulting from the validation tests to the SystemOut.log file.
Refer to the log file to learn about inconsistencies with specifications
in your SCA composites.
Note: This topic references one or more of the application
server log files. As a recommended alternative, you can configure
the server to use the High Performance Extensible Logging (HPEL) log
and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM® i systems. You can also use
HPEL in conjunction with your native z/OS® logging facilities. If you are using HPEL, you can access
all of your log and trace information using the LogViewer command-line
tool from your server profile bin directory. See the information
about using HPEL to troubleshoot applications for more information
on using HPEL.
- The product uses the following process for QName resolution:
- A JAR file can contain other JAR files at the top level. The contained
JAR files are available on the classpath. However, any archives inside
those JAR files are not available. The product supports one level
of embedded JAR files.
Deployment of WAR files
- A composite file in a WAR file must be named default.composite.
A composite file that is not in a WAR file can have any name.
- The default.composite composite file must be
inside a WAR file in the META-INF/sca-deployables directory.
- The META-INF/sca-deployables directory must
contain no more than one composite file. If there is more than one
composite file in the META-INF/sca-deployables directory,
then the product returns a validation error and stops the WAR file
deployment.
However, you can place other composite files in directories
other than META-INF/sca-deployables, and reference
those composite files in the top-level composite under the META-INF/sca-deployables directory.
- The product does not support having a sca-contribution.xml file
inside the WAR file under the META-INF directory.
If the product finds a sca-contribution.xml file,
then the product returns a validation error and stops the WAR file
deployment.