Disadvantages

  1. Extra download time. To be able to communicate with another CORBA object, the Java applet running in a Web browser needs an ORB to talk to. Therefore, an orblet is downloaded along with the classes that form the applet. These orblets are just other Java classes, but still need to be downloaded each time a Joe applet (in our case) must be executed.
  2. Complex technology. CORBA is a very complex technology, and enterprises eager to create CORBA-based applications must make investment in regards with new training and new architecture.
  3. No shipping of live objects. Shipping of live objects is a new notion introduced by Java RMI and, according to JavaSoft, it is one of the key features of that technology. Sending object classes between CORBA objects can be done, but it has obviously no use at all: what can a C++ object do with some Java bytecodes it has just received from an applet?

    4. However, first, few developers currently see the real use of sending live objects over the network. When JavaSoft delivers some pertinent application examples, we will be able to judge for ourselves.

    And secondly, if indeed ``shipping of live objects'' was a good idea, we could use it between two of our Java CORBA objects ...

  4. Availability of CORBAservices. Unfortunately many Object Services specified by the OMG still lack as implementation products. This is the case for both the Security Service and the Trading Service, although beta version of that last one will be available soon.
However, must of those disadvantages will be very soon out of date, as it will be explained in next chapter. CORBA, IIOP and Java have been acknowledged as the tools of choice by the Internet community for the development of both Intranet and Extranet applications. Wide industry support is now backing the pioneering efforts of early Java ORB providers like SUN, Iona and Visigenics.