Post #02 of a collection of posts with some more technical details about the creation of richer implementations with Visual Studio Team Architect.
This is post 1: How To Fire a Guidance Package Recipe from the Implement Application Feature of Team Architect.
[Dynamic System, Lorenz attractor]
First you have to understand System Definition Model (SDM).
SDM is part of the overall Dynamic Systems Initiative (DSI) from Microsoft.
The Dynamic Systems Initiative (DSI) is a commitment from Microsoft and its partners to help IT teams capture and use knowledge to design more manageable systems and automate ongoing operations, resulting in reduced costs and more time to proactively focus on what is most important to the organization. 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.
Quote from System Definition Model Overview White Paper.
Dynamic Systems Initiative also contains ideas like Application Lifecycle Management, Microsoft Infrastructure Optimization Model and the just released V2 version of the Design For Operations Models [full name: Visual Studio Team System Management Model Designer Power Tool].
Often you here the term Service Modeling Language (SML) in relation with SDM, the SML Insight blog gives some explanation.
The model-based management functionality in Windows Server 2008 is based on Microsoft's System Definition Model (SDM) version3, which provided the basis for the Service Modeling Language (SML) proposal and submission to the World-Wide Web Consortium SML Working Group.
I'm curious how the DSI initiative and SDM / SML are going to evolve with Oslo and with that how Team Architect is going to evolve, a nice subject for another post.
Anyway, SDM is an XML-based meta-language for distributed systems.
The SDM structure behind Team Architect.
You can split the SDM structure behind Team Architect's Distributed System Designers in two parts. One XML part responsible for the loading, structuring and displaying systems, endpoints and resources in the Distributed System Designers, the <DesignData> element [MSDN link]. The other part holds all SDM relevant information, building blocks as SDM objects, relationships, and optional additions to objects such as settings, flows, and constraints, which also has <DesignData> elements.
Best explained with an empty Application Diagram file.
The ROOT Node still named after the codename "Whitehorse", I like that ;-)... next you have a one <Solution> node with a <DesignData> element, contains information about the solution, and one <SdmDocument> with two <DesignData> elements. The first is information for the Deployment diagram the second for the design-surface, this one will contain sub-systems when we add shapes on the design surface. [see XML below]
When we add an WebService shape to the design surface we will get an extra <SdmDocument> element which contains beside <DesignData> all the configuration.
adding an endpoint to the Service will give you this XML.
So, although the structure looks a little bit overwhelming , it's easy to understand and basically you can say that there are models which contains models [The "designsurface"model has "application"models and an "application"model got "endpoints"models which also have types], all the models got <DesignData> and are described in a separate node which contains settings / properties.
Distributed System Designers Reader
Now, you only have to make some kind of Distributed System Designers Reader which collects this information for you. I made a object model [see image] and a factory method [with many XML readers] which loads the model. [started to change that to LINQ]
This last step, actually the complete post, needs to be done when you use VS2005 or VS2008 for Rosario it's much easier [see this post, Rosario Team Architect Exposed, Getting Information Out Off the Designers].
Anyway, next post generate Service Models which uses this object model.