TN_1104: Understanding the System Definition Model

Bill Gibson, Program Manager
Microsoft Corporation

This note describes the System Definition Model, focusing on its core type system. Other aspects of the model are discussed in other notes.

Modeling Computer Systems

Imagine picking up the computer from beneath your desk and shaking its contents out onto the floor. Among the components, wires and connectors that fall out will be the hard drive. Now imagine (this next bit takes a little more imagination) picking up the hard drive and shaking out all the software components installed in it, together with the software equivalent of wires and connectors. Now we have a pile of hardware and software on the floor - quite a mess!

If you want to design deploy and manage applications on this computer, you’d want to understand these components and how they relate to each other. Defining a rich model of these components and how they interact would enable you to design complete computer systems and analyze aspects of their behavior, performance, scalability, and manageability without committing those designs to code. This is the promise of model-driven tools.

So you might think to use a class model to represent the various classes of software and hardware systems within the computer and their relationships. As you started to build the model, you’d find that, in both the hardware and software, a pattern emerges of cooperating systems - such as the motherboard and graphics card, or the Web server and database software. You could swap these systems for other similar components with compatible interfaces. You’d see that each system was made up of smaller components that actually did the work and defined the system's characteristics, but might not be as freely interchangeable. You’d also notice that many components were configurable in some way, either by using pin settings or configuration files.

So while you could model all you’ve found using classes, you’d soon find that a general purpose class modeling language runs out of steam. Even with a custom profile, this language would be cumbersome and have limited extensibility. Enter the System Definition Model.

SDM is an extensible domain-specific language, purpose-built for describing the cooperating systems found not just inside the computer, but inside an entire datacenter. SDM provides a way to think about computer systems, operating systems, application hosting systems, and application systems as well as how they interact and are combined, connected, deployed, and managed.

The SDM Type System

The SDM type system is based on the three core types: system types, endpoint types, and resource types. In addition, there are four key relationship types: containment, communication, delegation, and hosting. Each of these and their interplay is described below.

Systems Resources and Containment

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. For software systems, resources are ultimately directories and files, such as binaries, XML files, configuration files, SQL script files, and so on. For hardware systems, such as graphics systems, motherboards, network interface cards and power supplies, resources might include the boards, processor chips, memory chips, fans, and other lower-level components.

If a system enables access to its resources, or if its resources access services offered by resources in other systems, it exposes those resources via endpoints. For example, a motherboard might provide an IDE endpoint for peripherals; Web service endpoints provide a means for an application to expose or consume Web services; HTTP endpoints provide a means for a server to enable access using the HTTP protocol.

Systems are atomic or composite. An atomic system is composed directly of resources, while a composite system is composed of other systems. A payroll system is composite since it is composed of many atomic applications, and the servers that the payroll system runs on are composed of many hardware subsystems.

The SDM type system is analogous to the .NET type system in which a programming class (a type) has members that are of different kinds (property, method, field, and so on) and that are each defined by a type. In SDM, a system is a type that contains one or more members, each of which might be a system, resource, endpoint, connection, or delegation and is defined by a type. Composite systems are like complex .NET types and are defined by other types. Like the .NET type system, where eventually all types are defined in terms of simple types, all systems are ultimately expressed in terms of resource types.

Endpoints, Connections, and Delegations

If the resources in one system need access to resources in another peer system, they connect via endpoints. Endpoints are the means by which systems expose resources. Systems can be connected when they are included as members in some higher-level system. For example, the wiring and connections between the motherboard, graphics card, and power supply are described in the context of the design of the computer type in which they are used. Each system type defines how it can be connected to, and, if it is composite, how it is assembled from its subsystems or resources. Thus, in a catalog system assembled from a catalog manager application that exposes a product catalog Web service, and a catalog database, the connection between the application and the database is a fact known by the catalog system and is not part of the definition of either the catalog manager application or the catalog database.

A composite system containing other systems can selectively expose the endpoints of its member systems as an endpoint. This allows systems to be composed and connected in new contexts.

In the catalog system, the designer might choose to expose only the catalog manager’s Web service endpoints and to hide the database. The composite catalog system can now be used as a component in other systems, which cannot connect to the database except via the catalog manager and its Web service.

Figure 1. A composite application system

An endpoint on a composite system is therefore always a proxy for an endpoint on some underlying member, with all communication to or from the proxy endpoint on the system delegated to an endpoint on the member. As a member of the composite system might itself be another composite system, communication may be delegated across any number of levels. A composite system is simply a configuration definition—there is no manifestation of the system once it has been deployed. During deployment all connections among a system’s members are resolved to connections among atomic systems which are in turn delegated to resources of some kind.

Hosting, Deployment Definition, and Validation

One of the key abstraction patterns in the design of hardware and software is the notion of hosting. A system is hosted on another system if the host system provides what are considered infrastructure services for the hosted systems. A system that hosts other systems will in turn be hosted on other systems, creating a layered model. For example, an ASP.NET application is hosted on IIS, which is hosted on Windows, which is hosted on a suitable hardware system. For a more detailed discussion about system hosting, see The Four Layers of Systems in the System Definition Model.

The hosting relationship allows you to define sets of systems at each layer independently and then bring the systems together later to host one on the other. The description of the way systems in one layer are hosted on systems in another layer is referred to as a deployment definition.

SDM allows you to define constraints that constrain systems being hosted on one another. Constraints can be defined on an SDM system type to restrict the kinds of system which it can host, or to restrict the kinds of system or configuration of the systems on which it can be hosted. So for example, you can define a constraint that prevents Web applications that offer Web service endpoints from being hosted on a specific Web server, and you can define a constraint on the same Web server that requires a specific operating system patch be present.

Visual Studio Team Edition for Software Architects includes an SDM compiler that runs static checks on the models and can report constraint violations in a deployment definition.

Abstract vs. Concrete Types

SDM distinguishes between abstract types and concrete types. Abstract types define ‘base’ or ‘technology’ models, which are then extended by concrete types in specific designs. For example, Microsoft defines the abstract types for IIS and ASP.NET and defines the Web services and Web site endpoints they support, the kinds of resources they contain, and the communication, containment and hosting relationships that exist between them. A specific Web services application design can then be expressed using concrete types that extend these abstract types.

The Distributed System Designers in Visual Studio Team Edition for Software Architects pre-load the available abstract types and then use the knowledge and rules described in them to control the design experience provided by the tools as you design new concrete types and describe their deployment. When you open the designers, tool behaviors that flow from the loaded abstract type models control the capability to add a Web services provider endpoint to an ASP.NET application and not a Windows application, to connect a Web service provider to a Web service consumer, and to deploy the ASP.NET application to an IIS server.

The Distributed System Designers also provide an SDK that enables you to extend or define new abstract SDM types and create new relationships.

Prototypes

While not strictly part of SDM, the Distributed System Designers introduce the notion of prototypes. These are pre-configured concrete type definitions that are used to populate the design. Prototypes are the building blocks provided in the Toolbox. As these are just concrete types that are pasted into the design, you can create your own prototypes from any concrete type in the diagram. For more information, see Understanding, Using and Creating Toolbox Prototypes.

Deployment and Instances

So while the SDM types are defined during design in a scale-invariant model, they represent instances that exist or will exist in the real world. System deployment or provisioning is the action that creates the instances, if they don’t already exist. Thus you can think of the settings and configuration associated with a member as instructions to the ‘constructor’ for that type. The constructor is executed during deployment to instance the member in the context of an instance of its parent type. For example, when you deploy the Catalog system in our earlier example, the Catalog service and the Catalog database are also deployed and configured as defined by the Catalog system, which configures the connection from the Catalog service to the Catalog database.

SDM Documents

All SDM types, whether abstract or concrete, are defined in SDM documents. SDM documents are versioned packages of types. Types defined in one document can reference types defined in another. While an SDM document can contain any number of any kind of type, it’s more practical for documents to have specific purposes and to limit the kinds of types they contain. Each design tool creates and uses distinct SDM documents, differentiated by their extension, for each distinct SDM system type. This keeps application definitions, system definitions, logical datacenter definitions, and deployment definitions in separately manageable documents.

An SDM compiler is provided and is used in the SDK to verify the definition of new abstract types and by the Deployment Designer to validate a deployment diagram. The compiler checks the syntax and semantics of SDM document submitted to it and all SDM documents that they reference. Note that in Visual Studio 2005 there is no support for signing SDM documents on compilation. Therefore, it is important to protect SDM documents and to adopt appropriate document management practices so that documents are not updated mistakenly after they are considered frozen.

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 http://msdn2.microsoft.com/en-us/vstudio/aa718757.aspx.