04/08/09 :: [MOP] Where is Oslo Going? [permalink]
I had an interesting discussion about Oslo with a reader, Sándor Nacsa, in the wake of my post on .Net RIA Services on InfoQ. Sándor provides plenty of new links about this Microsoft project. What is clear is that now Oslo is only about "modeling", SOA and Composite Applications are simply areas where Oslo can be applied. That's a bit different from the original announcement on the project in the fall of 2007 and pieces like "Dublin" seem to have fallen off Oslo which is now only 3 elements: a metadata repository, quadrant and the M language.
Before I start commenting on these new links, I'd like to make my position very clear. When it comes to MDD, MDE and MDA I support an approach that I call "Metamodel Oriented Programming" (MOP).
MOP is an approach which seeks to create a programming model independent of architecture such that architects can architect and developers can build the solution in an architecture independent way. This is in line with projects like Microsoft Volta which talked about "Architecture Refactoring" concepts. Incidentally Volta has disappeared from the face of the earth, what a shame. MOP is not about creating a single programming model, but again, rather an approach to separate architecture(s) from programming model(s). I, of course, focus on SOA and Composite Apps, but as a good software engineer, I believe that anything I do is so general MOP can be applied to anything...
So let's talk first on the approach that the Oslo team is taking to drive its direction and requirements. If I understand it correctly, they are using "FTA"
what is it? ‘FTA’ stands for Federated Task Assistant, which could just be descriptive enough to tell you what it does, but probably isn’t. So, let’s start from this premise: you have a bunch of tasks you have to perform, from a bunch of sources and as parts of many bigger things. For example, I need to order a new credit card because my current one’s magnetic strip is failing; I need to write people’s reviews because it’s that time of year; I have to write a blog entry on ‘FTA’; I have to ensure my wife’s rather substantial list of tasks for me is at least partially addressed, and so forth. Some of these tasks are personal, some are work-related; some get tracked through other systems (like our internal bug tracking system, our HR systems, TFS, and so forth) and some get forgotten if they don’t get tracked (well, for me, that’s most things).
IMHO, it is not a good start. If you build something like Oslo you start with a programming model like .Net RIA Services or anything you want that tries to do the same thing and then you build Oslo to make it easy(ier) to build something like .Net RIA Services. In case you have not noticed MOP has already happened, all the annotations in Java or C# is MOP layered on top of OO. But MOP layered on top of OO does not provide a clean separation between Architecture and Programming Models. This is the mission that Oslo should set itself up with. So starting with an "app" is, of course, a traditional Microsoft approach. But this is the wrong level. This is actually catastrophic to start at this level, it ensures they will never deliver something at the MOP level. What our industry needs today is not a better way to write code snippets or string templates, it needs a way to express business logic in a sustainable way, i.e. outside a given architecture.
Sándor provides another link on "Oslo Q&A". It is probably Doug Purdy who is answering these questions. After a little bit of blabla
Oslo” will help provide greater levels of agility and productivity by greatly simplifying the development of applications.
They seem to understand the problem that MOP addresses as they talk about "Visibility into Distributed Solutions".
“Oslo” will bring together a connected view of today’s models, which are often built in vertical, isolated silos.
But frankly I am a bit scared by this sentence, MOP is not about stitching together the programming models across the layers of an architecture, MOP is the other way around, it is about creating and deploying a unified programming model onto all the layers of an architecture (whatever this architecture is, SOA, WOA, EDA...). MOP is a much safer bet when you look at how efficient our industry has been at delivering stable architectures that last more than a Gartner business cycle.
So when you combine, blabla, an out of the gate flawed approach and an undefined shipping date ("We are not disclosing the release schedule at this time."), I don't see why I would spend any time on Oslo.
If you want further signs that Oslo seem to be going completely off track I'd like to point out that:
a) Oslo can't eat its own dog food: "EF and EDM are important technologies for Microsoft. “Oslo” full embraces EF/EDM as a primary mechanism for “Oslo”-based runtimes to access the repository. "
b) Doug Purdy touts 10X improvement as a great achievement, he obviously has not done any homework on what IT needs and Cloud Computing provides today in terms of a programming model that abstracts architecture and provides already 10X or more
c) "M lets developers build out domain-specific languages (DSLs) relatively easily" is no longer the problem, Microsoft has DSL tools for that, the question that the Oslo team should ask itself is does M stands for Model or Metamodel?
d) It seems that the Oslo team is heavily (and emotionally) involved in REST, actually let me rephrase that, involved in both lo-REST and CRUD-REST. That's pretty pathetic for a team that think they are working on models. One of the key foundation of MDE is precisely to avoid CRUDing at the programming level.
I would conclude, that yes, the direction of Oslo is fairly clear based on all the links you provided, sadly, this project is focused on solving problems that people have already solved and completely missing the mark on MOP.