Deploying Applications with Distributed System Designers

Ali Pasha, Krishnakumar Balasubramanian
Visual Studio Team Edition for Software Architects
Microsoft Corporation

April 2006

Applies to:
   Visual Studio 2005 Team Edition for Software Architects

Summary: The Distributed System Designers in Visual Studio 2005 Team Edition for Software Architects provide an environment for designing, developing, and validating a deployment of a distributed system. In addition, Distributed System Designers generate artifacts, such as a Deployment Report that can be used for scripting a deployment. The goal of this whitepaper is to provide an overview of deploying applications using the Deployment Report. (8 printed pages)

Contents

Distributed System Designers
Why Use the Deployment Report for Deployment?
Understanding the Deployment Report
Supported Applications
Configuring Applications for the Deployment Environment
ASP.NET Application
Windows and Office Applications
Future Directions
Conclusion

Distributed System Designers

Visual Studio Team Edition for Software Architects gives architects, operations managers, and developers the ability to increase the predictability of success by visually constructing service-oriented solutions that can be validated against their operational environments prior to deployment. The tools used to achieve this objective are called the Distributed System Designers. They are a collection of four different designers: the Application Designer, System Designer, Logical Datacenter Designer, and the Deployment Designer. For more information on the designers, visit Overview of Distributed System Designers in the product documentation.

A key output of the Distributed System Designers is the Deployment Report. One purpose of the Deployment Report is to improve communication between Software Architects and Infrastructure Architects, and to increase the likelihood of a successful deployment. Another purpose of the Deployment Report is to automate a deployment; this is the key topic for the rest of this paper.

Why Use the Deployment Report for Deployment?

Using Distributed System Designers to validate the architecture of a system, configured for the target environment, against the logical datacenter will increase the predictability of a successful deployment if the actual system being deployed reflects the configuration described in the system. This is, furthermore, also true only if the target environment is equivalent to the logical datacenter used for validation.

The Deployment Report, therefore, is an essential piece for achieving a successful deployment. Because the Deployment Report captures information about the application uses, the target datacenter environment, and the application-to-logical server binding information, it allows the users to increase the likelihood of a successful deployment:

• By providing information about the configuration of each application use in the target environment as envisioned and validated during design, to ensure that the applications are configured correctly during deployment.
• By providing information about the logical datacenter, so that assertions about the target physical environment can be made and validated.

Understanding the Deployment Report

In a nutshell, the Deployment Report is a compilation of the data associated with applications, logical servers, zones, and endpoints across the various distributed system diagrams required for deployment. For more information, see Creating Deployment Reports in the product documentation.

The generation of the Deployment Report creates a machine-readable report and a human-readable report. The human-readable (or HTML) version of the Deployment Report is meant to be used for communicating requirements and information about the distributed system to those responsible for the deployment and operation of the distributed system. The machine-readable (or XML) version of the Deployment Report contains the information required for automating a deployment. The rest of this paper refers to the machine-readable version of the report.

When the Deployment Report is generated, a directory of the applications that need to be deployed can also be created, if the Project files properties are set correctly in the Deployment Designer. The created directory is located at the path specified using the Destination Path property, with a structure that mirrors the organization of files and directories inside the corresponding Visual Studio solution hierarchy. This, together with the machine-readable version of the Deployment Report, is all that is required for a successful deployment.

The Deployment Report contains the following information deployment:

• Applications —This contains definitions of the applications and composite systems that comprise the system being deployed. Each member of the system contains the settings, resources, and endpoints that can be configured for deployment.
• LogicalServers —This contains all the information related to the configuration of the logical servers that need to be set or validated on the target machines during the installation of the applications.
• Binding —This contains information about the bindings between applications and logical servers. It is used to identify the logical server, and ultimately the physical server, to which each application will be deployed.
• Errors —This contains information about the errors that are generated during the validation of the deployment. For the purposes of deployment, make sure that there are no errors in the report, because the presence of errors under this element usually indicates that the system is not ready for deployment.

Supported Applications

Only ASP.NET Web applications, Windows applications, and Office applications can be deployed using the Deployment Report. All other application types—including Generic Application, External Web Service, External Database, and BizTalk Web Service—exist for the purposes of visualizing external applications. Because external applications are external to the solution, the deployment of these external applications is outside the scope of the Deployment Report.

A custom System Definition Model (SDM) type can be used to capture the deployment information for an unsupported application type. In such a case, the deployment process will need to be defined during the creation of the SDM type in order to deploy the application modeled by the SDM type. For more information about the SDM SDK, visit System Definition Model (SDM) SDK in the product documentation.

Configuring Applications for the Deployment Environment

Applications designed and implemented using Distributed System Designers require modifications to the configuration settings to reflect the migration of the application from a development environment to a test deployment environment. Therefore, when configuring applications for deployment, the following need to be kept in mind:

• Application Uses —When deploying an application, it is important to remember that, while there is only one application type in the Application Designer, there might be multiple uses of that application type in the system being deployed. A common example is that of a front-end application deployed on two different servers with different security settings. Because the generation of the Deployment Report will create only one directory for each application type, the deployment process is responsible for using the information in the Deployment Report for creating separate uses, where each use is configured discretely.
• Deployment Settings —Each setting in the System Designer and the Logical Datacenter Designer has a deployment check box. If selected, this deployment check box indicates that the setting can be provided at deployment time. Otherwise, the setting has a Fixed attribute set to true in the Deployment Report. In this case, the setting provided in the Deployment Report must be used during deployment.
• Logical Server to Physical Server Mapping —Ultimately, the goal is to deploy each application to a physical server. By mapping a compatible physical server to a logical server, the target destination of an application can be determined. During this mapping, a physical server mapped to the logical server must conform to the configuration of the logical server, in order to guarantee that the application will deploy. In many cases, the human-readable version of the Deployment Report can help the user determine which physical machine each logical server should be bound to.

In the following sections, we give an overview of the different deployment settings and how to configure the applications, with the correct settings, for a successful deployment.

ASP.NET Application

Updating Application Settings

Each application type can have multiple uses as defined in the System Designer. The Web.config file that is placed in the target destination directory contains only the configuration settings as they were configured during development. It is unsuitable for the target deployment environment. In the Deployment Report, the Configuration resource contains the configuration settings that should be used during deployment. For each use of the ASP.NET application, the Web.config will have to be updated with these values. For more information on how to map SDM resources to configuration elements in the Web.config file, see the product documentation.

Endpoints

Each ASP.NET Web application has both provider and consumer endpoints defined in the Deployment Report. Figure 1 shows the actions that need to be performed for each type of consumer endpoint in order for communication to occur in the target environment. These actions are described in the following sections.

Figure 1. Updating configuration file settings

Web Service Consumer Endpoint

Each Web service consumer endpoint has to be configured so that it can connect to the Web service provider endpoint in the target environment. Because the absolute URI will be used by clients to consume the service, the absolute URI needs to be resolved for the Web service provider endpoint. Once the absolute URI has been determined, the connected consumer endpoints can be configured. To configure the Web service consumer, use the value of the Config File Entry setting on the Web service consumer endpoint to locate the appSettings element whose key attribute has a matching value in the Web.config file. Update the appSettings entry with the absolute URI retrieved from the corresponding Web service provider endpoint.

Database Consumer Endpoint

If the ASP.NET Web application is connected to a database, the database consumer endpoint needs to be updated to point to the target database server, which is provided during deployment. This can be done by using the value of the Config File Entry setting on the endpoint to locate the connectionStrings entry whose name attribute has a matching value in the Web.config file, and then updating the connectionStrings entry with the target environment's database connection string.

Web Content Consumer Endpoint

The same strategy used to resolve the URI for a Web service consumer can be used for determining the absolute URI for the Web content endpoint. The deployment process will need to manually modify or inform the client about the URI that will be used in the target deployment environment in order for the client to access the Web content.

IIS Server Requirements for ASP.NET Application Deployment

Binding an application onto a logical server denotes that the application will be deployed onto a physical server that is configured like the logical server. Therefore, as a part of the deployment process, it is recommended that this assertion be validated.

Each IIS Web server contains an InternetInformationServices resource that contains the IIS metabase configuration, an OperatingSystemDescription resource that represents the operating system settings associated with the Web server, and a CommonLanguageRuntime resource that represents the version of the CLR on the logical server. The deployment process should use these resources to verify that the target physical IIS Web server is configured as expected.

Deploying the ASP.NET Application to IIS

Each website on the Web server is represented as an endpoint. For each website defined on the Web server, the user will need to decide whether to create the website on the target server or to use an existing website.

If a website is created, the server bindings— that is, the IP address and the port number—will need to be configured. The server bindings can be set using the setting named ServerBindings associated with each website endpoint on the IIS Web server on the Logical Datacenter Designer. To enable secure ports (HTTPS), use the SecureBindings setting associated with each website endpoint, instead of ServerBinding.

If an existing website is to be used, use the ServerComment setting to locate the appropriate website.

Updating IIS Metabase Settings

The IIS metabase is a structure for storing IIS configuration settings. In the Deployment Report, IIS metabase settings can be found under the InternetInformationServices resource. Each ASP.NET application that is deployed on an IIS Server will require the IIS metabase settings for that particular application to be configured during deployment. Some SDM settings have different names and values from the equivalent IIS metabase settings. This was done to provide users with setting names and values that were easier to understand. Therefore, a translation of names/types will need to be done to set the IIS metabase settings. This can be done by referring to the product documentation, which contains the IIS metabase to SDM settings mapping.

Windows and Office Applications

Windows applications also need to be configured for deployment, as described in the following sections. Aside from Windows applications, Distributed System Designers also supports five different Office project templates: Word document, Word template, Excel workbook, Excel template, Outlook add-in. Office applications have a similar configuration to Windows applications. They do, however, have different deployment requirements.

Office Solutions Architecture Overview describes the interaction between the Excel and Word applications and the host—that is, Microsoft Office. Architecture of the Outlook Add-in Support in Visual Studio 2005 Tools for Office describes the interaction between Outlook add-ins and Microsoft Office.

Updating Application Settings

Each Windows application type, like ASP.NET applications, can have multiple uses as defined in the System Designer. Therefore, the configuration settings will need to be modified in the configuration file for each use. This can be done in a manner similar to that stated above for ASP.NET applications.

Endpoints

Each Windows application that consumes external services (database or Web services) needs to be connected to the service provider. After the URI for each consumer is determined, as described for ASP.NET applications, the client's configuration has to be modified to consume the service. The configuration setting used to configure Web service consumer endpoints is different from ASP.NET applications. To update the configuration, use the value of the Config File Entry setting on the same Web service consumer endpoint to locate the ApplicationSettings entry whose name attribute has a matching value in the configuration file. Update the contents of the ApplicationSetings entry with the absolute URI retrieved from the corresponding Web service provider endpoint.

Deploying the Windows or Office Application

A Windows Client server represents a Windows server that is used to host Windows and Office applications. Each Windows Client server contains a resource named OperatingSystemDescription, which represents the operating system settings associated with the Windows Client server, and another resource named CommonLanguageRuntime, which represents the version of the CLR on the logical server. The values of the settings defined on these resources should be used to define installation requirements on the target machines.

Office applications have additional deployment requirements. Therefore, when deploying Office applications, ensure that the following prerequisites are installed:

• Microsoft .NET Framework version 2.0
• Microsoft Visual Studio Tools for Office Runtime
• Microsoft Office 2003 SP1
• Microsoft Office Primary Interop Assemblies

Outlook add-in projects require additional information for deployment; this is described in Architecture of the Outlook Add-in Support in Visual Studio 2005 Tools for Office.

Future Directions

The Distributed System Designers are a key part of the Microsoft-wide Dynamic Systems Initiative (DSI), which has a goal to simplify and automate how enterprises design, deploy, and operate distributed systems. The Distributed System Designers in Visual Studio Team Edition for Software Architects are the first release of tools that help users create better architected systems with a lower cost of deployment.

Future directions that are being investigated include working with partners to enable additional applications and logical servers for deployment, improving the application and logical server abstractions, improving the deployment of applications, and improving the integration of deployment into the build process.

Conclusion

Because most systems are configured differently in the target environment from the development environment, Visual Studio Team Edition for Software Architects gives architects a tool to describe the desired or expected configuration for a particular target environment. Because the system can be validated against the logical datacenter prior to deployment, the chances of a successful deployment are high if the validated system is configured as expected during deployment. Therefore, using the Deployment Report to configure the system during deployment is essential. Additionally, validation is useful only if the logical datacenter is a reflection of the target physical datacenter. It is, therefore, essential to use the Deployment Report to validate that the architects made the correct assumptions about the target physical datacenter prior to deployment.

About the Authors

Ali Pasha finished his undergraduate studies in Computer Science at Lahore University of Management Sciences (LUMS) in Pakistan. After working in Karachi, he went to the US to complete his graduate studies in Engineering Management at Dartmouth College. For the last two years, he has been working for Microsoft as a Program Manager in the Visual Studio division on the connected systems software factory. The first deliverable of the connected systems factory was released in Microsoft Visual Studio 2005 Team Edition for Software Architect as the Distributed System Designers. His particular interests reside in Contract-first development of Web services. Ali has an active blog that he maintains at https://blogs.msdn.com/a_pasha.

Krishnakumar Balasubramanian is a graduate student in the Department of Electrical Engineering and Computer Science at Vanderbilt University. His research interests are model-driven development, and deployment and configuration of component middleware and frameworks for distributed, real-time and embedded systems. He was a Program Manager intern at Microsoft during the Summer of 2005, where he worked on a prototype deployment tool which formed the basis for this whitepaper. Balasubramanian received an MS in computer science from Washington University in St. Louis. Contact him at kitty@dre.vanderbilt.edu.

© Microsoft Corporation. All rights reserved.