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 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. Click the image to expand it.

Graphic depicting role of components in deployment model

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.

Component Types

You can work with the following Component types:

  • Basic Components: Components based on a custom type. See: Working with Application Components
  • Shared Components: Predefined components that can be reused in different applications to minimize the design process. Shared components are configured once and then reused, with some adaptations, in different Applications. See: Working with Shared and Proxy Components
  • Proxy Components: A Proxy Component must be created within an Application to reference the properties defined in a Shared Component (for example: Workflow, Dynamic Properties).
  • Nested Components: Used to execute a single deployment process where multiple Components are deployed on the same Target. Nested Components can also be used to deploy one Component that needs to get multiple Artifacts from different Artifact Sources. To deploy nested Components, you have to assign them to a normal Component and then deploy the normal Component. See: Working with Nested Components
  • Component Links: Enables one Component to retrieve information from another one. You may usually bind multiple instances of one Component to a single instance of another Component. For example, multiple front-end servers may reference one database. See: Working with Component Links

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 Profiles. Sometimes, values are dynamically constructed out of dynamic property reference expressions, including references to 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.

See also: