Microsoft & .NET.NETExploring the Oslo Repository

Exploring the Oslo Repository

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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,
CONSTRAINT [PK_Applications] PRIMARY KEY CLUSTERED
(
   [Id] ASC
)WITH (PAD_INDEX               = OFF,
       STATISTICS_NORECOMPUTE  = OFF,
       IGNORE_DUP_KEY          = OFF,
       ALLOW_ROW_LOCKS         = ON,
       ALLOW_PAGE_LOCKS        = ON) ON [PRIMARY]
)  ON [PRIMARY]

GO

ALTER TABLE [System.Application].[ApplicationsTable]
   WITH CHECK ADD
   CONSTRAINT [FK_Applications_DefinedInApplication_System.
               Application_Applications]
   FOREIGN KEY([DefinedInApplication])
REFERENCES [System.Application].[ApplicationsTable] ([Id])
GO

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

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

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

Earlier, I alluded to “item.id” working a lot like a TSQL foreign key constraint. In fact, that’s exactly what the M statement is translated into when it becomes TSQL.

I also mentioned that there is no object-orientededness in M. In the M declaration Application conformed to Manageable and DerivedItem. Instead of expressing the TSQL as a complete copy of these other types, the conformity becomes keys matching the keys on the other types.

Folders are a feature built into the Repository. According to the SDK documentation, Folders allow for security and versioning. Folders are arranged in a hierarchy. More general Folders appear at the top and version numbered folders appear at the bottom of the hierarchy.

Collections like “Applications” declared in the System.Application.Application module are implemented in views. The TSQL code appears below.

create view [System.Application].[Applications]
(
[Id],
[DefinedInApplication],
[Folder],
[LifecycleState]
)
as
select top (  9223372036854775807) [AT].[Id]
   as [Id], [AT].[DefinedInApplication]
   as [DefinedInApplication], [AT].[Folder]
   as [Folder], [AT].[LifecycleState]
   as [LifecycleState]

from [System.Application].[ApplicationsTable]
   as [AT] with (readcommitted)
inner join [Item].[ReadableFolders]()
   as [RCV] on [AT].[Folder] = [RCV].[Folder];

The INNER JOIN to Item.ReadableFolders enforces Folder Security and versionining.

At this point, one lingering question is why “create” new tables in the Repository? Why not leverage some existing internal tables and store the data in these tables?

Why Relational?

Creating all of these tables is a lot of heavy lifting to store data in the database. SQL Server includes XML data types; why not leverage the new datatypes? Why wasn’t Oslo implemented using more flexible datatypes?

From what I’ve gathered and what I understand about the XML datatype, there’s one big reason: performance. Relational data can be queried and written faster to the database. Consider how a developer will query and write to the database. Also, reporting tools are tuned to Relational data.

Another reason is enforcement. Relational databases include foreign keys, primary keys, views, and triggers. These are all simple, mature constructs for enforcing scalable data relationships. Plus, often it’s better to enforce relationships in the database rather than forcing some intermediate layer to do the enforcement, especially when you want to open the database to 3rd party tools.

Conclusion

Oslo is Microsoft’s model-driven future. The Repository is one of the many architectural components debuting in the Oslo SDK. M is the Oslo model building language. M is translated to TSQL and the resulting Data Definitions create tables and views in the Oslo Repository.

Sources: Oslo SDK—Documentation and Source Code

About the Author

Jeffrey Juday is a software developer specializing in enterprise integration solutions utilizing BizTalk, SharePoint, WCF, WF, and SQL Server. Jeff has been developing software with Microsoft tools for more than 15 years in a variety of industries including: military, manufacturing, financial services, management consulting, and computer security. Jeff is a Microsoft BizTalk MVP. Jeff spends his spare time with his wife Sherrill and daughter Alexandra. You can reach Jeff at me@jeffjuday.com.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories