Microsoft Codename "Oslo" Distilled

One of the things that amazes me most about Oslo isn't all of the functionality it provides or the productivity it claims to enhance. No, the most amazing thing about Oslo is the fact that nobody I talk to understands what the hell it is or why they should care about it. Worse, it usually takes me nearly an hour to explain to these people enough about Oslo so that they're convinced one way or the other if Oslo should be on their radar. To me, this is a clear sign that the information available on Oslo right now isn't cohesive enough. Sure there is a LOT of information, including a ton of videos - but the information is all at the bottom level. If you want details of how the underpinnings work or if you want syntax examples then you're good to go. But if you want info on what Oslo is and why you should care, it's harder to find - even if you watch some of the "lap around" videos.

I don't claim that my information will be any more cohesive than Microsoft's, but I'm writing this post as much for my own edification as I am yours. I often gain better insight about things I'm working on by blogging about them or trying to explain them to others.

What is Oslo?

This is, of course, a loaded question. The fact that Oslo appears to be so many things is one of the big problems. In short, Oslo is all about modeling. Not just data modeling in the traditional sense of sketching out ERDs but in the abstract notion of simply creating models. More specifically, Oslo is what I would call a platform for model-driven development. Everything that Oslo has and does is designed to enable developers to do model-driven development.

Model-driven development is what a lot of us do without knowing it. We start with abstractions of the models on which our application needs to operate (whether these models become C# classes or tables in a database is irrelevant at this point). As work progresses the models become more refined until finally we're working with code. Some of the classic problems that come with model driven development are:

• Model Complexity - Not every application is a "Hello World" app. Real-world data-heavy applications have hundreds or even thousands of database tables. Now add to the mixture SOA and exchanging a subset of those models with customers or business partners over web services, through Biztalk, etc and simply managing and keeping track of all of your models can become a burden or even a nightmare.
• Model Versioning - Many environments are extremely rigid and brittle and make it very hard for us to version our models. If we're managing a model domain that is vastly complex (see previous bullet), making small changes to this model often involves weeks of "deployment on our knees" (deployment that involves more praying than deploying).
• Unified Language - Sure, we've all probably used UML for modeling but UML is over-hyped (IMHO) and not everybody understands it or worse, people think they understand it and use it incorrectly. Since everyone seems to have their own unique interpretation of how they should be doing UML ... it isn't very universal is it? Also, 99.9% of all UML tools I've used in the past have sucked.
• Model-to-Code Resistance - In most cases right now, model-driven development can seem like an awful lot of work. People usually give up because their abstractions are nice to look at and they give people a nice frame of reference, but there is often a herculean effort that goes into converting that model into executable code or store-able data. Because of this, people think it's not worth it.
  

Wouldn't it be awesome if we could do model-driven development in a way that allowed our developers, architects, designers, and business stakeholders to all communicate about that model using a unified language? Better still, wouldn't it be awesome if we could take that same shared model, store it in a repository of models that can be re-used throughout an enterprise, and then actually use that model directly to build data, generate code, or even execute the model directly? This is the crux of what Oslo is attempting to do.

What you get with Oslo is the following:

• "M" , the Modeling Language. It's syntax is very simple to read even if you're not a hardcore developer. This means that reasonably tech-savvy business analysts will be able to understand your model definitions even from the text you've written in "M". "M" allows you to define model schemas (types) as well as instances of models (extents). If you are using "M" to target SQL, this means the same language you use to define your table schemas can be used to define the contents of those tables, and it's a hell of a lot nicer to look at than SQL, T-SQL, or PL/SQL.
• "Mgrammar" or "Mg". This is a language that allows you to define your own DSLs (Domain-Specific Languages). A DSL is a language for declaring instances of models or model data. Mg takes a little getting used to, but it dramatically simplifies the process of making a DSL, so much so that people who used to think DSLs were too much work should reconsider that evaluation based solely on the existence of Oslo.
• Model Repository - SQL Server database to allow for storing, versioning, and querying models. Multiple blog posts could be written on this so I'll keep it brief here.
• "Quadrant" - A visual modeling tool written in WPF that allows you to visualize models defined by "M" and stored in the repository.
• IntelliPad - An incredibly extensible editor that you can use to write your models, your Mgrammar languages, and even test your DSL input and output dynamically.
• Visual Studio Integration - quite frankly this sucks (during this CTP) compared to just using IntelliPad and the command-line tools so I don't really have much to say about this.

Why should I Care?

The bottom line is if you build data-heavy applications or applications with large models or you are currently doing your development in a model-first fashion, then you should definitely be looking into Oslo and experimenting with it. I will be showing an example of what this looks like in an upcoming blog post, but the simple benefit of being able to define your model in the easy-to-read "M" instead of writing your own T-SQL directly is a beautiful thing. 

There are other things that are all worthy of their own blog posts like integration with Dublin (Microsoft's new Web Application Server Extensions... think of it as a container for WCF and WF services), using the repository to query and version shared models, and much more.

I've already experienced how different it feels to start with a simple .m text file to define my model. I can see what kind of SQL it would generate on the fly. Once I'm happy with the model, I can put it in the repository. Now if I want to I can create my own Domain-Specific Language (DSL) for defining instances of my models in a way that makes sense to the domain experts, not necessarily in a way that requires a programmer.

Anyway, this is just a quick overview of Oslo... the more lengthy I make this post the more I run the risk of confusing people with too much details too soon. I will be posting subsequent blog posts that go into the details of all the different parts of Oslo that interest me and that will hopefully interest you as well.

tags: oslo  mgrammar  mschema  mgraph  modeling  quadrant  dsl  

links: digg this    del.icio.us    technorati    reddit