System.Application
[This is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders.]
This topic describes the key extents and data types that provide the basis for defining software application models using code name “Oslo”.
System.Application Overview
The System.Application module defines a set of storage extents and data types for commonly occurring data in many software application models, as well as storage specific to certain aspects of Web applications. The System.Application module is referenced by other application-specific modules, including the System.ServiceModel and System.WorkflowModel and System.WorkflowServiceModel modules, each of which describes some additional aspect of an application.
The System.Application model implements a notional generalization hierarchy for software components, software resources, and software endpoints. In this hierarchy, general characteristics are represented by entity types high in the hierarchy while more specific aspects are represented by entity types lower down. The concrete (or “real-world”) entities that actually need to be stored and manipulated in the model are typically represented by the lowest-level entity types in the hierarchy. In some cases, these concrete types or additional concrete types are represented in other modules that extend the System.Application module.
This notional hierarchy is implemented using a vertically partitioned storage design in which storage for any given entity is partitioned across a number of Extents. Extents are defined for entity types at each level in the generalization hierarchy, forming a corresponding hierarchy of extents. Each extent stores information and holds references to other extents consistent with relationships among the corresponding entity types. Each extent (excluding the root extent) also references its immediate parent in the hierarchy via a membership constraint on its identity field. Storing a real-world entity that conforms to the notional hierarchy requires creating an instance in the appropriate lowest-level extent and in each extent above it in the hierarchy, up to and including the root extent. Similarly, deleting an entity requires deleting instances from each extent in which that entity is represented. This partitioning approach for mapping a generalization hierarchy to storage is sometimes referred to as the table-per-type (TPT) pattern. This pattern is implemented using the RootItem and DerivedItem types defined in the System module. Extents that represent the root of a generalization hierarchy include RootItem in their definition and are referred to below as root extents; extents that implement non-root nodes in the hierarchy include DerivedItem and are referred to below as derived extents. For more information, see System.
The System.Application namespace defines the following extents:
SoftwareComponents is a root extent that supports common aspects of Applications, and SoftwareModules. A SoftwareComponent can be part of another SoftwareComponent. A SoftwareComponent exposes behavior through one or more SoftwareEndpoints; if the SoftwareComponent is composite, its SoftwareEndpoints are delegated to SoftwareEndpoints on its member SoftwareComponents.
UsageDependencies holds information regarding dependency relationships between pairs of SoftwareComponents in which one SoftwareComponent requires the other to be present. The interpretation of the dependency is up to the installation driver for specific kinds of software component.
The UsageDependency type defines a relationship between two SoftwareComponents in which one SoftwareComponent requires the other to be present. At a specific subtype level, the interpretation of the dependency is up to the installation driver.
Applications is a derived extent that holds information about specialized SoftwareComponents that can be composed of SoftwareModules, other Applications (or both), which might be connected within the context of the Application by their SoftwareEndpoints. An Application is a deployment and management unit. SoftwareEndpoints exposed by an Application are always delegated to a SoftwareEndpoint on a member Application or SoftwareModule.
SoftwareModules is a derived extent that describes specialized SoftwareComponents that are conceived, designed, deployed, and managed as independently deployable and functional entities. A SoftwareModule is typically composed of one or more SoftwareResources. A SoftwareModule is a unit of distribution, normally deployed as a unit to a single host, often as part of a larger Application. A SoftwareModule can reference the Application within which it is defined and a DeploymentTarget to indicate how the SoftwareModule should be deployed.
SoftwareResources is a root extent that holds representations of physical or virtual entities that require or support allocation, provisioning, or managing. A SoftwareResource might reference a Document in which the actual resource is stored in binary form. (For more information about Document, see System.) SoftwareResource references the SoftwareResource or SoftwareComponent in which it is defined.
SoftwareEndpoints is a root extent that holds representations of discrete exposed functions of SoftwareComponents that are manifested as logical points at which those components can be connected to or from. Each SoftwareEndpoint references the SoftwareComponent on which it is defined and indicates whether the endpoint is a provider or consumer of its function.
The Connections extent holds links between a pair of SoftwareEndpoints on peer SoftwareComponents contained within a common Application. A communication link indicates that instances of the two connected components should be configured so that the connected SoftwareEndpoints.
The Delegations extent holds links from a SoftwareEndpoint on some composite SoftwareComponent to a SoftwareEndpoint on a member or sub-SoftwareComponent. A delegation link identifies the member and SoftwareEndpoint that implements the function exposed at the SoftwareEndpoint on the composite SoftwareComponent.
ExternalModules is a derived extent that holds specialized SoftwareModules which, while they can be included in the model of an Application, are not deployed as part of the Application. For example, proprietary systems or external Web services would be represented as ExternalModules. ExternalModules can also be used to represent SoftwareModules that are deployed as part of another Application.
The WebApplicationModules extent holds specialized SoftwareModules that represent Web applications (modules), implemented by Internet Information Services (IIS) or Windows Activation Services (WAS).
The WebSites extent represents IIS or WAS Web sites that might be referenced by one or more WebApplicationModules.
UnspecifiedEndpoints is a derived extent that represents specialized SoftwareEndpoints that are of unknown, unspecified, or unsupported type. UnspecifiedEndpoints can be defined early in the design of an Application before a technology decision has been made and replaced later with technology specific SoftwareEndpoints or can be used when the technology is not otherwise modeled or supported by the available deployment targets. Examples include ADO.NET calls directly out of a service, or native connections on customer relations management (CRM) systems. ExternalModules will often have UnspecifiedEndpoints.
DeploymentTargets defines application-specific logical targets for deployment. A DeploymentTarget is mapped to a physical deployment target during the deployment process. Introducing DeploymentTargets to an Application design enables the designer to indicate how SoftwareModules should be grouped on deployment.
The System.Application module defines the following type:
- The Manageable type is used to introduce a LifecycleState field to an extent that indicates whether an instance is managed or not. If the LifecycleState is null, the lifecycle of the instance is not managed. Within the System.Application module, Application and SoftwareModule types are Manageable.