- 1 -

Comparison of Middleware Technologies - CORBA, RMI & COM/DCOM

Abhishek Patil, Rajesh Korde, Kapil Sabharwal

Michigan State University

Abstract

The goal of this project is to provide an architectural analysis of the existing distributed object oriented technologies. We have examined other aspects like the ease of programming, applications, etc. We considered a few issues to be addressed to systematically analyze and compare CORBA, Java RMI, and COM/DCOM.

Key Words

CORBA, Java RMI, DCOM, Distributed Objects, Distributed Computing

- 2 -

Table of Content

Introduction................................................................................................................. 3 CORBA........................................................................................................................ 4

Introduction............................................................................................................. 4 Providing and employing a service ......................................................................... 5 CORBA Architecture .............................................................................................. 5 STEPS in deploying the CORBA application ........................................................ 9 Benefits of CORBA .............................................................................................. 10

Java RMI ................................................................................................................... 11 Introduction........................................................................................................... 11 Architectural Details ............................................................................................. 11 Running RMI ........................................................................................................ 14 Advantages of RMI .............................................................................................. 15

DCOM....................................................................................................................... 16 Introduction........................................................................................................... 16 Architectural Overview......................................................................................... 16 Server Side ............................................................................................................ 17 Client Side............................................................................................................. 18 MTS ...................................................................................................................... 19 COM+ ................................................................................................................... 20 Benefits of DCOM................................................................................................ 21

Implementation.......................................................................................................... 22 RMI ....................................................................................................................... 22 DCOM................................................................................................................... 22 CORBA................................................................................................................. 23

Conclusion ................................................................................................................ 24 Architectural Differences ...................................................................................... 24 Programming Differences..................................................................................... 25 Application Differences ........................................................................................ 26

References ................................................................................................................. 27

- 3 -

Introduction

Distributed object computing is gaining a lot of importance in today’s computing world. An important characteristic of large computer networks such as the Internet or large corporate intranets is that they are heterogeneous. Distributed object computing methodologies aim to allow application interoperability and independence of platform, operating system, programming language and even of network and protocol. With the advent of the Internet (and other network technologies), there is a wide spread utilization of object technologies. Object oriented paradigms are increasingly getting employed in distributed environments. The use of object technologies in distributed systems gives rise to some key issues like sharing address space, sharing object, etc. In a distributed object system, each of these distributed object components interoperate as a unified whole. These objects may be distributed on different computers throughout a network, living within their own address space outside of an application, and yet appear as though they were local to an application. In this project, we focused on CORBA, Sun’s Java/RMI and Microsoft’s COM/DCOM, the three most popular distributed object paradigms for application development today. The first one, CORBA, is specified by OMG, which is the largest consortium in the software industry. CORBA has undergone an evolution ranging from CORBA 1.0 (1991) and CORBA 2.0 (1995) to CORBA 3.0, which is soon to be released. The Java environment, designed by Sun Microsystems, has probably experienced the greatest evolution recently. From the broad spectrum of the Java platform segments, we will focus on Java RMI, which targets working with distributed objects. The last platform analyzed is the Microsoft Component Object Model (COM). This platform has also been evolving gradually along the milestones OLE, COM, DCOM, and COM +. In this paper, we will focus on COM/DCOM, as this is where Microsoft targets distributed objects. This report is divided into three main sections each describing one technology, its architecture, problems in implementation and the advantages of using it. The report ends with a summary that compares the key elements amongst the three.

- 4 -

CORBA

Introduction CORBA is based on the Request-Response architecture. There is an object implementation on the server, which the client requests to execute. The client and the server object implementation do not have any restrictions on the address space, for example the client and the server can exist in the same address space, or can be located in separate address spaces on the same node, or can be located on separate nodes altogether. CORBA objects are essentially object that supports the CORBA:: Object IDL interface and the Remote references are called Object References. There is a specification of the CORBA IDL Language and how it is mapped with other languages. It essentia lly provides a means for the interface definitions. The Proxy or a local representative for the client side is called the IDL stub; the server-side proxy is the IDL skeleton. The proxy represents an object created on the client side, which is used for more functionality like support for Dynamic invocation. For Marshalling the request and the response, the information is delivered in a canonical format defined by the IIOP protocol used for CORBA interoperability on the Internet. IDL stub makes use of dynamic invocation interface for marshalling on the client side. Similarly on the server side, IDL Skeletons use the Dynamic Skeleton Interface for un-marshalling the information. The request (response) can also contain Object Reference as parameters; remote object can be passed by reference.

Fig 1 CORBA architecture (stubs are IDL stubs, DII denotes DII stub, skelet. are IDL skeletons, DSI

denotes DSI skeleton)

- 5 -

Fig 1 shows the CORBA architecture, which follows a Broker pattern [1]. The ORB is used for connecting the client and the server and it acts as a broker object. The IDL stub along with DII stub performs the client side proxy and the POA IDL skeleton (along with the DSI skeleton used for dynamic delivery) does the Server-Side proxy. Many CORBA implementations use a direct communication between the client stubs and the Server Skeleton. The Interface Repository is used for introspection (particularly in case of a dynamic invocation and dynamic delivery). The Implementation Repository is used for reactivation of servers.

Providing and employing a service For registering a service (object) with the broker, CORBA uses the Object Adapter POA which provides methods like activate_ object(), activate(). CORBA makes use of the CORBA Naming Service for providing name spaces and for mappings among the Object References and names. Object References can be obtained by a client in two ways: first, the client can ask the naming service to resolve a known name into a corresponding Object Reference; second, the client can also ask the CORBA trading service to provide a list of services (Object References) that have the properties used as the search key. The client then bounds to the server once it obtains the object reference for the implementation. The client can use two types of invocations as:

1. Static invocation and delivery: For static invocation the client is compiled with the knowledge service IDL specification. Here the proxy implements the mapped IDL interface methods with the corresponding code of the proxy being encapsulated in the IDL stub. In the same manner the IDL skeleton is the code of the server-side proxy. This implements the static delivery.

2. Dynamic invocation and delivery: For dynamic invocations, a Request object is returned by calling the create_request() method in the proxy. There is also a way to submit arguments with the request. For getting information about the target interface the Interface Repository acan be consulted. The actual dynamic invocation is initiated by calling invoke(), a method of the Request object. As far as dynamic delivery is concerned, the server-side proxy contains the Dynamic Skeleton code which delivers the request via the invoke() method supported by the PortableServer:: DynamicImplementation interface.

CORBA allows for combining static invocation at the client side with dynamic delivery at the server side and vice versa. At the server side, the choice between static and dynamic delivery is made by the server object itself (it can be determined, e. g., as a part of the registration with POA), regardless of the way a request was created, i. e., via a dynamic or static invocation.

A halfway between static and dynamic invocation is dynamic downloading of stubs which can be applied in CORBA clients implemented in Java. In this case, the client code can be compiled without employing the IDL compiler (just the knowledge about the interface form will do).

CORBA Architecture

The following sections provide a top-level view of the elements that make up the CORBA infrastructure.

Object Request Broker (ORB)

In-order for the objects to make requests and receive response from other objects remotely of locally, Object request broker (ORB) is used, which is the object bus. Using this bus, the

- 6 -

client is not aware of the mechanisms used to communicate with, activate, or store the server objects. There is predefined language called the Interface Definition Language, which achieves this. The CORBA 1.1 specifications introduced in 1991 specified the Interface Definition Language (IDL), language bindings and APIs for interfacing to the ORB. CORBA 2. 0 specifies interoperability across vendor ORBs. There are a wide variety of distributed middleware services provided by CORBA ORB. Objects can discover each during runtime and invoke each other services using the ORB. An ORB is much more sophisticated than alternative forms of client/ server middleware, including the traditional Remote Procedure Calls (RPCs)[2], Message-Oriented Middleware (MOM), database store procedures, and peer-to-peer services. Benefits that every CORBA ORB provides:

1. Static and dynamic method invocations – Using this, developers can statically define method invocations at compile time, or dynamically discover them at run time by making use of the CORBA ORB. Thus developers can make use of useful features like strong type checking at compile time or maximum flexibility associated with late (run-time) binding.

2. High-level language bindings – CORBA provides language-neutral data type and separates interface from implementation and that make it possible to call objects across language and operating system boundaries. The client and the server can be written in totally different languages. On the other hand, other types of middleware typically provide API libraries that are low-level, language-specific. This drawback that makes the API very sensitive because there is no separation between implementation and specification.

3. Self-describing system – In order to provide the client with updated information about the various server interfaces, CORBA provides run-time metadata for describing every server interface known to the system. CORBA ORB provides this information through an Interface Repository (IR) that contains real-time information describing the functions a server provides and their parameters. The clients use the metadata to discover how to invoke services at run time. It also helps tools to generate code on the fly. The metadata is generated automatically either by an IDL-language pre-compiler or by compilers that know how to generate IDL directly form an OO language, e. g. Visigenic/ Netscape's Caffeine generates IDL directly from Java byte code. CORBA is the first and also the most mature middleware to provide this type of run-time metadata and language-independent definitions of all its services.

4. Local/ remote transparency – Inter ORB interconnection is also possible in CORBA. This is achieved using the IIOP (Internet Inter-ORB Protocol). An ORB can run in standalone mode on a laptop, or it can be interconnected to every other ORB in the universe using CORBA Internet Inter-ORB Protocol (IIOP) services. An ORB can broker inter-object calls within a single process, multiple processes running within the same machine, or multiple processes running across networks and operating systems. This is completely transparent to objects.

5. Built-in security and transactions – In order to handle security and transactions across machine and ORB boundaries, the ORB includes context information in its messages. This can be useful for security and transactions.

6. Polymorphic messaging – Polymorphic messages are possible in CORBA. An ORB does not simply invoke a remote function; it invokes a function on a target object, which

- 7 -

means that the same function call will have different effects, depending on how the object receives it.

7. Coexistence with existing systems - CORBA's separation of an object's definition from its implementation is prefect for encapsulating existing application. Using CORBA IDL, a developer can make his own existing code look like an object on the ORB, even if it is implementation in stored procedures. This enables CORBA an evolutionary solution.

CORBAServices

Collections of system-level services packaged with IDL-specified interfaces are called CORBAservices. They are used to augment and complement the functionality of the ORB. OMG has published standards for sixteen object services:

The Life Cycle Service defines operations for creating, copying, moving and deleting components on the bus.

The Persistence Service provides a single interface for storing components persistently on a variety of storage servers, including Object Databases (ODBMS), Relational Databases (RDBMSs), and simple files.

The Naming Service components on the bus to locate other components by name; it also supports federated naming contexts. The service also allows objects of be bound to existing network directories or naming contexts, including ISO's X. 500, OSF's DCE, Sun's NIS+ etc.

The Event Service allows components on the bus to dynamically register or unregister their interest in specific events. The service defines a well-known object called an event channel that collects and distributes events among components that know nothing of each other.

The Concurrency Control Service provides a lock manager that can obtain locks on behalf of either transactions or threads.

The Transaction Service provides two-phase commit coordination among recoverable components using either flat or nested transactions.

The Relationship Service provides a way to create dynamic associations between components that know nothing or each other. It also provides mechanisms for traversing the links that group these components. You can use the service to enforce referential integrity constraints, track containment relationships, and for any type of linkage among components.

The Externalization Service provides a standard way for getting data into and out of a component using a stream-like mechanism.

The Query Service provides query operations for objects. It is a superset of SQL. It is base on the upcoming SQL3 specification and the Object Database Management Group's (ODMG) Object Query Language (OQL).

The Licensing Service provides operations for metering the use of components to ensure fair compensation for use. The service supports any model of usage control at any point in a component's life cycle. It supports charging per session, per node, per instance creation and per site.

- 8 -

The Properties Service provides operations that let developers associate named values (or properties) with any components. Using this service, the properties can be associated with a component's state, e. g. a title or date.

