I’ve been bloging some about my experience using and playing with different parts of the Oslo stack on projects and articles. I’ve gotten a couple of reactions as to why it matters.  I have covered some of it in my article series that focuses on DSLs and developers here:

• Part 1: http://msdn.microsoft.com/en-us/library/dd441702.aspx
• Part 2: http://msdn.microsoft.com/en-us/library/dd548006.aspx
• Part 3: http://msdn.microsoft.com/en-us/library/dd789404.aspx

But there is a bigger picture here that I want people to get their heads around: Models Matter.

As many of you know, I used to go by “The ADO Guy”. When I started to look into Silverlight and Oslo, I didn’t leave my ADO Guy at the door. I always tried to let people know that it was data (not necessarily databases) that inspired my love of development. Oslo is a natural extension of that.

“Why? Because Models Matter.”

First, what is a model. A model (to me) is simply the description of shapes of data that represent real objects. You can call them domain objects if you like or business objects, but they are still just models of real world counterparts. We have had models in our code for years (or for me…decades), we just didn’t try and name them that.

“If we know what a model is, how does that relate to Oslo?”

Oslo empowers models in our development. It allows us as developers to focus on building models that drive applications and platforms. So much of what we do as developers is try to deal with user input. We’re collecting it, reporting against it, merging it, changing it, etc. But that’s because we think of all data as end-user visible data.  In fact data and metadata is all data. Some is used to define and drive how an application behaves and some is the data that our applications are written to work with.

“How does Oslo empower models?”

Oslo is made up of three basic pieces:

“M”

“M” is a language (or languages) that allow you to describe data. This may be in the form of structure (MSchema), maybe in the form of instance data (MGraph) or maybe in the form of human language (MGrammar). These languages enable the creation and storage of data in a variety of forms (only one of which is database data). “M” is how we define our models (with MSchema and MGrammar).

Repository

The repository is a database(s) that allows for models to be stored. These models can be readily related to each other (which is why storing it in a Relational Database is important). The models in the repository represent metadata (as well as data).

Quadrant

In many ways this last piece of the Oslo stack is the one that pulls the whole notion of Oslo together. Unfortunately its also the one that hasn’t been much available to play with (the PDC preview didn’t allow you to view your own types so it doesn’t count). Quadrant is a viewer of models in your system (meaning the Repository). Quadrant is an editor that is primarily used to change system parameters, not necessarily end-user data (though you could see that it might be used in some scenarios for just that). Quadrant allows you to define your own visualizers/editor for data that is in the Repository. This does imply that enterprises that embrace Oslo may decided to use Quadrant to handle their IT roles instead of writing a number of tools and dashboards that fill the same need. The expectation (though this is based on what I’ve seen publically) is that writing visualizers or editors should be much easier than writing a number of standalone apps or a web dashboard.

Putting It Together

The Oslo stack is made to work together (though you can get a lot of benefit using part of the stack). So in a usual case, lets assume that we use “M” to build a set of rules that define a business need: salesman commission calculation. Then we store those rules in the Repository. Also in the Repository are models that you are already familiar with, the .NET Framework types. So in the Repository are types like a System.ServiceModel.OperationContract. We might define a new contract in the Repository that includes our rules and tie it to a new endpoint that exposes that contract to retrieve our rules.  This doesn’t mean that we’ll always use Repository-based WCF Services, but it provides a mechanism to make our applications completely driven by models. To change these related elements in the Repository, you may edit those models in the Repository.  Change the model, the system changes. Its a live connection between the two. And our rules that were defined with “M”, now living in the Repository, could have an editor/visualizer in Quadrant to allow the Sales Manager change the rules about commissions as (s)he changes it or even makes one-off deals with certain sales people. (Which, if you haven’t had to code a commission calculatork, you haven’t lived.)

By modeling your application from top to bottom, you can create systems or applications that can evolve without necessarily having to do a full-cycle build everything, test everything, deploy everything. It approaches the concepts of modularization is a huge way. It allows us to think about and test our systems is an extremely loosely coupled way.

Oslo is a high-risk, high-reward gamble for Microsoft (and me). If Oslo succeeds, it will fundamentally change the way we think about building systems. We can be intentional about our designs and know that systems change. We will cease ‘encoding’ intent into code, but allow models to contain today’s ‘intent’ and let it mature like the rest of the system. This isn’t about making programming easier, its about making systems more flexible.

What should you be doing about Oslo? Watch it mature. Download the SDK and play with the bits. Build a simple DSL and understand why that’s important. When Quadrant ships, start thinking about how you can leverage it. We’re at the point where you probably don’t need to build systems with Oslo, but if you want to be ready when Oslo is, keep your eyes open and read the progress.

What do you think?