DSI, OSLO and Models in the Lifecycle. Get Prepared..!
OSLO vs DSI vNext.
There is lot of buzz around Oslo and it looks like all the ideas around this concept are completely new. But when you take a look at the vision behind Oslo it's not that new, it's acutely the next step to maturity of Microsoft's Dynamic Systems Imitative [DSI] from a few years ago.
What is OSLO?
From http://www.microsoft.com/soa/products/oslo.aspx...
Making a new class of model-driven and service-enabled applications mainstream.
Deliver a world class and mainstream modeling platform that helps the roles of IT collaborate and enables better integration between IT and the business. The modeling platform enables higher level descriptions, so called declarative descriptions, of the application.
Ron Jacobs talks about Oslo in this video...
[always interesting to listen to Ron Jacobs but from minute 14 it gets interesting]
Key points of Oslo are:
- Models (Making models a mainstream part)
- Services (Extending services from the client to the cloud -- S+S).
- Integration (Limit the boundaries between Business and IT and within IT departments)
An important part of the vision is that the models exist in the whole lifecycle. So, they not only exist during analyses and design.
Another idea is that all the different models are connected. So, all the different viewpoints [operations, security, application, environment, etc] stay in sync. enable integration. "Enable ALM by Automation" [I talked about this in some previous posts]
Beside this application lifecycle management support with models, there is a focus on S+S application types. Products launched with this concept in mind are also counted under the Oslo umbrella and should also support this modeling vision. For example Biztalk Services [ a must visit link Biztalk Labs ] and the Internet Service Bus.
Some Oslo links:
What is DSI?
DSI is a vision from around 2003, ages ago... 
Microsoft has established the Dynamic Systems Initiative (DSI) to build software solutions that facilitate the movement to the Dynamic stage. DSI describes a vision where IT systems become self-aware and self-managing. From a core technology perspective, DSI is about building software that enables knowledge of an IT system to be created, modified, transferred, and operated on throughout the life cycle of that system. These core principles—knowledge, models, and life cycle—are the keys in addressing the complexity and manageability challenges that IT organizations face today.
Key points of DSI are:
- Knowledge,
building software that enables knowledge of an IT system to be created, modified, transferred, and operated on throughout the life cycle of that system. - Models,
System Definition Model (SDM) provides a common language, or meta-model, that is used to create models that capture the organizational knowledge relevant to entire distributed systems. - Life cycle
Business, Development and Operations by providing integration between the various tools used and activities performed within each of these capabilities.
Some DSI links:
What do have OSLO and DSI in common?
Models in the Lifecycle..!
The Products... [DSI]
Visual Studio 2005 Team Edition for Architects was the first product with designers/ models. The VSTA designers [application diagram, logical datacenter diagram, deployment diagram] where the first implementation of DSL's [Domain Specific Languages] with SDM as language.
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.
SMS and MOM are the other products which supported SDM. SDM later evolved to SML [SML Insight blog].
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.
SCCM2007 SCOM2007 and Windows Server 2008 are also based on SML.
And there are a lot more products with models in it now days, all of them stand alone. During the past Orcas TAP program I worked on some ideas to connect those models.
The products... [Oslo]
Visual Studio "10" is one of the products that's going to support the Oslo vision [see image from Ron Jacobs video].
What can we see in the recent released Rosario April CTP about this? Not much... although, we can see a shift in focus in the architecture edition [more models] and we can see an investments in the modeling tools [designer bus]. We have to wait for other releases to get more implementation details... a visit to Biztalk Labs is interesting to get some ideas around the "Cloud"Services [Identity Services, Connectivity Services and The BizTalk Labs SDK].
Prepare for Oslo.
Not much news around "Oslo"products, but this doesn't have to mean that we have to sit down and wait. The mind-switch, the internal culture are more challenging then the adoption of new development products.
First, developers, operational managers, the business and everybody else involved in software development must starting work together, for example developers and testers [Collaboration between Test and Dev.: Rob Kuijt talks about this, Collaboration between dev. security manager and architects: Creating Secure Services, with Visual Studio Team Architect and the Web Service Software Factory and operational manager]. Seems like an open-door but more challenging then it looks like, because it's mostly the internal culture how people collaborate. This collaboration should first be supported by processes, within Oslo its going to be supported by models.
Second, start working with models there are already a bunch of models available. The mind-switch it takes is big. Architects can start working with Team Architect, developers with the Web Service Software Factory Modeling Edition and other, analysts with CTP 12 UML diagrams, operational managers with SCOM etc etc etc... get experiences. Give some control away to the models...
Third, start take a look at Software + Services / SaaS. Take services from The Cloud go look what you need. For example SLA's are interesting and what kind of capabilities do you need from those cloud services? [ Software plus Services [S+S] vs Software as a Services [SaaS] The Battle ]
Anyway, its an interesting time...
How To Collect Data from the Application Diagram to create WSSF Service Models
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.