The Time Service provides interface for synchronizing time in a distributed object environment. It also provides operations for defining and managing time-triggered events.

The Security Service provides a complete framework for distributed object security. It supports authentication, access control lists, confidentiality and non-repudiation. It also manages the delegation of credentials between objects.

The Trader Service provides a "Yellow Pages" for objects; it allows objects to publicize their services and bid for jobs.

The Collection Service provides CORBA interfaces to generically create and manipulate the most common collections.

The Startup Service enables requests to automatically start up when an ORB is invoked.

CORBAfacilities

CORBAfacilities are collections of IDL-defined frameworks that provide services of direct use to application objects. The two categories of common facilities, horizontal and vertical, define rules of engagement that business components need to effectively collaborate. In October 1994, the OMG issued the Common Facilities Request for Proposal 1 (RFP1) to obtain technology submissions for compound documents. In March 1996, OMG adopted OpenDoc as its compound document technology (Distributed Document Components, DDCF). DDCF specifies presentation services for components and a document interchange standard based on OpenDoc's Bento. The Common Facilities include mobile agents, data interchange, business object frameworks and internationalization.

CORBA Business Objects:

In-order to provide a natural way for describing application-independent concepts such as customer, employee, account, payment and patient business objects are used. They encourage a view of software that transcends tools, applications, databases, and other system concepts. A business object, by definition, independent of any single application, is an application-level component that can be used in unpredictable combinations. It represents a recognizable everyday life entity. On the other hand, system-level objects represent entities that make sense only to information systems and programmers. In the CORBA model, a business object consists of three kinds of objects:

a) Business objects encapsulate the storage, metadata, concurrency and business rule associated with an active entity. They also define how the object reacts to changes in the views.

b) Business process objects encapsula te the business logic at the enterprise level. In traditional Model/ View/ Controller (MVC) systems, the controller is in charge of the process. In the CORBA model, short-lived process functions are handled by the business object. Long-lived processes that involve other business objects are handled by the business

- 9 -

process object. The process object typically acts as the glues that unites the other objects. For example, it defines how object reacts to a change in the environment.

c) Presentation Objects represent the object visually to the user. Each business object can have multiple presentations for multiple purposes. The presentations communicate directly with the business object to display data on the screen. The OMG also recognizes that there are non-visual interfaces to business objects.

The business object and the process object typically reside on a server where as the business object may have different presentation objects spread across multiple clients. The CORBA based architecture provides a unique was in which all the constituent objects have IDL-defined interfaces and can run on ORBs. It does not matter if the constituent objects run on the same machine or on different machines. As far as clients are concerned, they are dealing with a single business object component, even though it may be factored into objects running different machines.

STEPS in deploying the CORBA application

STEP 1: Defining object interfaces-The first step in creating an application is to specify is to specify all of your objects and their interfaces using the OMG's Interface Definition Language (IDL).

Writing the StockMarket interface in IDL: The StockMarket interface provides a single method get_price() for obtaining the current value of the stock.

STEP 2: Generating client stubs and server servants

Use IDL compiler(idl2java) to generate:

• Client Stub Code

• Server Skeleton Code

STEP 3: Write the client

STEP 4: Write the server object implementation code

STEP 5: Compile the client and server code

vbjc –d classes <directory_for_classes> StockMarketClient.java

vbjc –d classes < directory_for_classes> StockMarketServer.java

STEP 6: Start the Visibroker Smart Agent

osagent -c

STEP 7: Start the server (vbj StockMarketServer or java StockMarketServer)

STEP 8: Run the client application(vbj StockMarketClient or java StockMarketClient)

- 10 -

Benefits of CORBA

• Programming-language independent interface. • Legacy integration • Rich distributed object infrastructure. • Location transparency. • Network transparency • Direct object communication. • Dynamic Invocation Interface.

- 11 -

Java RMI

Introduction This is a brief introduction to Java Remote Method Invocation (RMI). Java RMI is a mechanism that allows one to invoke a method on an object that exists in another address space. The other address space could be on the same machine or a different one. The RMI mechanism is basically an object-oriented RPC mechanism.

Architectural Details

Java/RMI relies on a protocol called the Java Remote Method Protocol (JRMP). Java relies heavily on Java Object Seria lization, which allows objects to be marshaled (or transmitted) as a stream. Since Java Object Serialization is specific to Java, both the Java/RMI server object and the client object have to be written in Java. Each Java/RMI Server object defines an interface, which can be used to access the server object outside of the current Java Virtual Machine (JVM) and on another machine's JVM. The interface exposes a set of methods, which are indicative of the services offered by the server object. For a client to locate a server object for the first time, RMI depends on a naming mechanism called an RMIRegistry that runs on the Server machine and holds information about available Server Objects. A Java/RMI client acquires an object reference to a Java/RMI server obje ct by doing a lookup for a Server Object reference and invokes methods on the Server Object as if the Java/RMI server object resided in the client's address space. Java/RMI server objects are named using URLs and for a client to acquire a server object reference, it should specify the URL of the server object as you would with the URL to a HTML page. Since Java/RMI relies on Java, 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 a Java Virtual Machine (JVM) implementation for that platform [2].

Fig 2: RMI Architecture

- 12 -

Define the functions of the remote class as an interface

In the Java programming language, a remote object is an instance of a class that implements a Remote interface. The remote interface will declare each of the methods that we would like to call from other JavaTM virtual machines (JVMs). Remote interfaces have the following characteristics:

- The remote interface must be declared public. Otherwise, a client will get an error when attempting to load a remote object that implements the remote interface, unless that client is in the same package as the remote interface.

- The remote interface extends the java.rmi.Remote interface.

- Each method must declare java.rmi.RemoteException (or a superclass of RemoteException) in its throws clause, in addition to any application-specific exceptions, because remote method invocations can fail in very different ways from local method invocations (due to network-related communication problems and server problems).

- The data type of any remote object that is passed as an argument or return value (either directly or embedded within a local object) must be declared as the remote interface type not the implementation class.

Write the implementation and server classes At a minimum, a remote object implementation class must: implements a remote interface, define the constructor for the remote object and provide implementations for the methods that can be invoked remotely. A "server" class, in this context, is the class, which has a main method that creates an instance of the remote object implementation, and binds that instance to a name in the rmiregistry. The class that contains this main method could be the implementation class itself, or another class entirely.

Implement a remote interface In the Java programming language, when a class declares that it implements an interface, a contract is formed between the class and the compiler. By entering into this contract, the class is promising that it will provide method bodies, or definitions, for each of the method signatures declared in that interface. Interface methods are implicitly public and abstract, so if the implementation class doesn't fulfill its contract, it becomes by definition an abstract class, and the compiler will point out this fact if the class was not declared abstract.

As a convenience, the implementation class can extend a remote class like the java.rmi.server.UnicastRemoteObject. By extending this, the class can be used to create a remote object that:

- Uses RMI's default sockets-based transport for communication

- Runs all the time

- 13 -

Define the constructor for the remote object The constructor for a remote class provides the same functionality as the constructor for a non-remote class: it initializes the variables of each newly created instance of the class, and returns an instance of the class to the program which called the constructor. In addition, the remote object instance will need to be "exported". Exporting a remote object makes it available to accept incoming remote method requests, by listening for incoming calls to the remote object on an anonymous port. When we extend java.rmi.server.UnicastRemoteObject, our class will be exported automatically upon creation. If we choose to extend a remote object from any class other than UnicastRemoteObject, we will need to explicitly export the remote object by calling the UnicastRemoteObject.exportObject method from our class's constructor (or another initialization method, as appropriate). Because the object export could potentially throw a java.rmi.RemoteException, we must define a constructor that throws a RemoteException, even if the constructor does nothing else. The call to the superclass's no-argument constructor, super(), occurs by default (even if omitted).

Provide an implementation for each remote method The implementation class for a remote object contains the code that implements each of the remote methods specified in the remote interface. Arguments to, or return values from, remote methods can be any data type for the Java platform, including objects, as long as those objects implement the interface java.io.Serializable. Most of the core classes in java.lang and java.util implement the Serializable interface. Using a serializable object in a remote method invocation is straightforward. One simply passes the object using a parameter or as the return value. The type of the parameter or return value is the Serializable class. Note that both the Client and Server programs must have access to the definition of any Serializable class that is being used. If the Client and Server programs are on different machines, then class definitions of Serializable classes may have to be downloaded from one machine to the other. Such a download could violate system security. In RMI, by default, local objects are passed by copy, which means that all data members (or fields) of an object are copied, except those marked as static or transient. Remote objects are passed by reference. A reference to a remote object is actually a reference to a stub, which is a client-side proxy for the remote object.

Create and install a security manager One of the most common problems one encounters with RMI is a failure due to security constraints. The main method of the server first needs to create and install a security manager: the RMISecurityManager. A security manager needs to be running so that it can guarantee that the classes that get loaded do not perform operations that they are not allowed to perform. If no security manager is specified no class loading, by RMI clients or servers, is allowed, aside from what can be found in the local CLASSPATH. A Java program may specify a security manager that determines its security policy. A program will not have any security manager unless one is specified. One sets the security policy by constructing a SecurityManager object and calling the setSecurityManager method of the System class. Certain operations require that there be a security manager. For example, RMI will download a Serializable class from another

- 14 -

machine only if there is a security manager and the security manager permits the downloading of the class from that machine. The RMISecurityManager class defines an example of a security manager that normally permits such downloads [11].

Create one or more instances of a remote object

The main method of the server needs to create one or more instances of the remote object implementation, which provides the service. The constructor exports the remote object, which means that once created, the remote object is ready to accept incoming calls.

Register the remote object For a caller (client, peer, or applet) to be able to invoke a method on a remote object, that caller must first obtain a reference to the remote object. RMI system provides a remote object registry that allows to bind a URL-formatted name of the form "//host/objectname" to the remote object, where objectname is a simple string name. The RMI registry is a simple server-side name service that allows remote clients to get a reference to a remote object. It is typically used only to locate the first remote object an RMI client needs to talk to. Then that first object in turn, would provide application-specific support for finding other objects. Once a remote object is registered on the server, callers can look up the object by name, obtain a remote object reference, and then remotely invoke methods on the object. The first parameter is a URL-formatted java.lang.String, representing the location and name of the remote object. No protocol needs to be specified in the URL-formatted string. If the IP address of the server is not mentioned, the remote object host defaults to the current host. Optionally, a port number can be supplied in the URL-formatted string. Specifying the port number is necessary when the registry that needs to be contacted is running on a port other than the default port, 1099. The RMI runtime substitutes a reference to the remote object's stub for the actual remote object reference specified by the obj argument. Remote implementation objects never leave the virtual machine where they are created, so when a client performs a lookup in a server's remote object registry, a serialized instance of the stub for the implementation is returned. For security reasons, an application can bind or unbind only to a registry running on the same host. This prevents a client from removing or overwriting any of the entries in a server's remote registry. A lookup, however, can be done from any host

Running RMI

Compile the source files

To compile the source files, run the javac command as follows: javac -d [the location where to keep the resulting classfiles] –classpath [location where to look for all the .java files] <filetocomplile1>.java <filetocomplie2>.java …

Use rmic to generate skeletons and stubs

To create stub and skeleton files, run the rmic compiler on the fully-qualified package names of compiled class files that contain remote object implementations. The rmic command takes one or more class names as an argument and produces class files of the form <interfacefile_Skel>.class and <interfacefile>_Stub.class.

- 15 -

rmic -d [the location where to keep the resulting classfiles] -classpath [location where to look for all the .java files]; [location where all the required import class exist] <interfacefilename> The generated stub class implements exactly the same set of remote interfaces as the remote object itself. This means that a client can use the Java programming language's built-in operators for casting and type checking. It also means that remote objects written for the Java platform support true object-oriented

Starting the RMI registry The RMI registry is a simple server-side name server that allows remote clients to get a reference to a remote object. Typically, it is used only to locate the first remote object an application needs to talk to. Then that object in turn would provide application-specific support for finding other objects. The registry can be started as: Start rmiregistry The default registry runs at port 1099. But, to change the port to 1013, the port number can be specified at the command line: Start rmiregistry 1013

Starting the server

There are three things that go on the command line:

java –Djav.security.manager –Djava.security.policy=policy <javafile> here the policy refers to a policy file that contains the policies to be followed.

Advantages of RMI [14]

• Support seamless remote invocation on objects in different virtual machines.

• Support callbacks from servers to applets.

• Integrate the distributed object model into the Java language in a natural way while retaining most of the Java language's object semantics.

• Make differences between the distributed object model and local Java object model apparent.

• Make writing reliable distributed applications as simple as possible.

• Preserve the safety provided by the Java runtime environment.

• Single language.

• Free.

- 16 -

DCOM

Introduction DCOM is the distributed extension to COM (Component Object Model) that builds an object remote procedure call (ORPC) layer on top of DCE RPC to support remote objects. COM is an component based development model for Windows environment. A component is a reusable piece of software in binary form (as opposed to source code), that can be plugged into other components from other vendors with little effort. COM has its roots in OLE (Object Linking and Embedding), shipped with Windows 3.1. The idea of OLE was to provide an improved mechanism for dealing with compound documents and enabling things like smart documents that could embed or link Excel spreadsheet into a word document. OLE is mainly a library of predefined interfaces and default implementation of some of them. Over the years, OLE faded into background and with the release of Windows NT 4.0 in 1996, COM took center stage. COM supports component interaction on local machine, both in one address space (process) and across separate address spaces. DCOM provides the same functionality but across machines over a network.

Architectural Overview The COM server is the program that implements COM interfaces and classes. COM Servers come in three basic configurations [15].

• In-process, or DLL servers • Stand-alone EXE servers • Windows NT based services

COM objects are the same regardless of the type of server. The COM interfaces and classes don't care what type of server is being used. To the client program, the type of server is almost entirely transparent. Writing the actual server however, can be significantly different for each configuration. In-Process servers are implemented as Dynamic Link Libraries (DLL's). This means that the server is dynamically loaded into the process at run-time. The COM server becomes part of the application, and COM operations are performed within application threads. Traditionally this is how many COM objects have been implemented because performance is pretty good - there is minimal overhead for a COM function call yet we get all of the design and reuse advantages of COM. COM automatically handles the loading and unloading of the DLL. An out-of-process server has a more clear-cut distinction between the client and server. This type of server runs as a separate executable (EXE) program, and therefore in a private process space. The starting and stopping of the EXE server is handled by the Windows Service Control Manager (SCM). Calls to COM interfaces are handled through inter-process communication mechanisms. The server can be running on the local computer (COM), or on a remote computer (DCOM). Windows NT offers the concept of a service. A service is a program that is automatically managed by Windows NT, and is not associated with the desktop user. This means services can start automatically at boot time and can run even if nobody is logged on to Windows NT. Services offer an excellent way to run COM server applications.

- 17 -

There is a fourth type of server, called a "surrogate". This is essentially a program that allows an in-process server to run remotely. Surrogates are useful when making a DLL-based COM server available over the network. In COM, the request and responses are delivered via the Lightweight Remote Procedure Calls (LRPC). DCOM supports clients and servers residing on separate nodes (remote server). In DCOM, the mechanism for request and response remains the same, except DCOM replaces LRPC with Object-Oriented RPC (ORPC) that uses network protocol, developed upon the base of DCE remote procedure calls from OSF. Neither the client nor the component is aware that the wire that connects them has just become a little longer. In both COM and DCOM, remote method calls are synchronous. The following figure shows the DCOM architecture [4].

Server Side

One of the cardinal rules of COM is that a COM object can only be accessed through an interface. The client program is completely isolated from the server's implementation through interfaces. The client program knows nothing about the COM object or C++ class that implements the COM object. All it can see is the interface. Every COM object supports at least one interface called IUnknown. All custom interfaces inherit from this interface. The IUnknown interface comes with three methods, QueryInterface, AddRef and Release. Through IUnknown, it can control the lifetime of an object and invoke QueryInterface. QueryInterface is the basic function in COM through which one piece of software determines what other interfaces are supported by a component. Call to Release results in decrementing the reference count. Reference counting provides a lifetime control mechanism that allows a COM object to keep track of its clients and can delete itself when it is no longer needed. The interface consists of virtual declarations of member functions implemented by the server. Each interface has a globally unique identifier (GUID) called the IID. Similarly, each COM object class is assigned a unique class ID (CLSID). The identifier is 128 bit long hexadecimal

Fig 3: DCOM Architecture

- 18 -

number that is unqiue in the universe. These unique indentifiers (for both CLSID and IID) are entered in the system registry by the server. On the Server side, the interface and shared objects are identified along with their GUIDs in the IDL file. The IDL language used by COM/ DCOM is called MIDL. Interface specifications are compiled by the standard Microsoft IDL Compiler (also denoted as MIDL), which creates the code of sever stubs and client proxies. However, the code of stubs and proxies can be generated by other Microsoft compilers as well (e. g., by Visual C++). For the following sections in DCOM chapter, we assume server implements a CTest object that exposes an ITest interface. The interface exposes one method MethodA(). Typical interface declaration looks like the following. Note the unique GUID for the interface. uuid(37483ED1-517E-412D-A715-0737F151EE65), interface ITest : IUnknown { HRESULT MethodA([in]int* param, [out]int* retval); }; DCOM requires that all methods return a 32-bit error code called an HRESULT . At the language/tool level, a set of conventions and system provided services (called the IErrorInfo object) allows failure HRESULTs to be converted into exceptions in a way natural to the language. For example, in Microsoft Visual C++ 6.0, client programmers can use standard C++ try/catch blocks to catch errors from COM method invocations; the compiler generates the correct code to map the failure HRESULT into a correct usage of IErrorInfo, effectively translating the failure return code into an exception. Similarly, tools can allow programmers to "throw exceptions" instead of returning failure codes [4].

