SCA application package deployment

The product supports deployment of many types of Service Component Architecture (SCA) artifacts as composition units of business-level applications. Typical artifacts include JAR files, compressed .zip files, and WAR files.

The following outlines the details about deployment of SCA artifacts:

• Deployment of JAR or compressed files

• Deployment of WAR files

• Notes and limitations

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:

  1. 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, we can select the composite to deploy.

  2. 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.

  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 the SCA composites.

  This topic references one or more of the application server log files. As a recommended alternative, we 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. We can also use HPEL in conjunction with the native z/OS logging facilities. If we are using HPEL, we can access all of the log and trace information using the LogViewer command-line tool from the 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:

  • The product uses the QName to resolve composite files included in the top-level composite that use the element. For example, the <include name="mynamespace:MyService"/> statement looks for a composite file whose composite name is MyService and whose targetNameSpace is mynamespace. The following rules apply:

    • name: Use the outer composite.

    • namespace declarations: Merged into the outer composite.

    • targetNamespace: Use the outer composite (must be the same).

    • local: Use the composite (preferably the same but not required).

    • requires(intents) and policySets: Must be compatible, and aggregated into the outer composite.

    Deployable composite files must have name and targetNamespace values. The name and targetNamespace values are combined to form the QName of a composite file.

  • When a composite is used as a component implementation in the top-level composite, the composite is also resolved using the QName. For example, the <implementation.composite name="mynamespace:MyComposite"/> statement causes the product administration to look for a composite file whose composite name is MyComposite and whose targetNamespace is mynamespace.

• 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, we 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.

Notes and limitations

• The product does not provide administration console pages for configuring contributions.

• If we import a package or namepace from a different contribution, or JAR (contribution.xml), we might need to import that contribution as an asset before importing our own asset.

  For example, suppose the Contribution A imports a JAR file from Contribution B. We might need to import Contribution B and then Contribution A as assets. Contribution A depends on Contribution B so you must import Contribution B before importing Contribution A.

• We cannot use a local interface across a class loader boundary. Use a remotable interface to cross a class loader boundary.

Related tasks

Deploy and administering business-level applications

Use High Performance Extensible Logging to troubleshoot applications