Oslo Really is About Model-Driven Development

As I’ve wrote about previously, I’ve flipped the bit on Oslo and I’m currently very excited about the long term prospects for the technology. Like many have wrote about in the blogosphere, I was initially skeptical about Oslo. Seeing the demos for modeling in M types (formerly MSchema) and creating a SQL Server DB for model hydration/dehydration were interesting, but relatively old hat for DDD aficionados like myself (can anyone say NHibernate?). Even the demos around M languages (formerly MGrammar) weren’t necessarily compelling as I am quite familiar with ANTLR and it seemed that Microsoft was just getting into “the ANTLR business”, cool but nothing really to write home about.

Oddly enough, what changed my perception of Oslo were the writings of a thought leader in the UML community – Anneke Kleppe. Anneke has authored a ton of very interesting work about modeling, Model-Driven Architecture (MDA), and software languages. As I’ve mentioned previously on this blog, I’m very much an unrepentant fan of everything UML. From the MOF to OCL to QVT, I’m firmly convinced that the Microsoft development community could make tremendous gains in productivity and maturity if our community full embraced a lot of the advanced thinking embodied in these technologies (which is why I was so heartened to see The Big Show back working with the OMG).

In studying Anneke’s work I started to get very excited by the prospect that maybe the Oslo guys have reached a very similar conceptualization of the model-driven development (MDD)/DSL space as Anneke had through a separate, but parallel, track. Acting on this hunch, I started doing some research into the subject. While M languages is an interesting technology (I’ve since come to realize that it does have advantages over ANTLR in terms of DSL development), it wasn’t a differentiating factor in the research. The use of what Fowler calls External DSLs is a relatively well-know subject in DSL circles and the conceptual link between M languages and the potential of Oslo is relatively intuitive. What I focused on instead was what I think might be the second-most underappreciated aspect of Oslo (where System.Identity is the most underappreciated, IMHO) – M types.

Quite frankly, what I’ve found so far on M types in the blogosphere isn’t that helpful in trying to understand what the long-term potential of Oslo is as a MDD/DSL platform. At the risk of being offensive to the Microsoft development community, I think this may be more a reflection of the relative modeling immaturity of the community than a fundamental disagreement as to what the vision of Oslo (and M types in particular) is. In fact, we at Microsoft may be (at least partially) responsible for this lack of clarity. I offer as an example of this some text quoted directly from the Oslo site on MSDN:

 

“Oslo” modeling platform models remain relevant throughout the project lifecycle. At the highest level, an “Oslo” modeling platform model can be rendered as a graphical representation of a system design. At a lower level, model data includes the schema for system data. A model describes the data structure of a system. When you use the model to create a solution, “Oslo” modeling platform creates a model instance that includes the data that describes the specific solution. As a result, an “Oslo” modeling platform model serves an integral role in the implementation of a system, in addition to its design.

Deploying and managing a solution is much easier when you can model the entire solution, including how the implementations are deployed. A model enables you to conceptualize the solution, even though it may require multiple components on multiple computers. It is much easier to deploy and manage a complex solution that is modeled, rather trying to deploy and manage a collection of components that are built and deployed separately. For more information about deployment and application models, see System.Application.

The use of modeling extends to the runtime, as well; a model can be more than just a static visual representation of the system. A model-aware application – a database-driven application, in other words – can understand models at runtime and execute them if they have the capability. The model can be updated dynamically at each stage of the design, development, deployment, and execution of the solution. The model can ensure that there is no loss of data from one stage to another stage of the project lifecycle. In the “Oslo” modeling platform modeling tools, anyone (with the appropriate permissions) can review the business requirements, implementation, and production status of the application by examining model data. You can determine exactly what is happening with the solution at each stage of the project lifecycle, including production.

 

Whoa! Those of us that are UML aficionados (and especially the subset of those aficionados that are interested in the MOF) recognize this bit of text as having some very profound implications. In essence, the text above can be interpreted that Oslo is envisioned to be a platform for the creation of software-based solutions that rely on executable models (for those that are interested, Executable UML is a conceptually related body of work). Additionally, MOF-heads will recognize that the text above clearly focuses the scope of Oslo on the executable metamodels of software-based solutions.