Client Side On the client side, the implementation varies slightly depending on the type of server (InProc or EXE). But the basic steps are the following. Continuing on from our earlier example of a CTest object on the server exposing an ITest interface. ITest *pi // pointer to xxx COM interface CoInitialize() // Initialize COM CoCreateInstance(,,,,&pi) // create interface pi->MethodA(); // call method pi->Release(); // free interface Couninitialize(); // Uninit COM CoInitialize()initializes the COM interface. Alternatively, OleInitialize() may be called, though it calls CoInitialize() internally. After initializing COM, the client instantiates the desired COM class containing the implementation of the interface, with CoCreateInstance. CoCreateInstance() takes the CLSID_CTest and IID_ITest for the interface as its arguments. It can thought to be equivalent of C++ new operator. CoCreateInstance uses the CLSID to search for a match in the HKEY_CLASSES_ROOT\CLSID section of the registry in order to locate the desired component. The third parameter is one of CLSCTX_INPROC_SERVER,

- 19 -

CLSCTX_LOCAL_SERVER, CLSCTX_REMOTE_SERVER, specifying whether the component may be available as an in-proc version, or as a local or remote version. The fourth parameter is the Interface identifier or the IID. Then the client accesses the methods exposed by the interface. After it is done using the object, it calls the Release method of the interface (always provided by IUnknown), which results in decrementing the reference count on the server. Finally, CoUninitialize() is called to perform the cleanup duties. It closes the COM library, freeing any resources it maintains and forcing all RPC connections to close. There are various versions for each of the functions mentioned above, each of which can be used in special cases. For instance, alternatives to CoCreateInstance() are CoCreateInstanceEx (used to run executable component across network using DCOM), CoGetInstanceFromFile (creates a new instance and initializes it from a file), CoGetClassObject (returns an interface pointer to a "class factory object" that can be used to create one or more uninitialized instances of the object class CLSID) etc.

MTS All the architectures described above are essentially two-tier client-server systems. This makes management of resources at the server application developer’s responsibility. This also makes interaction with legacy database servers, which are not integrated with Windows NT well, very difficult. Hence, Microsoft introduced the three-tier architecture, which consists of the usual client and database server tiers, but adds a middle tier, which handles the server object creation, deletion and requests, rather erroneously named Microsoft Transaction Server (MTS), because it handles much more than just transactions [16]. In fact, MTS is a COM component hosting environment that

• Manages system resources (e.g. processes, threads, and connections); • Manages server object creation, execution and deletion; • Automatically initiates and controls transactions; • Implements security so that unauthorized users cannot access the application; • Provides tools for configuring, managing, and deploying the application's components.

The key benefit of this is that it frees developers from many of these aspects of middle tier application development and allows them to concentrate on the business logic that they are implementing. It forms the middle tier of a distributed system and hosts the COM components that do the work. In a typical system, it uses Open Database Connectivity (ODBC) or OLE DB to connect to the database server. A very useful functionality that MTS provides is Just in Time Activation of components, which drastically reduces the number of components and database connections, when used along with Object Pooling. This is based on an observation that most of the time the client applications are waiting for the users to think and type. Only 10% of the time, it actually uses the server objects it has instantiated. So if each client application has a dedicated component in the middle tier and a corresponding database connection all this time, it would be wasting enormous amounts of resources.

- 20 -

Hence, MTS doesn’t really create a component, when the client initiates it. It waits until the client actually invokes one of the methods. MTS usually destroys the component when it has finished a method call for a client. This sounds counter-intuitive and it would be if the components had to be completely recreated each time, including all their resources such as threads and database connections. Especially the latter, because database connections are very expensive to established. Here is where it uses object pooling. Say, there are 100 different clients that are accessing the server, but at any time only 10 of these are actually using the objects. So MTS creates only 10 objects and pools many of its resources. So when a new component requires a database connection, it is given an existing one. When it is finished with it, MTS takes it back instead of closing it. The threads used to run the components are also pooled in this way. Consequently, the overhead of repeatedly creating and destroying components is reduced and, when the number of client connections is high enough, is fully compensated by the reduced resources. The load on the database will also be reduced. Microsoft suggests at least 100 users to be active for the difference in performance to appear. MTS components are dynamically created and destroyed each time they are required – Just in Time Activation. Any resources that they use are pooled and shared between the components as they run. When a client application creates a COM object it receives a reference to that object (or, more correctly, interface). If the object is destroyed this reference becomes invalid and subsequent method calls will fail. MTS needs to do something to avoid this. It also needs to maintain some state information for the client application, such as security and transaction information. This is handled by the context object. In a way, context object can be thought of as pretending to be the MTS component so that the client’s reference is always valid. When the client first creates an MTS component, the context object is created. This exists while the client holds a reference to the component. When a method is requested, the context object creates the component, runs the method and destroys the component. The exact operation of this object and MTS is more complicated. It may appear that having a context object for each client violates the idea of reducing resources by Just-in-Time Activation. However the context objects are very small, so impose far less load on the MTS server than the actual MTS components. There are a few caveats, however that accompany MTS. For the same component to be used by multiple clients, the server and server objects have to be stateless. Since, traditionally the state is usually stored in the object itself, these object cannot take advantage of the resource sharing and just-in-time activation features of MTS. It is possible to save the state on the client side or even in the end database server. MTS offers additional utilities (for example, Shared Property Manager) that help the developer in maintaining the state of the object. The other problem is that if the object themselves are small but store a lot of state for each client, recycling and pooling will actually decrease performance. Recycling and Pooling would help only if the object takes long time to create and holds up a lot of system resources [15]. The decision of whether to support recycling should be based on the expense of creating new objects vs. the cost of holding up the resources of that object while it is in the pool.

