TN_1109: Understanding Systems and the System Designer

Bill Gibson, Program Manager
Microsoft Corporation

Visual Studio Team Edition for Software Architects includes two designers focused on the design of application software—the Application Designer and the System Designer. The Application Designer makes it easy to create and connect applications in your solution. As you can also define deployment from this designer, you might think that it’s all you need. However, the System Designer is really the key architectural design tool, while the Application Designer plays an important although auxiliary role. This note discusses the use of systems and the role of the System Designer and highlights its importance.

Systems

The System Definition Model (SDM) defines a system as a configuration of resources. In the application layer, there are two important kinds of system: atomic systems and composite systems. Atomic systems comprise resources such as assemblies, DLLs, and configuration files and are referred to as applications. Composite systems are composed of applications and other composite systems and are referred to as application systems (or simply ‘systems’). Except in trivial cases where an application is deployed alone, a system is always used to describe the configuration of applications that are deployed together. In complex datacenter scenarios, the application architecture will be described by many interconnected systems. For more information, see System Portfolio Management.

For a more detailed discussion of SDM, see Understanding the System Definition Model.

The Scope of an Application Diagram

The goal of the Application Designer is simply to help you define applications that you can compose into systems using the System Designer. The application diagram that you create using the Application Designer is scoped to a single Visual Studio solution. Applications on the diagram fall into three categories:

• Implementable applications—applications that either are implemented or can be implemented. This includes ASP.NET applications, Windows applications and Office applications. Implementable applications support synchronization to or from Visual Studio projects, source code and configuration files;
  
  
• External applications—applications that are not part of the solution but are referenced by applications in the solution; and
  
  
• Other applications—applications that are modeled but for which there is no synchronization with code. This includes generic applications and all applications based on custom application types defined with the SDM SDK.

Connections from implementable applications reflect how these applications are or will be configured in the solution.

While a solution controls the build process in Visual Studio, it is an arbitrary scoping construct with no specific design or deployment semantics. Unlike systems, solutions are not composable. A solution often contains projects that are used during the development process but are not intended to be part of a deployment. Some examples of these projects include test clients and test services with stubbed-out behavior. While you might want to define and deploy test versions of systems that include test applications, the production system you eventually deploy won’t include these. So while you can validate the applications you’re designing by describing a ‘trial’ deployment definition based on an automatically managed default system scoped on the solution, in most cases you will need to define an explicit system to describe the configuration you want to deploy.

For more information about defining a trial deployment, see Understanding and Using the Default System.

Creating a System and Adding Members

You can create system definitions by adding a new system at the solution level using the Solution Explorer or from one or more selected applications on the application diagram. Once you create a system, you can add or remove applications or systems to extend the system definition. You add additional members to a system by dragging applications or systems from the System View window.

The System Designer allows you to create a custom configuration of any number of applications and/or other systems. Not only can you exclude test applications, you can create custom configurations of applications for different deployment contexts (a common requirement). For example, you might need to deploy a system in Europe that is configured with services that can handle European tax law. Deploying an equivalent system in other markets might require other services. Similarly, you might define different systems to represent different product SKUs. For example, you could include a more advanced system service in upper-level SKUs but omit it from a lower-level SKU.

Connecting Members

On the application diagram, connections represent the actual configuration of applications in your development environment. By contrast, connections on a system diagram represent an intended configuration of the application should the system be deployed. For example, on a system diagram of a sales system, a storefront client application is connected to a catalog service, which is connected to a catalog database. When this sales system is deployed, the storefront client, catalog service, and catalog database must be deployed. In addition, the storefront client must be configured so that it connects to the catalog service, and the catalog service must be configured so that it connects to the catalog database.

Figure 1 The initial sales system design three member applications

If you create a system from connected applications on the application diagram, as a convenience those applications remain connected on the system diagram. However, you can configure applications on a system diagram differently from their configuration on the application diagram (which if the applications are implemented, reflects their configuration in the solution). You can delete or change the application connections on a system diagram without impacting the configuration of those applications in the solution or their connections on other system diagrams. Likewise, you can delete or change application connections on the application diagram without impacting connections on system diagrams. However, deleting an application’s endpoints removes them from system diagrams as well as any connections or delegations to those endpoints.

