The CORBA Connection

The Object Management Group's (OMG) effort to define interoperability for distributed objects began well before the current obsession with the Internet. As a result, its Common Object Request Broker Architecture (CORBA) 2 standard now looks slightly old-fashioned, though perhaps classic would be a kinder word. This is the classical view of object orientation, where all the data is encapsulated into objects that communicate by sending messages to each other via well-defined interfaces. CORBA is supported on all the major versions of Unix, on IBM's OSes, and on Windows NT. Netscape is even ad ding support for CORBA's IIOP to future versions of its products, so that you will be able to browse CORBA objects as well as Web pages. The notable missing name here is Microsoft, whose ActiveX/Component Object Model (COM) is in direct competition with (and incompatible with) CORBA (although you can bridge them together with interworking products).

The problem with CORBA is that it took such a long time to achieve a workable standard, and the result is so complex that there's still no retail market in reusable CORBA objects. Most vendors are still at the stage of selling ORBs. Many smaller developers are not prepared to wait and are settling for simpler solutions based on ActiveX or Java. Also, the existing CORBA model presupposes that objects are so large that they will stay put and send messages to each other, rather than moving around the network. (There is a request for proposal [RFP] that would extend CORBA to enable passing objects [including Java objects] by value, solving that problem to some extent.) This puts it out of step with the latest Internet/intranet thinking. It doesn't help CORBA that none of the current generation of Web browsers are IIOP-enabled.

Nevertheless, several large firms are using CORBA-based technologies successfully, including Federal Express, Boeing, Chevron Petroleum, and Motorola. Wells Fargo Bank built a mission-critical three-tier customer service system in 1993 using Digital Equipment's ObjectBroker (now owned by BEA). The learning curve for implementing CORBA is higher than for ActiveX or Java, but once that's been climbed, it seems to deliver industrial-strength results and supports features such as implementation inheritance that COM lacks.

This suggests that CORBA objects will remain part of the mix in any service-based future. But they will remain in large corporations and will stay on the server. That makes the issue of talking to CORBA objects from ActiveX and Java clients crucial. Fortunately, there are some powerfu l tools to help do this. CORBA ORBs can be made to talk to COM components--that's what ORBs do. However, programming to raw CORBA or COM interfaces is too tedious for any developer weaned on Visual Basic. Iona Technologies' Orbix offers an automation interface to ActiveX objects via Visual Basic scripting. BEA's ObjectBroker Desktop Connection goes further still. It can take the interface definition language (IDL) of a remote CORBA object and generate an ActiveX control--complete with GUI--which you can embed in any OLE container. The first version of Desktop Connection supports only objects on ObjectBroker servers, but future versions aim to support objects on any CORBA 2-compliant ORB, as well as remote COM objects.

On the Java side, JavaSoft, SunSoft, and Netscape are all working on Java support for IIOP, so that Java programs can interact with CORBA object services. Also, Visigenic Software is shipping a Java-based ORB called VisiBroker, which Netscape now bundles with its Enterprise Server 3.0. Vis iBroker contains a native implementation of IIOP as well as a tool that compiles CORBA IDL into client- or server-side Java code. Netscape's LiveConnect (a layer of the ONE architecture that enables HTML, Navigator plug-ins, Java applets, and JavaScript to interact with each other in the client) will be extended to support IIOP, so that ONE applications can access remote CORBA services as named components.