Isn't OOP dead?

The XML and Web Services age

S V Ramu (2001-11-11)

The Three Models

At present there are three competing models to represent data, namely, RDBMS, Objects, and lately XML. Where one model should relinquish control to the other, and which should do what, is a debate of considerable entertainment to us. Currently there is a broad spectrum of solutions that are considered to be best, right from one-of-the-three-alone is sufficient for everything fanaticism, to everything-is-needed-for-sure type of diplomacy. My favorite is XML, and XML alone. Why this fanaticism? Chronologically the order of maturity of these three is RDBMS, Objects and recently XML. Each has its own merits and its own niche to occupy. All three were trying to satisfy the Data-Method dichotomy of the programming world. The one that seamlessly bridges both will succeed. XML can, will and is!

The Data - Method dichotomy

Right from the day of assembly language, till now, any programmer will immediately breakdown an application as a set of data structure and some associated activities to be performed on them. This Data and Method are the Men and Women (which is which?) in the world of digital logic. They are complimentary hence inseparable. Each has its merits and importance. In the foreseeable future these two idioms cannot fail us in the successful visualization of a software application. All the above-mentioned three data models are not just for data, but also to satisfy this perennial yet bothersome dichotomy of data from Methods.

The RDBMS case

Even before the Codd's enunciation of the RDBMS rules, a form of Data Base is always accepted, and rightfully so. The need for persistence of data is both primitive and inescapable. The question is one of form. The RDBMS solution for it is to model data as a Set of Rectangular Tables. When RDBMS won the field, its contenders where some Hierarchical and Network databases. Whatever the reasons and whoever the contenders, RDBMS is symbol of evolutionary maturity, and a dead end! All the modern development of ORDBMS and OODBMS is just an attempt to perpetuate this dead life form, by intermarrying it with another emerging successful species, Objects. Even in its purest form, RDMS supported all the mandatory relations between data itself, and with methods (Stored Procedures) to act upon them. The glory of RDBMS is not completely over yet. It's latest avatar in Oracle 8-9 and SQL Server 2000 are both the results of its crossbreeding, former with Objects and latter with XML.

The Objects case

Though OOP model's history can be traced back to the early days of RDBMS itself, its popular rising came about only recently, and only after the full maturity of RDBMS itself. Maybe people thought that RDBMS alone would suffice, hence methods, a glue, do not need any more improvement. Anyway, some compelling need should have made developers to see that methods are indispensable (C is a testimony to this fact) and methods need equal treatment with data. No more, no less. Thus OOP bundled both data and methods inseparably, and moving the focus from data-alone paradigm and method-alone paradigm to one of Data-Method resonance (where whole is seemingly greater than the parts). Of course, RDBMS still is the back end of any application, hence cultivating an O-R mapping community.

First ORDBMS shot to fame, then even full-fledged OODBMS was seriously considered. Object-Relational mapping is a big business, and a blatant messy task, that is always controversial and tough. The mood swinged even to the extreme of storing objects directly. If not for some performance bottlenecks (in fact overcome-able), RDBMS would have been already committed to some digital history. Whatever the reasons, for now both are alive and kicking, and forever quarrelling, waiting for some miracle to make things elegant. Fortunately, in a sense, RDBMS has already lost the battle of total supremacy, and its extended lease on life is tolerated only due to its performance benefits, its supplementary nature and the its easily available expertise. In early days, it was even predicted that OODBMS would one day be the de facto option for persistence too, when computers and technology will advance sufficiently. All these were true only before XML. This new species was masquerading both as Data and as a structured Method, and as a bonus as Document too!

The XML case

Like any new concept, and like RDBMS and OOP, XML too had its own long gestation. After the full maturity of both the OOP and RDBMS models, and after the success of Internet through HTML and SGML, XML had its delayed but strong birth. Its initial days, like everything else, were promising yet controversial. Initially Markup languages where considered only as a solution for the Documents (the third candidate in the Data-Method-Document Trichotomy). HTML and WML only made this more so. But, slowly its clout to represent data was also acknowledged. So much so, that most of the ubiquitous current day use of it is only for data. With CSS and XSL, its use with documents is relegated to few inevitable document standards like HTML, WML, MathML and Chemical ML. The DOM standard and the rapidly proliferating numbers of XML parsers and XSL engines, only enhanced the data angle of the XML. Not that Documents are any less important, only that data manipulation requirement of the developing community is far higher.

Then, all along, XML was touted as the doyen of data representation, again as is custom, to the extent of considering pure XML-native databases, with native support for XSL (as the bridge between different flavors of XML applications). Again, the old leveler, performance, is delaying this process, but this destiny is inevitable. XML is the uncrowned king of Data, both for persistence's public interface, and for transient transport. In coming days, due both the speed and maturity of storage technology, and due to that of on-the-fly compression (for both storing and transporting), XML is bound to replace RDBMS as the basic data format, especially due to its transformability into different forms. Like the definition of table being a table itself, and the definition of Class being a class itself, the definition of XML too is becoming XML itself. This superior symptom of maturity, self-recursion, is conspicuous. Though we might compare, XML element tree to the bygone (now demised) Hierarchical data model, I suspect some basic differences (need more research here).

One domain, yet to be fully conquered by XML is to represent Methods. What are methods? Can they ever be unified with Data seamlessly? Apparently, the answer is yes, if we consider the method as a data structure of Name, some inputs and one or more outputs. This is not new (assembly languages do this all the time. A function call is just pushing and popping of parameter data into stack and suitably jumping over program counter), yet XML does make it much more natural and obvious. I even imagined and saw some proposals, for standardizing an XML model for the programming structures like assignments, loops, branches, function calls and Class-Package idioms. Thus paving way for a universal intermediate language, with which we can transform one programming language to another, towards a one-platform future. What we could not do much with natural languages, we are trying on its smaller counterpart.

All said, the dare to touch and perturb the OO's strong hold of method modeling is on. It is a question of time before XML becoming a markup of all human thoughts and activities. The recent adoption for Ant, XSL, SOAP and XML-RPC, is only the indication of things to come. These standards are full-fledged procedural markups, with an appealing declarative flavor to it. Due to the ubiquity of Internet, and the upcoming Web Service revolution, the need for remote processing and communication will only become stark. For now, Java RMI and XML are the only contenders for dynamically executing logic, instead of just working upon data. Amazingly, XML has made even procedural calls data-like. At least it would be right to say, that XML can consistently represent data and methods identically, if not considering methods as data itself.

The Impact of XML on GUI

As it can be assumed that, RDBMS is not at all a contender for complete programming, it can be safely factored out in any discussion on software architectures and programming patterns. The fight is only between the veteran OOP and the rookie XML. The question of where to draw a line between two seemingly complimenting concept is the key. Curiously, the now EJB popularized O-R mapping for CMP is keeping RDBMS still in the fray, inappropriately at that. But assuming that all data from external data source, whether RDBMS or a native XML store, can be converted into XML and used consistently as a data structure of choice, we can safely relegate it to the darkest backend of OO programming, and that too for performance alone and not for conceptual superiority. From the peripheral Data Layer inwards, all serious data structures could be XML alone. And these days with the XML-ized shell offering of SQL Server, Oracle and DB2, this job of DB layer XML mapping is more automatic than anything.

Thus, having RDBMS out of our way, it is only the Objects themselves that are in question. If data is fully taken out of the programming domain and into the XML world, what else remains for OOP? Of course, loops branches and assignments, are there. What if they too are swiped out into XSL like XML based block structures! You say classes and packages are there still? No, classes etc. are grouping idioms only, and what else does this job better than XML?! I do realize that I'm trivializing the situation bit too much (especially since not all loops and braches are done by XSL alone), the fact remains that the range of pure programming functionality that needs to be done by OOP is severely limited in the light of XML.

One domain that always warranted serious OO programming was GUI creation. Right from Microsoft Windows programming, X Windows object model and Java AWT and Swings, GUI creation has become the custodian of OO tradition. The raise and fall of Delphi like sophisticated custom component RAD tools, can be equally traced with the raise and fall of client based application development. As the focus shifted to server based middle tiers, the OOP too is loosing its hold, in spite of the bold loyalty of EJB like attempts. And now, even this GUI support for OOP is fast eroding! The latest release of Netscape browser 6.1, is sporting fully a novel concept of XUL (eXtended User interface Language) from its Mozilla effort. Using this, Netscape is able to provide unprecedented super-skin like configurabilty to its interface. The XUL attempts to describe all the UI elements as XML tags, along with their event plumbing. Even the event code is written in simpler Java Script, instead of requiring its full blown OO counterpart, Java. Essentially, a meek scripting language thus trivializes one main reason of Java like serious OOP.

The Netscape effort is not alone; W3C is formalizing a common standard for GUI description under the name XForms. When these efforts mature, we can expect XML to GUI generators to appear for each of Java, Windows, Linux, PDA and other devices and platforms. Already HTML, WML and CSS has removed this OO development need for all types of browser based GUI. If XUL or XForms will remove this need for applications too, then the arena of OO indispensability is so much negated.

The New Application Architectures

Now, the RDBMS is fast vanishing into native XML databases like Ipedo, goXML etc., the GUI is stripping itself clean of OO through XUL and XForms, all internal data transport is well adapted for XML manipulation. Then, what else is remaining for the elite OO programmers?! As a glue between two different XML formats through DOM? No, even this solidity is slipping under its feet due to XSL and its breed of transformers. If EJB and some others like it are not there, the stream based OO language is indeed fast disappearing into the darkest corners. In fact, even with EJB it won't take much effort to declare our Home and Remote interfaces in XML and map transactions, and security to them in the middleware.

The key case to topple this final balance would be SOAP and XML-RPC (Remote Procedural Calls). While all non-method calls like loops, branches and assignments are beautifully represented in XML in Ant and XSL, SOAP and WSDL even abstracts methods and classes with XML envelops (won't WSFL be likened to packages!). The highly distributed and decoupled nature of the Web Service model, necessitates XML like flexibility. All three things of net programming, namely the network protocol (TCP, IP, HTTP), the data format (XML) and the data semantics (ebXML) are non-OO paradigms. Whither gone the OO spirit!

See it this way, if method name and params can be modeled as XML, then what remains of a method call is only the act of calling itself. If so, at least for areas that need high level of decoupling, why cannot we breakaway from the convention and use TCP/IP itself as the message passing channel? The fact is, this is a good idea, and is being practiced already. Almost all the key Client-Server applications like RDBMS and others use IP address and port to identify a service. Still the data that was sent through these neutral channel was ad hoc, which has now changed to XML, thus removing the magic of parsing altogether. HTTP, FTP, POP3 etc are a layer above the TCP/IP layer for the data format itself. The XML content will form a layer above this too. Some small applications like JEdit too is communicating between its instances through encrypted TCP/IP ports. The next step is ebXML like major consensus on the data semantics too.

Forgetting the anti-OO chant for sometime, what are then the modern Application Architecture options available to us? If key module-to-module communication can be in neutral terms with ports and XML, then it doesn't matter if these models are in the same machine or across the world. Of course, performance is still a deciding factor, before going overboard and converting all our method call as port calls. All the same, an application can now be imagined as a bunch of Service modules which communicate over neutral channels and format, and possibly with neutral semantics as well (i.e. the XML schema too might be a global standard, instead of a proprietary one). And all that remains of programming is to code these Service Nodes which just transform some input XML to some other output XML, not altogether a OO demand at all.

If you imagine all the service nodes as points, and their interconnections with other services as directed lines. Then what we have for an application is a network of points and lines. Now, if the semantics of these communication (i.e. if XML is the universal format, a particular schema of tag structure is the semantics) is an international standard, draw that line in red, and if it is proprietary then in black. If done, then our application network would be many points with red or black colored directed (arrowed) lines connecting them. We can say that as the number of red lines grow, the application is to that extant an extensible and maintainable product, since any new vendor can deliver a module with better performance and yet with complete integration assurances. This is really the promise of the Web Services paradigm, where a service is the software equivalent to the IC of electronics.

Philosophical Overtones

All software creation is slowly becoming automatic, as the primitives we are dealing with are not registers or functions but services! If the future application is just a mix of existing services (like what WSFL is facilitating), then that job will not need a C or Java pro, but just a smart computer literate. And as is usual, the question of employment to all these unused brains becomes a big question. Though I cannot claim to know a complete solution for this situation, I'm confident that human brain will always find a way to entertain itself, even if it has to pass through a phase of turmoil and tension.

As a philosophical aside, life basically has no objective purpose at all! We subjectively create our own recreation and avoid the open chuckle of life's purposelessness. To live is a voluntary decision, not a decision based on any non-circular proofs. In early days we forgot ourselves in war, then philosophy, literature, then machines during industrial revolution, then with logic in the IT age, maybe with content alone in future. But we will always be busy and content (or discontent for that matter). Always finding our own opiums and distractions. My take in accepting this screaming speed and in fact fast-forwarding it, is just to ensure that our own time is well (interestingly) spent, and that being it is the best way to accept it.