where developers meet development
Friday,October 18,2019


Designing Data-Driven Applications with Microsoft Introducing Microsoft's new modeling platform

Picture Holder1

What is Oslo? Oslo is a code name for a new  modeling platform for building data driven applications. Oslo consists of three major pieces:

  A modeling language: M

  A modeling and data visualization tool: Quadrant

  A repository: SQL Server

This paper will focus on a small piece of Oslo, the M language.

I have been learning something new about Oslo every day. My company, Telerik is building some cool Oslo tools for Microsoft and I am designing them. I have to deliver the spec for the first tool to the programmers next week, so I have been hard at work. I thought it would be cool wrote about how I learned Oslo while building this tool, giving you the ability to learn from my many mistakes. (You can get Oslo, along with M and the repository here: msdn.microsoft.com/oslo.)

The M language is very exciting. M is actually a little like XML and XSD. Meaning that you never do anything in XML, you create an XML grammar (XSD) to give your XML some meaning. M ships with two tools to give your M some meaning: MGraph and MGrammar. (Note: this paper will focus on M only, not the repository or Quadrant.)

With Oslo you will create an M grammar using MGrammar; MGrammar a contextual DSL creation language.  MGrammar will convert your users or applications’ input (the users of your DSL) into MGraph. MGraph is a JSON-style M syntax that will allow you to put data into an instance of your M type.

I won’t go too deep into MGrammar here, let’s use one DSL that ships out of the box for Oslo: MSchema. MSchema  is a DSL for TSQL DDL or data definition language. If you learn MSchema, you don’t have to deal with TSQL “CREATE TABLE” ever again. (For some of us this is a good thing.) MSchema is just one of many M grammars that will ship with Oslo, others will include MService, a DSL for working with WCF in C# and VB.NET.

I will model parts of the application with MSchema and then map some data to that MSchema using MGraph. When it is all said and done, I will create database tables and views and sample data from my M code. (M will transform all that from my MSchema/MGraph code to SQL Server databases and data.) This database and metadata will be put into the Oslo repository.

The Application

I will not give all the details of the application here, not because it is super-secret, but because they are still evolving. Also I want to focus more on the process I took and the M code itself. In a nutshell, we are building an Oslo repository comparison tool with an M visualization engine as well as a data migration piece. Sorry to be vague, but only the first sprint or two are clear in my head, future sprints and versions will include a Visual Studio 2008/2010 plug in, a repository migration wizard, and a contextual DSL using MGrammar. We are building the repository comparison piece in the first few sprints and I will discuss it here.

The purpose of the repository comparison piece is for a developer who has modeled an application and transformed the MSchema and MGraph code into the repository and a runtime (such as .NET) is interacting with that metadata and the repository. Now the developer wants to make changes to the repository (version II of their app) by writing some more M code. The first feature of this tool will compare the old M to the new M and point out the inconsistencies. (I am starting with some basic stuff to get my feet wet.)

Modeling the Application


I was approaching this design process the wrong way. First I was writing up some initial user stories and then started to model the domain around those stories using various tools (mostly on paper) so they can be translated into requirements for developers on their first sprint.  I was building a tool for Oslo, but I was not using Oslo. So I started over and did this the Oslo way.

I still started with a user story, but to accompany the user story, I started to model the domain using the M language. I am not sure if this is the right way to be completely honest, but it felt like the right thing to do since imho, it will be easier for the developer to understand these user stories and then estimate them and move them to the product backlog. It feels like a modified version of Scrum and DDD, but I am far from a purist.

While you are suppose to do the design as part of the sprint, I don’t think that modeling a few domain entities is a true design, I expect the team on the first sprint to completely refractor this (via M) as more issues and requirements come to light. Of course I am not the typical user to write a user story. I don’t expect users to know M, so maybe in the real world where the user doesn't know M, a developer will do the M code to accompany the user story, or do it as part of the sprint. As I play more with Oslo, this process will become more clear to me. I suspect that there is not going to be a right answer, it will be a matter of preference.

Anyway, the first thing that we need is an entity to deal with the users of the application. So I fired up a tool that ships with the Oslo SDK: Intellipad (or iPad) and I used MSchema to define a type called “ApplicationUser.” The type is defined below.


//MSchema to define a user type

type UserType


    UserID : Integer64=AutoNumber();

    FirstName :Text#15;

    LastName : Text#25;

    Password : Text#10;      

} where identity UserID;



This is the most basic of types, but I figured I would get my feet wet with an easy one. (And besides, I am lazy.) I am defining the fields that will make up the user type, just using the most basic ones now (I am sure that the developers will add more later on.) I defined UserID as an AutoNumber (identity), FirstName as a 15 character text field, LastName as text 25, and password as text 10. (Yea, yea I know I should use a hash with a random salt, but this app does not need rock solid security.)

What I like about Oslo is that by defining the type here, I am giving the developers my intent. While they will most definitely rename, refactor, and reorganize this before it goes into production, they know the intent, the application will have a user and that user can log in with a password. I think this is more natural for a developer to work with (since it is code!) than boxes and lines or a formal written spec, or at least compliments those traditional artifacts nicely.

Now I need an instance of this type. I only can truly get a grip on my type once I put some data into it. This is where other modeling platforms fall down for me. Once I play a little bit with the data, I realize my model is wrong, and I go back and add to it.

