Design a distributed system for deployment

  Release Date: 8/18/2004 | Renew Date: 8/18/2004

Bill Gibson and Alex Torone

Microsoft Corporation

Scope of application:

Microsoft Visual studio®2005 Team System

Summary : This article describes the software design tools for building distributed applications in Visual Studio's team System.

Note : This document is written before the product is put into production and some of the details may be inconsistent with the actual product. The information in this article is based on the condition of the product at that time, only for your reference in planning. Changes are subject to change without prior notice. Microsoft has patents, patent applications, trademarks, copyrights, or other related intellectual property rights in the subject matter of this document. Microsoft provides only the rights expressly stated in any written license agreement and does not grant you the above-mentioned patent, trademark, copyright or other intellectual property rights in this document. content of this page

	Introduction
	Challenges in designing distributed systems
	Improved design and deployment of distributed systems
	Distributed System Designer Overview
	Extensibility
	Integrated with Visual Studio's team System
	Conclusion

Introduction

The Distributed System Designer consists of a variety of tools that support graphical design and validation of distributed systems. The Toolset is intended for application architecture designers, designers, developers, and operational architecture architects. Distributed System Designers are early tools from Dynamic Systems Initiative (DSI) designed to improve the development, deployment, and management of enterprise-class distributed systems. For more information about the DSI, see Microsoft Dynamic Systems initiative. These tools are part of Visual Studio's team System.

Service-oriented architecture is the foundation of the next generation of distributed applications. The Microsoft "Indigo" platform will implement industry-leading service-oriented systems. "Indigo" will be built on the SOAP and Web service support provided by the current Windows platform, with increased support for transport and system topologies. It also enables secure, reliable, and persistent message-based communication between services and services. The Indigo platform itself has a number of significant improvements, and organizations can now use SOAP, XML messaging, and ASP.net Web services to develop service-oriented systems. For more information, see Indigo. Back to the top of the page design the problem of distributed system

Designing and deploying distributed systems is a fairly complex process. This section describes some of the issues that may arise. visualize the design of distributed systems

It is becoming more and more difficult to visualize the system structure and as a whole. The reason is that the system is increasingly fragmented in a service-oriented architecture. In addition, over time, enterprises will generally form many different systems, such as purchasing department, development Department. Applications in these systems may also be of various kinds. Because the number of programming techniques used by each system varies widely, it is generally difficult to share functionality and data among them. For interoperability, the design of a messaging interface has increasingly become a fundamental requirement for developers and architects, and it is critical to design new messages and ensure compatibility with existing message schemas. Interoperability through messaging is the core of a service-oriented architecture. Keep design synchronized with code

To keep the system design documents up to date, there must be more communication between the architects and developers of the architecture. However, once you start writing code (even for perfect purposes), system design documents often become outdated and inaccurate. But the daunting task of synchronizing design documents with fast-changing code is going to be the past. Deployment Design

Software and hardware vendors often believe that developers understand every nuance of platform configuration (SQL, IIS, BizTalk, and so on), and that operational management can fully identify the framework and message protocols that application developers use. Although the operation should be part of the overall software development lifecycle, the part is organizationally and functionally separate from development. Operators and developers basically do not actively collaborate, the two sides are generally passive cooperation, usually in the development of late diagnosis can be early prevention problems.

Please try to develop and deploy a simple Web service. While the developer's focus is on implementing the service, the following aspects need to be considered: security, the authentication model, other support services required by the target environment, and the configuration settings required to make the WEB service work as expected. For operations, you must be able to identify the protocols and services that are required for the new service, and whether the enterprise IT strategy is being followed. Separating development from operations will result in deployment problems (often the result of configuration mismatches) that will result in the design being incompatible with the data center (resulting in a large amount of IT budget wasted on correcting deployment issues).

Although many enterprises try to solve these problems through documentation, design reviews and elaborate diagrams, they are often unable to implement and communicate strategies effectively because of the lack of relevant tools and common language. In addition, these processes have so far not been present in the day-to-day tools of developers and operations personnel, so the process itself has some problems. Configuring Applications for Security

Ensuring the security of distributed applications is a time-consuming and complex process that involves a large number of technologies and settings that affect application design. Currently, an integrated approach has not yet emerged to represent the security configuration of the application or the security requirements of the data center when designing the application. Therefore, it is really difficult to ensure that security is implemented correctly. Go to the top of the page improve the design and deployment of distributed systems

Distributed System Designer is an integrated design tool, whose goal is to realize the visual design and verification of distributed systems. The designer uses the system Definition Model (SDM) as the underlying metamodel for describing the connection state, configuration, and interrelationships between application services and the Run-time environment. SDM is based on a multi-tiered model that includes applications, application hosting environments, network topologies, operating systems, and physical devices. The model not only allows the Distributed System Designer to describe the design of each layer, but also allows it to express the constraints and policies of each layer to cross all layers of the distributed system.

The Distributed System Designer supports an integrated model of two domains (development and operations). This allows the designer to resolve customer problems using the following methods:

•	Provides a common language (SDM) to describe the design and configuration of distributed systems.
•	Allows developers to express the requirements of the application for the Run-time environment.
•	Allows an operator to express application Run-time, security, and connectivity requirements that are deployed as a target environment policy.
•	Use abstract concepts to allow developers and operators to communicate on a common basis.
•	Integrates with existing Visual Studio project systems and. NET Technologies.
•	Provides a full synchronization of visual design elements with code.
•	Incorporate extensibility frameworks that allow the creation of models for new applications and host systems.

The following section details the various designers and editors for the Distributed System Designer toolset. Return to the top of the page Distributed System Designer Overview

The Distributed System Designer includes the following designers:

•	Application Connection Designer
•	Logical Datacenter Designer
•	System Designer
•	Deployment Designer

Application Connection Designer

The Application Connection Designer (ACD) helps developers or architects define and configure applications to be included in the system for deployment. The Toolbox provides a set of predefined application prototypes, including Web services, Web applications, Windows applications, external databases, external Web services, and external BizTalk services. In addition, the Toolbox includes a generic application prototype to record other application types in the design.

The application connection diagram shows the application defined in a Visual Studio solution. You can add each application from the toolbox to create a chart from scratch, or you can reverse-engineer the diagram based on an existing solution or an existing project.

An example of an application connection diagram is shown in Figure 1.

Figure 1 : Application Connection Designer

ACD can display both "internal" and "external" applications. An internal application is a deployable application defined within a solution that organizes the applications together to form one or more deployable systems. Typically, an internal application is a project that defines a managed executable program (for example, a WEB application or a Windows application). Resources can be included in the project or in other referencing or shared projects, including class library projects. External applications allow developers to make visual references to other systems that are involved in the deployment process.

Each application is represented by a box, and a smaller box represents the connection point, indicating whether the application is a connection target or a connection source. These connection points are also called endpoints. The service provided by the application is represented by the provider endpoint (a solid shape), and the connection point of the service provided by the other application is represented by the client point (The hollow shape). Each application is connected to each other through endpoints.

Although the SDM model focuses primarily on the type, configuration, and connectivity of endpoints, each application can extend the model to represent the definition of the behavior provided by the service. For example, you can define a Web service endpoint using one of the following two methods: Click the Web Service provider endpoint, allow the operation of the Web service to be defined in the Endpoint Details window, or import the behavior definition in the existing Web Service Description Language (. wsdl) file. If you extend the model in the way described above, ACD can support a complete design experience. For example, the behavior and configuration of a WEB service application are allowed to be fully specified.

The connections shown in ACD describe the current configuration of applications in the development environment. If the application has been debugged, it will run along the displayed connection path.

ACD supports the deferred implementation of the method, which allows the user to create and validate the design before the code is paid for. If you add an application definition to ACD from the Toolbox, the corresponding projects, code, and configuration files are not created immediately. The first generation of code is also known as "implementation." The application definition can be implemented incrementally or one-time. In the diagram, the implemented application is distinguished by shadows. Once the application is implemented, the generated code files, configuration files, and application designs displayed in the chart will always be synchronized as long as the chart and code files are kept open. If the chart is closed for some reason, reopening it will synchronize it with the code, and update it with changes to the code during the closing of the chart. In this way, the design model in ACD can be easily synchronized with code changes, which solves problems that other tools cannot solve. If an application is created by reverse engineering an existing project or solution, the system considers the application to be implemented and automatically performs the synchronization.

