DSI, SDM and the Distributed System Designers (Show me the SDM!)

  • Article

While there has been a lot of talk about DSI and SDM, I feel that there is a need to clarify how they fit into the SOA designers.

What is DSI? What is SDM?

“The Dynamic Systems Initiative (DSI) is an industry effort led by Microsoft to enhance the Microsoft® Windows® platform and deliver a coordinated set of solutions that dramatically simplify and automate how businesses design, deploy, and operate distributed systems. The System Definition Model (SDM) is a key technology component of the DSI product roadmap that provides a common language or meta-model that is used to create models that capture the organizational knowledge relevant to entire distributed systems.” - https://www.microsoft.com/windowsserversystem/dsi/sdmwp.mspx

The way that I like to think about this is that Microsoft is making an effort to automate much of the work that is required to create, deploy and maintain distributed systems. To do this, they have defined a schema known as the SDM. This common language or meta-model facilitates the interaction between the different components in a distributed system (applications, tools, operating systems) to achieve the automation required to simplify designing, deploying and operating distributed systems. Thereby simplifying many of the tasks that otherwise requires significant effort today.

DSI, SDM and the Distributed System Designers

The Distributed system designers allow you to enable validation of system configurations against models of target environments to increase the predictability of deployment.

If you’ve read my blog before, you’ll realize that I’ve covered our ‘value’ proposition in detail several times before. Lately I have recieved a lot of requests to show the SDM itself, and in this post I want to specifically discuss the SDM VSTA generates through our Designers.

As I have mentioned before, the SDM is simply a schema. This schema can be found at: https://schemas.microsoft.com/SystemDefinitionModel/2005/1/DesignData/VisualStudio

Currently, the Distributed System designers generate several files. All of these files have some SDM information:

  • .ad file for storing information about the Application Designer
    • Contains the presentation information about the application diagram
    • Contains the SDM information about the various applications and endpoints prior to implementation.
  • .sdm file for storing information about the Projects
    • Once an application is implemented, a corresponding project is generated according to the parameters set for the application. The .sdm file is located in that project and contains the SDM information about the application corresponding to the project that has been generated.
  • .sdm file for storing information about external components
    • contains the SDM information about the exteral component; for example external databases, and external web services
  • .lddd file for storing information about the Logical Datacenter Designer
    • Contains the presentation information about the logical datacenter diagram
    • Contains the SDM information about the various logical hosts, zones, endpoints, etc.
  • .dd file for storing information about the System Deployment Definition
    • Contains the presentation information about the Deployment Designer
    • Contains the SDM information about the system deployment
  • .sd file for storing information about the System
    • Contains the presentation information about the System Designer
    • Contains the SDM information about the System

If you open the files up in the XML editor (as opposed to the default designers), all the SDM is contained in between the <SystemDefinitionModel> tags.

Tip : Ignore everything between the <DesignData> tag. Any information in the <DesignData> tag is presentation/design information that the SDM compiler is being asked to ignore.

 

Actions that impact the generated SDM

In the Application Designer, editing properties through the properties grid for an application may not have any effect on the SDM generated itself unless there is a setting that is roundtrip from that property.

All Settings and Constraints information that is in the Settings and Constraints Editor directly correspond to information that will be in the generated SDM. Editing a Setting or a constraint will affect the generated SDM.

For example, adding WindowsXP to the OsType as a valid Operation System the ASP.NET Web Application can be hosted on as shown below will affect the SDM. You can see this by following the subsequent steps:

  1. Create a new Project->Distributed System Solutions->Distributed System
  2. Add a ASP.NET Web Service Application
  3. Bring up the Settings and Constraints Editor (HINT: RMA the Application on the designer and select Settings and Constraints)
  4. Set the following Constraint below in the Setting and Constraints Editor
    1. https://a_pasha.members.winisp.net/images/SCE.jpg
  5. Save All
  6. Close the Application Designer
  7. RMA the Application Diagram file in the Solution Explorer and select Open With…
  8. Select the XML Editor
  9. The following was the change the occurred due to your setting the constraint.

<SystemDefinition Name="WebApplication1" Extends="MicrosoftWebApplication:WebApplication" SimulationRoot="false">

...

        <Constraint Name="OsType" Definition="SystemConstraints:EnumComparison">

          <Description />

...

  </SystemDefinition>

Therefore, any time that you use the Setting and Constraints editor in any of the Distributed System designers you are editing/generating SDM metadata.

Should I care about the SDM?

This depends on who you are. If you want to create your own application definition types using the SDM SDK, you will have to understand the SDM metadata. Otherwise, generally most users should not need to look at or edit SDM directly.

For more information about SDM see https://labs.msdn.microsoft.com/teamsystem/workshop/sdm/default.aspx.