In our example, suppose you create a test version of the catalog service by copying and pasting it on the application diagram and then implement it. You could then connect the storefront application to your test version of the catalog service in the application diagram without impacting the way the storefront application is connected in sales system. You can change the connection on the application diagram by deleting the existing connection and then connecting the application to the test service. Deleting the connection on the application diagram does not affect the way the storefront application is connected in the sales system. However, changing the connection in the application diagram does reconfigure the storefront application’s Web.config file in your solution so that the Web reference URL becomes the test service URL—you will see the impact of this change when you next press F5 to debug the solution.

Overriding Configuration in a System

Another key feature of the system diagram is that you can override application configuration, particularly configuration settings. In the Application Designer, you can edit settings associated with the application definition using the Settings and Constraints Editor. Once an application has been implemented, changes to settings are synchronized with the appropriate configuration files. In the Application Designer, you can mark individual settings as overridable using the Settings and Constraints Editor. This action indicates that you can override them in the System Designer in the context of a specific system. You can also mark settings as deployment settings, indicating that the value is provided during deployment by an operator or a deployment script. When you deploy the system, the actual configuration of an application comes from a sucession of potentially overridden settings. Default settings are defined on the underlying abstract application types. These may be overridden by settings specified on the application definition in the application diagram, which may be overridden by settings defined on the use of that application in the system diagram. Ultimately, all of these settings might be overridden at actual deployment.

System Composition and Proxy Endpoints

A system defines not only a configuration but also an encapsulation boundary. As an application system is just another SDM system, you can include it as a subsystem in other systems. A system must expose endpoints so that you can connect it with peer subsystems or applications within another system. You can selectively expose the endpoints of any system member as system endpoints, making the behavior of that member public. You can expose consumer and/or provider endpoints as required. You expose an endpoint by adding a proxy endpoint to the system. This proxy endpoint delegates communication to a member endpoint. As the member can also be a system, this proxy endpoint can continue delegating communication to other systems, thus you can nest systems without limit. To create proxy endpoints on a system, you can either right-click the member endpoint you want to expose and choose Add Proxy Endpoint, or you can press the ALT key and drag a delegation line from the member endpoint to the system boundary.

Figure 2 The catalog system encapsulates the catalog service and database

Referring back to our catalog example, you can now introduce a catalog system that encapsulates the catalog manager application and the catalog database but exposes only the Web service endpoint of CatalogManager. See Figure 2.

You can then use this new catalog system as a single entity in the sales system and other systems. See Figure 3.

Figure 3 The revised sales system that includes the catalog system as a member

Systems are just Configurations

A system defines how to configure its members for deployment. At deployment, all delegations and connections in composed and connected systems are resolved to connections between the lowest-level applications. As a rule, systems have no tangible representation once deployed.

Systems definitions are also scale-invariant. A system defines a set of members that must be deployed to suitable host systems. In a depoyment of a system, each member of a system is deployed exactly once to a host in a scale-invariant model of the datacenter. If an application or system is required to play multiple roles in the system then more than one member of that type must be included in the system and connected and configured appropriately. Adding additional members of the same definition does not change the scale. A member’s scale is indicated by its Scalable property. If marked as scalable the member it indicates themember can be scaled out, for example, onto a server farm. By default members are marked as not scalable.

By default, all members of a system are required to be deployed in a deployment of the system. Individual members can be marked as optional indicating that they are not required in a deployment of the system. You should not mark a member as optional that offers services that are required by a member that is not also marked as optional.

Navigating Among System Definitions

If a system is composed from other systems, you can easily navigate among the system definitions. In the System Designer, double-click any system member to open that system’s definition in another system diagram. You can drill-down through any number of nested systems and then use the Visual Studio navigation buttons on the toolbar to move back and forth between recently visited documents and back to the original system.

Bottom-up or Top-down Design

While the System Designer has been optimized for composing systems with applications from the bottom-up, you can also design systems and their behavior from the top-down and then define the applications that implement the behavior. This is a valuable technique for application architects. The technique for doing this is described in Top-Down System Design.

Versioning Systems

Like all other SDM types, a system, can be versioned. In SDM, a version stamp is applied to the SDM document which defines the version of all the type defined within that document. All member references in a system are versioned references, which specify the version of the referenced system or application. A version of a system is thus a configuration of specific versions of its members.

Versions references are resolved when diagrams are opened based on matching the SDM document name and major version number as well as the system name. If a correct version cannot be found the member is higlighted in red and the type name underlined with a squiggly line.

Versioning systems is discussed further in System Portfolio Management.

References

For more information on the SDM model, see the Dynamic Systems Initiative Web site at http://www.microsoft.com/windowsserversystem/dsi/default.mspx.

For more information on the SDM SDK, see System Definition Model.