Why process models and SOA are steps backwards in development of computing

I was about to write of software packages and their integration. But just by go incidence I run into JBoss ESB and I got very annoyed. Here I stumbled in SOA and its heirs again. Grady Booch ( even as he was working for IBM which at lest at that time was a strong supporter of this “new” SOA approach) got totally pissed off with this SOA and wrote an article SOA ( Sneak Oil Architecture ) and accused the whole thing being complete bluff. So I just must once more return to the very roots of OO.

 

The real step from procedural to OO was the the encapsulation of behavior. The big invention was to tie up all behavior into objects. This meas that the structure comes FIRST and the object will limit and guideline this behavior. This means that ALL the behavior is boxed inside these objects and the total behavior is result of objects’ internal behavior ( ie. methods) and the collaboration between objects.

 

When OO started to technically mature and become possible to implement it in Java, the big legacy code owners and people around it got upset and where afraid that they become obsolete. This was why some powerful groups started the manipulation of language and started to speak about services instead of methods. In the same situation the idea of object was semantically changed to component. With these tricks the whole OO- paradigm was diluted away. After this a service could be any colossal old COBOL application!

 

Along this line of thought the SOA with “orchestration” was born. This orchestration was previously call “main program” and the services where call subprograms. In this process class-model was degenerated to entity model that we did in ancient time for relational databases. So the reason where the big relational DB-vendors ( such as IBM & Oracle and later also Microsoft) had a huge steak to be concerned of. In early days of OO we used to talk about “impedance mismatch” between object and relational. This created a considerable threat for the whole profitable DB- business. Finally this wiped out the whole OO-paradigm.

 

In this way we (at least big part of us) were taken backwards in time at least for a decade or even more. The truth remains that the complexity of this process or use case approach leads at lest tenfold complexity of the result and the trouble is that the growth of that complexity is unavoidable when the domain is something else that totally trivial.

 

In my next post I will write about the difficulties that rice from trying to assemble operation management system with package software and “integration”.