Export (0) Print
Expand All

Overview of the System Definition Model (SDM) 

SDM supports the Dynamic Systems Initiative (DSI) in simplifying and automating how enterprises design, deploy, and operate distributed systems. SDM facilitates communication between application architects, developers, and infrastructure architects by offering the following benefits:

  • Provides a common language to describe the design and configuration for all aspects of a distributed system.

  • Provides familiar abstractions that make it possible application and infrastructure architects to communicate on common ground.

  • Makes it possible for developers to communicate application requirements in the run-time environment.

  • Makes it possible for infrastructure architects to communicate application run-time, security, and connectivity requirements that result from policies defined in the deployment environment.

For more information, visit the Microsoft Dynamic Systems Initiative site at http://go.microsoft.com/fwlink/?LinkID=47203.

The following sections contain more information about SDM and SDM documents in Distributed System Designers:

SDM in Distributed System Designers

In Visual Studio Team Edition for Architects, SDM provides the basis for the underlying metamodel used by Distributed System Designers. SDM describes distributed systems using a model that includes the following layers:

  • Application layer

  • Application host layer

In Distributed System Designers, SDM describes the application layer in terms of configured and connected application systems. SDM describes the application host layer in terms of configured and connected zones and logical servers, which represent run-time environments.

By adopting a common way to describe these layers, SDM makes it possible for these layers to work together so that you can define, configure, document, and validate requirements and policies across all layers while you work in each layer.

For example, you can specify that an application can require a certain authentication mode or that certain resources must exist on the server hosting the application. A server can also require that the applications it hosts must support a certain authentication mode and that it disable specific features that present a security risk.

In addition, SDM is intrinsically extensible and makes it possible for you to add new abstract definitions at each layer. For example, you can add other types of applications, logical servers, or resources created by Microsoft, third parties, or other users. For more information, see Application Types and Prototypes for Defining Applications and Logical Server Prototypes in Logical Datacenter Designer.

SDM Documents in Distributed System Designers

Distributed System Designers store SDM information in XML-formatted documents. In addition to this data, SDM documents can also contain graphical information for diagram items and extended data definitions. For more information, see Relationships Between System Definition Model (SDM) Documents.

The following table describes SDM documents supported by Distributed System Designers and that appear in a Visual Studio solution.

File and extension Description

Application diagram (.ad) file

The following apply to the application diagram:

  • The application diagram surface appears when Application Designer is the currently visible designer.

  • The solution can contain only one application diagram.

  • The .ad file contains SDM definitions for applications that support implementation but are not yet implemented on the application diagram.

  • The application diagram appears as a solution item in the solution directory and is scoped on a single solution.

For more information, see Overview of Application Designer and Application Designer Terminology.

Application definition (.sdm) file

The following apply to an application definition document:

  • An .sdm file contains one of the following items:

    • An SDM definition for an implemented application on the application diagram.

    • An SDM definition for an application that does not support implementation and does not contain implementation information.

  • For each implemented application, the corresponding .sdm file appears after implementation in the root directory of the associated project in your solution.

  • For each application that does not support implementation, the corresponding .sdm file appears immediately in the solution directory as a solution item.

For more information, see Application Types and Prototypes for Defining Applications and Application Designer Terminology.

Application or endpoint prototype (.adprototype) file

Contains information for a prototype that is used to define applications and endpoints on the application diagram.

You can create these files using the System Definition Model SDK or from applications and endpoints on the application diagram.

For more information, see the following topics:

System diagram (.sd) file

The following apply to a system diagram:

  • The system diagram surface appears when System Designer is the currently visible designer.

  • An .sd file contains the following items:

    • An SDM definition for an application system.

    • Possible references to SDM definitions for applications and other application systems.

  • One or more system diagrams can appear as a solution items in the solution directory.

For more information, see Overview of System Designer and System Designer Terminology.

Deployment diagram (.dd) file

The following apply to a deployment diagram:

  • The deployment diagram appears when Deployment Designer is the currently visible designer.

  • A .dd file contains the following items:

    • An SDM definition that describes deployment of a specific application system definition to a logical datacenter.

    • A reference to an SDM definition for a specific logical datacenter.

    • A reference to an SDM definition for a specific application system.

    • Information for hosting applications on logical servers.

    • Information for hosting application resources on logical server resources.

  • One or more deployment diagrams can appear in the same directory as its associated system definition.

For more information, see Overview of Deployment Designer and Deployment Designer Terminology.

Logical datacenter diagram (.ldd) file

The following apply to a logical datacenter diagram:

  • The logical datacenter diagram surface appears when Logical Datacenter Designer is the currently visible designer.

  • An .ldd file contains an SDM definition for a logical datacenter.

  • Logical datacenter diagrams are standalone documents within a solution but can be referenced by deployment diagrams.

  • One or more logical datacenter diagrams can appear as solution items in the solution directory.

For more information, see Overview of Logical Datacenter Designer and Logical Datacenter Designer Terminology.

Logical server, zone, or endpoint prototype (.lddprototype) file

Contains information for a prototype that is used to define logical servers, zones, and endpoints on the logical datacenter diagram.

You can create these files using the System Definition Model SDK or from logical servers, zones, and endpoints on a logical datacenter diagram.

For more information, see the following topics:

Resolution Rules for Multiple SDM Documents

SDM documents are identified using the following set of attributes: document name, version, culture, platform, and public key token. Of these attributes, only the document name attribute is required. Only the document name, culture, and version attributes can be modified by users. For more information, see How to: Change Culture Codes for System Definition Model (SDM) Documents.

When loading multiple versions of SDM documents, conflicts might occur. Distributed System Designers resolves references to different versions of an SDM document using the following rules:

  • If an SDM document is compiled, such as those associated with predefined application prototypes or custom prototypes created by the SDM SDK, the document is accepted only if every attribute identifying the document matches the reference and with only minor version variations allowed.

  • If an SDM document is not compiled, the document is accepted as long as its name matches the reference. Other attributes such as version and culture (in that order) are also given priority if they match the reference. Given a choice between two equally qualified documents, the first one loaded is the accepted document.

See Also

Community Additions

ADD
Show:
© 2014 Microsoft