09/20/08 :: [MOP] MetaModel Oriented Programming [permalink]

|

What do I mean by MetaModel Oriented Programming? There has been a lot of Meta and Model stuff showing up in the last decade or so. Of course the modeling roots are much older. I started to think about Metamodel Oriented Programming when I was working on a composite application framework at Attachmate in 2003-2005. The goal set forth by the VP of Product Management was "no code". This is I think a bit naive, it only works to a certain extend then you reach the point where the model is simply used to express "code". I strongly believe today that Model Driven Engineering is the way forward and that general purpose languages such as Java, C# or the dynamic languages will disappear -as we know them, not necessarily as a syntax. So if MDE is the goal, I also believe that MOP is a way to get there faster. 

Our industry has changed dramatically in the last 10 years. We have seen the rise of "containers" (from libraries and framework) and ever since, it has been a real challenge to weave traditional programming into container-based solutions. This mess, frankly cannot last much longer. Today, most people think in terms of programming languages as a syntax and some familiar APIs and they demand containers to both "contain" and offer the same flexibility that a traditional programming environment offers when using a library or a framework. This is not possible because both the container and the programming model have an expressed or most often implied metamodel. And these metamodels are incompatible. That's why, for instance, Spring was invented because the JEE container made "programming" (i.e. expressing business logic) difficult. This is also why Microsoft, I think, is coming up with Volta and the concept of architecture refactoring. They want to offer you a familiar programming environment (syntax and APIs) and later decide how to "contain" this application (i.e. deploy it into one ore more containers), much more so than compete with GWT, even though that could be a nice side effect.

IMHO, Spring and Volta are simply the expression of the need for MOP, even though neither of them think of it that way. The emergence of containers from JEE, ASP.NET, ESBs or Process Engines is a necessity. You can't deal efficiently with the "-ilities" of life without a container approach. You can't rewrite that type of code for each solution you build and a framework is not enough, when you consider security or the strong operational component offered by containers. Yet, containers make it themselves both hard to express the business logic you are accustomed to write in a traditional programming language and also hard to migrate from one to another, even a different version of the same container :-(.

People understand all this and they have boarded the Model Driven Engineering ship, anxious to sail to greener pastures. DSLs seem and are indeed a viable solution for such a modern programming environment. However, DSLs are still hard to design and leverage, unless you are a vendor selling a DSL based solution.

What does this all mean for IT? for the most part, IT can't swallow Model Driven Engineering, IT simply does not have the skills, resources and budget to initiate a Model Driven Engineering approach based on the tools and technologies available today. So a few things have been trotting in my head for several years now, for sure as far back as 2005, with some sources dating back to 1999 with the concept of an "extensible object model" I had developed at NEC Labs.

So what is the problem I am trying to solve? In a container world, IT needs a way to capture his knowledge in a timeless way, MOP is really about POM (Plain Old Metadata). But wait, before you run away, I am not talking about angle-bracket or curly-bracket metadata, I am talking about "programming as writing metadata" or how code and metadata relate?  Sincerely, I love this quote from Jean Bezivin's (OOPSLA 2003):

  • Model engineering is the future of object technology.
  • Model engineering subsumes object technology (goes beyond but does not invalidate)
  • Many general principles learnt during the development of object technology may be applied to the development of model engineering  

This is what MOP is all about.

Why does IT need POM? Pretty much for the same reason you need Spring, but Spring only works with JEE (Please, note that MOP is not replacing Spring it is a layer above):

  • you need to make your business logic timeless, regardless of which "container" or version of container you use, you want your business logic to depend as little as possible on the container
  • there are a lot of aspects that need to be weaved behind your business logic
  • you want you business logic to be easy to write and test
  • ...

I don't want to look like a sales person, but I am just trying to give you an idea of where MOP fits. We'll see if what I am talking about really materializes.

MOP is also part of the broader Model Driven Engineering picture and intends to complement it,  not change it, not replace it:

MOP is about creating a Solution Metamodel to capture POMs but what's new is the POM element are expressed in code, based on your favorite language syntax (yes, for those of you that request it I'll support APL) and completely container specific free. MOP is about freedom and agility, it's goal is to drive IT away from lock in situations. Actually even vendors loose from the lock in  they serendipitously impose on their customers because customers can't upgrade from one version to another.

Of course, MOP is not magical, there is a hard part in it which is write the POM compiler for your particular instance of infrastructure. So what is MOP? it is really, really easy to understand.

You may want to check this document I wrote about WSPER which is my first attempt at MOP. You should compare it an contrast with WCF API principles. WCF is Metamodel Oriented Programming in a general purpose programming language and that's the best example of what you should never do. If you look at these sample on the link I just provided, it is easy to see the metamodel spilling from WCF: ServiceContract, DataContract, MessageContract, OperationContract...

Of course this metamodel is layered on top of and stitched to OO metamodel (classes and methods).

[ServiceContract]
public interface IPeople
{
   [OperationContract]
   public void StorePerson(
	[MessageHeader] UpdateBehavior UpdateBehavior, 
	[MessageBody] Person Person);
}

The MOP equivalent would be:

public service.interface IPeople
{
      public operation void StorePerson( Person person) : invalidDataException(person) {    MEP = In-Out;
requires = {das.validate,das.update};
}
}

In other words, the OO metamodel has disappeared entirely from your programming environment. This is MOP ! This is why you can have keywords like service.interface since a metamodel can have different types of interfaces. You are not in C# or Java anymore, you have no longer access to .Net or JEE / JRE's APIs.

There are still "implementation" elements in MOP. For instance in WSPER, an operation may have an implementation. A Service may also have an implementation (BPEL). However, the kind of code you can write in these implementations is strictly metamodel related.

This was a just a preliminary post, just some quick thoughts about things to come. Keep me honest, suggestions and criticisms are welcomed. I just saw this post from Rich Unger which I think is talking along the same lines.