Bill Gibson's Blog : Whitehorse

Whitehorse Architecture TechNotes Published on MSDN

Bill Gibson — Tue, 06 Dec 2005 17:40:00 GMT

Phew! A set of Visual Studio Team System Tech Notes have now been published on MSDN, including some fifteen new articles I've written on topics related to the Whitehorse architecture tools. These should all be easy to read and are inter-linked, to make them an easy to browse. Hopefully they will provide some useful background and some new insights into the Distributed Systen Designers.

Below are links to each of my notes, ordered in what is probably a good sequence in which to read them.

TN_1104: Understanding the System Definition Model

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

TN_1100: Understanding Applications and the Application Diagram

TN_1105: Why Class Libraries are not shown on an Application Diagram

TN_1109: Understanding Systems and the System Designer

TN_1101: Understanding and Using the Default System

TN_1110: Using Systems to Represent Services in a Service Oriented Architecture

TN_1112: System Portfolio Management

TN_1102: Designing Substitutable Web Services

TN_1113: Representing Connections to Manual, Physical and Other Kinds of System

TN_1111: Top-down System Design

TN_1108: Connecting Applications to Web Services via Class Libraries

TN_1106: Copying Endpoints vs Creating Endpoints from WSDL

TN_1103: Web Service Endpoint Name Propagation

TN_1107: Understanding, Using and Creating Toolbox Prototypes

Why do ASP.NET WebService and ASP.NET WebApplication look alike on the Application Designer?

On shadow applications and agile development

Bill Gibson — Fri, 02 Dec 2005 00:49:00 GMT

Randy Miller has published a paper on agile development that discusses the use of 'shadow' applications in an agile modeling and development context, in which he talks in somewhat veiled terms about the use of the Whitehorse design tools. The term shadow application emerged from discussions Randy and I had at Tech Ed earlier this year as we developed the top-down design approach described in my earlier article. In the article I show how you can use a shadow application as a placeholder for the behavior of a system and thus design systems top-down. In his paper, Randy take this idea further and suggests the shadow application is actually written or generated, consistent with the code-oriented agile development philosophy.

Understanding SDM: Systems and the Four Layer Model

Bill Gibson — Sun, 16 Oct 2005 19:14:00 GMT

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.