COM+ COM and MTS were introduced with Windows NT. From Windows 2000, the same services are provided by COM+, which is a combination of COM and MTS and it offers some new services that didn’t exist in COM or MTS. COM+ doesn’t replace COM/MTS, it extends it. It is backward compatible, so migrating MTS packages is simple. The improvements include a new threading model, and better way to handle database connections. COM+ also improves on COM by providing default implementations of standard COM interfaces. This relieves the programmers of

- 21 -

implementing obscure interfaces like IConnectionPoint, IconnectionPointContainer etc. It also automates writing housekeeping code, which takes up as much as 30 percent of the time for COM developers. COM is easier to program in Java and VB, than C++. Although COM claims to be a language independent binary standard for components, there are various internal implementation issues that has resulted in peculiarities regarding the way it uses and builds COM based components [15]. COM+ aims to smoothen out these differences and make a component written in any language automatically accessible to all other languages supporting COM+.

Benefits of DCOM • Large User Base and Component Market • Binary Software Integration

- Large-scale software reuse (no source code) - Cross-language software reuse.

• On-line software update. - Allows updating a component in an application without recompilation, relinking or even restarting.

• Multiple interfaces per object • Wide selection of programming tools available, most of which provide automation of

standardcode.

- 22 -

Implementation We implemented a StockMarket application for all three architectures. Each of these implementations defines an IStockMarket interface. They expose a get_price() method that returns a float value indicating the stock value of the symbol passed in. The get_price() method takes in an integer or an array of integers. This way we can measure the performance for different parameter sizes. There are a number of ways performance can be evaluated.

• The client can be made to invoke the server with different parameter sizes (like 4 bytes, 8 bytes etc). The time before sending the request and after receiving the reply is noted and the response time can be calculated. The response time can be measured in terms of total delay as well as CPU time consumed.

• Running the applications as in-process and remote-process in DCOM. • The server load can be tested by varying the number of clients making a request

simultaneously and measuring the response time. The reason for not mentioning the comparison results from the application implementation part of our project was because we could not get all the three technologies to work on one common platform and OS, so that we could compare them. Also, there was no standard tool available to benchmark the three. There are benchmarking tools available for comparing different implementations of CORBA. Perhaps, these can be ported to compare the three technologies themselves, but we didn’t get time to get into that. Only the performance evaluation criterions mentioned above were implemented. These are the evaluation criterion mentioned on the Microsoft’s DCOM website. Since, the implementation of each was done on a different machine, there was no point in comparing the results of these tests. We contacted the system manager at CSE to let us run the applications on one CSE lab machine, but this was not allowed because running some of the server involves changing system registries.

RMI In RMI, the application was implemented with the application version of the client. It can also implemented as an applet version. All the programming was done using JDK 1.1.8 with java 1.3-runtime environment. In the applet version, the client applet makes a call to the server. While implementing the application, we faced the problem of implementing the security manager. RMI is very particular about the way the security policies are implemented. A good approach is to define a policy file with all the security settings in it. From the client different test conditions specified above were tested. In case of RMI, the second test condition cannot be implemented. RMI was implemented on Windows 98, Celeron 650MHz PC.

DCOM In DCOM, we implemented the StockMarket application in two different ways. One implementation is based on the In-Proc invocation model with the server DLL being loaded at run time. The Client and Server are written in C++. The other implementation is based on the remote

- 23 -

server model, capable of being run across a network. Here the client was written in VB, while the server was in C++ and the application used COM+. Performance evaluation code for the implementations has been written. Visual Studio was used as the programming environment. However, there were some practical problems with this, because VB does not have any in-built support for measuring time in microseconds. DCOM was implemented on a P2 350 MHz machine running Windows 2000.

CORBA In CORBA, we implemented the StockMarket application using the Visibroker 4.5 and Java 2 SDK. IDL is compiled and the Server is run after which the Client application is run and the get_price() method is invoked, both of which are written in Java. The second testing case also does not apply for CORBA application. For the Server code, ORB and BOA are initialized and for the client the ORB is initialized. For performance evaluation, there needs to be some timing mechanism which gives a realistic time for using varying byte size and the number of calls per second. Jbuilder was used as the programming environment. CORBA was implemented on Windows NT platform on a P3 450MHz PC.

- 24 -

Conclusion

The architectures of CORBA, DCOM and Java/RMI provide mechanisms for transparent invocation and accessing of remote distributed objects. Though the mechanisms that they employ to achieve remoting may be different, the approach each of them take is more or less similar. The following table summarizes the differences among the three technologies.

Architectural Differences

This table describes the differences from an architectural point of view.

DCOM CORBA JAVA/RMI

Supports multiple interfaces for objects and uses the QueryInterface() method to navigate among interfaces. This means that a client proxy dynamically loads multiple server stubs in the remoting layer depending on the number of interfaces being used.

Supports multiple inheritance at the interface level

Supports multiple inheritance at the interface level

Uniquely identifies an interface using the concept of Interface IDs (IID) and uniquely identifies a named implementation of the server object using the concept of Class IDs (CLSID) the mapping of which is found in the registry.

Uniquely identifies an interface using the interface name and uniquely identifies a named implementation of the server object by its mapping to a name in the Implementation Repository

Uniquely identifies an interface using the interface name and uniquely identifies a named implementation of the server object by its mapping to a URL in the Registry

Tasks like object registration, skeleton instantiation etc. are either explicitly performed by the server program or handled dynamically by the COM run-time system.

The constructor implicitly performs common tasks like object registration, skeleton instantiation etc

The RMIRegistry performs common tasks like object registration through the Naming class. UnicastRemoteObject.exportObject(this) method performs skeleton instantiation and it is implicitly called in the object constructor.

Uses the Object Remote Procedure Call(ORPC) as its underlying remoting protocol

Uses the Internet Inter-ORB Protocol(IIOP) as its underlying remoting protocol

Uses the Java Remote Method Protocol(JRMP) as its underlying remoting protocol (at least for now)

The mapping of Object Name to its Implementation is handled by the Registry

The mapping of Object Name to its Implementation is handled by the Implementation Repository

