In a second article, Tom Welsh takes a further look at Ovum’s controversial report on object request brokers
Arthur C Clarke, inventor of the communications satellite and author of 2001: A Space Odyssey, once made a perceptive remark about innovation. Every revolutionary idea, he wrote seems to evoke three stages of reaction. They may be summed up by the phrases: (1) It’s completely impossible; (2) It’s possible, but its not worth doing; (3) I said it was a good idea all along. Apparently Ovum’s middleware analysts have reached stage (2) as far as object technology is concerned. This seriously undermines the credibility of their report ‘Ovum Evaluates Object Request Brokers’, the fifth and last volume of an ambitious survey of middleware. Previous reports dealt with database connectivity, message-oriented middleware (MOM), RPC and DCE, and distributed transaction processing monitors (DTPMs).
Objectophobia
Ovum analyzed all of these expertly. Confronted by ORBs, however – the first radically innovative technology of the bunch – it has turned into a crusty old reactionary. The report says precisely nothing about the benefits of object technology. Instead we find a virulent and consistent objectophobia that seems to stem from a lack of understanding of basic object concepts. For instance, an object is, in any case, only a group of functions (methods) that have something in common. Or again, it is the use of object technology that makes the task complex. So it is not surprising to read that after our evaluation of the products, we felt that pure CORBA products were really only of interest to object purists wanting to stick to a standard based solution. Ovum’s Henk Bakker later explained: Having looked at Corba-based products, we felt that they were too difficult to implement and write applications for. We have in mind here a mainstream enterprise IS shop, not a laboratory full of propeller heads. But if a mainstream enterprise IS shop is defined as one that uses procedural languages to program relational databases using MOM, RPCs and DTPMs, Ovum’s argument is circular. When Arabic numerals and the digit zero were introduced, no doubt there were diehards who argued that these new-fangled methods were far too difficult to understand, and plain folks would be better sticking to Roman numerals. Fortunately today’s younger developers cut their teeth on C++ and Java, and find OO concepts perfectly straightforward. Ovum complains that CORBA is too difficult to program and says that access to code on non-object-based programming languages [is] virtually impossible. Andrew Watson, chairman of OMGs Architecture Board, begs to differ. Actually, CORBA’s first language mapping was to C, he points out, and the most recent to COBOL. Legacy application integration has turned out to be one of CORBA’s greatest strengths. Serious factual errors. In a previous article I pointed out half a dozen serious factual errors and omissions in the ORB report. Based on research that was up to two years out of date, Ovum said that CORBA products do not interoperate (they do), that IIOP doesn’t work (it does), and that few platforms were supported (at least 30). Ovum also said that CORBA is hardly being used seriously, and that there is little tool support. In fact over 260 organizations have publicly announced their adoption of CORBA, including many of the world’s major banks, financial institutions, telecom providers, oil companies, airlines, hospitals, utilities, engineering firms and government agencies. And practically every client/server tool vendor – with the predictable exception of Microsoft – supports CORBA or will do so soon. The four leading database suppliers IBM, Informix, Oracle and Sybase have all announced new architectures based on CORBA/IIOP, as have the two best known systems management specialists, Computer Associates and Tivoli.
Bland conclusions
IIOP is used by Netscape Communicator, the world’s most popular web browser, and has been adopted by Sun as the underlying protocol for Java’s Remote Method Invocation (RMI). In her reply Rosemary Rock-Evans fell back on safer ground by repeating some of the report’s blandest conclusions – that DTPM’s provide more transaction processing functionality than ORB’s, and that many organizations will fail to adopt any middleware strategy and end up using Microsoft’s DCOM because it takes less effort. She praised future products such as BEA’s Iceberg and NCR’s Top ORB, which will put OO interfaces on top of existing DTPM’s. Of course vaporware has no defects, but how does this differ from the CORBA approach? Not much, because BEA and NCR plan to use CORBA, IIOP and the CORBA Object Transaction Service (OTS) in their future products – as Visigenic and Hitachi have already done in TPBroker, Tandem in NonStop DOM, Iona and Transarc in OrbixOTS, and Sybase in Jaguar. For a contrasting view of CORBA and DTPMs, it is worth glancing at the book Instant CORBA by Robert Orfali, Dan Harkey and Jeri Edwards. For the last four years, the authors declare, our perennial questions to the ORB vendors have been How do you scale the server side? Where’s the load balancing? Where’s the fault tolerance? Exactly the features that Ovum finds lacking in ORBs. Four years later, they admit, it finally dawned on us that we were barking up the wrong tree.The ORB vendors are simply communications middleware providers. And middleware communications providers do not normally deal with these issues.
Next generation
Content from our partners
You don’t normally purchase a mission-critical server framework from your TCP/IP stack vendor. So who’s going to provide this mission-critical stuff? Orfali, Harkey and Edwards are quite clear about that. It should come as no surprise that Object Request Brokers (ORBs) like CORBA and DCOM are being considered the next generation TP Monitors. What do the DTPM vendors get out of this alliance? The distributed object infrastructure provides TP monitors with myriads of standard services including metadata, dynamic invocation, persistence, relationships, events, naming, component factories, licensing, security, collections, and many others. These are services TP Monitor vendors will not have to recreate. So there you have it: ORBs and DTPMs are going to merge, to the advantage of both. Oh, by the way, who are these people who so confidently lay down the law about middleware? Orfali and Harkey are distributed object consultants for IBM, and Edwards is VP of Strategy and Product Planning at BEA.
