04/13/09 :: [MOP] M3 [permalink]
This is such an interesting discussion. What a change. Charles provided some background information about M3 and Oslo.
First let me take a few items off the discussion. What I like about Oslo is that for the first time a modeling framework is not afraid of surfacing the continuum that exists between code and models. The MDE community has taken the wrong turn a while ago when it decided to oppose models and code. This was actually a tragic mistake (like so many - some people could learn from that and avoid eradicating concepts simply because they don't fit their day to day job).
If you (not you Charles) still don't see it today, well you need some glasses: code-less DSLs have had a marginal impact on software engineering (I'd like to argue they have had none), and code is full of ... metadata sprinkled wherever a developer decided to land them: annotations, descriptors, graphical tool... That mess has to stop. My mission in life is to help stop that mess by surfacing more general programming models (from a connected systems point of view, for instance) and helping change people's view on MDE towards MOP. I don't work for a software vendor or a standard organization so believe me, my agenda is as clear as what I have stated.
I also would like to separate "Metadata Management" from "Semantics". XMI, MOF compliant repositories... are all great, and they are a consequence of the existence of the M3 layer. But I don't care, really. For me it is more important to first focus on the kinds of problems your modeling framework is going to tackle, i.e. the semantics.
I am not an OMG guy, I actually never attended a single OMG meeting in my life. I like the organization, they have a good process. They produce well designed specs (most often...) and I know some great people that contribute such as Conrad Bock and Fred Cummins (and many more).
So when you say:
'Oslo' really isn't expressed in terms of 'classic' metamodel architecture.
I am still a bit worried. Microsoft has often "innovated" well outside the "classical" roads in the last 10 years but I would argue that it was most often out of ignorance rather than based on a bold new way of thinking. A lot of teams at Microsoft simply never get out of the Redmond campus or even read what's going on outside of the Microsoft world. I have no doubt that some bright people at Microsoft can push the boundaries of classicism (Volta comes to mond), but my word of caution is 9 times out of 10, this proves to be shortsightedness.
Again, if 'M3 exists', as in 'gravity exists', there is nothing 'classical' about it. When you design something to be used on earth, you can't just pretend that gravity is too 'classical' and you have had the brilliant idea to simply ignore it in your new designs.
I'm schooled in the old linguistic philosophy that languages (including modelling languages) are built on the 'trinity' of syntax, semantics and pragmatics.
I am a bit worried again of the 'pragmatics' aspects. Pragmatism works well with humans, just a tiny bit less with software, specially when you are talking about building something as significant as:
M is designed to be used at any level within a metamodel architecture.
If M would allow me to build my M3 layer that would be just fine. That's totally doable, but I am not sure this is what M does today or even tomorrow. This kind of thing does not happen serendipitously or even pragmatically.
It seems that M is more built around the premise that a particular
formalism (graph theory) is good to express lots of stuff and you
can even build a general repository to store graphs of stuff and
then you let it loose and you see what people do with it.
So, while I appreciate Jean-Jacques' comments about pragmatics, I think that this is potentially the area of greatest strength in terms of what Microsoft is doing.
Again, Microsoft has used this excuse so often that it's not even funny to point out that pragmatism has this unique ability to drive you fast where you don't want to be. Based on the CSD track record I would actually be very wary of focusing only on 'pragmatism'.
Let's talk about M3 layers for a second. The most famous ones are probably MOF and Eclipse's ECore. The beauty of an M3 layer is that it is reflexive and should be capable of describing itself. So there is no need (that I know of) for an infinite numbers of layers. The problem in the OMG's Modeling Architecture is UML. UML was just a particular (and large) metamodel supposedly designed to model OO solutions. Unfortunately, UML started to take off at the same time as "architecture" but UML was never designed to model architected (i.e. n-tiered) systems. Even though I use UML to communicate a few things, I see it as vastly useless for an architect and so does pretty much anyone. The reason why I say that is because UML has been made "extensible" with profiles, so nobody is really using "UML". As soon as people started to use profiles, UML got promoted to the M3 layer and created even more problems there. The UML metamodel is way too complex for an M3 layer and people change widely the semantics of UML elements (via stereotypes) as they please. As an M2 technology UML is quite dated (UML2 added a few interesting new concepts, but again missed the mark on architecture) and as an M3 technology UML is a real disabler of Model Driven Engineering. In particular, UML's implied programming model is inappropriate for connected systems (again with some improvement in UML2). UML should actually be useful as a warning that a modeling architecture is a modeling architecture and you can't mess with it "pragmatically".
If you want another warning, Microsoft itself suffered quite a bit from an ill designed M3 layer in the Operations and Management area. Microsoft started with SDM claiming that:
There is an elegant simplicity to modeling in SDM
You want to laugh when you hear something like that. Microsoft created a cluttered M3 layer, a la UML and well what happened later? they came out with SML a much cleaner M3 layer, but probably a bit too thin to be useful. As I mentioned I am not religious about a particular M3 layer, I am simply trying to warn you that "the 'trinity' of syntax, semantics and pragmatics" is bound to drive you in the wrong direction without the lights of the M3 layer. It is very important to understand and manage that layer appropriately, not because of repository and serialization concerns but precisely because of the semantics that you are going to be able to express at the M2 level. M2 is were people work, M3 is where Microsoft should work. Now that you are bringing "implementations" into the picture it is even more important to drive the design at this level. So it is not like Microsoft does not have experience with all this, but I am very worried about the casual approach that the Oslo team is having with these extremely complex issues.
So when you say:
M3 is always there in some sense, but doesn't always need to be represented explicitly within a given context.
I agree, but don't use it as an excuse to advise Microsoft to ignore this layer, this is the worst disservice you could do to them. As a user of Oslo, I don't need to go back at this level, agreed.
I need more time to understand your diagram, however I don't get the M1-Mn arrow. Again everything stops at M3, there is no "Mn". All I know if that M3's goal should allow you to avoid "extensions" and "stereotypes". As I eluded here, there is not one "uber" M3 metametamodel. SML is an M3 layer for building operations and management systems. So it would be perfectly honorable for Oslo to allow you to build your M3 layer, but that's different from "I don't need an M3 layer".
Oslo, the stated intention is to reduce the barrier between models and runtimes to the point of near-invisibility. The Oslo goal is to promote the direct consumption of models (including metamodels and meta-metamodels) within a wide variety of runtimes.
All this is good intentions and nicely said, but I, again, am very concerned by the later part of your sentence ("direct consumption of models (including metamodels and meta-metamodels) within a wide variety of runtimes") runtimes consume models, possibly implement metamodels and usually have nothing to do with MetaMetaModels.
Again, I would strongly suggest that instead of just thinking outside the box the Oslo team also looks outside the box, not to mention that defining very precise goals (such as the ones around architecture) really helps, it's way too easy to build something that "can do everything" and claim later that people simply don't know or are too stupid to use it.
PS:
That should not be interpreted as some conspiratorial (and completely pointless) attempt to undermine well-accepted standards.
We all know Microsoft well that Microsoft's "bratsy" attitude in this area has made it lose a lot of credibility both technical and leadership wise. Who cares today about what Microsoft is doing in standards? Just tell me one standard where Microsoft has shown technical excellence and provided industry leadership towards enabling a large market for our industry. Being one of the editors of the OASIS ebBP specification, I can speak from experience. Who today comes up with a standard idea and wants to bring Microsoft in? Who wants to join a standard lead by Microsoft? Again, looking outside the box would certainly help a lot.