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]:
TechEd News - UML on tap in Oslo SOA modeler
Not that I'm at the TechEd US, but just read this article "Outgoing Bill Gates says UML on tap in Oslo SOA modeler".
Two quotes:
Microsoft will incorporate UML as part of its effort to create its Oslo unified modeling environment for SOA, Chairman Bill Gates told attendees at TechEd 2008 for Developers in Orlando, Fla.
The company also confirmed that it expected the first Oslo Community Technology Preview (CTP) would be released at the PDC in September. Gates also disclosed that UML will be part of Visual Studio 10. The reappearance of the general-purpose industry standard UML for modeling in the flagship products in Microsoft's developer line comes after several years of emphasis on special-purpose Microsoft-brewed DSLs, or Domain-Specific Languages.
We already know UML is in Rosaro "Visual Studio 10 2010 ;-)", but still haven't heard anything about the connection betweed Oslo and Rosario...
I'm curious what he really said...
DSI, OSLO and Models in the Lifecycle. Get Prepared..!
OSLO vs DSI vNext.
There is lot of buzz around Oslo and it looks like all the ideas around this concept are completely new. But when you take a look at the vision behind Oslo it's not that new, it's acutely the next step to maturity of Microsoft's Dynamic Systems Imitative [DSI] from a few years ago.
What is OSLO?
From http://www.microsoft.com/soa/products/oslo.aspx...
Making a new class of model-driven and service-enabled applications mainstream.
Deliver a world class and mainstream modeling platform that helps the roles of IT collaborate and enables better integration between IT and the business. The modeling platform enables higher level descriptions, so called declarative descriptions, of the application.
Ron Jacobs talks about Oslo in this video...
[always interesting to listen to Ron Jacobs but from minute 14 it gets interesting]
Key points of Oslo are:
- Models (Making models a mainstream part)
- Services (Extending services from the client to the cloud -- S+S).
- Integration (Limit the boundaries between Business and IT and within IT departments)
An important part of the vision is that the models exist in the whole lifecycle. So, they not only exist during analyses and design.
Another idea is that all the different models are connected. So, all the different viewpoints [operations, security, application, environment, etc] stay in sync. enable integration. "Enable ALM by Automation" [I talked about this in some previous posts]
Beside this application lifecycle management support with models, there is a focus on S+S application types. Products launched with this concept in mind are also counted under the Oslo umbrella and should also support this modeling vision. For example Biztalk Services [ a must visit link Biztalk Labs ] and the Internet Service Bus.
Some Oslo links:
What is DSI?
DSI is a vision from around 2003, ages ago... 
Microsoft has established the Dynamic Systems Initiative (DSI) to build software solutions that facilitate the movement to the Dynamic stage. DSI describes a vision where IT systems become self-aware and self-managing. From a core technology perspective, DSI is about building software that enables knowledge of an IT system to be created, modified, transferred, and operated on throughout the life cycle of that system. These core principles—knowledge, models, and life cycle—are the keys in addressing the complexity and manageability challenges that IT organizations face today.
Key points of DSI are:
- Knowledge,
building software that enables knowledge of an IT system to be created, modified, transferred, and operated on throughout the life cycle of that system. - Models,
System Definition Model (SDM) provides a common language, or meta-model, that is used to create models that capture the organizational knowledge relevant to entire distributed systems. - Life cycle
Business, Development and Operations by providing integration between the various tools used and activities performed within each of these capabilities.
Some DSI links:
What do have OSLO and DSI in common?
Models in the Lifecycle..!
The Products... [DSI]
Visual Studio 2005 Team Edition for Architects was the first product with designers/ models. The VSTA designers [application diagram, logical datacenter diagram, deployment diagram] where the first implementation of DSL's [Domain Specific Languages] with SDM as language.
The Dynamic Systems Initiative (DSI) is a commitment from Microsoft and its partners to help IT teams capture and use knowledge to design more manageable systems and automate ongoing operations, resulting in reduced costs and more time to proactively focus on what is most important to the organization. The System Definition Model (SDM) is a key technology component of the DSI product roadmap that provides a common language, or meta-model, that is used to create models that capture the organizational knowledge relevant to entire distributed systems.
Quote from System Definition Model Overview White Paper.
SMS and MOM are the other products which supported SDM. SDM later evolved to SML [SML Insight blog].
The model-based management functionality in Windows Server 2008 is based on Microsoft's System Definition Model (SDM) version3, which provided the basis for the Service Modeling Language (SML) proposal and submission to the World-Wide Web Consortium SML Working Group.
SCCM2007 SCOM2007 and Windows Server 2008 are also based on SML.
And there are a lot more products with models in it now days, all of them stand alone. During the past Orcas TAP program I worked on some ideas to connect those models.
The products... [Oslo]
Visual Studio "10" is one of the products that's going to support the Oslo vision [see image from Ron Jacobs video].
What can we see in the recent released Rosario April CTP about this? Not much... although, we can see a shift in focus in the architecture edition [more models] and we can see an investments in the modeling tools [designer bus]. We have to wait for other releases to get more implementation details... a visit to Biztalk Labs is interesting to get some ideas around the "Cloud"Services [Identity Services, Connectivity Services and The BizTalk Labs SDK].
Prepare for Oslo.
Not much news around "Oslo"products, but this doesn't have to mean that we have to sit down and wait. The mind-switch, the internal culture are more challenging then the adoption of new development products.
First, developers, operational managers, the business and everybody else involved in software development must starting work together, for example developers and testers [Collaboration between Test and Dev.: Rob Kuijt talks about this, Collaboration between dev. security manager and architects: Creating Secure Services, with Visual Studio Team Architect and the Web Service Software Factory and operational manager]. Seems like an open-door but more challenging then it looks like, because it's mostly the internal culture how people collaborate. This collaboration should first be supported by processes, within Oslo its going to be supported by models.
Second, start working with models there are already a bunch of models available. The mind-switch it takes is big. Architects can start working with Team Architect, developers with the Web Service Software Factory Modeling Edition and other, analysts with CTP 12 UML diagrams, operational managers with SCOM etc etc etc... get experiences. Give some control away to the models...
Third, start take a look at Software + Services / SaaS. Take services from The Cloud go look what you need. For example SLA's are interesting and what kind of capabilities do you need from those cloud services? [ Software plus Services [S+S] vs Software as a Services [SaaS] The Battle ]
Anyway, its an interesting time...