More Oslo / "M"

Core premise of Oslo is executable models. today we've been looking into the customization features of Quadrant (the graphical tool part of Oslo)

Three main components


Yesterday I blogged mainly about the M modeling language. Today we'll focus on Quadrant the design tool and the Repository services in Oslo.

High level "quadrant" architecture


Architecture for customizing the shell and service


What we've seen:

  • Quadrant is a flexible tool interacting with diverse data
  • Quadrant uses repository for both specification and state

Let's focus on the repository for now and the different aspects that play a role.

Insight: It good to store more and more of our applications in the database, and to build our applications on top of SQL.

This means that below our modeling language we need to store certain things in our repository.


What specific features should be added on top of the current SQL Server features.


Oslo SDK Provides

  • New models: Intellipas, VS.NET languages
    -  Compile models m.exe, msbuild build tasks
    -  Deploy models mx.exe
  • Once in the database, it's just SQL

How to build applications on top of the repository database

After you've expressed a piece of your model in M you can use mx2edmx.exe to generate an .edmx file for use with the Entity Framework. Below a simple example to consume this data.

class Program
  static void Main(string[] args)
     var context = new MicrosoftPDCEntities(..);
     context.AddFriendShips(new Friendship()
       ContextParty = 124,
       ReferenceParty = 328

     foreach(var f in context.FriendShips)
       Console.WriteLine("{0} + {1} are friends, "f.ContextParty,

Repository core services

  • Deployment
  • Security
  • Catalog
  • Versioning


  • mx.ex packages SQL for deployment to repository nodes
  • Application models van be used to define applications to be deployed


  • Security is claim based
    - Identity becomes just one of several possible claims
    - Claims presented to authorized operations against resources
  • Repository tables keep track of claims, resources and operations
    - Triggers implemented on /t:Repository generated views to check claims
    - Views protect against direct access to tables
  • Domain specific security containers
    - Folders to partition data
    - Applications decide which data goes into what folder
    - Security checks happen on folder boundaries
    - Must call the field folder for compiler to find it
    - Folder ID must exist in the Item.Folders table


  • SQL Server has a catalog
    - List tables views stored procedures etc and adds relationships
  • Repository has its own catalog
    - Adds information about relationship modules, types and extends.
  • Useful for
    - Rich export
    - Impact analysis
    - Enriched SQL data access code generation
    - ..


  • Data change synchronization
    - Between nodes using SQL Server replication and occasionally connected systems
    - Import/export using SQL server change tracking, eg repository<->file system
  • Schema evolution
    - Extend M type and provide backwards compat for old clients w/ computed values
    - SQL server integration services for data migration

In conclusion

  • Repository is optimized for many reads, few writes
  • Contains models for Oslo app domain
  • Can be extended with M
  • Models can be deployed, secured and versioned


Comments have been disabled for this content.