The mapping of Object Name to its Implementation is handled by the RMIRegistry

All parameters passed between the client and server objects are

When passing parameters between the client and the remote

When passing parameters between the client and the

- 25 -

defined in the Interface Definition file. Hence, depending on what the IDL specifies, parameters are passed either by value or by reference.

server object, all interface types are passed by reference. All other objects are passed by value including highly complex data types

remote server object, all objects implementing interfaces extending java.rmi.Remote are passed by remote reference. All other objects are passed by value

Attempts to perform distributed garbage collection on the wire by pinging. The DCOM wire protocol uses a Pinging mechanism to garbage collect remote server object references.

Does not attempt to perform general-purpose distributed garbage collection.

Attempts to perform distributed garbage collection of remote server objects using the mechanisms bundled in the JVM

Programming Differences The following table summarizes the differences in programming environment offered by the three technologies. It discusses issues like server object locaters, object inheritance etc, that would be more important to the programmer.

DCOM CORBA JAVA/RMI

Every object implements IUnknown.

Every interface inherits from CORBA.Object

Every server object implements java.rmi.Remote (Note : java.rmi.UnicastRemoteObject is merely a convenience class which happens to call UnicastRemoteObject.exportObject(this) in its constructors and provide equals() and hashCode() methods)

When a client object needs to activate a server object, it can do a CoCreateInstance()

When a client object needs to activate a server object, it binds to a naming or a trader service.

When a client object needs a server object reference, it has to do a lookup() on the remote server object's URL name.

The responsibility of locating an object implementation falls on the Service Control Manager (SCM)

The responsibility of locating an object implementation falls on the Object Request Broker (ORB)

The responsibility of locating an object implementation falls on the Java Virtual Machine (JVM)

The responsibility of activating an object implementation falls on the Service Control Manager (SCM)

The responsibility of locating an object implementation falls on the Object Adapter (OA) - either the Basic Object Adapter (BOA) or the Portable Object Adapter (POA)

The responsibility of activating an object implementation falls on the Java Virtual Machine (JVM)

The client side stub is called a proxy

The client side stub is called a proxy or stub

The client side stub is called a proxy or stub

- 26 -

The server side stub is called stub

The server side stub is called a skeleton

The server side stub is called a skeleton

Allows you to define arbitrarily complex structs, discriminated unions and conformant arrays in IDL and pass these as method parameters. Complex types that will cross interface boundaries must be declared in the IDL.

Complex types that will cross interface boundaries must be declared in the IDL

Any Serializable Java object can be passed as a parameter across processes.

Each method call returns a well-defined "flat" structure of type HRESULT, whose bit settings encode the return status. For richer exception handling it uses Error Objects (of type IErrorInfo), and the server object has to implement the ISupportErrorInfo interface.

Exception handling is taken care of by Exception Objects. When a distributed object throws an exception object, the ORB transparently serializes and marshals it across the wire.

Allows throwing exceptions which are then serialized and marshaled across the wire.

Application Differences Different technologies are suited for different classes of applications and have different levels of compatibility with platforms and programming language. However, as the technologies develop, the line for suitability for applications begins to blur. The different technologies not only are suitable for most classes of applications, but even become interoperable themselves.

DCOM CORBA JAVA/RMI

Will run on any platform as long as there is a COM Service implementation for that platform (like Software AG's EntireX)

Will run on any platform as long as there is a CORBA ORB implementation for that platform (like Inprise's VisiBroker)

Will run on any platform as long as there is a Java Virtual Machine implementation for that platform (provided by a whole lot of companies in addition to JavaSoft and Microsoft)

Since the specification is at the binary level, diverse programming languages like C++, Java, Object Pascal (Delphi), Visual Basic and even COBOL can be used to code these objects

Since this is just a specification, diverse programming languages can be used to code these objects as long as there are ORB libraries you can use to code in that language

Since it relies heavily on Java Object Serialization, these objects can only be coded in the Java language

For client server programming in DCOM, using VB seemed to be the easiest.

For CORBA implementation, C++ is the easiest.

RMI works only with Java.

Best suited for Desktop Applications

Best suited for Enterprise level Applications.

Best suited for Internet Applications

- 27 -

References [1] František Plášil, Michael Stal, “An Architectural View of Distributed Objects and

Components in CORBA, Java RMI, and COM/DCOM” [2] Gopalan Suresh Raj, “DCOM, CORBA, Java-RMI – A step-by-step comparison” [3] Kari Alho, “A Comparison of CORBA, DCOM and RMI”, Helsinki University of

Technology. [4] Microsoft White Paper, “Windows DCOM Architecture”, 1998 [5] OMG, “CORBAservices Specification, Object Transaction Service”, OMG 97-3-4, 1997 [6] OMG, “CORBA 2.2 Specification”, OMG 98-2-33, OMG, 1998 [7] Sun Microsystems, “ Java Remote Method Invocation Specification”, October 1997,

http://java.sun.com/products/JDK/1.1/docs/guide/rmi [8] Sun Microsystems, “A Spring Collection”, SunSoft, September 1994 [9] Szyperski,C., “Component Software, Beyond Object-Oriented Programming”, Addison

Wesley, 1997 [10] Orfali,R., Harkey,D., “ Client/Server Programming with JAVA and CORBA”, John

Wiley, 1997 [11] RMI Tutorials - http://www.ccs.neu.edu/home/kenb/com3337/rmi_tut.html [12] RPC - http:// www-lc.llnl.gov:8080/library/all/ SR-2089_ 9. 0/ 28 [13] Getting started with RMI – http://java.sun.com/products/jdk1.1/docs/guide/rmi/ [14] Component based development – KPN Research

http://www.serc.nl/espinode/evenementen/19990525_CBD/presentaties/Nieuwenhuis/sld001.htm

[15] Guy Eddon, Henry Eddon, “Inside Distributed COM”, Microsoft Press [16] Malcolm, Matthews, “Writing MTS and COM+ components”,

http://www.dthomas.co.uk/pgResourceDL105.htm