CC BY
34
SCALING FROM OOP TO SOA AND ENTERPRISE ARCHITECTURES. COMPLEXITY CONTROL AND EVOLUTION SUPPORT IN SOFTWARE DESIGN
Ilya E. Ermakov, lecturer, Polycarpov Institute of Technology at the State University - Educational-Scientific-Industrial Center, CTO, NPO «Tesla», Russia, Orel, ilya@ermakov.net.ru
1. Reliability and Evolvability
Essentially, reliability and evolvability of systems are two sacred goals ahead software engineers. What is the main gap in reliability? Of course, it's complexity of systems. In coherence with this fact, a lot of programming tools, abstractions and principles may be considered as control complexity facilities. Control complexity requires, first of all, abstractions, and, secondly, some strict discipline in system design and implementation. Such discipline helps us to overcome new large problems, but it may be strait for future life of a system because of flexibility lack.
Abstractions and Discipline => Complexity Control => Reliability Reliability and Flexibility => Evolvability
Fig. 1 - Main Forces of Effective Design
Evolvability is the second basic property of system design — to be ready for a long life in volatile world. Complexity control is the first condition for evolvability because unreliable system can't have long life. But not all reliable systems are evolvable. Squeeze structure is a cost of reliability. Therefore flexible areas should be established during design if we need some freedom for system evolution. We introduce reliable skeletons over a homogeneous set of elements (for example, strict typing over plain memory) and after than we'll be forced to introduce facilities for flexibility over the squeeze layer.
Such contraries should not be perceived as disappointing. True system design demands well-balanced thinking from an engineer. There are many well-known things in IT history (LISP, Forth and some of modern dynamic languages), that have beautiful abstractions and homogeneous structure. But abstractions without a discipline (that need to be implemented as some concrete facilities) don't achieve true complexity control and reliability. And flexibility without reliability don't achieve evolvablity. All languages used for large system design (Ada, Java, Component Pascal, C#, chronologically, and others) are balanced for all sides of described above.
2. Modular and Object-Oriented (OO) Facilities
Modular and object-oriented facilities were introduced in porgramming languages independently one of another, but because of similar problem's vision. Actually, two these approaches may be considered in overlaped notions — let's try to do it.
We'll tell about so called «true modules» based on D. Parnas conceptions and supported by special language constructions in modular languages (Mesa, Modula-2, Ada, Object Pascal, Oberon, chronologically, and others). True module is:
1. a part of division system;
2. a unit of hiding internals (hiding statical information);
3. a unit of hiding dynamical state (by an inteface consisting of abstract operations; and it's nothing like encapsulation).
There are some other practical flavors of true modules: they are units of separate (but not independent!) compilation and dynamical loading and linking (as it's prevalent in the Oberon's family).
More than, we should behold that a module may be a unit of variation several implementations of one interface (several implementations for one definition). And it's nothing like polymorphism.
So, true modular programming helps us to create complex and easily modifiable systems. But modification is not as yet evolution generally.
30
Native OO languages (Simula and it's derivatives) and «total OO» languages (Smalltalk etc.) support (2) and (3) on a fine-grained level: for data types and data instances. Such abstract data types and their instances have been named classes and objects. OOP in software design introduces explicit expression of classification relations between entity types. Facilities of inheritance have long history — from wars between single and multiple inheritance to modern principle of pure interface extension, without implementation inheritance (and without problem of fragile base classes[1]). Since OOP is fine-grained modularization of dynamical data instances, it opens way to dynamic reconfiguration and extension of software (well-known fantastic flexibility in Smalltalk environments).
As we discussed above, real engineering requires not so flexibility, but also large-scale design and reliable ribs. Native OOP has powerful facilities for extension, but true modular programming supports reliable middle-scale organization of systems. It's main cause for incorporation of modular facilities in OO languages (classical modules similar Modula-2 etc. have been offered in Java SE 7). Concept «module is a singleton object» is shallow because these facilities live on different layer of system architecture.
Another way is to incorporate OO facilities in modular languages (Oberon, Ada-95, Component Pascal). Class-object notion is superfluous in this case. Modularity, data type extension and strong typing establish base for reliable and evolvable design (as in component-oriented paradigm [1]). Some modern languages such as Google Go use this approach too.
3. SOA and REST essentials
Let's remember what we have before SOA. Broadly speaking, there were modular and OOP architectures and component programming for control complexity at a middle level, there were realtional databases for separation data-model level in enterprise systems and there was multitiered structure for separation information processing from interactions with external world.
A lot of approaches (OO-DBMS, CORBA, RMI, DCOM etc.) have been concentrated on scaling facilities of OO languages for needs of large distributed systems. There are two problems: first of all, fine-grain facilities of OO languages are meticulous on this level — it may implicate vague, unreliable and inefficient design; secondly, very successful clean separation between data level and other tiers is lost. It may be posited that any new approach shouldn't lose division lines introduced for complexity reduction formerly.
An initial idea of SOA was simple, natural and implementation-independent: to keep horisontal lines of tier separation and to force vertical lines between different group of functions. Every such group should be encapsulated in enough independent service. A service encapsulates responsibility for some database partition and offers set of actions for it's clients. We see same logic as it have been described above for modularity. And, of course, ability to vary several implementations of service is attractive for enterprise system's engineers. For such variation (and dynamical binding and reconfiguration) some middleware was suggested by several vendors. Enterprise bus for service communication is example of simple and effective facility.
There are more and more critique of SOA today. Such critique is because of complexity, low flexibility and high use cost of all favourite SOA middleware. Total interface specifications don't add measurable growing of reliability, but greatly decrease evolvability. A lot of trash features cover clean idea of SOA. We shouldn't forget, that approaches such SOA are oriented not to implementation, but to design, so we need nothing fat tools to support them.
And so, what is the REST approach — new fashion or an objective trend? It is clearly on base of comparison modular and OO facilities, that has been done above. Let's rely on SOA gains, introduce explicit identification of enterprise informational resources and apply fine-grained service-oriented interfaces to each resourse — and we have REST, that binds data resources with services same as OOP binds data structures with procedures. It's meritoriously that REST is based on unused potential of simple HTTP protocol. Well-known principle of hiding real processing implementation under requests to abstract URIs is yet another example of modular and object-oriented (polymorhic) facility.
31
Summary
There is some trend in evolution from modular and OO programming to modern enterprise architectures like SOA&REST. This trend is oriented to control complexity and support evolvability in large systems. Essentials of enterprise architectures are simple and implementation-independent.
References
1. C. Szyperski. Component Software. Beyond Object-Oriented Programming. Addison-Wesley Longman, 1998.
32
