A Detailed Comparison of CORBA, DCOM and Java-RMI

download A Detailed Comparison of CORBA, DCOM and Java-RMI

of 14

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of A Detailed Comparison of CORBA, DCOM and Java-RMI

  • 8/7/2019 A Detailed Comparison of CORBA, DCOM and Java-RMI


    A Detailed Comparison of CORBA, DCOM and Java/RMI

    (with specific code examples)

    Gopalan Suresh Raj


    Distributed object computing extends an object-oriented programming system by allowing objects to be

    istributed across a heterogeneous network, so that each of these distributed object components interoperate unified whole. These objects may be distributed on different computers throughout a network, living within

    heir own address space outside of an application, and yet appear as though they were local to an application.

    Three of the most popular distributed object paradigms are Microsoft's Distributed Component Object Mod

    DCOM), OMG's Common Object Request Broker Architecture (CORBA) and JavaSoft's Java/ RemoteMethod Invocation (Java/ RMI ). In this article, let us examine the differences between these three models

    rom a programmer's standpoint and an architectural standpoint. At the end of this article, you will be able tobetter appreciate the merits and innards of each of the distributed object paradigms.

    CORBA relies on a protocol called the Internet Inter-ORB Protocol (IIOP) for remoting objects. Everythin

    he CORBA architecture depends on an Object Request Broker (ORB). The ORB acts as a central Object Buover which each CORBA object interacts transparently with other CORBA objects located either locally or

    emotely. Each CORBA server object has an interface and exposes a set of methods. To request a service, aCORBA client acquires an object reference to a CORBA server object. The client can now make method calls on

    he object reference as if the CORBA server object resided in the client's address space. The ORB is responsib

    or finding a CORBA object's implementation, preparing it to receive requests, communicate requests to it and

    arry the reply back to the client. A CORBA object interacts with the ORB either through the ORB interface orhrough an Object Adapter - either a Basic Object Adapter (BOA) or a Portable Object Adapter (POA) .

    Since CORBA is just a specification, it can be used on diverse operating system platforms from mainframes to

    UNIX boxes to Windows machines to handheld devices as long as there is an ORB implementation for thatplatform. Major ORB vendors like Inprise have CORBA ORB implementations through their VisiBroker produ

    or Windows, UNIX and mainframe platforms and Iona through their Orbix product.

    DCOM which is often called 'COM on the wire', supports remoting objects by running on a protocol called theObject Remote Procedure Call (ORPC) . This ORPC layer is built on top of DCE's RPC and interacts with CO

    un-time services. A DCOM server is a body of code that is capable of serving up objects of a particular type a

    untime. Each DCOM server object can support multiple interfaces each representing a different behavior of thobject. A DCOM client calls into the exposed methods of a DCOM server by acquiring a pointer to one of the

    erver object's interfaces. The client object then starts calling the server object's exposed methods through thcquired interface pointer as if the server object resided in the client's address space. As specified by COM, a

    erver object's memory layout conforms to the C++ vtable layout. Since the COM specification is at the binaryevel it allows DCOM server components to be written in diverse programming languages like C++, Java, Obje

    Pascal (Delphi), Visual Basic and even COBOL. As long as a platform supports COM services, DCOM can be use

    on that platform. DCOM is now heavily used on the Windows platform. Companies like Software AG provideCOM service implementations through their EntireX product for UNIX, Linux and mainframe platforms; Digita

    or the Open VMS platform and Microsoft for Windows and Solaris platforms.

    ava/ RMI relies on a protocol called the Java Remote Method Protocol (JRMP ). Java relies heavily on Jav

    Object Serialization, which allows objects to be marshaled (or transmitted) as a stream. Since Java Object

    Page 1 oDCOM,CORBA,Java-RMI - A Step by Step Comparison by Gopalan Suresh Raj


  • 8/7/2019 A Detailed Comparison of CORBA, DCOM and Java-RMI


    Serialization is specific to Java, both the Java/RMI server object and the client object have to be written in JavEach Java/RMI Server object defines an interface which can be used to access the server object outside of the

    urrent Java Virtual Machine(JVM) and on another machine's JVM. The interface exposes a set of methods whi

    re indicative of the services offered by the server object. For a client to locate a server object for the first timRMI depends on a naming mechanism called an RMIRegistry that runs on the Server machine and holds

    nformation about available Server Objects. A Java/RMI client acquires an object reference to a Java/RMI servobject by doing a lookup for a Server Object reference and invokes methods on the Server Object as if the

    ava/RMI server object resided in the client's address space. Java/RMI server objects are named using URLs aor a client to acquire a server object reference, it should specify the URL of the server object as you would wi

    he URL to a HTML page. Since Java/RMI relies on Java, it can be used on diverse operating system platforms

    rom mainframes to UNIX boxes to Windows machines to handheld devices as long as there is a Java VirtualMachine (JVM) implementation for that platform. In addition to Javasoft and Microsoft, a lot of other companie

    have announced Java Virtual Machine ports.

    Comparing Apples to Apples

    CORBA 3.0 will add a middleware component model (much like MTS or EJB) to CORBA. Since it is still in a prepec stage, we do not know much about how the CORBA middleware component model is going to look like. A

    CORBA 2.x, there is no middleware component model that CORBA defines. Though I would really like to compare MJB and CORBA 3.0's middleware component model (whatever it's going to be called) , I reserve it for a future article (Cli

    Here...). By the way, there is a lot of comparison going on between COM and EJB. This is entirely wrong. This is

    ke comparing apples to oranges. The competing technologies are MTS and EJB. Hence, the real comparisonhould be between MTS and EJB.

    Application Sample - The StockMarket Server and Client

    The StockMarket server reports the stock price of any given symbol. It has a method called get_price() to g

    he stock value of a particular symbol.

    have selected Java as the implementation language for these examples here for three reasons :

    1. Java/RMI can only be implemented using Java.2. Since I am comparing Java/RMI with other object technologies, I would have to implement the DCOM an

    CORBA objects too in Java.3. Java is the best language to code CORBA and COM objects in since it keeps the implementation simple,

    easy to understand, and is most elegant.

    Each of these implementations define an IStockMarket interface. They expose a get_price() method that

    eturns a float value indicating the stock value of the symbol passed in. We list the sources from four files. The

    irst set of files are the IDL and Java files that define the interface and its exposed methods. The second set oiles show how the client invokes methods on these interfaces by acquiring references to the server object. Th

    hird set of files show the Server object implementations. The fourth set of files show the main programmplementations that start up the Remote Server objects for CORBA and Java/RMI. No main program

    mplementation is shown for DCOM since the JavaReg program takes up the role of invoking the DCOM Serverobject on the Server machine. This means you have to also ensure that JavaReg is present on your server


    The IDL Interface

    Whenever a client needs some service from a remote distributed object, it invokes a method implemented by emote object. The service that the remote distributed object (Server) provides is encapsulated as an object a

    he remote object's interface is described in an Interface Definition Language (IDL). The interfaces specified in

    he IDL file serve as a contract between a remote object server and its clients. Clients can thus interact with

    Page 2 oDCOM,CORBA,Java-RMI - A Step by Step Comparison by Gopalan Suresh Raj


  • 8/7/2019 A Detailed Comparison of CORBA, DCOM and Java-RMI


    hese remote object servers by invoking methods defined in the IDL.

    DCOM - The DCOM IDL file shows that our DCOM server implements a dual interface. COM supports both st

    nd dynamic invocation of objects. It is a bit different than how CORBA does through its Dynamic Invocationnterface (DII ) or Java does with Reflection. For the static invocation to work, The Microsoft IDL (MIDL)

    ompiler creates the proxy and stub code when run on the IDL file. These are registered in the systems registo allow greater flexibility of their use. This is the vtable method of invoking objects. For dynamic invocation to

    work, COM objects implement an interface called IDispatch. As with CORBA or Java/RMI, to allow for dynaminvocation, there has to be some way to describe the object methods and their parameters. Type libraries ariles that describe the object, and COM provides interfaces, obtained through the IDispatch interface, to quer

    n Object's type library. In COM, an object whose methods are dynamically invoked must be written to supporDispatch. This is unlike CORBA where any object can be invoked with DII as long as the object information