Three Model Archetypes for Oslo…
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…
So after
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!
Oslo’s place in the modeling world…
A lot of news-sites published yesterday an article around Oslo … probably there was a journalist event in Redmond ;-)
A short summary:
- Codename ‘D’ is rename to ‘M’ --- creating textual DSL’s. [inside Visual Studio]
- There is a Software Modeling Tool called ‘Quadrant’ --- author models visually [outside Visual Studio].
- The models can be executed directly on the platform --- work with multiple runtimes.
- Model repository, model transformation --- [SQL Server]
- Not in place yet models for ‘non-functional requirements’ like security, performance, operations, etc etc.
The modeling world – Models in the Application Lifecycle
I often use these images [below] to organize the discussion that is going on in the modeling-world according to UML vs DSL. It gives some direction where we are talking about when discussing ‘Modeling in the Application Lifecycle’.
Models in the Application Lifecycle - A brief explanation…
First ALM…
Application Lifecycle Management is about the whole spectrum of software development, the processes that are used, the people who use it, make and maintain the applications and about the tools and technology that are used during the complete lifecycle. Application Lifecycle Management is not only about software development and a grown-up development environment but also about business, operations and the connection between these domains.
Second, Domains…
The models used to define the problem should be independent from any technology, you can re-use them with other technology and on different platforms. Models in the solution domain describe how the problem is solved, so when those are technology / implementation independent you can re-use them with other technologies, for example generate C# or Java and WCF or ASMX. Together with technology independent these should also be platform independent so the effort to create these solution models can be used on different platforms and the models or code can be executed on different platforms [runtimes].
- Problem Domain: Business specific – technology /platform independent.
- Solution Domain: Solution specific – implementation / platform independent [is this true? not always]
- Runtime Domain: Platform specific
The Modeling-World and Oslo.
It's a very simple overview and not complete but gives a nice view of the different modeling approaches available at this moment .
| Domain Specific Languages [business, vertical, external] |
|  A language used by the business / domain experts to describe their ‘problems’ [needs], the models can be used to generate code or can be executed on the platform.
Can be done with dedicated DSL Tools, like MetaEdit and the Microsoft DSL tools or with UML the MDA way [UML as DSL with Profiles]. Examples:
At Sogeti we made several DSL’s like this [with the Microsoft DSL tools].
MetaCase does a great job in this modeling segment.
Haven’t got any experience with tools who use model execution [Google give some result]. Would Oslo fit in this approach with model execution? I think at this moment and when I read all the articles according to Oslo I would say it better fits the next modeling approach [vertical, internal DSL]. |
| Domain Specific Language [technical, horizontal, internal] |
|  A language used by developers / architects / designers to model the solution domain.
There are already a lot of languages in place in this segment. Not all of them are technology independent [most of them only make the use of a specific framework easier]
Examples: WSSF ME, Regular expressions, SQL, WF, DFO, WiX… and many more Example with model execution: OSLO
|
| Unified Modeling Language |
|  As I call it ‘plain old UML modeling’… UML diagrams like Use Case and activity Diagrams are used during defining the business domain.
Solution design is done with UML component diagrams and/or Sequence diagrams. The red arrow is a kind of validation of the solution design, replay the scenarios described in the problem design [use case realizations]… Other UML models, like class- and sequence diagrams are used to model the implementation domain. technology independent but implementation specific. Tools Examples: Visio, EA… some have a kind of code-generation. |
| Hybrid UML–Internal DSL Approach |
|  UML –> model business domain / capture requirements and ‘high level’ design -- ‘design’ validation with scenarios. [the same as the previous approach]
Implementation design with many different internal DSL’s and / or model transformation from solution design to implementation design with model transformation / connection Top Red line: Runtime validation with testcase generation from the business domain models. [<—I like this one] Example: Rosario Team Architect, although not everything is in place [Yet?!]… to realize this. You can add OSLO as an example to this modeling approach, VS2010 is part of the OSLO ideas and with Oslo’s model repository and TA’s Designer Bus you get an interesting combination or overlap? ‘Blueprints’: because the new factory imitative gives the use of small specific ‘internal’ languages a mature infrastructure, although I'm curious how this is going to work with the model repository and the designer bus... |
You could add an other one a hybrid External DSL – UML approach, but haven't seen that one and can’t find examples.
Steve Cook just wrote an interesting post “UML and DSL” what could give the modeling space an other approach or view.
To resolve these issues long-term I think we need a new architecture for modelling languages in which the false distinction between UML and DSLs would evaporate. Widely used languages would be standardized; new languages could emerge and evolve; different languages could be loosely-coupled yet interoperate.
Do I miss something? does this summary of available modeling approaches make sense?
Also interesting division are the different modeling archetypes defined by Forrester [see this webcast], I’ve added the modeling-approaches to it.
- Model Driven Development (MDD)
- Domain Specific Languages [business, vertical, external]
- Model Assisted Development (MAD)
- Domain Specific Language [technical, horizontal, internal]
- Hybrid UML -- [internal] DSL Approach
- Lightweight Visual Modeling (LVM)
- Unified Modeling Language
At this moment I would put Oslo in the MAD [funny abbreviation] section although I think it also should be in the MDD part. Anyway, haven’t read everything about Oslo and I don’t know the details.
Now we have to wait till the PDC so we can find out if it works and if the division I made is right…
10-10-2008 News Items about Oslo [also the birthday of Abel]:
