My personal View on "Oslo"
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.