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: