Bringing CORBA-based designs to life faces a multitude of obstacles.
Lately, the Object Management Group (OMG) and its Common Object Request Broker Architecture (CORBA) have generated a lot of activity. Promises of open object capabilities and object distribution have been widely marketed, and major standardization has taken place to provide industry-wide interoperability. Tool makers are clambering to the standards and providing OMG compatibility. Is this a new wave of a technology that will change the face of computing, or is it just the latest wave of hype to sweep distributed computing since DCE?
As more vendors migrate toward object-oriented approaches and infrastructure, OMG continues to play a larger role in setting standards and direction. Developers of object-oriented technology have greatly relied on OMG's ability to define the future of object infrastructure. Recently, OMG has defined enough of the architecture to make object middleware a reality to the industry. The technology has been created, documented, and presented -- but has it really been proven?
How many companies really implement the technology successfully? I took this question to a conference of professionals who claimed to be using the technology and tried to find some who had implemented and deployed it. Out of some 40 or so people I talked to, I found only three who had succeeded. Although this is hardly a scientific study of OMG projects, it does indicate far less success in building up CORBA-based designs than portrayed by the press. Further, I have spent the last three years researching next-generation object middleware and working with companies that had encountered problems in using OMG on a large scale.
Does this stuff really work? Are you taking a risk in using CORBA? These questions weigh heavily on the minds of developers as rumors of CORBA failures permeate the industry. Large-scale distribution problems plagued CORBA a year or so ago, back before the OMG changed their transport mechanism from a remote procedure-type call (RPC) to a socket-oriented call. Early on, CORBA was heavyweight. Between the overhead of the RPC and the demands of the implementation, CORBA approaches never made it to deployment.
Since then, the transport mechanism has changed to much faster socket calls, and ORB makers have learned how to make their software implementations much lighter weight. Is it safe? We'd better hope so. Now it's even being put on the Internet in the form of the Netscape ONE project as the object infrastructure. If a developer can't dispatch to 15,000 field people per hour using CORBA, how can you hook up 30 million people to it on the World Wide Web? Several large-scale projects are currently becoming the guinea pigs for OMG, but we still have no successful large-scale implementations to point to. The ones that are deployed are so lightly loaded that they provide no real test of the technology.
The cure is to combine calls -- a rule of thumb in building up CORBA objects. Although this solution has both client and server change implications, it is solvable. If the functions are regrouped, chances are that both the client and server software must be updated. The usual preference is to change only the server side so that client software doesn't have to be updated or redistributed.
Another common oversight takes place when a system is integrated and tested on a small scale but distributed on a large scale and no longer performs adequately. Most of the time, the problem lies in the use of the Dynamic Invocation Interface (or DII). The SII, the Static Invocation Interface, compiles the interface definition language (IDL) and binds to an object. In binding, the shell object you have on the client side is brokered and matched up with a server-side object that is real. When you call the methods with the SII on the object, things move pretty quickly -- everything's set up to make the call. But in larger applications it's not viable to statically compile and bind to all the objects you may need. Instead, the DII is used to attain access to an object dynamically. The overhead involved causes client delays and increased network loading. The operations of the DII are much more complex than those of the SII, and they require more network traffic. When a lot of people use the DII, the network traffic goes up -- along with server overhead -- and things slow down.
The answer, which doesn't work in many cases, is to statically bind to objects that you access most frequently. Most of the time this binding can't be accomplished because of how the application is implemented or how objects are shared in the system. Because of increased network traffic, communications saturate the network, and performance degrades with additional users. By using a smaller client/server ratio and adding more servers, this problem can usually be cured (although the process may be prohibitively expensive).
The last problem is inherent to what you are doing: distributing the system or objects in the system. This distribution really forces implementers of the technology to distribute portions of their database across objects to get the distributed benefits of the technology. In doing so, you force the user to do distributed joins across multiple objects. Joins take information from one table and correlate it to another table in a database. If the two tables are in separate locations, the act of coordinating the join must be done across the network. These joins require a lot of system resources to execute; if you lock the table, no one else can use it. This hogging of resources and the slow speed of the transport mechanism create major performance problems.
Again, the solution doesn't always translate well to applications. Often, one of the joined tables must be replicated locally within the database so that the join does not occur across the network. Also, partitioning the tables into the same database instance can help at times.
Architectural problems also have surfaced. The object-oriented community has given a half-warm reception to OMG. The group's efforts were perceived as open-systems-driven, as opposed to object-oriented-driven. Many people involved in OMG early on were standards people, not OO people. As a result, CORBA's object orientation has also come into question. OMG designed CORBA and IDL to be able to hook into different programming environments such as Cobol and 4GL. In doing so, it set a lower common denominator of functionality from the object-oriented model, thereby removing many of the benefits of using objects as well as the richness of the object language.
The problem with objects in the OMG architecture is that they are relatively flat. They can be thought of as function calls grouped into a library or class. You can't inherit from these objects. If these objects contain other embedded objects, you can't navigate the top object to get to the embedded object; they just serve as a flat interface.
The database interface that OMG adopted by way of the ODMG is also pretty flat. The Object Database Management Group used an OODBMS vendor's technology in defining its database interface; and although the interface deals with objects, it is just an object view of a relational database. In relational database technology, when you do a query, you get your information back in a view. With the ODMG interface, the only difference is that the view is replaced with a class that has a method for each column, and one object is returned for each row. The object can't be navigated. It has no binding to the object in the database. If the binded object's table has a foreign key, you can't automatically navigate off that key to get to another table -- once again, because of the flatness of the objects.
What about distributed databases with tables on different database instances that need to be joined? The OMG-defined database interface can only deal with one instance of a database at a time. There are no capabilities for dealing with distributed information within a system.
Then there are support problems: You have all your objects and your big distributed system. How do you distribute these objects and manage them in the system? How do you move objects around in the system without affecting the binding in place? Centralized object managers that control, allocate, provide security, or change the distribution of the system are nonexistent.
Another problem involves the lack of transactional support among object request broker (ORB) vendors. OMG transactional standards for ODMG are somewhat new, with ORB makers starting to provide support. A lot of these companies provide proprietary transaction support through the use of X/Open's XA interface, which was developed as a portable transactional programming standard. Some ORB makers don't provide any transactional support and leave it to the user to either integrate a transaction monitor or provide a proprietary transaction interface.
Most application builders are developing their own object management and transactional implementations tools. OMG has now defined this behavior and standardized on it, leaving those who have done it themselves with non-standard OMG facilities.
Unfortunately, CORBA bears some disturbing parallels to its predecessor. Both implementations use IDL to define interface formats. Interpreting IDL on the fly with dynamic connections to server objects adds significant overhead. CORBA services almost mirror the DCE service suite, with CORBA's naming and directory services split, instead of together as in DCE. DCE has time and thread services, and CORBA has pretty much the same components. Obviously, the involvement of the Open Software Foundation (OSF) in the development of OMG has practically guaranteed DCE's influence in the CORBA architecture.
If DCE won't work on a highly distributed scale, how will CORBA, an inherited technology, operate as a common system interface that is even more distributed? What was done differently in CORBA? There doesn't seem to be a large difference. OMG provides some vertical market facilities that weren't part of DCE, and there are more options for binding. But other than that, CORBA's network approach and system architecture is quite similar and will probably behave in a similar fashion.
Next time CORBA is brought up in conversation, try replacing the word CORBA with DCE and see how much sense the conversation makes. Would you put DCE on your local LAN? Of course not. Its resource requirements would never let you achieve your desired performance targets. CORBA is actually even more complex. CORBA is DCE, and it should be treated as such. OSF couldn't get its last incarnation of middleware to work efficiently, and now it wants you to buy the next generation. If it couldn't prove that DCE works, then why use the same faulty technology to launch another standard?
It will probably take another two years for OMG to sufficiently standardize its services and facilities to address full distributed systems and management mechanisms. For now, many tools exist for implementing an OMG approach, but the gaps are still evident. No product will distribute your system for you, but it would be nice to have the tools to help accomplish the task. The available tools lack these features, and therefore some of the current ORB offerings for CORBA are incomplete.
As OMG takes its time defining its standards and capabilities, will other technologies evolve to make the OMG approach obsolete? A good standard may last 10 years before becoming out of date. If it takes 10 years to define a standard, odds are it will be obsolete by the time it is completed.
Already, new technology such as rules-based messaging, true OO infrastructure, alternate transaction paradigms, and new models for dealing with databases are becoming common. Can a large undertaking such as CORBA provide adequate performance, fill the missing functionality gaps, and be delivered before it is overtaken by newer technology?