As Microsoft's program manager in charge of the "Oslo" Developer Center on MSDN (since merged with the Data Developer Center http://msdn.microsoft.com/data), you'd naturally have every reason to expect that I wholly "get" what all this "Oslo" stuff is about. After all, I acquire, publish, and manage the DevCenter content that's intended to tell the "Oslo" story. [It's now called SQL Server Modeling, by the way, as we've retired the "Oslo" name.]

I must confess that this is actually not the case, at least not yet. Frankly, I still ask myself—quite often, in fact—just what's it's all for and what, in fact, someone really does with it--with the whole of it. Like many people, I can see how certain pieces like the "M" toolchain are useful in and of themselves (writing nifty languages and such), but when you start talking CLR and UML domains or "middle-tier" applications, I'll listen politely while trying to pretend my eyes aren't going glassy.

To my credit, this state of affairs is actually by design, which gives me a perfect opportunity to bore you with the backstory of how, after a hiatus of around 12 years, I found myself back at Microsoft and eventually working on "Oslo." People are going to ask about this anyway, so…well, OK, originally I wrote that whole section right here, conveniently forcing you to indulge my penchant for storytelling. But charity won out in the end and I moved it into its own piece.

So like I was saying, this present state of affairs is intentional. Since the beginning of February, when I officially began this role and could at least differentiate between Microsoft code name "Oslo" and a city in Norway, much of my time has been consumed in just getting my bearings on the project while keeping the DevCenter reasonably fresh. Combined with the demands of the "Oslo" May CTP and my wife's recovery from abdominal surgery, it was only in late summer that I was able to delve into a serious learning project of my own.

My hope is that this effort will lift me out of the slums of ignorance, so to speak, and in the process lay a path for other developers (and mind you, this particular post is just a start, not the complete story). For as much as being embedded in a team that eats middle-tier for breakfast (and effortlessly speaks of app servers, repositories, and domain-specific languages with every breath) makes me at times feel quite alone, it's certain that I'm not. Many developers are surely wanting to slake their thirst for understanding, even while they skillfully feign competence. (But that's OK. We're friends and I promise I won't rat on you.)

This journey must needs begin with what I already understand: desktop client applications. Admittedly, this isn't the sweet-spot for which "Oslo" is intended—indeed, not entirely the sweet spot for the larger data-driven application realm into which "Oslo" is merging (see "On 'Oslo'" by Douglas Purdy, who is my present manager). Nevertheless, working in this space will take us through many essential concepts about modeling software that will be applicable to applications at whatever level. Such is my motivational leap-o'-faith, a leap that should at least start form a stable foundation.

O Brother API, Where Art Thou?

The other essential question to answer from the outset is something that myself and many others have been confused about for a long time: just what, exactly, does Microsoft expect developers to do with "Oslo"? This is something we've been hearing over and over again since PDC 2008. While the presenters did a great job explaining what "Oslo" is (a language, a repository, and a visual tool, yada yada), the big picture just wasn't clear. What kinds of applications does one build with "Oslo," exactly?

Now again, with Douglas Purdy's forewarning that "Oslo" is merging with Microsoft's whole "data programmability" technologies, "Oslo" will no longer be an isolated reality. Still, there is a little historical ground to make up here.

You see, a big reason why the point of "Oslo" has been confusing is that Microsoft, at the 2008 PDC, positioned "Oslo" as a platform. In doing so, and by virtue of offering an "Oslo" SDK, Microsoft implicitly suggested that "Oslo" introduces certain capabilities for an application to exploit. That, after all, is what "platforms" do. However, as you dig around in the "Oslo" documentation with the shovel of such assumptions, you start to wonder: where's the API for those capabilities? Please, please, tell me just where O where is the API?

The honest truth is that you're hard pressed to find any API at all. What you find instead are, well, the same things that everyone keeps talking about: a language, a repository, and a visual tool. (The only place you find an API, in fact, is in the "MGraph Object Model" that supports dynamic parsing of a domain-specific language (or DSL), if you happen to grok what that's all about yet).

