In a recent article (CI No 3,257), Tom Welsh criticized a recent report by Ovum Association on Object Request Brokers. Now we give Ovum a chance to reply.
My findings on Object Request Brokers, recently published by Ovum, have proved intensely controversial, writes Ovum associate Rosemary Rock-Evans. But by focusing on the DCOM versus CORBA contest, the controversy has diverted attention from my conclusion that the real competition for ORBs comes, not from Microsoft, but from the likes of NCR and BEA. Their Distributed TP Monitors have, or are acquiring, object layers dealing with both CORBA and DCOM. They provide effectively the same services as ORBs, yet present the IS developer with a much simpler programming interface. In investigating middleware solutions I have always borne in mind the problems of the typical IS environment. Every organization has an extremely large base of technology in use, with legacy applications running on heterogeneous databases, operating systems and hardware. New development is rarely entirely new: often it provides a new perspective on a combination of existing applications and data.
Unique position
The new application needs to locate, select and invoke portions of existing applications and exchange instructions and information with them, regardless of the platform they run on, the language they are written in, or the database they use. That is the challenge. It is a complex challenge, made more so by demands for security, robustness and high transaction throughput. Luckily, the challenge is more or less the same for any new development you do, suggesting that you might be able to re-use a generic solution. Middleware, in its various forms, provides such a solution more or less off-the-shelf. In obtaining and using middleware you effectively delegate the problem to a specialist: a business that makes its living out of solving these problems and has a laboratory full of software engineers to keep up with ever changing technologies. I have, over the past year and a half, evaluated five kinds of middleware: Database Connectivity products; DCE, and RPC-based products; Message Oriented Middleware (MOM); Distributed Transaction Processing Monitors (DTPMs); Object Request Brokers (ORBs). This has put me in a unique position to compare not only the products in one category, for example Object Request Brokers, but also to assess how entirely different approaches could solve the same problems. In the mainstream IS scenario, Object Request Brokers are not the only – or even the most obvious – choice of middleware. The typical ORB exposes its services to the developer through some 700 API calls. Distributed computing in a heterogeneous environment is, of course, a complex problem, so it is no surprise that it should require a complex solution. But it is a complexity that few mainstream IS shops are well prepared to deal with. Consequently, a middleware product which provided the requisite services but presented a much simpler interface to the developer should, by rights, prove a winner in the IS environment. Especially if it delivered high levels of throughput and robustness in the face of failures in the distributed environment. But does such a product exist? Surprisingly, it does – or I should say, they do. Having evaluated Distributed TP Monitors, I have found in NCR’s Top End and BEA’s Tuxedo two products which meet these requirements and I believe they should prove winners in the mainstream IS environment. So am I saying that Distributed TP Monitors and ORBs are somehow equivalent? This is certainly not an obvious insight – nor a fashionable one. But if you line up the needs of the IS environment against the services provided by ORBs and DTPMs, as I have done in my most recent evaluation work, you will find DTPMs are better middleware than ORBs. Their traditional strength is in assuring transaction integrity and throughput, and they have long been able to do so in a distributed environment. With NCR and BEA layering object services and interface description languages
on top of their DTPMs, they have an infrastructure which supports the interworking of procedural applications with object technology, including CORBA, Java Beans, and DCOM. This leaves developers free to choose the most appropriate paradigm for the job in hand, and makes DTPMs better ORBs than ORBs. So what about DCOM? In many companies, with no middleware strategy in place, meeting the connectivity challenge falls to the programmer. Microsoft has a long-standing and highly successful marketing and education programme, targeting programmers. And with DCOM embedded in NT, it is both ubiquitous and free to any programmer in an NT environment. With programmers keen to experiment, DCOM will be adopted by many companies, not as a matter of strategy, but by default.
Highly unstable
Even if you do have an alternative strategy, given Microsoft’s dominance on the desktop, you will almost certainly have to deal with DCOM as yet another component in your heterogeneous environment. This means you have to understand thoroughly what DCOM is and what it might become. Our evaluation is that Object Request Brokers combines analysis of Microsoft’s middleware strategy, with a detailed evaluation of DCOM as it exists today. DCOM looks promising but is as yet highly unstable as a middleware foundation. Nevertheless, the proponents of CORBA have no cause for complacency. IS strategists and middleware vendors alike must prepare for interworking with DCOM as an unavoidable component of the heterogeneous, distributed environment. In the ORB world Iona has got the message and offers a commendable solution. But NCR and BEA, deliberate outsiders to the CORBA vs. DCOM wars, will have the solutions most attractive to mainstream IS.
Content from our partners
