OOP and the path of the oriented-services architecture styles
OOP (Object-Oriented Programming) was coined by Alan Kay to define the programming way driven by Smalltalk. In his mind, the approach was to code objects as computing units encapsulating local state-process and communicating between them by messaging to perform higher coarse-grain computation. It was in the 70's.
In another way, there were different attempts to define a communication model between different programs to share information in order to perform higher level computation. We passed from the simple client/server model to the actual emerging SOFEA model (Service-Oriented Front-End Architecture) that extends the service-oriented architecture principles up to the client side.
As we can see, the two seem to be related.
OOP can be defined by the following citations taken from Bob Barton and Alan Kay:
The basic principal of recursive design is to make the parts have the same power as the whole.
the objects should be presented as site of higher level behaviors more appropriate for use as dynamic components
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
But, some persons didn't understand what OOP really means and they simply saw in him a way to what they are looking for, that is to say a better structuration of the code (among them Ole-Johan Dahl and Kristen Nygaard, the authors of Simula) and they evangelized their own definition of OOP. The acculturation was so profound in the Software Engineering that nowadays all the imperative programming is mainly focused on the code structuration. The daily practiced OOP have finally lost the more important principles: transparent messaging, dynamic components and recursive design. And it is a shame because these appear to be also the fondation of a correct distributed architecture model.
So, we should not be surprised the Software Engineering was continuously looking for a model to perform a better inter-application communication to share information in order to perform higher level behavior. Several approaches emerged, among them we can cite the famous technologies but with the same fallacies:
- CORBA (Common Object Request Architecture),
- J2EE/JEE (Java Entreprise Edition),
- SOA (Service-Oriented Architecture).
Despite their local success and their current use, they in fact all failed because they are both limited and complex. The failure comes from they were primarily built on only structural principles. Indeed, It is difficult to build something of a different approach when you are used to use structuring-oriented tools (C++, Java, RPC, ...) that have conditionned your own way of thinking; habbits are difficut to change. Look at these technologies: they have in common to define the components as a set of static structural bricks a top of a semi-hidden messaging mechanism and they focus on technical details to manage the life-cycle of such components or to hook the messaging with additional technical features. Even with SOA that is in fact an attempt to apply a CORBA approach in a higher level, to a web of heterogeneous applications, by using XML-related technologies. They missed the main principles to build a such distributed technology: transparent messaging, dynamic components and recursive design. As you see before, these features are not new, we have just forgotten them with the time. To attain some of these features, additional tools were spawn like ESB, complexifying by the way the whole infrastructure of the distributed technology.
OOP is not just a way of programming single applications but it should be also an approach to model a distributed architecture. Smalltalk was an example of the implemention of it. Erlang is another example by leveraging the principles we cited previously in a higher level order; it is then not surprised Erlang was regarded by Alan Kay as a OOP technology. The Software Engineering working on distributed technologies have just to glance at to original OOP. Nevertheless, we are empirically on the path to reach the OOP way of thinking. The service-oriented architecture styles are more near to OOP than the client/server architecture styles. It will just take some time. It could probably be achieved more rapidly if the software engineers and scientifics took the time to reconsider OOP. It will be a time we can build a web of dynamic services communicating between them by transparent messaging to perform higher level behavior and in which the front-end (the UI) is just another service. For example, currently, in Silverpeas, we are working on an a service-oriented architecture based upon the REST and SOFEA approaches. In our first attempt, Silverpeas will be deployed as a single one service whereas its front-end will be served by another service. Because Silverpeas is already made up of reusable and well-integrated applications, it will be possible, thanks to our REST adoption, to bootstrap it as a distributed service-oriented application. Nevertheless, because we are tied to the Java ecosystem, it will took more time to have a correct distributed model with a very high scalability and an extreme late bindings of all things.