Exploring the Oslo Repository

Oslo will be Microsoft’s new Model Driven Development platform. Oslo’s success will depend on many factors, but must begin with some foundational architectural decisions. In particular, technology decisions must be made for building and storing models.

The Microsoft Professional Developer’s Conference (PDC) introduced Oslo to the world. If you’ve seen any of the PDC Oslo sessions or read anything about Oslo, you’ll quickly realize that Oslo is composed of a nontrivial number of working parts. There are parts for viewing models, new languages, and a database housing it all. This article centers on the role of the model storage database called the Repository. Using models shipping with the Oslo SDK, the article will show how models are stored in the Oslo Repository.

Oslo Explained

A complete introduction to Oslo is beyond the scope of this article. Refer to the Sources section at the end of the article. Still, some context is important to understanding the role of the Repository.

Model-driven development has existed for years in the guise of markup languages such as HTML. In Model Driven development, a tool creates the markup and a runtime executes against the generated markup. In the HTML example, an HTML editor creates the HTML code and a browser (runtime) interprets the HTML.

Oslo will carry model-driven ideas further. It will encompass not only XAML models like WCF and WF, but also model information devoted to platforms like System Center Operations Manager and roles like the Systems Analyst.

Oslo can be decomposed into the following components appearing in Figure 1.

Source: “Microsoft PDC 2008—A Lap Around Olso”

Figure 1: Oslo Architecture

  • “M”, a language for composing models
  • A Repository for storing models
  • Quadrant, a tool for editing and viewing model data

Currently, Quadrant is only available to PDC attendees, but M and the Repository come with the Oslo SDK available on the Oslo Developer Center site http://msdn.microsoft.com/en-us/oslo/default.aspx. As I stated earlier, I’m going to focus on how Models work with the Repository. I’ll start by outlining my approach.

Approaching the Repository

Studying sample code is often the best way to understand how something was intended to be used. The Oslo SDK ships with some preassembled models as well as some tools for building and loading the models into the Repository.

Using these tools, I’ll show you some of the preassembled models written in the M language. Then, using the tools I’ll load the models into the Repository and, finally, show how the Repository stores models.

Before I explore the Repository, I thought I should emphasize that Oslo is currently in CTP. So, documentation is often scant and tools can be quirky. Also, much of what is presented here will, no doubt, change or be abstracted into tools like Visual Studio.

A model called System.Application.Application is easily grasped by a developer, so I’ll focus the model portion of this article here.

System.Application.Application Model and M

Intellisense Work Pad (Intellipad) ships with the Oslo SDK. Although you can theoretically develop models in Notepad, Intellipad is M aware. As with Visual Studio, you can view and edit multiple source files in a project.

Product.mproj in the Models folder inside the Microsoft Oslo SDK program files folder contains all of the preassembled models. Figure 2 shows Intellipad and the Product.mproj file.

Figure 2: Product.mproj in Intellipad

M is composed of MSchema, a syntax for defining models, MGraph a syntax for defining model instances, and MGrammar a syntax for creating your own modeling language. A complete introduction to M is beyond the scope of this article, so I’m only focusing on how M gets translated to TSQL and is then loaded into the Repository.

As I mentioned earlier, the best way to understand a model in M is to look at a sample. If you’ve ever built a database in TSQL, designed an XML schema, and done any C# development, M concepts and structure will be familiar to you. Following is sample code from the Application.m sample.

module System.Application
   import System;
   import System.Management.Lifecycle;

   export Application;
   export Applications;

   Applications : Application* where
      item.Id in SoftwareComponents.Id,
      item.DefinedInApplication in Applications,
      item.LifecycleState in LifecycleStates;

   // A composite SoftwareComponent or "software system".
   // Composed of a deployment and a management unit.
   type Application : Manageable, DerivedItem
      DefinedInApplication : Application?;



According to CTP documentation, the components contained in the module System.Application: “represents a “Software System” composed of SoftwareModules and other Applications. An Application is a deployment and management unit.”

The “parts” of System.Application.Application are broken down into their particular M components as follows.

  • M code is contained in a Module. Modules are groupings of related things. Module naming works similar to namespaces in C#. If you explore other pieces of code, other .m files are located inside System.Application modules.
  • The import statement works a lot like the using statement in C# or the import statement in VB.NET. Export is similar to a public statement in C# and VB.NET.
  • “Application: Application*” declares a collection of type Application.
  • “item.Id in” works like a Foreign key declaration in TSQL.

“type Application :” would appear to be creating a type inheriting from other types, but that’s not the correct way to interpret this. There is no inheritance in M. Rather, the syntax declares a type that conforms to or “looks like” the Manageable type and DerivedItem type.

The “?” after Application simply means that the DefinedInApplication Field can be set to NULL. The concept is similar to declaring NULL after a TSQL column declaration.

For a more complete introduction to M, the SDK documentation is pleasingly thorough. The “documents” folder in the SDK directory contains many M resources.

With a taste of M and background on a sample model, I’ll turn to how the model gets loaded into the Repository.

From M into SQL Server

The Repository is a SQL Server database. Making Repository a SQL database creates a number of opportunities for developers. SQL Server has quite a few reporting, querying, auditing, recovery, scalability, and “data” features. Putting model data in SQL Server allows a developer to leverage these features.

The Repository includes some base supporting table and views.

Models are compiled to an intermediate format “.mx” file and loaded into the Repository using the MX.EXE utility. Some typical MX.EXE command line usage appears below.

mx /i:models.mx /db:Repository /s:ServerName

The M model code is translated into TSQL, creating all the supporting tables, views, and keys in the Repository database. The resulting TSQL code for the System.Application.Application model can be viewed in Intellipad and some of the TSQL appears below.

CREATE TABLE [System.Application].[ApplicationsTable](
   [Id] [bigint] NOT NULL,
   [DefinedInApplication] [bigint] NULL,
   [Folder] [int] NOT NULL,
   [LifecycleState] [bigint] NULL,
   [Id] ASC
)WITH (PAD_INDEX               = OFF,
       IGNORE_DUP_KEY          = OFF,
       ALLOW_ROW_LOCKS         = ON,


ALTER TABLE [System.Application].[ApplicationsTable]
   CONSTRAINT [FK_Applications_DefinedInApplication_System.
   FOREIGN KEY([DefinedInApplication])
REFERENCES [System.Application].[ApplicationsTable] ([Id])

ALTER TABLE [System.Application].[ApplicationsTable]
   CHECK CONSTRAINT [FK_Applications_DefinedInApplication_System.

ALTER TABLE [System.Application].[ApplicationsTable]
   ADD DEFAULT ((100)) FOR [Folder]

Modules are expressed in the TSQL Schema. In the example above, the Schema is System.Application.

More by Author

Must Read