.NET Developments

Apr 6 2009   7:13PM GMT

Clarifications on Microsoft’s Oslo, M

Yuval Shavit Profile: YuvalShavit

When I complained last month that we haven’t seen enough of Microsoft’s Oslo to know what it is, Microsoft responded.

To recap: my gripe with Oslo — and specifically its programming language M, which is the most concrete part of Oslo we’ve seen so far — wasn’t that it isn’t useful. M lets developers build out domain-specific languages (DSLs) relatively easily, and that’s obviously handy. But a new language to define DSLs does not a SOA platform make, I argued.

Microsoft’s answer: Oslo isn’t about SOA; it’s about modeling (hence the “M”). SOA is one of the domains that Microsoft anticipates could be helped by Oslo, but the terms are not synonymous, said Burley Kawasaki, director of developer platform product management at Microsoft.

The problem with data modeling as it exists today is that everyone has their own way of doing it, which means nobody can talk to anybody else, Kawasaki said. Even within a given company, different groups may model data differently, which makes the handoff a pain point. Microsoft’s vision is to unify data modeling in the same way that XML unified markup.

For instance, frameworks like WPF and Spring are increasingly using metadata to build portions of applications, Kawasaki said. That means developers have “a whole bunch of mini Oslos,” each modeling and executing its own metadata; it’d be like each application writing its own XML-like specification and the tools to use parse and write it.

The biggest thing XML has going for it is that it’s a standard. If you’ve got an XML document, it’s trivial for me to read it, manipulate the data, and spit it back to you in a way you understand. That’s what Microsoft wants Oslo to do for modeling, and it wants M to be the workhorse behind the scenes.

Microsoft’s vision is to be able to actually compile and run the model, just as WPF compiles XAML and turns it into a program’s UI. That ensures that the model changes as the project goes forwards, instead of just being printed out and forgotten among a stack of papers. That’s what M and its compiler do.

But that gets us back to the original issue: we haven’t seen that kind of pervasiveness from Oslo yet. Microsoft has shown us how to use M to develop DSLs, but that’s a far cry from using it to build standardized, useful, easily transferable models.

That goal depends on three building blocks, said Kris Horrocks, senior product manager for Microsoft’s developer platform team:

  • a common way to represent models
  • a common way to store them; and
  • a common way to display and manipulate them

M addresses the first of those steps, and the Oslo repository — currently SQL Server — addresses the second. The third will presumably be the role of Quadrant, the GUI model editing tool that Microsoft has announced but not yet demoed.

But beyond the technical building blocks, Horrocks said, is industry adoption. After all, you can’t address a lack of standardization just by throwing another contender in the ring. To that end, Microsoft has included M in its open specification promise, and it’s encouraging developers to get a head start by downloading M, playing around with it and possibly even contributing to the project.

2  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • JohnIMM
    Technology to map and update models would definitely be a huge advantage, provided the original data models are business data models and of a high quality. Too many people now use the term "data model" when what they are actually talking about is a database schema. They are not talking about attributes, entities and relationships but about tables, columns, primary keys and foreign keys. This is not a business data model but an implemented instance of all or part of such a model. There can be many such implemented instances - one for each application in a business - and all would be different. There is a logic chasm here that developers who describe their databases as "data models" are unaware of: You can derive a database from a data model but you cannot derive the original data model from the derived database. You could make many assumptions as to what it should be but they would be merely assumptions. So, if technology such as Oslo is to be of real use, it must be able to work on business data models and map entities, attributes and relationships, etc. Otherwise all it will do is accelerate database design further and further away from the underlying business data models that it is meant to be supporting.
    0 pointsBadges:
  • Vfedorchenko
    I still cannot find an answer for a question why MS Oslo ignores a lot of standards and tools that already present (starting from XML-family mentioned in the post, and finishing by existing OMG standards like MOF, XMI, QVT etc). Another questionable thing is OSLO repository: using RDBS for it (SQL Server for now) seems not very good idea (for instance all popular version control systems like SVN work with files only). And final question is learning cycle. Model driven development still far from mainstream; introducing absolutely new specifications (M-generation) will only increase 'entrance' barrier. BTW, XML-based DSMs could be used in easy (as for me much more easily than CTP Oslo) way right now with only knowledge of XML/XSL. My [A href="http://code.google.com/p/nreco/wiki/Models"]XML-based DSMs[/A] are stored as usual files so I have no problems with version control; from other hand, they may be indexed as usual text files / or using models semantic for organizing fast search in the repository. You may be interested in the DSM framework I've talked about: open-source project named [A href="http://code.google.com/p/nreco/"]NReco[/A].
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: