Components

As an Application Developer, you define the Application Components after creating an Application. A Component is a single deployable application artifact.

Components may contain files, objects, and administrative scripts among others and are to be deployed on Deployment Targets (see CDA Deployment Model). Each Component has different properties which determine where to get it from, how to configure it, and so on. You need at least one Component per Application.

This page includes the following:

Overview

A Component can be any file (also configuration files), objects (for example, database structure), administrative scripts that are stored under version control or in a source or staging system, and so on. For example, the .war file that must be deployed into a Tomcat container can be a Component.

Note: The following graphic illustrates the role of Components in the Deployment Model. Select the image to expand it.

Components of an Application

Components typically reflect the tiers of a distributed Application. You can create one or more Components per tier. For example, one for the database back-end, one for the mid-tier and one for the web application.

Consider defining several Components per tier if they are separately deployable units (for example, EJBs). See Component Best Practices.

Detached Components

Detached Components are not connected to Deployment Targets. You can use them as blueprints for hosts that should be provisioned.

Properties of Components

The properties of Components are settings that can be used to:

Feed Component Workflows.
Customize any type of configuration object, for example, configuration files or database tables.

Usually they have one of the following values:

Environment-specific

Defaults are typically overwritten within deployment profiles. Sometimes, values are dynamically constructed out of dynamic property reference expressions, including references to deployment targets.
Software/configuration package-specific

Values are prompted when a package is created or defaults are overridden on the package-level.
Deployment-specific

Values are prompted before deployment runtime.
Provided via dynamic property overrides

On package-level. They are specific to the software/configuration package.
Provided at deployment runtime

Specific to the individual deployment.