05/01/09 :: [MOP] Meta-Architecture-Framework II [permalink]

I re-read the 2006 paper from Wil van der Aalst et al on a "SOA based Architecture Framework". This is a good paper, it creates a metamodel of SCA, a posteriori, and defines SOA that way. This time around my read was completely different from the first time I read the paper. It is really interesting to look at all their assumptions in the light of MOP and MAF.

One very successful approach for handling complexity is modularization 

I would argue that this is especially true in monolithic programming models, when everything IS-A xxx you have no other choice than taming the complexity of the system through a systematic partition of the concepts reified behind xxx. They continue:

A collection of modules that are properly connected to each other, should behave as one module itself...In object-oriented programming modules, called classes or objects, are first class citizens. During the last decade modularization is considered as the most important feature of a design of a system. In the rest of this paper we will use the term component for a module

From this concept they propose the definition of an architecture:

An architecture of a system is a set of descriptions that present different views of the system. These views should be consistent and complete. Each view models a set of components of the system, one or more functions of each component and the relationships between these components."

I don't necessarily discuss the definition, an architecture will always at least be composed of a technical view and a physical view and possibly a "deployment" view that expresses how a solution is deployed on a given architecture. But you realize that because people have not been able to define a unified programming model abstracted from a particular architecture, people have been forced to create "logical views" based on the programming models of each element of the architecture and by stitching these programming models in an ad hoc basis. Sometimes giving up altogether (do you see a lot of people modeling JavaScript?).

For example, a view could show a data model of some components and the inheritance relationship between the components.

Ah..inheritance... I am wondering how many components in my car inherit from each other.

The meat of the paper is Section 4. They analyze the requirements of a SOA-based architecture framework. Not surprisingly but in the most ironic fashion they start with:

The basic concept of an architecture framework should be a component.

I don't know what it is with Software Engineers but everything has to be of "one kind". How about everything is a "thing" (after all Reenskaug, the inventor of the MVC pattern, had originally called it the Thing-Model-View-Editor)? Would that work for everyone?

And of course, the programming is just as monolithic:

A component should also have an internal structure that consists of a partially ordered set of activities. Activities describe the component's behavior. Zero or more data elements, which are global to the component. Data elements can be used to configure the component.

Interestingly enough the authors realize that this monotheism is impractical and suggest to leave the model open with 3 plugins:

  • A process formalism describes the ordering of the activities in a component.
  • A data model defines the data elements, their types and their methods
  • A language defines the operations of activities

I did not speak much about "implementation" elements as part of MOP. As Wil et al point it out several formalism should be allowed: procedural, orchestration-based or template-based. Defining specific "things" which all have "implementation" elements which can manipulate some other "things" (not all of them) is what's different in MOP. I think Wil et al intuitively understand that "implementations" need to be added at the right level in the metamodel but they fail to create a general formalism to do so. For instance we could define a "transformation" thing which can be applied to other "things" (e.g. types) with a template-based implementation language (say XSLT). I apologize for using "thing", I just want to emphasize that it is incorrect to try to find a generic type all all "things" inherit from or behave like.    

Even though I don't like J.D. Meyer's Application Model (which is the same that Microsoft had in 2002) and the fact that he is ok to publish bogus REST definitions, I do think his work on "Language for Architecture" is quite useful as he set out to "Map Out the Architecture Space" and came out with this:

 

The picture does not do justice to his work but this provides a description of where a MOP model can be deployed and some of the aspects that need to be injected in the process. It also provides a foundation for studying how architecture refactoring can work.

In many respect, it does not matter what programming model vendor I, M or O came out with. The premise behind MOP is that there is no unique programming model, at least today. I actually don't think anyone can design a ubiquitous programming model. Thinking that Java or C# would ever produce such programming model was quickly invalidated by JEE or all the code behind that Microsoft added here and there. I understand that MOP is the tower of Babel of Software Engineering, I understand that everyone coming into MOP will come from an OOP/MOF perspective and leave with a dedicated programming model, often incompatible with the one of others. But who could argue today that OOP/MOF is sustainable? even with the crutches of anemic DSLs?

At the end of the day, the problem is not to (painfully) model corny programming models, the problem is to find programming models that don't require modeling to understand that a particular element of a solution does.