Release Date: 8/18/2004
| Update 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 2005 Team System.
Note: This document is written before the product is put into production, and some details may be inconsistent with the actual products. The information in the text is based on the product status at the time, only for your reference. If there is any change, no notice. Microsoft holds patents, patent application rights, trademark rights, copyright or other related intellectual property rights. Microsoft only provides the right to clearly specify in any written license agreement, without granting the above patents, trademark rights, copyright or other intellectual property rights of this document.
This page
Introduction to design distributed systems Improved distributed systems Design and deploy the "Distributed System Designer" Overview Scalability and Visual Studio 2005 Team System Integration Conclusions
introduction
"Distributed System Designer" consists of various tools that support distributed system graphic design and verification. This tool set is for application architect designers, designers, developers and operating architectors. "Distributed System Designer" is an early tool derived from Dynamic Systems Initiative (DSI) to improve the development, deployment and management of enterprise-class distributed systems. For more information on DSI, see Microsoft Dynamic Systems Initiative. These tools are part of Visual Studio 2005 Team System.
Service-oriented architecture is the basis for next-generation distributed applications. The Microsoft "Indigo" platform will realize the industry-leading service-oriented system. "Indigo" will be based on the SOAP and Web services supported by the current Windows platform and add extensive support for transmission and system topology. At the same time, it will also realize security, reliable and long-lasting messages between service and services. The Indigo platform itself has many major improvements, and companies can now use SOAP, XML messaging and ASP.NET Web services to develop service-oriented systems. For more information, see Indigo.
Back to top
Design distributed system puzzle
Designing and deploying a distributed system is a fairly complex process. This section describes some problems that may occur.
Design visualization of distributed systems
The system structure is visualized and is more and more difficult as a whole. The reason is that the system is more harder in the system-oriented architecture. In addition, over time, companies generally form a lot of different systems, such as procurement departments, development departments. Applications in these systems may also be a wide range. Since the number of programmed technologies used in each system is very different, sharing features and data between them are generally very difficult. In order to achieve interoperability, the design-based interface has become increasingly becoming a basic requirement for developers and architect designers; design new news and ensuring compatibility with existing messaging architecture. Interoperability achieved via a message is the core of the service-oriented architecture.
Keep design and code synchronization
In order to maintain the latest documentation of the system design, it is necessary to strengthen communication between the designer and developers of the architecture. However, once you start writing code (even for perfect purposes), the system design document will often become outdated and inaccurate. But this arduous task that makes the design document and the rapid code synchronization of the code will soon become the past.
Deployment design
Software and hardware suppliers often think that developers understand each of the platform configuration (SQL, IIS, BizTalk, etc.) and identifying operation management to fully identify the framework and message protocol used by application developers. Although the operation should be part of the overall software development lifecycle, this part is in terms of organization and function. The operator and developers are basically unique to collaboration, and both parties are generally accepted by passively, usually in the development of post-diagnostic problems in early prevention. Please try to develop and deploy a simple web service. Although developers' focus is to achieve services, they still need to consider the following: security, authentication models, other support services required to target the target environment, so that the Web service is set by the desired configuration settings in the expected operation. For operation, it is necessary to identify the protocols and services required for the new service, and whether the enterprise IT policy is followed. Separation of development and operation will lead to deployment issues (the results are often configurable), which will cause design and data center that is not compatible (the result is made on corrective deployment issues).
Although many companies try to solve the above problems through documentation, design review and carefully drawing charts, they are often unable to implement and communicate their strategies due to lack of related tools and public languages. In addition, these processes do not appear in the daily tools of developers and operators so far, therefore there is a certain problem.
Configuring applications for security
Ensuring security of distributed applications is a time consuming and complex process involving a large number of technologies and settings that affect application design. Currently, an integrated approach has not appeared to express the security requirements of the application's security configuration or data center when designing an application. Therefore, it is really difficult to ensure that security is implemented correctly.
Back to top
Improved design and deployment of distributed systems
"Distributed System Designer" is an integrated design tool that is a visual design and verification of distributed systems. The designer uses "System Definition Model" (SDM) as an infrastructure that describes the connection status, configuration and interrelationships of the application service and runtime environment. SDM is based on multi-layer model, which includes applications, application hosting environments, network topology, operating systems, and physical devices. This model not only allows the "Distributed System Designer" to describe the design of each layer, but also allows it to express all layers of constraints and strategies to span all layers of the distributed system.
"Distributed System Designer" supports integrated models for two domain (development and operation). In this way, the designer can use the following method to solve customer problems:
• Provide a public language (SDM) to describe the design and configuration of the distributed system. • Allows developers to express applications on runtime environments. • Allows the operator to express the application runtime, security, and connection requirements as the target deployment environment policy. • Use abstract concepts to allow developers and operators to communicate on a common basis. • Integrate with existing Visual Studio project systems and .NET technology. • Provide a visual design element with complete synchronization of code. • Incorporate the extension framework, allowing models for building new applications and host systems.
The various designers and editors of the Distributed System Designer tool set will be described in detail below.
Back to top
Distributed System Designer Overview
"Distributed System Designer" includes the following designer:
• Application Connection Designer • Logic Data Center Designer • System Designer • Deploy Designer
Application connection designer
Application Connection Designer (ACD) helps developers or architect designers define and configure applications to be deployed in the system. 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 also includes a general purpose application prototype to record other application types in the design.
Application Connection Chart shows the application defined in a Visual Studio solution. You can create charts from the toolbox to create a chart from the header, or you can create graphics by reverse engineering or existing projects.
Application connection diagram representation is shown in Figure 1. Figure 1: Application Connection Designer
ACD can also display "internal" and "external" applications at the same time. The internal application is one or more deployment systems that can be organized together in the internal application to organize these applications to form one or more deployment systems. Typically, an internal application is an item that defines a managed executable (eg, a web application or Windows application). Resources can be included in the project, or in other reference items or shared projects, including class library items. The external application allows developers to visualize other systems to be involved in the deployment process.
Each application is represented by a box, a smaller box represents the connection point, indicating that the application is a connection destination or a connection source. These connection points are also called endpoints. The service provided by the application is represented by the provider endpoint (solid shape); the connection point provided by other applications is represented by the client endpoint (hollow shape). Each application is connected to each other through endpoints.
Although the SDM model focuses on the type, configuration, and connection of the endpoint, each application can extend the model to express the definition of the behavior provided by the service. For example, one of the following two methods can be used to define a Web service endpoint: Click the Web service provider endpoint, allowing the WEB service to be defined in the Endpoint Details window; or import an existing web service description language (. The behavior definition in the WSDL) file. If the model is expanded according to the above method, the ACD supports a complete design experience. For example, the behavior and configuration of the web service application is allowed to be fully specified.
The connection displayed in the ACD describes the current configuration of the application in the development environment. If the application has been debugging, it will run along the displayed connection path.
The delay of the ACD support method allows users to create and verify design first, then pay the code. If you add an application definition from the toolbox to the ACD, the appropriate item, code, and configuration files are not created immediately. The first generation of the code is also called "implementation". Application definitions can be incremented and can be implemented one-time. In the chart, the implemented application is distinguished with a shadow. Once the application is implemented, just hold charts and code files open, the generated code file, configuration file, and application design displayed in the chart will always be synchronized. If the graph is turned off for some reason, reopen it will make it synchronized with the code, while the code changed during the chart is closed to update it. Thus, the design model in the ACD can easily keep synchronization with code changes, so that other tools cannot solve. If the application is created by reverse engineering with existing projects or solutions, the system considers that the application has been implemented and synchronized automatically.
By delaying implementation, architectural designers and application designers can concentrate on completing the functional design and verification of the system, while delaying some implementation of decision making by the development team later. These decisions may include the selection of programming languages and templates, or server locations for web projects.
Since the chart is saved as a file (.dsdgm file), it can be included in the source control and incorporate the conventional workflow of the group. Relevant information that has implemented applications is saved in each item .sdm file. As a result, you can multiplex items in multiple solutions and divide the work into different developers in different units.
ACD can access the full model of the application configuration settings and define the host constraint. The host constraint allows the application designer to designate the relevant requirements of the host environment. By defining host constraints about applications in the Settings and Constraint Editor, application developers can request to enable a set of required features in the target deployment environment to communicate important applications to operators. Thereafter, the operator can determine if the logical data center is to be changed to meet the above request. As part of deployment verification, the system must verify the settings and host constraints of the application based on the settings and constraints of the logical data center (see "Deploy Designer"). Logical data center designer
Logic Data Center Designer (LDD) is used to create a chart of a logical server that represents a data center logic structure. These logical data center charts communicate important information about the target deployment environment to developers. With the designer, the designer of the operating architecture can specify and configure server types, licensing communication types, specific communication paths, and enabled service types.
Typically, the logical data center chart is created and owned by operation analysts, but is used by developers. After the logical data center chart is created, the operator can lock the chart throughout the application development lifecycle and manages the chart version to keep it synchronized with the design changes to the data center. Like other "distributed system designers", the logical data center designer is also integrated with Visual Studio. However, the creation of the logical data center chart is independent of the development process of the application. These charts are saved as .lsad files, can be reused by other distributed systems deployed in the same target environment.
The figure below shows the build process for a simple logical data center chart.
Figure 2: Logic Data Center Designer
In LDD, the toolbox contains a predefined logical server prototype, which can be added to the chart. The logical server represents the application host in the data center. 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 for configuring servers. The reason why the general server is included, just considering the record. The general server allows other types of servers to be present in the data center to establish a model. Each logical server has two endpoints that specify a specific communication protocol. The endpoint can be added to the logical server to communicate with other logical servers via this endpoint.
By editing the provided settings, the configuration of the logical server within the data center can be established. These settings can be imported from the actual server except for editing the settings provided. Once the description of the data center is completed, you can use the "Setup and Constraint Editor" to specify policy constraints related to the application type and configuration, where the application refers to the application that can be hosted in the instance in the data center. These constraints are created based on the settings in the application layer because they are used to constrain the server hostable application type and specify the configuration required by the application. For example, for applications managed by the web server, you can restrain the ASP.NET security settings; for the Windows client server hosting applications, you must have the required .NET Framework version. Tag some settings as fixed to specify that these settings are not overwriting during development.
"Setting and Constraint Editor" is shown in Figure 3.
Figure 3: Settings and constraint editing
The toolbox also includes several regions and endpoints. The area represents the communication boundary of the data center. The area endpoint represents the connection point between the area and the server. The communication path between the area and the server is controlled by the area endpoint, configuring the area endpoint to determine the type of communication protocol allowed to enter and exit. The server endpoint is used to specify the communication paths and protocols allowed between the server and the server that transmits (or receiving) communication data.
As part of deployment verification, the system must verify the configuration settings and application constraints defined in the logical data center chart according to the settings and constraints defined in the application (refer to the Deploy Designer "). In this way, the strategy and deployment requirements of the data center can communicate from the operation team to the development team. System designer
The system designer is used to build and configure the system according to the application defined in the ACD. In the Distributed System Designer, the system is a deployment unit and is an configuration of one or more applications and other subsystems. Since the system can be built from other systems, it is possible to define a large-scale distributed system solution. The application architecture designer can design complex multi-layer systems to use this as a hierarchy of the "nested" system.
When creating a system definition, the deployment configuration can be defined independently of the development configuration displayed in the ACD. If allowed, the application of the system chart uses the application settings of the application that can override the ACD definition. You can create multiple system definitions, each defined in the solution defined different application configuration. In this way, deployment within a different plan (possibly configuring different data center configurations, different geographic deployments or different customers) can have different configurations.
Figure 4 shows an example of a system diagram including a nested system.
Figure 4: System Designer
Deployment designer
The deployment designer is used to define a deployment of a particular system to the target logic data center. Typically, the deployment designer is used by developers and architectural designers. In the deployment designer, the application in the system is bound to the logical server in the target data center. The designer provides the functions highlight the intrinsic communication advantages of the SDM model, and the SDM model is the basis for distributed system designers. Once the deployment is completed, you can verify it as needed. Verify that all applications in the confirmation system are bound to the logical server and check if the application meets the application constraint specified in the logical data center chart. In addition, verification also confirms if the logical server is in line with the host constraint specified in the application connection chart and the system chart.
Finally, verification ensures that there is a necessary communication path and determines if there is a correct communication protocol, and whether these protocols are compatible between applications and host servers.
Figure 5 shows an example of a deployment chart.
Figure 5: Deploying Designer
All verification errors are displayed in the Visual Studio error list, which provides a simple navigation mechanism for correction and adjustment errors. Double-click the error in the error list, the deployment designer will open the appropriate chart, select the appropriate application or logical server and navigate to the appropriate settings to correct it. This allows users to correct configuration errors before deployment (even before fully implementing the system). With the deployment designer, you can generate all reports of all required applications and data center configuration settings and use it in the script of the custom deployment tool.
Back to top
Extensibility
"Distributed System Designer" will include an extensibility model that allows partner expansion platforms, and supports support for other protocols and other kinds of applications and logical servers.
Back to top
Integrate with Visual Studio 2005 Team System
"Distributed System Designer" provides support for the design and deployment of distributed applications. Designer integrates with other Visual Studio 2005 Team System Tools in the following ways:
• Distributed system development projects using the "Distributed System Designer" design, development and testing are managed by Visual Studio 2005 Portfolio Management Tools. • The application uses Visual Studio 2005 Team Test for unit testing. • Source Codes Controls and Integrated Work Project Tracking Using Visual Studio 2005 Team Foundation Server and Client.
Back to top
in conclusion
"Distributed System Designer" consists of a set of designers that simplify the design and verification process of distributed systems based on a service-oriented architecture.
• Service-oriented architecture: According to the expected, service-oriented architecture will become the basis for next-generation distributed applications. However, it is a very difficult thing to make the fragment of the architecture necessary. Application Connection Designer (ACD) and System Designers will help application architectures, designers, and developers visualize and design-oriented systems. • Operation Design: "Distributed System Designer" can create charts to represent the system's application layer and application host layers. Since the service constant changes in the application, the first deployment application (and the entire lifecycle of the application), with these charts helps design and deploy applications to verify the configuration of the application based on the operation requirements. • Executive Design: With the unified model in "Distributed System Designer", applications and infrastructure designers can capture large amounts of metadata during design. This metadata can be used to generate code, or can be used to verify the design of the application based on the data center definition. This model allows the application architecture designer to create more formal, more accurate design. In the entire life cycle of the application, keeping design and code synchronization is still critical, which helps the application architecture designer maintenance and expand the application as needed. "Distributed System Designer" can help companies successfully build web services and service-oriented applications, and conduct valid preparation for successful deployment of the data center.
For more information on other members of Visual Studio 2005 Team System, see:
• Visual Studio 2005 Team System: Overview • Visual Studio 2005 Team System: Building Robust and Reliable Software • Visual Studio 2005 Team System: Software Project Management • Visual Studio 2005 Team System: Enterprise-Class Source Control and Work Item Tracking • Visual Studio 2005 Team System: Microsoft Solutions Framework • Visual Studio 2005 Team System: Extending The Suite • Visual Studio 2005 Team System: Enabling Better Software THROUGH BETTER TESTING