Recognizing this problem—recognizing, that is, that a goodly portion of the developer community has been trained to salivate over a new platform like the quintessential Pavlovian pooch—Microsoft has recently been positioning "Oslo" not as a platform in itself, but as a set of modeling capabilities for an the already-existing .NET platform. That is, instead of "Oslo" introducing new capabilities for applications to use, it's introducing a new and hopefully more powerful means of authoring .NET applications.

The Point of "Oslo"

This means that there is no such thing as an "Oslo" application, per se. Get this into your head right now. Repeat it rhythmically until you enter a superconscious trance: there is no such thing as an "Oslo" application. There is only .NET.

"Oslo" applications, in other words, are .NET applications, and maybe also middle-tier/enterprise .NET applications with Pixie Sauce, but in the end, it's all just .NET. Nothing more. .NET apps. Believe it.

(Actually, believe this more: .NET is the official story because most people do .NET these days. Fact of the matter is, however, that any code, .NET or otherwise, that can pull stuff from a database can benefit from "Oslo" technologies. So whether you have a new .NET application talking to a SQL Server database with LINQ to Entities or a legacy Win32 application using OLE DB, the "Oslo" can still be applied.)

This is why the so-called "SDK" for "Oslo" really only contains a toolset (the "M" compiler, "Quadrant," and "Intellipad") that looks, tastes, and smells more like Visual Studio and SQL Server Management Studio rather than, say, a set of redistributable assemblies and related API documentation. No one ever talks about a "Visual Studio" application: they talk about .NET applications. "Oslo," like Visual Studio, is a mean to an end; once you've reached that end, it pretty much disappears from anyone's awareness.

The basic point of "Oslo," then, at least as I understand it, is to provide an end-to-end system for designing, describing, implementing, deploying, executing, and maintaining applications using nothing but "models," which is to say metadata (comprised of both model schema and values/instance data) that describes all aspects of an application's behavior and functionality. "Oslo," in short, is a way to create and manage applications while writing only a fraction of the code (if any). How convenient!

Of course, something, somewhere, at some point has to translate that metadata into the stuff the underlying platform understands. Having a bunch of metadata sitting in the "Oslo" repository or some other database is neat to look at, sure, but so is the Weather Channel. As different presenters kept saying at the 2008 PDC, the real action happens when some "runtime" comes along and "does something interesting" with that metadata.

Sans Runtime, Life Has No Meaning

I don't know about you, but the more I watched those PDC sessions, the more I started to understand that this "interesting" part was simultaneously the most critical element in the whole story and yet the one that hardly anyone actually talked about. Curious, yes, but sometimes the bricks and lumber are so engaging that folks can forget about the house they're building. That is, having the ability with the "M" language toolchain to pop off DSLs with no more effort than writing a grammar is pretty darn hot, kinda like having universally configurable custom-brick factory. Yet for all that, you still end up with just bricks.

Let's talk about those runtimes, then, because for as much as DSLs and tools like "Quadrant" get metadata into the "Oslo" repository (or some other database), that metadata only turns into a working, useful application when there's some runtime to do that exact job. A runtime, in other words, directly "executes models" (which is to say, model instances or values) by translating them into whatever form is needed by the next layer down in the system. This is just like MSIL in .NET. MSIL by itself is only "executable" because of the existence of the .NET Common Language Runtime (CLR) that knows how to translate MSIL into whatever form is needed by the next layer down, which is to say the API of the operating system (which in turn is a runtime that translates those API calls into machine instructions).

XAML works the same way, and is actually a closer analogy for "Oslo". By itself, XAML is meaningless; it only has meaning in an environment with the Windows Presentation Foundation (WPF) runtime. Fortunately, because the WPF runtime has been integrated into the.NET platform, directly, XAML assumes the status of "native code": a running application can be written and even modified in XAML on the fly without any intermediate compilation steps. As far as the developer is concerned, XAML doesn't have to be converted or compiled into another form before feeding it to "the platform." Sure, the platform internally is converts XAML to MSIL which the CLR then converts to machine code, but we don't have to care about that. We can just write XAML and be done with it.

Thus the simple "Oslo" story is very similar: once models and values are in a suitable repository/database, a suitable runtime within the operating environment gives those values the status of "native code." And again, those values can describe both application data as well as behavior depending on what the runtime is capable of doing.

All that said, it bears mention that "Quadrant" itself can and will increasingly serve as a suitable runtime where the "application" you're interested in is all about viewing and editing data. And let's face it: there are a whole lot of applications that do nothing else. So Microsoft does envision "Quadrant" to be the host environment for such things, where its configurable and composable viewers, its "query-everywhere" design, and custom commands all let you do some pretty neat stuff. (And will probably continue to be more so as the product matures toward its first full version.)

Configuring Generic Engines

Now these runtimes can be written using any platform technology that knows how to get stuff out of a SQL Server database. The good part is that the runtime need only be written once by a small number of people, after which many, many more people can realized increased productivity by cranking out applications for that runtime. Indeed, a 10x productivity boost is one of the big promises of "Oslo".

For a single application, it's probably a pointless exercise to write a specific one-shot runtime just to deal with application-specific models. Why not just write the app and be done with it? (I think there are reasons, but I haven't thought about them.)

What's more valuable is to create a runtime that effectively implements a class of applications, where each specific application is wholly defined by metadata alone. That is, the runtime is a kind of generic application engine for that class. One essentially configures that generic engine with specific metadata to thereby produce any number of particular, custom "applications" (you know, the thingies that are visible on the screen that users poke at all day). From this one realizes a significant productivity gain in comparison to writing each such application from scratch.

I already mentioned "Quadrant" in this capacity, which is a kind of universal visual editor that is again (and will increasingly be) configurable to suit the needs of specific domains. Eventually it will support many kinds of capabilities for working with models visually, again in a generic way that can be customized. Thus instead of having to write your own visual tools for some specific domain from scratch, most of the work has already been done for you. (That's at least the idea; how "Quadrant" appears in the May 2009 CTP is really just the beginning foundation as much more work remains to fulfill this vision.)

Other parts of "Oslo" seem to follow the same philosophy. The "M" toolchain is really a universal language compiler that only needs to be configured with an appropriate "grammar" to process virtually any kind of input and turn it into a standard output graph. This easily saves 90% of more of the work that's typically involved in dealing with textual DSLs.

"Intellipad," too, is a kind of universal textual editor that can be configured with different "modes" and customized using Python scripts.

Even the "Oslo" repository (the use of which is optional) follows this pattern. The Base Domain Library (BDL) is intended to provide a generic, baseline, enterprise-ready database, saving you the trouble of starting from an empty SQL database and building out such capabilities yourself. Other "Oslo"-provided domains such as the CLR and UML domains are also meant to supply features and capabilities that will be widely useful. (With these domains, in particular, they mean that you don't have to figure out how to model CLR metadata, for instance, or create a loader to "shred" CLR assemblies and stuff their data into the repository. That's what the "CLR domain" has already done for you.)

But again, apart from "Quadrant," most of this is pretty well focused on getting metadata into the repository in the first place. But it's really a runtime that turns such metadata into a working application if the application is beyond the scope that "Quadrant" can support.

O Runtimes, Where Art Thou?

Now the big problem at present is that, well, there really aren't any runtimes out there to work with! Microsoft knows this, and knows that the "Oslo" story isn't complete without them. The expectation is that a number of runtimes will become available over time for various application classes. Microsoft is working on some, yes, but what it means at present is that seeing the whole end-to-end "Oslo" story means writing your own runtime.

Thus in pondering my own end-to-end learning project, it must revolve around a runtime.

Plan for My Learning Project

Now there is already an end-to-end sample, Spork, which involves a textual DSL to create model instances and a runtime engine to turn those instances into a working application. I'm planning to do something similar with my own learning project, but I also want to make sure I also involve "Quadrant" along the way. I'm also planning to document every stage of this project so you can see the incremental steps instead of just the completed project.

Now "Oslo" is really oriented around domain-specific development. That means I have to find some domain to work with. Given that I'm starting from the baseline of desktop client applications, this really means thinking of some class of applications that I can create through a generic runtime that's configured through metadata values.

For simplicity's sake--which means keeping all this within a scope I'm capable of handling at the moment--I'm going to create a domain around calculator applications. It's simple, yet has great potential for exploring many facets of "Oslo" including the modeling of behavior. I'm also doing it for historical reasons, to complete a grand circle in a way. Unless you happened to open its About… box in Windows 95 or earlier, you may not know that I wrote the Calculator applet that started shipping with Windows version 3.0 in 1990 and has continued to run all the way through Windows Vista (for that backstory, see Chapter 2 of my memoir, Mystic Microsoft). Only in Windows 7 is it finally replaced with a completely new program.

Calculator was the third Windows program I ever wrote and also my first real learning project for Windows programming, way back in 1988 during my first internship at Microsoft. (Never did I imagine it would have a 20-year lifetime and find its way to well over a billion machines!) It only seems fitting, then, to launch another cycle as my first real project for learning "Oslo". Let's be clear, though, that I harbor no more ambitions or dreams of wild success than when I cranked out the first version of Calculator in a couple of weeks. But I won't mind if they pick this up for Windows 8!

That said, here's how I figure things will shape up, which I give with the obvious caveat that everything is subject to change:

1. Put together a .NET clone (more-or-less) for the existing Windows Vista Calculator program (four-function mode only). This program will serve as the basis for the project and allow us to see how functionality and behavior (layout and mathematical operations) are inherently "modeled" in native .NET code structures (XAML and C#).
2. Translate these code-based "models" into data structure models. This step is really essential at this point because everything in a model-driven environment, by definition, revolves around the models! Rather than there being an API against which to program, models serve as a kind of Application Declaration Interface (call it an ADI) against which one programs declaratively via a visual tool or a textual DSL of some kind, which we'll get to somewhere down in steps 5-7.
3. Upon the advice of Rockford Lhokta to "start with the runtime," create a generic runtime that will execute some sample values for the data-structure models in #2. At this point those values will exist only as in-memory structures to validate the model designs, allowing for rapid iteration to get the models right. Involving a database at this point would be an unnecessary complication.
4. With the basic models worked out, create model schema in "M" for this metadata and load that schema into a database along with a custom icon so all shows up nicely in "Quadrant."
5. Create a suitable viewer customization in "Quadrant" oriented around the specification of a calculator application using the models.
6. Use the viewer in step 4 to create values that collectively define a simple four-function calculator application.
7. Define a simple textual DSL to accomplish the same goal as #6, which is to populate the database with metadata that wholly describes a specific calculator application.
8. Using that DSL, define model instances for a calculator with some additional capabilities (like scientific functions). This is then again given to the runtime from #6 to produce the working application. This may—and this is intentional—require modification to the original models from #2, which will give us the opportunity to explore versioning questions.

Like I said earlier, because all this is a learning project for myself, I plan to document the entire process--the thinking as well as the intermediate results. And I'm sure that by the time we get to #8, we'll see more opportunities to take the example still further, especially if another "Oslo" CTP is available at that time with some new capabilities.

In closing, all I can add is "Thank God for 'No-Meeting Wednesdays'" as we have within the "Oslo" team. If I truly stick to this observance—as my manager (until recently) Chris Sells has been pressing me to do so I can specifically work on a project like this—I should have much to share in the weeks and months ahead. Stay tuned.