To add some data, I need to use MGraph. To me, this seems like a collection of User Types, so I named it the most logical thing that came to my mind: ApplicationUser. Not sure if this is the best name for this collection or not, but hey, I am learning and I know this will be refactored by me a few times before it is refactored by the developers many times. So I will leave it this way and see how it evolves.

To create an instance of my User Type, I need to tell M which type I am binding to with this syntax: ApplicationUser : UserType*;

Think of UserType as the class and ApplicationUser as the implementation or the instantiated object. Not an exact analogy, but it should give you a feel. I can also bound another instance like so: SuperUsers: UserType*;  however, we only need one instance.

I won’t go too deep into how MGraph works, since Shawn Wildermuth has a great 3 part series on MSchema and MGraph here: http://wildermuth.com/2008/12/28/MSchema_An_Example_-_Part_1. Just notice that MGraph takes on this format:









Here is the implementation of my type:


//MGraph to get some test data in

ApplicationUser : UserType*;




     //using a named instance (Steve, etc)

     Steve {





     Vassimo {





     Zarko {





     Todd {







When this is all compiled by the M parser, this will be transformed into TSQL INSERT INTO statements into my table, the table that was defined in my User Type. We don’t have to worry at all about TSQL and SQL Server now since all we are doing is modeling the application in MSchema and MGraph. We won’t bother converting this to TSQL now, since I guarantee it (the M code) will change soon. Since I am at such an early stage of the design phase and I only modeled one simple entity (and not even a domain entity for that matter, all applications have users), I am just going to save this file to disk via iPad.

Generating TSQL


Now it is time to transform our M code into TSQL. To do that we have to enter iPad and choose from the menu M Mode|Generic TSQL Preview and iPad will show this:


create table [Telerik.MigrationTool].[ApplicationUser]


  [UserID] bigint not null identity,

  [FirstName] nvarchar(15) not null,

  [LastName] nvarchar(25) not null,

  [Password] nvarchar(10) not null,

  constraint [PK_ApplicationUser] primary key clustered ([UserID])




And the insert statements are also generated:


insert into [Telerik.MigrationTool].[ApplicationUser] ([FirstName], [LastName], [Password])

values (N'Stephen', N'Forte', N'Telerik');

declare @Telerik_MigrationTool_ApplicationUser_UserID0 bigint = @@identity;


insert into [Telerik.MigrationTool].[ApplicationUser] ([FirstName], [LastName], [Password])

values (N'Vassil', N'Terziev', N'123');


insert into [Telerik.MigrationTool].[ApplicationUser] ([FirstName], [LastName], [Password])

values (N'Svetozar', N'Georgiev', N'456');

declare @Telerik_MigrationTool_ApplicationUser_UserID2 bigint = @@identity;


insert into [Telerik.MigrationTool].[ApplicationUser] ([FirstName], [LastName], [Password])

values (N'Todd', N'Anglin', N'789');


I ran the entire TSQL and then the next step is to load it into the database.


I opened SQL Management Studio and created a new database called oslotest1 as shown here:

create database oslotest1



Now I will copy and paste the TSQL in the preview pane of iPad and run it. Success!


In this article you have seen the absolute basics of an Oslo DSL: MSchema. Whatch for other Oslo DSLs to come out and you have the ability to create your own DSLs using MGrammar. Stay tuned.


Stephen Forte is the Chief Strategy Officer of Telerik, a leading vendor in .NET components. He sits on the board of several start-ups including Triton Works and is also a certified scrum master. Prior he was the Chief Technology Officer (CTO) and co-founder of Corzen, Inc, a New York based provider of online market research data for Wall Street Firms. Corzen was acquired by Wanted Technologies (TXV: WAN) in 2007. Stephen is also the Microsoft Regional Director for the NY Metro region and speaks regularly at industry conferences around the world. He has written several books on application and database development including Programming SQL Server 2008 (MS Press). Prior to Corzen, Stephen served as the CTO of Zagat Survey in New York City and also was co-founder of the New York based software consulting firm The Aurora Development Group. He currently an MVP, INETA speaker and is the co-moderator and founder of the NYC .NET Developer User Group. Stephen has an MBA from the City University of New York.

Register to DeveloperMarch

Be part of DeveloperMarch and get updates on upcoming events. Youcan register with the form below:

Job Title*
Phone Number*
Confirm Password*
E-mail address:*
Your Details:
Your name: *
E-mail address: *
Software Supportby Advanced Millennium Technologies

Advanced Millennium Technologies. Expertise in software development, offering consultancy services, Open source programming, CRM - Customer Relationship Management, CMS - Content Management System , ERP - Enterprise Resource Planning and Ecommerce development, AJAX, PHP, .NET, J2EE, SOA, XSLT, DOJO toolkit development and software testing. A robust onsite-offshore model. A well-defined global delivery model. AMT Outsourcing center. www.amt.inTAROBY - The E-Mail Dashboard for EntrepreneursTaroby is a SaaS based messaging and collaboration suite inbox that enables sharing of email accounts among team members. The unique concept of 'Team Inbox' makes Taroby an excellent enterprise collaboration suite for enterprises. Taroby is an effective tool for CEO's and entrepreneurs to manage multiple departments or manage multiple projects under them. The team inbox gives the entrepreneurs an overview of what is happening their business and give a quick snap shot of the employees who is responcible for handling the tasks/emails. For team members taroby brings in transparency and efficiency in their teams. Taroby improves the internal and external communication in an organization. Using the Taroby's Team Inbox also helps in reducing the usage of disc space and there by helping the enterprises to reduce carbon footprints.