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.
Deprecated feature: The Service Component Architecture (SCA)
programming model and samples are deprecated, and will be removed in a future release. You cannot
deploy new SCA business-level applications.
Update your applications to use different programming
models. The programming models that you use vary depending on how you previously incorporated SCA in
your application.
If you used SCA for binding, consolidate the ways in which your application
is exposed to a few standards, such as Java API for RESTful Web Services (JAX-RS) or Java Message
Service (JMS). For example, use JAX-RS for application bindings. To minimize the duplication of
binding level implementation, structure your application to use shared code.
If you want to
continue to use SCA as part of your long-term strategy, consider hosting your applications on IBM Business Process Manager.
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.