TN_1114: The Four Layers of Systems in the System Definition Model

Bill Gibson, Program Manager
Microsoft Corporation

The Distributed System Designers are based on the System Definition Model (SDM).  SDM has been designed to support the design, deployment, and management of distributed systems. The purpose of this note is to discuss the layered view of SDM that reflects the model of system hosting in SDM. This layered view helps factor the SDM models that are created by the design tools to reflect the concerns of architects, developers, IT professionals, and others involved in designing different aspects of a computer system.

Systems

At the heart of SDM is the notion of a system. In its most basic form, a system is an independently deployable configuration of resources. If a system offers access to its resources, or if those resources need to consume the services of resources in other systems, it does so using endpoints. Systems are either atomic or composite. An atomic system is directly composed of resources, while a composite system is composed of other systems. For more information on SDM, see Understanding the System Definition Model.

Hosting

A key concept in SDM is the notion that systems can host other systems. One system is considered to host another system if it provides infrastructural services to the other system.  Services are considered to be infrastructural under the following conditions:

• They are essential to the hosted system.
  
  
• They are available to any hosted system of the same kind.
  
  
• They are implemented independently of the hosted system. 

To represent this kind of dependency, a hosting relationship is defined between the underlying abstract SDM types. Instances of this relationship are then created when describing a deployment of an instance of the hosted system onto an instance of the hosting system.

With this notion of hosting, you could simply sit down and create a monolithic model of the stack of systems required to configure a datacenter, from the hardware systems all the way up to the application software system. Such a model would be extremely precise but very unwieldy.

Layering Systems

The hosting relationship allows the model to be layered, so that different concerns can be addressed in different layers.  In this way, the design and configuration of a set of systems in a hosting ‘layer’ can be described separately from the design and configuration of the systems they are to host. Each layer can be represented in discrete models/SDM documents making the system designs in each layer reusable.

Figure 1 Hosting relationships and constraints between layers of systems

Consider an example: an ASP.NET application connected to a SQL Server database requires services from IIS and SQL Server that each host one of these applications. The design and configuration of the ASP.NET application and SQL database is based on business end-user needs, whereas the configuration of IIS and SQL Server is normally driven by orthogonal concerns such as security, privacy, performance and scalability. Similarly, these configurations of IIS and SQL Server will be hosted on a configuration of Windows, which in turn is hosted on a hardware system configuration. Both the operating system configuration and hardware system configuration will be designed with different criteria in mind.

Factoring Concerns and Reuse to Layers

Typically, there is increasing reuse made of system designs as you descend lower in the stack. It is not typical (although certainly not unheard of) for the entire stack of systems to be custom designed for each end-user application. Most organizations use a small number of standard configurations of hardware systems on which they install standard configurations of operating systems and networking systems. On these operating system configurations, they run standard configurations of application hosting systems. On these hosting systems, they run standard configurations of their business applications. In addition, its not just the concerns that are different, there are frequently different people involved in application design, infrastructure design and configuration, and operating system and hardware configuration, all with different needs.

Hosting is not just a basis for defining a structural relationship between systems, but it is also for defining validation rules or constraints. SDM allows constraints to be defined on types (systems and resources) at a level that either constrains types that they host or types on which they will be hosted. These constraints are then evaluated when a deployment definition is compiled. A deployment definition expresses a specific mapping of a system at one level to a system at a lower level.

Model-driven design, validation, and provisioning processes offer the opportunity to lower the cost of customization. Today, key reasons for reusing system designs are cost and risk reduction. It is cheaper and safer to reuse a tried and tested configuration than to custom-design each configuration for the job. In reality, most configurations will contain some element of compromise. One of the longer term goals of SDM and the tools being built around it is to bring (at least in some measure) the benefits of mass customization to the datacenter.

The Four Layer Model

While SDM allows for arbitrary levels of hosting among systems, a simpler four-layer model proves a useful way of thinking about the space in most installations:

• Applications (such as ASP.NET applications and Windows applications)
  
  
• Application Hosting (such as IIS and SQL Server)
  
  
• Operating System and Network (such as Windows XP and Windows Server 2003)
  
  
• Hardware (such as a Dell or HP servers and Cisco routers) 

Figure 2 The four layer model of hosted systems

This notion of layers as well as the scenarios and requirements of different users who design, deploy, and manage systems have influenced the design of the SDM-based modeling tools. Visual Studio Team Edition for Software Architects introduces tools to support the top two layers – applications and application hosting. While the tools implement a common underlying model and provide a similar user experience, the specific concepts and user requirements at each layer suggest important differences in the tools required to support them. If you explore the Application Designer and System Designer (both of which work at the applications layer) and the Logical Datacenter Designer (which works at the application hosting layer), you can see the similarities and some key differences.

For example, in the application layer, there is a high likelihood that application definitions will be used in different system configurations and that systems can be composed in different ways to create alternative packages. In the application hosting layer, greater attention is focused on the need to visualize a nested structure of zones and application servers. Reuse of types was judged less important. Therefore, in the Logical Datacenter Designer, more attention was paid to the ability to visualize arbitrarily nested system members, and composite endpoints were introduced on zones to simplify the wiring.

At a simpler level, aligning the tools with the layers cleans up the models and the Toolbox content so that the tools and models have a more clearly understood purpose.

Summary

SDM allows systems to be hosted on other systems to an arbitrary depth. However, a simple four-layer organizing model reflects the concerns of key participants in the systems development lifecycle, allows models to be factored and reused, and provides a useful basis for tooling.