It took me several days and a lot of discussions at the PDC to understand the value of “Oslo” and still didn’t get it after the PDC. But, now finally after watching all the session’s / video’s, walking almost all the walkthroughs and after reading the complete documentation, I think I’m there, although still not sure...
The piece what confused me was the first demo at the “A Lap around Oslo” session.
First a little background. Several weeks ago I made a post about different modeling approaches to discus Oslo’s place in the modeling world. The most important feature from Oslo, in that post, is the “Model Execution” part and I was really thinking of this feature like: draw/ write your model and it will be interpreted to running applications on the server. So, where I was looking for at the PDC, what I was expecting “how to make an interpreter for Oslo”.
It even didn’t got more clear after asking the question “What if I want to translate the MService Model [a great example for modeling and executing services] from English to Dutch. The execution/ interpretation will break. So I have to change something in the interpreter… how?”. How can I make my external/ business DSL’s or a translated version of the MService model or a custom internal DSL which executes at runtime? there isn’t any explanation around building an interpreter for my ‘not–out-of-the-box’ model.
It took some mind re-setting to figure out what the value of Oslo is. Finally after a deep-dive in the documentation I found three different Model Archetypes. See picture below…
1. Model Data Aware Application.
The “A Lap Around” demo type which got me confused.
This type is the same as Steve Kelly is writing in his blog:
Overall, it looks like Oslo is primarily just a way to provide configuration information for Microsoft applications
When during that demo the presenters promised that they would be going to build a runtime for the model I was really excited. To bad, it turned out to be an ASP.NET Form with a grid view which reads the XML file that was generated out of the models. For sure it is pretty exciting what you can do with M, MGraph, MGrammer, MSomething and Quadrant but this was a kind of disappointment.
This is indeed something that can be used for configuration of applications. A more interesting scenario is, the company wide use of the same data structure. But in this scenario the business problems are more challenging than the replacing of the Canonical Data Model by Oslo.
2. Model Runtime Aware Application
type 2, get’s more interesting, but very tied scoped.
This Archetype is almost the same as David Chappell uses in his whitepaper “A First Look at WF 4.0, Dublin, and Oslo”.
Step 4 should be skipped for this type, after adding the extra or changed activity to the also changed workflow, the model is updated in the repository. An application which uses this model starts running with this new flow. Workflow uses XAML and this is interpreted at runtime from the repository.
This type makes it easier to change or add flows and other kind of pieces of an application [you could for example make a model, and interpreter for the menubar]. The application understands the by Oslo system provided models. [ and which are interpreted during Runtime ].
This archetype will help with several deployment and maintenance problems of a typical type of business application. Business processes change overtime and the business can change them without the interference of IT people. [Workflow Foundation already has this capability but isn’t used by the business]. I can imagine that overtime more and more interpreters would be available for different kind of ‘models’ and that IT can more and more stitch everything together. Till now it’s very narrow scope, but promising. Although I think Steven still will call it “Configuring Microsoft Applications” ;-) [you are right, it is…]
An interesting scenario for this type, is using the Oslo models together with the Team Architect Models. Probably the models in Oslo are company wide or even worldwide used, it’s a big effort to make an interpreter for these models so they will have a wide uses scope. So, when you can put constrains from the Team Architect Models [your specific solution] what the business can do with the Oslo Models so it still fits your business solution… interesting scenario, maybe later on more on this.
3. Model Interpreted Application
This is the Archetype I expected from Oslo. Define your language, execute it at runtime and use that model on different platforms / runtimes. Oslo, helping with building your own runtime. It is possible to accomplish this with the current bits [maybe not the platforms due to SQL Sever].
Anyway, first let’s start playing with archetype 2. I do think that’s a valuable solution, maybe in conjunction with Team Architect… later on with a self-made model and interpreter. So an other thought about Oslo next to hundred of thoughts already there in the cloud. … cloud? azure? live? mesh? ssds?… everything in Oslo!