When Oslo is understood in this light, an argument can be made that we at Microsoft haven’t necessarily done the best job in evangelizing the potential of Oslo. Most of our (meaning Microsoft’s) talks, articles, blog postings, and demos don’t really capture the executable metamodel aspects of Oslo very well. Hopefully this doesn’t come across as an indictment of the Oslo team, because I think the evangelization problem is very tough. What the MSDN excerpt above tells me is that Oslo is squarely aimed at providing very powerful architectural leverage at a high level of abstraction. It’s must be ridiculously hard, if not impossible, to create a compelling 1-hour Tech Ed preso to illustrate this idea.

In a humble effort to be part of the solution to this evangelization problem, I’m hoping that this post (and others I will likely write in the future) will be used as another resource in evangelizing the potential of Oslo - with the end goal of generating some well-justified excitement in the community about the platform.

Along these lines I found a completely illuminating MSDN article on Oslo by Chris Sells that clearly echoes the ideas outlined in the MSDN excerpt above, but does so in more concrete terms. If you are interested at all in Oslo, I would highly, highly suggest reading the article. The article is so compelling because it clearly articulates (to my mind, anyway) something that you don’t see a lot on the Internet – M types (and Oslo) is really focused on providing a metamodeling solution (where metadata is just one type of metamodel). Chris also points out that the use of executable metadata actually has a long history at Microsoft (I offer IDL with COM as an example of this from my own past ;-), so Oslo can be seen as Microsoft just taking these ideas to the next level.

The examples that Chris cites are excellent – especially since they show Microsoft’s acceleration towards, in recent years, executable metamodels. However, at the risk of arrogant presumption (Chris is a far smarter guy than I am) I would argue that there exists another example of Microsoft technology that not only relies on executable metadata models, but better typifies Oslo’s potential long term affect on software development – Microsoft Dynamics CRM (MS CRM).

The MS CRM architecture is built upon executable metadata. Specifically, the MS CRM architecture makes use of a dedicated metadata database in SQL Server that is completely separate from the OLTP database that stores MS CRM’s transactional data. Almost every aspect of MS CRM’s execution is affected in one way or in another by the metadata stored within MS CRM’s metamodel. The centricity of executable metadata within MS CRM has a number of profound architectural benefits:

• MS CRM provides robust data modeling capabilities that allow for powerful custom extensions to the MS CRM OLTP database
• MS CRM provides robust UI generation capabilities for custom entities
• MS CRM provides capabilities for customizing the out of the box data entities, including renaming attributes and adding new attributes
• MS CRM provides capabilities for customizing the MS CRM UI
• MS CRM provides dynamic generation of a web service API, with dynamic WSDL, from metadata – including the addition of custom data entities to the web service API
• MS CRM provides Workflow capabilities to custom data entities added to the system
• The list goes on

The kind of power and flexibility enumerated above has traditionally been the purview of vendor-provided application platforms (for an interesting take on this power and flexibility, see this whitepaper). From my perspective, I would argue that the real promise for Oslo as a platform (assuming my interpretation of the MSDN excerpt above is correct), is that Oslo will operate as a “solution accelerator” effectively democratizing the ability for development teams of all stripes to enjoy the architectural leverage traditionally embodied in application platforms like MS CRM.

In line with this view, I plan to write a number of blog posts over the next couple of months focusing on some of the potential of Oslo from the perspective of executable metamodels. This actually has interesting ramifications not only for software architectures, but also for the creation and usage of DSLs as well.

I figure that’s enough pontification for one day, so I’ll mention that any thoughts (or corrections) on what I’ve talked about here would be greatly appreciated.

 

Post Script [added after initial writing]

So I thought I was on to something pretty profound with this post – hopefully the bit about MS CRM has some value add :-).

However, I found that I’m a Johnny-come-lately to the ideas of Oslo, metamodeling, and MOF linkages. Check out these excellent posts:

https://geekswithblogs.net/cyoung/archive/2009/01/05/128369.aspx

