Partager via

My personal View on "Oslo"

  • Article

I want to share my personal view on Oslo with you. It's personal as it might not fully be aligned with the official Microsoft Message.

I will first look at Oslo repository and associated tools to interact with models stored in the repository.

    1. Repository to store metadata (referred to as Model)
    I have been using Microsoft Meta Data Services (aka MS Repository 2.0/3.0) in
    the past for some model driven apps. It serves similar purpose of storing model
    and meta-data company wide. It was used by SQL Server DTS and Visual Component
    Manager (part of VS 6.0). Also one big Software Factory named tangible architect
    uses it for persisting runtime data.

    So what is different in Oslo Repository ?
   First   Oslo Repository   is not   meant only   for  storing   design  data.
    Instead it is meant to store meta-data and possibly even instance that is used
    at runtime, as well (like wise tangible did in the past "miss-use" the Microsoft
    Repository) for that purpose.

    The benefit of using models at runtime is that when you start not generating
    code from models but instead write runtimes that interpret models (E.g. if
    your write a web-shop with product categories make the product categories
    not hard-coded but part of the model).  Then someone (E.g. your boss) can
    change them using a separate interface to your application for administrative tasks.
    I bet you did this already not using any modeling technology. This is probably
    ok, however you have to deal with versioning, multi-user access and Access
    Permissions yourself. Oslo Repository can do Versioning,  Multi-User-Access
    and access permissions for you. Besides Oslo Repository now officially
    supports database mirroring ;-)
   
     2. Oslo Repository API. Oslo Repository uses SQL Views which are made updatable
    by the help of triggers. So you do not need to use a Repository API to access the
    data instead you can use any Data Access Stack like LINQ-To-SQL and just work on
    the Views. Note there is a view for each Class/Type you define in your model.
     In the Microsoft Repository 3.0 days the views did not have the triggers and
     thus were read only.

      3. Oslo Repository Model Definitions

     Repositories store meta-data in form of models. A Model defines types with values
     you want to store. So basically it is a schema. Oslo Models are represented as SQL
     Schemas as shown well  in this video. To define Models Microsoft this time invented
     a new language "M". M can be used to represent Schemas and (Meta-) Data.
     For each "M"-Model there exists a transformation to a TSQL-Schema (as shown here).
     In MS Repository 3.0 this was based on COM Definitions. So we are now going to have
     a real Model Language M which is textual language. Similar to MS Repository 3.0 there
     is a model compiler and a model-inserter tool to be able to create the corresponding
     schema in SQL Server. I hope someone will provide a T4 Transform from .NET DLLs
     to M Models so i do not need to redefine models i already have in M.
     (PS: Note sure if that is a good choice but thinking of it)

     Note, that the Java-based MOF Repository standard defines their models in Java -
     so having that transform would make things comparable.

     4. Model and Instance Data Viewing

     To view and edit instance data Microsoft announced a tool called Quadrant.
     This is a visual tool for interacting with the model on a canvas. Here is a video .
     Besides any application can use the SQL-Views to visualize or edit data in
     the repository.

     5. Dealing with several model formats and creating new DSLs

     As discussed to insert a new schema into the repository one must first
     create a package with the model compiler and then insert it using another tool.
     Microsoft works on providing samples for various known
     models, e.g. the "a" language shows how to import and model ASP.NET ASPX files.
     To allow you to create a bridge from your Model representation to the M language
     Microsoft offers a tool/language called "MGrammer". With is basically a really nice
     parser generator that comes even with a Intelli-Pad that provides basic
     syntax-highlighting for your model instance data. This means if you have
     textual models you want to import into the Oslo Repository then one route
     is to create a MGrammer for your Model. The other route is to write your own
     parser or importer (importers would also work on non-textual formats for sure).

Now let's look at the Vision with "Dublin" or maybe Biztalk Future

As you can see, if you store (meta-)data in the repository you get versioning,
access rights etc for free. You can also enable the Repository to understand
your textual DSLs with MGrammer. You can use any Data-Access Layer.
So basically the Repository is a small SQL-based Layer on top of SQL-Server
from an application view. Your applications as well as Dublin and future versions
of Biztalk could actually read workflow descriptions, workflow instances and other
data from there getting all these features plus scalability for free. In addition if an
administrator or business user decides to change the workflow definition while
the system is running the versioning features will enable you to handle this correctly
within your code. Using Oslo Repository you will end up having less meta-data in XML
or Code and more in a version-enabled, multi-user-enabled, scalable "Oslo" repository.
This will lead to more flexible applications that are easier to change during runtime
- reducing maintenance and administration costs.

Final thoughts on Oslo's repository and executable models

I hope managed to explain the value of the repository. Indeed some advance
applications have been using repository technology for a long time.
Also many ERP-Systems (including Axapta) have a repository inside to manage the
configuration of the system and interpret it at runtime. With Oslo this proven
technique will be come widely available to .NET & SQL Developers. However
there is still some work to do to support many of the model formats including
binaries and textual DSLs that you currently work with. Once this is done Oslo
will become an important component for model-execution, configuration
management and possibly versioned instance data - as it really provides
a lot out of the box by then.

Comments