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”.


5 Responses

  1. Very interesting issue though I maybe do not quite agree. 🙂
    The difference and relationship between “entities” and “objects”, the “impedance mismatch” between OO and RDB, are very meaningful questions. I think some significance of SOA be ignored yet, relational model and database as well.

    • @TY

      You say that you disagree but after that you remain mysterious and don’t explicitly express you arguments or line of thought. Anyhow I’ll try to elaborate on some of these issues.

      The core here is the complexity management. It took a considerable time of the computing community to invent the OO- approach. The key here is to increase structural restriction in programming. Very simply put this means that instead of been allowed to write function (or programs) with hundreds of thousands of line of code quite wildly OO restrict a function ( this time call a method) access freely only the attributes within the object it self and call methods of its immediate neighbor object. This way a method in an object can do only things that are in the scope of this object. The second structural layer is a collaborative set of object that can perform more complex task in collaboration with each other. This thing will dramatically reduce the possibility of unnecessary complexity.

      The concept of Service is very relevant, but ti must be strictly treated as described above. Unbounded “services” “Do-this-and-that” are the inevitable source of exponentially growing complexity.

      A real but at the same time theoretically clean OO- application should abstract away the implementation of objects persistence. This means that the programming environment should provide programmers means for object creation, but so that all created objects are persistent and when you really want it to disappear all objects would implement some common method like destroy(), which would delete the object. The platform should also control automatically concurrent access to objects and preserve is consistence.

      In other words the OO- programming environment should be equal or better than those of current OO-databases. To day when relational databases are used to persist object the best standard solution are JPA or JDO but these require quite a lot of unnecessary programming effort.

      Paradoxical is that Oracle one of the most important relational DB vendors are at the same time the Java VM developers. So it seams quite evident that they wouldn’t develop a free Java VM, which would wipe out all their relational DB business.

      Here is a web post that I have written on this same issue in 2004. I have to sadly notice that nothing has changed in eight years in this issue.

      • Hi Jukka,

        Thanks for your detailed reply. I could not agree that “process models and SOA are steps backwards in development of computing”, though there are much commercial cases, as you mentioned, where use such the technologies to protect the legacies, such as the code or programs outdated. This is the problem of the uses but the technologies (ideas) themselves.

        For OO and Database, firstly, the OODB, Object-Oriented Data Base, seems somewhat a pseudo proposition: there is no OO DATA base, just OBJECT base. In other hand, some of essential ideas with the Relational Model and the Data Base be ignored, and even, many of them are never be really understood and employed in practice, e.g., the successful RDBMSs, even the standard for SQL, are all have no complete realization of Relational Model, and the architectural ideas for applications contained in the idea of Data Base (Data Bank) has been abandoned.
        Basally, I think OO is one of the architectures for programming but not all; the SOA, the complete Relational Model and classical Data Base also have the unique uses can not be replaced. Today, in reality, the former has often been somehow exaggerated while the latter (especially the Relational Model and DB) were usually increasingly be misunderstood or ignored.

      • Hi TY

        Thank you for your argumentation. I must say that I have worked with Relational Model from 1975 and I have promoted Peter Chen’s views in late 80’s and I just disagree with you.

        Today I am completely convinced that all databases are obsolete. This is actually a deep paradigm change between procedural and OO. I my world there absolutely no need for any database. This is only implementation and should be solved bellow application programming level in the development environment.

        I am sorry that I missed the link from last reply but I correct my mistake here.

        Here you are:
        The article from 2004:



  2. Wow, you are a pioneer, I’m luck too meet you here!
    Thank you for the links, I’ll take some time to read them, then perhaps will continue to argue with you 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: