TN_1101: Understanding and Using the Default System
Bill Gibson, Program Manager
Microsoft Corporation
This note discusses the use of the default system created by the Application Designer when a deployment definition is created directly from an application diagram.
What is the Default System?
As a convenience to help you quickly validate applications on the application diagram against a logical datacenter design, the Application Designer allows you to create and maintain a deployment diagram without first creating a system.
To make this possible, a default system is created and maintained as a mirror image of the application diagram. As you make changes to the application diagram, the equivalent changes are made to the default system. If you create a deployment diagram from the application diagram, it uses the default system. As the default system always reflects the application diagram, it cannot be opened in the System Designer or saved to disk. If a deployment definition is based on the default system the System name in the diagram heading will be, “Default”.
While you can create a deployment definition and a deployment report from the default system, it is not recommended you use these as the basis for a final deployment. To understand why, it helps to understand what a deployment definition is and how it relates to the other System Definition Model (SDM) documents.
Application Systems and Deployment Definition
The Distributed System Designers are used to define applications and to compose these into systems for deployment. The tools are based on SDM. SDM views the world in terms of compositions of systems that can be hosted on other systems. The Distributed Systems Designers support the definition of application systems and allow you to define how these are to be deployed using a logical model of a datacenter. The logical datacenter diagram depicts logical application servers on which the applications in an application system can be hosted on deployment.
A logical deployment is described using a deployment diagram created using the Deployment Designer. A deployment definition is defined in an SDM document and defines how the applications in a specific system will be deployed to logical servers defined in a specific logical datacenter. Any number of deployment definitions can be created that describe mappings between a system and one or more logical datacenter definitions.
For more information on the SDM, see Understanding the System Definition Model; for more information on system hosting and layering of systems, see The Four Layers of Systems in the System Definition Model.
Deployment Validation
The Deployment Designer allows you to validate a deployment definition. This highlights possible deployment or configuration errors, and can also produce a detailed deployment report that contains enough information to script an actual deployment. Validation determines whether the application and logical server configurations and connections are compatible. If validation of the deployment definition produces no warnings, then there is a high likelihood that the applications configured as defined in the system will deploy successfully to a datacenter configured as described in the logical datacenter definition.
When a deployment definition is validated, it and all referenced SDM documents are submitted to an SDM compiler. This compiler checks that the documents are both syntactically and semantically correct. The semantic checking on the deployment definition document includes two key categories of constraints: logical server constraints and application constraints.
Logical server constraints are defined by the application architect on the underlying application definitions in the application diagram, and constrain aspects of the logical servers on which these applications can be deployed. Application constraints are defined by the infrastructure architect on logical servers in the logical datacenter definition, and constrain aspects of the applications that can be hosted on those logical servers.
Defining a Deployment Report Based on the Default System
For the deployment definition, its validation, and the deployment report to be reliable, it is recommended that the deployment definition reference stable versioned definitions of the application systems, applications, and logical datacenter. If produced from the default system, the deployment report reflects the solution at the moment the report was run. With no corresponding version stamped system definition file, you will not be able to recreate the state of the system easily in any other context except by reloading the solution as it was at the moment the report was run.
By comparison, an explicit system is version stamped, and all references from it to other systems and applications are version-aware references. A system file opened with an incompatible version of an application provides a visual warning and will not compile or pass validation.
Configuration Scenarios not Supported by the Default System
For straightforward scenarios, the configuration in your solution may be an adequate representation of your intended production configuration. However, many scenarios require customizing the configuration, which is not possible with the default system. An explicit system is required if you need to:
Specify that the configuration of any application in the system differs in production from the configuration in your solution. You can specify that specific configuration settings on an application are ‘deployment settings’ in which case they can be overridden during deployment.
Exclude any application in the solution from the deployment, for example, test applications or optional context-specific applications.
Create multiple alternative configurations from the same applications.
Connect applications in different ways in production than in development.
Add multiple uses of the same application into a deployment, for example, to deploy the same application inside and outside a firewall.
If you want to deploy a system that is configured exactly as in your solution, then it is still recommended that you create an explicit system as a final step and use that for the final deployment report creation. To do this, you can simply create a system containing all the applications in the application diagram and make no further changes. If you right-click on the application diagram surface to create the system, the system will be a snapshot of the application diagram at that moment.
Summary
A deployment definition created from the default system is useful to help you quickly check the validity of applications as configured in your solution, but it is recommended that you create an explicit system as the basis of final validation and deployment. If the final system configuration must differ from the configuration of applications in your solution, then this will always require that you create a system explicitly.