Random thoughts on how "Oslo" is going to affect the every day life of an developer on the Microsoft platform...
I've been pondering abit on how this "Oslo" business is going to affect me as a developer, in what ways will it change the way I architect and implement the applications I'm working on? I'm sure that this will be a journey that will take a while and surely will result in further postings on the subject.
The eminent mister Aaron Skonnard has written a looong and very well written article Introducing "Oslo" that I recommend that you read. I will not go into that detail but rather skim the surface and inject a few of my own reflections on how this will affect me as a developer.
"Oslo" is a modeling platform that consists of three things:
A Language called "M" used for authoring models and textual DSLs. I think Don Box summed it up is pretty good as usally in his presentation of the language at PDC08.
He states that is a language about data, in fact the process of capturing, schematizing and transforming data. He also clearly states that "M" is not a object oriented language and neither a replacement for T-SQL.
"M" actually consists of three parts: MSchema which is what you use to schematize your data, MGrammar lets you create textual DSLs and finally MGraph which is what is the compile result of the input to the "M" compiler.
A tool called "Quadrant for interacting visually with models. This is a very slick WPF based application which is extremly customizable. It looks very nice but it feels a little bit like drowning :) when you start using it.
Hopefully this will be easier to work with when it release since some of the slides at the PDC08 hints at different SKUs are to be made avaiable but I am speculating here so don't hold me acountable :) the once mentention where:
Quadrant Web Editor (ASP.NET)The way you work with "Quadrant" is to create workspaces of infinite size that are zoomable (a really cool feature is to popup a model element to the foreground, letting you work with a part of the model while have a nice overview picture of the complete model). The vision behind this is to be working with large wall mounted multitouch screens in the conference rooms (remember Minority Report, we are not that for from this now).
Quadrant Service Editor (WCF/WF)
Quadrant Entity Editor (Entity Framework)
Quadrant Schema Editor (SQL/XML)
A Repository for storing and sharing your models. The vision is that most products from Microsoft will use the repository for storing their configuration data and such, first out is the new application server "Dublin" and then in future versions System Center and Team Foundation Server has announce that they will move towards using the repository.
So to be able to start talking about what we can use this model driven platform for we kind of need to define what a model is, or atleast what Microsoft are talking about in regards to "Oslo". You can categories models into three general categories:
Models for communication, this is typically you boilerplate UML diagrams of your applications that you produce upfront and often then forget about. The main thing here is to communicate intent when creating your software and bridge the gap in between users and developers.
Models assisting development, pretty much when you take the communication models and generate code from this. Serves as a great kickstart when working with greenfeild development but in my personal experience the efforts that went into reverse enginering of code into model and vice versa (like in tools such as Rational Rose) never really succeded altough people keep trying.
Models driving development, this is about declarative programming and there is a whole slew of examples such as HTML, CSS, XAML, BPEL, .NET Attribute, .NET Configuration and COM+ to name a few. This is the space where Microsoft wants to change the way we do software with "Oslo".
A few examples of applications that are model driven (or data driven if you prefer it) you can look a Microsoft Sharepoint and Microsoft Dynamics. Both these applications are all about customization and they are driven by a repository containing their models. You have most likely written something similar yourselves (I know I have) maybe not on the magnitued of Sharepoint but still model driven applications are not really not that uncommon. The definition of model in this context is that the way the application looks and functions is driven by a model in some form of a repository).
That's enough background for now, what are we gonna do with this Oslo stuff then? Well for one thing we will be using it all over the place when working with various microsoft products. It's not going to change our everyday situation as developers very much since we will continue to work in pretty much the same fashion as previously, but there are a whole new range of integration possibilities that opens up once we go for the central repository with the models both for us and for Microsoft.
I can see three areas of usage for the everyday developer using Oslo today:
Modeling our domains in a more friendly fashion and then use the complier to generate the SQL statements needed to create the database. One thing that will be a challenge with this however would be dealing with none greenfeild development and evolving your schema overtime. From what I have seen so far these areas are yet to be solved fully.
One really nice feature here would be the fact that we can really easily create a textual DSL for working with the domain that our users could understand and use for populating the needed configuration data, we might be able to simplify data entrance to such a degree that writing a maintenance client wouldn't be needed. I seriously doubt that this would work for more complex data, but it is still an intressting idea since we could infer compliance through the DSLs syntax and thus prevent corrupt data from being inserted.
Simplify and automate development, this is an area where "Oslo" really shines. Since it is so easy to create a textual DSL and with the available framework that we are provided with we could easliy create an simplified version of for instance WiX (which is in itself is an abstraction over MSI) adding yet another layer of abstraction over the installation process.
Altough you can almost always speed up development or solve a tough problem using another layer of abstraction there is one drawback with this approach and that is the fact that the more layers of abstraction the more power over the details we loose. Thus abstracts like these pretty much always leads to homogenity across an domain which is good for performance but bad for innovation.
I can personally see a bunch of places that we can use "Oslo" in our own frameworks we have build at my work. In these situations we strive for homogenity and speed of development and really the reason for not rolling your own little DSL is the sheer costs assosiated with writing compilers and such.
Drive our application with models, this is the most intresting one in my oppinion. I remember an application that I wrote back in 1998 where we wanted to produce a dynamic user interface based on templates (we even went the extra mile to build a template designer as well) using java and reflection and even though this was a very fun ride it cost alot of money to implement. Had we done this targeting "Oslo" and WPF instead it would have been a breeze in comparision you can check out Josh Williams post Using MGrammar to create .Net instances through Xaml for a really cool example of dynamically producing XAML using a textual DSL.
Erik Wynne Stepp also wrote a good post on the subject of dynamic interfaces and the impact of "Oslo" which is a good read as well.
If you want to get more information about what "Oslo" is about you can watch and read the following material:
"Oslo" Developer Center
A Lap around "Oslo"
"Oslo": The Language
"Oslo": Repository and Models
"Oslo": Building Textual DSLs
"Oslo": Customizing and Extending
the Visual Design Experience
First Look at M – Oslo’s Modeling Language
First Look at Quadrant - Oslo’s Modeling Tool
MGrammar in a Nutshell
MGrammar Language Specification