次の方法で共有

Understanding SDM: Systems and the Four Layer Model

  • [アーティクル]

The Whitehorse Distributed System Designers are based on SDM - the System Definition Model.  SDM offers a simple model for representing computer systems that can help in many parts of the design, deployment and management space.  I'll try over an occasional series of posts to introduce some of the key SDM concepts and how they play together.  I'll also show how we can extend these to do some neat things in the application architecture modeling space.

At the heart of SDM is the notion of a 'system'.  Let's look at a definition of system that I find useful.

A system is a configurable collection of resources that can be independently deployed . If the resources in a system need to access resources of another system they do so by communicating via endpoints on the systems.  

A system can be atomic or composite; a composite system is composed of other systems. I'll explore system composition, resources and endpoints further in other posts, this post will focus on the notion of system hosting.

One system is considered to host another system if it provides infrastructural services to the hosted system.  Services can be thought of as infrastructural if the services are provided to many systems of the same type.  Introducing the hosting relationship allows the model to be layered, so that different concerns can be addressed in different layers.  For example, the requirement of an ASP.NET application on the services provided by IIS is an infrastructural hosting relationship.  Similarly IIS is hosted on Windows which in turn is hosted on an appropriate physical system.  It wouldn't be useful to have to include models of IIS and Windows and all the other systems that exist in those layers every time you wanted to model an application so we model those separately and then host a model at one level on the model of another. This reflects the reality that one tends to think of configuring standard system 'platforms' on which other systems are installed.  Most organizations use a small number of standard configurations of hardware systems on which they install standard configurations of OS and networking systems on which they run standard configurations of application hosting systems on which they run standard configurations of their business applications.

We typically think about there being four layers of systems: application systems, application hosting systems (such as IIS, SQL Server), operating and network systems (such as Windows), and hardware systems (such as a Dell or HP server, Cisco router etc.).  In reality there are no hard boundaries and there may well be more than four layers of interest, but it is often useful to think about these four general categories of systems, and it certainly helps people 'get' the overall model.

Different roles/people at different stages are interested in defining, deploying and managing each of the layers.  Information about one layer can be provided to those involved in defining another layer to assist in validating that systems at one level will successfully deploy on a specific configuration of systems at the next level.  The Distributed System Designers, for example, support the definition of models of the application layer and the application hosting layer and enable deployment validation - where the configuration of an application is verified against a configuration of application hosting software with the goal of increasing the likelihood of successfully deploying the application.

Comments