By delaying implementations, architecture designers and application designers can focus on completing functional design and validation of the system while delaying implementations that are best to be made later by the development team. These decisions may include the choice of programming languages and templates, or the server location for WEB projects.

Because the chart is saved as a file (. dsdgm file), it can be included in the source code control and included in the team's regular workflow. The relevant information for the implemented application is saved in the. sdm file for each project. As a result, you can reuse projects in multiple solutions and divide the work into different units to assign to different developers in your group.

ACD can access the full model of application configuration settings and define host constraints. Host constraints allow application designers to specify requirements for the hosting environment. By defining host constraints on application definitions in the settings and Constraints Editor, application developers can request that a set of required features be enabled in the target deployment environment to communicate important application requirements to the operator. The operator can then determine whether to make changes to the logical datacenter to satisfy the above request. As part of deployment validation, the system verifies application settings and host constraints based on logical Datacenter settings and constraints (refer to Deployment Designer). Logical Datacenter Designer

Logical Datacenter Designer (LDD) is used to create diagrams that represent interconnected logical servers representing the logical structure of the datacenter. These logical datacenter diagrams communicate important information about the target deployment environment to developers. With this designer, the designer of the operations architecture can specify and configure the server type of the datacenter, the type of traffic that is permitted, the specific communication path, and the type of service that is enabled.

Typically, logical datacenter diagrams are created and owned by the operations analyst, but are used by developers. After the logical datacenter diagram is created, the operations analyst can lock the chart and manage the chart version throughout the application development lifecycle to keep it synchronized with the design changes in the datacenter. As with other distributed System designers, logical Datacenter Designer is fully integrated with Visual Studio. However, the creation of logical Datacenter diagrams is independent of the application development process. These charts are saved as. lsad files that can be reused by other distributed systems deployed in the same target environment.

The following figure shows the build process for a simple logical datacenter diagram.

Figure 2 : Logical Datacenter Designer

In LDD, the toolbox contains predefined logical server prototypes that can be added to the diagram. The logical server represents the application host in the datacenter. Local types include Windows client servers, WEB servers (IIS servers), SQL Server, and general servers. In addition to the general server, each prototype defines a set of settings and applicable constraints that are used to configure the server. The reason that you include a generic server is to take account of records. The generic server allows other types of servers to be present in the datacenter where the model is to be built. Each logical server has two endpoints, specifying specific communication protocols. Endpoints can be added to logical servers to communicate with other logical servers through this endpoint.

By editing the settings provided, you can model the configuration of logical servers within the datacenter. In addition to editing the settings provided, you can import these settings from the actual server. Once you have completed the data center description, you can use the Settings and Constraints Editor to specify policy constraints related to application types and configurations, where applications refer to applications that can be hosted in the data Center implementation instance. These constraints are created based on the settings in the application layer, because they are used to constrain the type of application that the server can host, and to specify the configuration required by the application. For example, for applications hosted by a WEB server, you can constrain ASP.net security settings, and for applications hosted by Windows client servers, you must have the. NET Framework version that you want. Mark some settings as fixed to specify that these settings will not be overwritten during development.

The settings and Constraints Editor is shown in Figure 3.

Figure 3 : Settings and Constraints Editor

The Toolbox also contains several areas and endpoints. The zone represents the communication boundary of the data center. The zone endpoint represents the connection point between the zone and the server. The communication path between the zone and the server is controlled by the zone endpoint, and the zone endpoint can be configured to determine the type of communication protocol allowed in and out of the zone. The server endpoint is used to specify the communication path and protocol allowed between the server and the server that sends (or receives) communication data across zones.

As part of deployment validation, the system verifies the configuration settings and application constraints defined in the logical datacenter diagram based on the settings and constraints defined in the application (refer to Deployment Designer). This allows the data center policy and deployment requirements to be communicated from the operations team to the development team. System Designer

System Designer is used to build and configure systems based on the applications defined in ACD. In Distributed System designers, the system is a deployment unit and is a configuration of one or more applications and other subsystems. Because the system can be constructed from other systems, it is feasible to define a large-scale distributed system scheme. Application architecture designers can design complex multi-tier systems as a hierarchy of "nested" systems.

When you create a system definition, you can define deployment configurations independently of the development configuration shown in ACD. If allowed, the system chart application uses application settings that can overwrite the application defined by ACD. You can create multiple system definitions, each defining a different application configuration in the solution. In this way, different planned deployments (possibly for different data center configurations, different geographic deployments, or different customers) can have different configurations.

Figure 4 shows an example of a system diagram that contains nested systems.

Figure 4 : System Designer Deployment Designer

Deployment Designer is used to define the deployment of a specific system to the destination logical datacenter. Typically, deployment Designer is used by developers and architecture designers. In Deployment Designer, applications in the system are bound to logical servers in the target datacenter. The functionality provided by the designer highlights the inherent communication advantages of the SDM model, which is the foundation of Distributed System Designers. Once you have completed the definition of your deployment, you can verify it as needed. Verify that all applications in the system are bound to logical servers and check that the application conforms to the application constraints specified in the logical datacenter diagram. In addition, validation confirms that the logical server conforms to the host constraints specified in the Application connection chart and system diagram.

Finally, validation ensures that the necessary communication paths exist and that the correct communication protocols exist and that they are compatible between the application and the host server.

Figure 5 shows an example of a deployment diagram.

Figure 5 : Deployment Designer

All validation errors are displayed in the Visual Studio Error List, which provides a simple navigation mechanism for correcting and adjusting errors. When you double-click an error in the Error list, deployment Designer opens the appropriate chart, selects the appropriate application or logical server, and navigates to the appropriate settings to correct it. This allows users to correct configuration errors before deployment, even before the system is fully implemented. With Deployment Designer, you can generate reports of all the required application and Datacenter configuration settings and use it in the scripting creation of the custom deployment tool. Go back to top of page extensibility

The Distributed System Designer will include an extensibility model that allows partners to extend the platform and to add support for other protocols and other kinds of applications and logical servers. Back to the top of the page with Visual Studio team System Integration

Distributed System Designers provide support for the design and deployment of distributed applications. The designer integrates with other Visual Studio team System tools in several ways:

•	Distributed system development projects designed, developed, and tested using the Distributed System Designer are managed by Visual Studio Portfolio Management Tools.
•	The application uses Visual Studio Team test for unit testing.
•	Source code control and integration work item tracking uses Visual Studio's Foundation Server and Client.

Back to the top of the page Conclusions

The Distributed System Designer consists of a set of designers that simplify the design and validation of distributed systems based on service-oriented architecture.

•	Service-Oriented architecture: as expected, service-oriented architecture will be the foundation of next-generation distributed applications. But it is very difficult to visualize and design the fragments that are necessary to the architecture. The Application Connection Designer (ACD) and system Designer help application architects, designers, and developers visualize and design service-oriented systems as a whole.
•	Operational Design:Distributed System Designers can create diagrams to represent the application layer and application hosting layer of the system. Because of the changing services that make up the application, the first time the application is deployed (and throughout the lifecycle of the application), these charts help people who design and deploy the application to validate the application's configuration based on operational requirements.
•	executable design: with the unified model in Distributed System Designers, application and infrastructure designers can capture large amounts of metadata during the design process. This metadata can be used both to generate code and to validate the design of the application based on the datacenter definition. This model allows application architecture designers to create more formal and accurate designs. Maintaining design and code synchronization throughout the lifecycle of an application is still critical, helping application architects to maintain and extend applications as needed.

Distributed System Designers can help organizations successfully build web-based and service-oriented applications and effectively prepare for successful deployment of data centers.

For more information about other members of Visual Studio's team System, see:

·	Visual Studio, System:overview,
•	Visual Studio system:building Robust and reliable Software
•	Visual Studio, System:software, Project Management
•	Visual Studio, System:enterprise-class, Source Control and Work Item tracking
·	Visual Studio system:microsoft Solutions Framework
•	Visual Studio, system:extending, the Suite
•	Visual Studio system:enabling Better Software through Better testing