In case you’ve been stranded on a distant planet or trapped in a parallel universe and hadn’t heard the news, Microsoft unveiled Oslo at PDC last week.
I am a member of the Connected Systems Advisors. In that capacity, I have been actively involved in the Oslo initiative for over a year now, providing the Microsoft product teams with input and feedback as “Oslo” has moved through the development lifecycle. Now, finally, we can speak freely about this exciting set of technologies, an evolutionary change that I feel will affect most developers.
<disclaimer> NOTE: this post is about pre-release software. Change is CERTAIN </disclaimer>
Oslo is Microsoft’s modeling platform, and consists of three parts:
- a repository (SQL Server)
- a modeling language (“M”)
- a visual editor (“Quadrant”)
Most developers are going to have a lot of new things to learn. This is a very ambitious and far-reaching initiative, encompassing many technologies. I think though that people that consider themselves “BizTalk people” will have an easier path, as they’ve already made some of the mind shifts required, but even for them, there’s still a lot to learn.
Fasten your seat belts, paradigm shift ahead…
The new wave of technologies brings with it some changes in the way we think about, construct and manage applications. In my opinion, the top ones are:
- make modeling mainstream
- advance the use of a declarative language
- involve more people in the development process
- make domain-specific languages mainstream
- bring distributed applications to the masses
Let’s look at each of these:
Make modeling mainstream
Generally speaking, models of the past were a static visual depiction, often a UML-ish thing used to ultimately generate code from. In “Oslo”, that’s not the case, the model IS the application. When the runtime is handed a model, it “executes” the model. This is a long way from the static depictions we’ve seen over the years.
Advance the use of a declarative language
For decades now I’ve been a huge fan of data-driven development, and over the years we as an industry have found the true value of metadata. Currently, applications may have some of their logic in code, some bits in a rules engine store, configuration files, stored procedures, etc. Logic can pretty well be sprinkled all over the place, which increases complexity. If instead we made our applications work in a more declarative manner, and kept that data in a single store, then we could reap the benefits of it by creating a new breed of tooling to work with those application. For example, if a runtime knew more about an application, it may be able to make decisions and take actions on how to deploy, scale or recover from errors. With .NET 4.0, Windows Workflow can now be expressed declaratively as XAML, which means we can now use XAML to describe WCF, WF and WPF applications.
Involve more people in the development process
This is something Microsoft has been trying to do for some years with BizTalk. For example, look at the now-deprecated “orchestration designer for business analysts”, and the fact that BizTalk BAM definitions begin their lifecycle in Excel. Although a great attempt, I don’t know how many business analyst types ever used these tools. However, if you look at Quadrant (the visual design tool for Oslo) and the fact that Visio will be able to work with models in the repository, I think this time we may actually get business analyst types involved.
Make domain-specific languages mainstream
The M language has an MGrammar counterpart, that allows the creation of new domain-specific languages. You care about this because it can dramatically reduce the amount of code you need to write, and meshes well with involving business analysts in the process. Analysts using a visual tool would see terms that are meaningful to them, as would IT Pros working with the application at runtime.
Bring distributed applications to the masses
We have all the bits and pieces today that we need in order to build, deploy and manage distributed applications. However, it usually takes highly skilled, and rare, resources to be able to do so effectively. Microsoft aims to change that by lowering the bar on what it takes to do that.
How do I think of Oslo? Oslo is an onion….
Why do I say it’s an onion? It has a core that is surrounded by multiple layers. In Oslo, the core of the onion is two parts: the repository, and the language used to create the models that inhabit the repository. It was when I came up with that mental picture that everything came together for me, so hopefully that will help others.
The repository is the heart of the whole thing. It’s where your applications are defined, and where the assets live that they need to execute. When Oslo ships, it will include a set of pre-defined models, just as we have a class library now in the .NET framework, you can expect to see models with names starting with “microsoft.” or “system.”. So, how populate the repository in the first place? It is after all a series of tables and metadata, we need a way to create and populate the repository with these items.
Outside of this core, we see the first layers of tooling. The PDC VM includes two tools for working with model: Intellipad and Quadrant. Quadrant is a visual tool, whereas Intellipad is a textual editor with enhancements such as syntax highlight and dynamic parsing (development-time notification of syntax issues). If you weren’t at PDC and didn’t get that VM, you can download the Oslo SDK to get Intellipad.
A couple of years back, I saw Don Box give a presentation about models (and he was billing himself as “Chief Modeling Office” at the time, another thing that intrigued me), and he did the whole presentation in Notepad. When I first thought about this, I wondered: why anyone would ever want to work with a textual editor when dealing with something as visual as a model? I was using conventional thinking that models are a visual thing. I am a visual person, when I start brainstorming solutions, it never takes long before I’m reaching for whiteboard markers or firing up Visio. Sure, there could be a textual or binary representation, but that would like be emitted by one tool for another tool to consume. Now that I “get” M however, I’ve completely changed my view. I now expect that at least some of the time, I will be creating models in text. Developers spend most of their days in a code editor, and many like it that way. Why force them to live in a “boxes and lines” visual world? Turns out that the language, and associated grammar, are really useful for other things too, like running it through a “loader” that creates SQL artifacts.
Beyond that, there will be other layers and other tools. Consider the Dublin runtime, it will “pull” a model from the repository and run it. Work is underway with other groups at Microsoft such as the Systems Center folks, whereby they will work with the models in the repository to deploy distribute applications.
Where are we at?
We are at the very early stages of what I think could end up being a fundamental change in the way we design, build, deploy and manage distributed applications. The overall vision is, in my view, brilliant. I stand in awe of what the team has been able to produce over the past year, but I also fear how much more remains to be done. There are no guarantees that they’ll achieve the goals they’ve set, but I am cautiously optimistic that they’ll succeed. No matter what happens, this should be a fun ride, and I suspect I’ll have much more to say about this over the next few weeks/months/years. It’s always a fun time being around building the bandwagon that everyone else will be clamoring to get onto in a couple of years, and… that’s where we are at today in my opinion.