ABOUT | COPYRIGHT

Service Oriented, Process Centric, Model Driven Heresies

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Subscribe in a reader

04/30/09 :: [MOP] Meta-Architecture-Framework [permalink]

The main goal of MOP is to help create meaningful programming models adapted to the class of problems they are trying to solve. MOP is on the solution side, in other words, it is designed to be used by developers. The second main goal is to help make these programming models (technical) architecture independent. Enterprises of all sizes are suffering tremendously as they create business logic in proprietary programming model. Vendors suffer too, once this business logic is written, customers can't afford to upgrade from one version to another, because they can't afford to migrate their business logic to the new library, component model, super-duper client-side rendering engine...

I am not claiming that MOP will immediately yield tremendous productivity gain as people will need to create the engines behind the metamodels they create, all I am claiming is that OO has lived, in many domains, especially in a connected system, nothing can be modeled by a Class, yet developers and vendors alike end up reifying many useful concepts into a class with a bunch of methods. I bet most people today think of a Service as a Singleton and a SOA as a JEE App Server full of Stateless Session Beans.

If OO will get us nowhere, I also explained here, that anemic DSLs are a dead end. They will simply never ever yield a programming model sophisticated enough to build complex solutions.

The goal of this post is to talk about the M3 layer of MOP, dubbed MAF, the Meta-Architecture-Framework (not facility). Before I talk about MAF, I'd like to express what I think is wrong with all Model Driven Engineering approaches that I have seen so far. As I said in my post on anemic DSL, using an OO-based M3 layer is the key problem. I did some research on ArchiMate, which seems to gain some momentum as it is associated with TOGAF. ArchiMate is an Enterprise Architecture metamodel. Sure enough, it's M3 layer is OO based:

This is what the authors argue:

The enterprise architecture concepts themselves can be defined as specializations or compositions of the generic concepts at the top of the triangle. Another way to look at this is to view the generic concepts as a general means to define the enterprise architecture concepts: they can be considered the concepts to describe the metamodel...

This is quite unfortunate. The second major flaw that people do in MDE is to try to find an articulation between the different layers of abstraction, again this is ArchiMate's overview (M2):

This kind of approach is hopeless, the whole idea behind MOP is to create a logical view of the solution which is independent of the technical and physical architecture. The connection is done at the engine level, not at the modeling level. I also want to reemphasize that MOP is not about bringing business people into the development process but rather making developers so productive that they can build what the business needs in a very short amount of time and if it is not what they wanted or if their needs have changed, it can be trashed without second thoughts. Throwing away 3 days of work to better meet the needs of the business is a no brainer. Throwing 3 years of work is another question.

I understand that ArchiMate is not trying to create programming models but rather a model-driven enterprise framework that could be used to model complex business systems. The value of such an approach is IMHO negative. The models are hard to come by, hard to read, totally out of synch with the reality and don't have any practical use. I'd be interested to hear about Nick Malik's opinion on this since he gave us hints he was working on such frameworks in Microsoft IT. Unless you can create a connection with a runtime, there is little value to create (and maintain) a long term model. MOP's goal is to create readable programming models (which could also be transformed into a graphical representation), based on concepts adapted to the solution that you are building. When people are assembling a car or a house, they never look at the molecular structure of the parts, they don't build parts molecule by molecule (ok some electronic devices are build that way, one monolayer at a time).

So what is MAF? MAF is still work in progress but at the core, MAF is a classification of types of architecture elements. One of the key dimension of this classification is the lifecycle of these elements. I am not completely sure yet that the lifecycle lives in MAF, I am just trying to figure out which M3 layer do we need to infer the programming model of a particular (vibrant) DSL. Ultimately, I am conscious that people may need to extend MAF or overwrite the lifecycle definition at the M2 level, but that's not too bad.

Let me illustrate why a lifecycle is important to the programming model. Let's take some architecture elements of a connected system:

• Type: created/released

• Service: deployed/started/stopped/failed/undeployed

• Resource: created/archived/deleted

• Assembly: deployed/started/stopped/failed/undeployed

• User: created/authorized/suspended/deleted

• Role: <<uses>> Type

If I want to create an OO metamodel, I can design an OO DSL with has the following elements: Class, Attribute, method and Instance. A method is an "implementation" element. We would define in the DSL that this implementation element can only manipulate instances and the lifecycle of an instance if the one of "Type" (above).

This means that the programming model can be inferred to be:

method(A a)
{
    B b = new B();
    //Do something with b and a
    b.~B();
}

Now, if I want to express that a destructor cannot be called directly I could specify that the lifecycle of a type is created/~release, in other words the destructor cannot be called directly from the programming model, but it must be defined explicitely. If you want to create a programming model that uses Garbage Collection then your lifecycle is just "created", there is no explicit "released"

Note that when I say that a method can manipulate instances, it also means that it can invoke its methods and access its attributes. This is a default behavior. I think the key to understand is that the major driver in the programming model is the lifecycle.

My goal in the next few weeks will be to create the OO side of MAF to show clearly that OO is a particular case of MOP. Ideally I would want MAF to support all OO concepts found in different language: JavaScript, C#, C++, Java, Ruby.... That's the litmus test I have to pass. After that I will take on both SCA and .Net RIA Services. My last step will be to take on the field of BPM. If MAF can describe successfully these three domains (OO, SOA, BPM), I would consider the approach viable.