https://geekswithblogs.net/cyoung/archive/2009/04/13/130921.aspx

Comments

• Anonymous
  May 29, 2009
  PingBack from http://asp-net-hosting.simplynetdev.com/oslo-really-is-about-model-driven-development/

• Anonymous
  June 29, 2009
  As someone heavily involved in Executable UML and working on a Model Compiler at the moment, I don't see the link between your idea of "executable models" in Oslo and Executable UML.  Firstly, Executable UML is a general language not a DSL.  It also has an associated method and well defined semantics that involve the relational data model, events and state machines.  A while back I looked at the DSL tools for Visual Studio with a view of implementing Executable UML as a DSL but found the tools inadequate.  Admittedly, my knowledge of DSLs is pre Oslo but I don't believe Steve Cook et al have seen the light yet!

• Anonymous
  July 10, 2009
  The comment has been removed

• Anonymous
  July 18, 2009
  Hi Dave, In this context, I would pitch a Model as simply being an abstraction of system (I’m using the dictionary meaning of “system”).  An Executable UML model has nothing to do with software as such and you don’t need to refer to programming concepts during the process of abstraction to build it.  Having made that point quite strongly, I have to mention that we do use an Action Specification Language (ASL) for some parts of the model, but I don’t consider this as programming!  Writing ASL is at a higher level of abstraction than programming because it deals with the behaviour of model entities, in the same way as programming C# works at a higher level of abstraction than machine code. Originally, ASL did not exist and we used diagrams (ADFDs which worked like Petri Nets) to show the behaviour.  This was in the days of the Shlaer-Mellor (Executable UML is based on the Shlaer-Mellor Method).  Writing ASL to describe behaviour came in when it became apparent that ADFDs were too cumbersome.  Of course, you could argue that writing ASL is programming but I prefer not too because I’m not working in the software domain. I seem to be rambling on bit so I’ll stop here. Regards, Mike

• Anonymous
  July 21, 2009
  Apparently Mike was experiencing some trouble posting comments to the site, so I took the liberty of including it here: Just to conclude... The point is that when creating an Executable UML (xUML) model, program building concepts no longer apply and that a different skill set based on analysis (abstraction) is needed.  This is why I find "The Model is the Code" and "The Code is the Model" type slogans very irritating.  They may be true in a way but they're just not very helpful.  Perhaps it’s an attempt by analyst's to make modelling appeal more to programmer's! I'm sure Oslo's and xUML’s intents are very similar, after all we all want to get to the same place.  But where does the real analysis take place in Oslo?  I may be a little rusty here as far as DSLs go, but I understand someone has to specify and create the DSL for users so they can specify the instances they want to design with.  So the questions in my mind is how do you analyse and design for a DSL and how does Oslo make it possible and hopefully relatively easy?  The trouble is I don't think creating a good DSL is going to be easy, especially for all the new users that will want to try it out.  If it’s not handled well it could turn out badly.  Is this where the xUML method (developed over the last 20 years) might be able to help?  This a very interesting question to me. Anyway, I look forward to find out more about Oslo and getting my hands on a copy in the future.  It must have improved significantly since DSL tools for Visual Studio appeared several years ago.

• Anonymous
  July 21, 2009
  The comment has been removed

• Anonymous
  July 31, 2009
  Hi Dave, Thanks for the comments in your last reply and generally having a very interesting discussion. I’m intrigued by “executable metamodels” above.  Why not simply say “executable models” (like xUML!).  These metamodel levels are all relative anyway.   IIRC doesn’t DSL put the application code down at the M0 instance level (using the OMG’s metamodel level notation)?  While the code at the M1 level is used to generate the actual M0 level model?  Like I say, it’s been some time since I played around with DSLs. I really wouldn’t know where to go for the definitive definitions of the terms Model Driven Development (MDD) and Model Based Development (MBD).  My general understanding of MDD is that it is any development that uses models.  So Oslo and xUML are both types of MDD.  MBD is not a term I’m particularly familiar with but I would say xUML is not equivalent to MBD (type of, perhaps). Regards, Mike