04/16/09 :: [MOP] Why M3 is critical to MOP? [permalink]

 Jorge Ubeda commented on my criticisms of Oslo. He emphasized two very important quotes from Charles Young:

We need to be able to specify the metamodel very precisely in order to ensure that our models are valid and well-formed in respect to BizTalk Server. However, we will probably be less interested, in this scenario, in ensuring that our metamodels conform to some meta-metamodel. One reason for this is that we probably won’t have a compelling need to exchange BizTalk-specific metadata with other systems and applications.

...

There is no need for developers to engage in a steep learning curve in respect to meta-metamodelling, no need to conform to unfamiliar APIs and no need to inject an unnecessary level of platform independence in the way models are specified.

Au contraire, Charles. M3 is essential to the mission set forth by Oslo in being able  to deliver amongst other things "Connected System Programming Model". M3 is not just about "metadata exchange". Who said so?

The whole goal of Metamodel Oriented Programming is to create programming models independent of architectures, however, MOP does imply a "programming model", actually a meta programming model. If we look at OO with the eyes of MOP we can see how critical it is to be able to stereotype the elements of the metamodel as this "metametadata" will define, in particular, their behavior in the "implementation" elements.

In OO, we know that a "class" can be "instantiated". In MOP you can have many different entities that don't behave like "classes". So, when we are able to write:

Class a = new Class();

It is because it is defined at the M3 layer. M3 will tell me that the elements of type "class" are instantiated that way, while, say, a primitive type has a different instantiation mechanism. You can easily see that in a connected system a "Resource" behaves very differently from a "Service", and both of them behave very differently from a "Class", at least from a lifecycle perspective. As I mentioned earlier, there are also fundamental differences between Methods and Operations.

Not convinced? Look at methods. Why can't methods be "instantiated"? At what level (class or instance)? Ah, yes some OO languages allow you to do that... How would you express that? Where do you define a "metamodel" that can describe any OO language? well this is actually a metametamodel. This is why M3 is so important.

An OO developer has no knowledge of M3, and in the case of OO, M3 is exactly equal to M2, which contributes to the perception that M3 is useless.

You could easily imagine that we could create an M3 layer called the Meta Architecture Facility (MAF) that specifies all the types of elements that can be encountered in a connected system (or a robotic system, or a musical system, ...). Anemic DSLs probably don't need such a strong M3 layer but MOP cannot exist without it.

The M3 layer could also be used in the runtime implementation to weave some aspects (monitored, secured...)

So we still agree on the fact that the users of MOP don't need to know as much about M3 and this is typically a layer where vendors will play. At a minimum, M3 will let me defined the rules with which I can write implementations using the metamodel elements. And I am not even talking about how useful M3 becomes when you need to version your metamodel or your metametamodel.

As I understand it, Oslo has given itself the goal of enabling something at the level of MOP: however, trying to do it from a pure "syntax/parser" perspective is bound to fail. Today Oslo gives me the ability to define a syntax and generates a parser that will let me parse files that are defined using that syntax. That's a key building block, agreed. Yet, unlike OpenArchitectureWare, Oslo doesn't let me define easily the metamodel underlying the syntax (at least based on my understanding). I just get a "tree" of metadata (the equivalent of a DOM) and I am on my own to consume that tree, assuming an underlying metamodel. One could argue that this is ok, since the runtime implementation is really the one that knows about the metamodel. However, if you now introduce "implementation" elements (such as an orchestration, or a more traditional implementation a la OO) then you need general rules (just like in OO) that expresses how a metamodel element behaves in an implementation.

So ignoring M3 has nothing to do with classicism or pragmatism. M3 is the foundation of MOP, without it you are building on sand.