IT Standards Logo

    CORBA: Its Consortium, Competition, and Criticisms

    by
    Ellen Fischer

    CORBA Competition and Criticism

    It seems CORBA’s success as a de facto standard (as well as an ISO Standard) should be guaranteed since it is created by the industry organizations who will develop and use the products. In fact, OMG claims it "has the backing of every major vendor in the computer industry ..." (ovumpr.htm). CORBA’s underlying protocol, IIOP (Internet Inter-ORB Protocol), apparently is becoming a de facto standard. For example, Java’s Remote Method Invocation and Visual Edge’s Network Ease for Applets, which are two products competing with CORBA for client-server communications, use IIOP. In fact JavaSoft decided to replace its proprietary protocol for RMI with IIOP (Foody, p. 24). CORBA itself, though, has growing competition for its status as a de facto standard. While many alternatives such as RMI and Network Ease for Applets are inferior to CORBA in overall capability (Foody, p. 32), Microsoft’s Distributed Component Object Model will provide significant competition to CORBA.

    Java

    The major attraction of Java, in addition to being object-oriented, is that it is platform-independent. Java’s "Write Once, Run Anywhere" slogan explains that one piece of software written in Java can run on any machine (www.javasoft.com). For new software development ventures, then, Java is suitable for bridging existing hardware platforms. In this case, Java’s RMI, which allows distributed Java objects to be called by Java programs on the network, is completely suitable. Most companies with existing infrastructures, however, are not able to use Java for all their applications; for example, they may have legacy applications which are not easily replaced. In this case, distributed computing must be able to cross language boundaries; new Java programs will have to be able to interact with those written in C, COBOL and other languages. This is the inherent advantage of CORBA. CORBA provides a standard interface for integration of many languages.

    David Curtis of the OMG prepared a white paper about the competition and relation between Java RMI and CORBA. He argues many of the points made about CORBA’s broad range of application as opposed to Java’s limited range, describing the difference well by explaining that Java RMI is a programming technology, whereas CORBA is an integration technology. He concludes Java and CORBA are "complementary technologies" (wpjava.htm). According to Java Report, this idea of complementary use is supported in the marketplace, as "[c]ompanies like Netscape, Sun, IBM, Corel, and many others have committed to making Java the cross-platform language standard and CORBA the distributed object standard" (Petschulat, p. 43).

    DCOM

    DCOM was Microsoft’s proprietary method of distributed computing and is now governed by the ActiveX Consortium (dcomtec.exe). DCOM uses Microsoft’s COM/COM+, which is Microsoft’s Component Object Model for incorporating objects in its systems (www.microsoft.com/com). DCOM provides many of the same features as CORBA, but was not designed to be open and applicable across many platforms as CORBA was. As RMI allows Java-to-Java language integration, so DCOM was designed to allow Microsoft-to-Microsoft product integration. RMI is for the integration of one language across many operating systems and DCOM is (or, rather, was -- see below) for the integration of many languages across one brand (Microsoft) of operating systems. Thus, DCOM is prone to the same criticisms as RMI -- that it does not account for the variety of platforms in companies’ computing environments. Yet, the existing Microsoft base as well as Microsoft’s projected growth makes DCOM a more likely competitor to CORBA, as organizations may rely almost exclusively on Microsoft systems.

    Microsoft’s threat to CORBA was recently made even greater, though, since DCOM is now being ported to non-Microsoft platforms. First, in Fall 1997, Software AG introduced the first of several ports to UNIX platforms; in particular, Software AG released a port to Sun Microsystems Inc.’s Solaris operating system (Object Magazine, p. 12). Then, in late January 1998, Microsoft announced that it will now use its own developers to port COM and DCOM technology to UNIX platforms (Zelnick).

    The perceived threat to CORBA by DCOM ranges from minimal to significant. In terms of the ports of DCOM to other systems, DCOM has a long way to go to catch up to CORBA. Not only is CORBA supported on over 30 platforms, it is supported on more Microsoft platforms than DCOM is (ovumpr.htm). One Object Magazine reporter apparently believes that DCOM will still be limited to companies with Microsoft infrastructures, despite the UNIX ports, and writes, "Analysts, however, doubt that DCOM will hold much initial attraction for large enterprise developers. After all, they note, CORBA is already up and running in dozens of large, international companies" (Object Magazine, p. 12). In the same issue, however, Alan Ewald and Mark Roy described COM+, writing that "[n]one of [the CORBA and Java vendors] have achieved the kind of seamless integration across development and management tools, infrastructure services, and the operating system that Microsoft promises with COM+" (Ewald and Roy, p. 18). This sentiment is echoed by Roger Sessions who compares CORBA negatively to Microsoft’s models, saying of COM and DCOM, "There’s a vision behind this" (Carr). This vision is being strengthened with the Internet Draft work-in-progress (dated January 1998) for the Distributed Component Object Model Protocol -- DCOM/1.0 to be approved as an Internet Engineering Task Force standard (draft-brown-dcom-v1-spec-02.txt).

    CORBA has also seen DCOM (as well as Java) as complementary, particularly since DCOM was limited to Windows platforms. CORBA claimed in 1997, "DCOM won’t ‘triumph’ over CORBA but rather continue to coexist with it. It is important to note that this coexistence is made possible due to work done by the OMG in allowing DCOM, Microsoft’s desktop object model, to interwork with CORBA enterprise applications" (ovumpr.htm). But, in other January 1998 news, Microsoft and IONA technologies announced that IONA had licensed COM for integration in Orbix, its CORBA product. So, rather than mapping DCOM to CORBA, as has been done in other products, Orbix will allow DCOM and CORBA to work side-by-side; "this means that communications between an ORB and a Windows client will be performed in DCOM, while inter-ORB communication will be in IIOP ..." (Zelnick). As IONA’s chief technical officer said, "COM is a very important technology in the marketplace, and we need to make sure that everything we do with Orbix works well with COM" (Ionapr.htm) IONA describes itself as being "in the business of making software work together"; so, the company’s philosophy seems to be that IONA should follow trends rather than try to force the market in one direction. This philosophy of IONA, which is one of the leading CORBA-compliant ORB vendors, and its application in the impending COM-CORBA product, may not make DCOM supplant CORBA, but will certainly narrow CORBA’s domain.

    General Criticisms

    Some early criticisms of CORBA centered around the fact that CORBA’s specification of an ORB is not detailed enough. That is, as noted, CORBA specifies a basic interface, but allows varying implementations and additions by vendors. Martin Libicki wrote of CORBA, "OMG deliberately chose to standardize practices and syntaxes and abjure specifying the fine details of every sort of object. The result may be guidelines so loosely defined that conformance may leave applications generally unable to trade objects without considerably more hand-tooling" (Libicki, p. 339). This conclusion is not difficult to arrive at when one reads of the many vendor-specific ORBs which advertise unique capabilities. Following the previous statement, Libicki noted that a version of CORBA slated for late 1994 was expected to help interoperability between ORBs.

    In fact, the solution Libicki referred to was the introduction of IIOP, which was made part of the CORBA standard with the express purpose of ensuring that all CORBA-compliant ORBs could interoperate. A demonstration that ORBs across vendors do interoperate is provided by CORBAnet at www.omg.org/news/corbanet.htm, which was set up in 1996. CORBAnet is a sample room-scheduling application which shows 7 ORBs and 12 vendors working together (ovumpr.htm). Yet, the OMG is still fighting the image that approved ORBs do not interoperate. This seems to be based partly on out-dated information which is easily rebutted. For example, the report "Ovum Evaluates Object Request Brokers", released in 1997, supports such contentions about lack of interoperability by citing "facts" and statistics true several years prior, but no longer correct (ovumpr.htm).

    In part, however, this criticism about interoperability seems to be based on solid ground. The comment David Chappell wrote of component vendors, "[U]ltimately, each of these vendors wants you to commit to its product, and so each will probably do its level best to create proprietary elements," (Chappell, p. 22) is equally true of ORB vendors. Several articles in the March 1998 Java Report issue support these claims. One author notes, "each ORB has its own strengths and weaknesses" (Foody, p. 28). Another author cites some of the advantages of Visigenic’s ORB, VisiBroker: "VisiBroker is CORBA 2.0-compliant and also comes with some extra features such as automatic fault tolerance, HTTP tunneling, and the ability to pass java objects by value" (Petschulat, p. 44). Also, he writes, "VisiBroker allows you to declare your CORBA objects using standard Java interface classes. If you prefer to have IDL definitions for all of your classes, it comes with a tool called java2idl, ..." (Petschulat, p. 46). So, it seems clear that inter-ORB interoperability can only be guaranteed at a very basic level and a company must sacrifice blanket interoperability in order to utilize the extra, very useful, features provided with each ORB. The OMG cites the flexibility given to vendors and companies to create tailored ORBs as a strength of the CORBA specification (ovumpr.htm and wpjava.htm), but it has been said of CORBA as with Java, it is a "least common denominator" solution.

    Introduction| The Work of the Object Management Group| CORBA Technology| Top of Page| References and Links

    Ellen Fischer, March 30, 1998