COMPARISON AND BRIDGE BETWEEN CORBA AND DCOM

Wenjie Lin

Directed by Dr. W. Homer Carlisle

Nov. 18, 1998

What’s CORBA and DCOM ?

CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Component Object Model) are two major standards for distributed object computing.

CORBA was proposed by the Object Management Group (a consortium of 700+ companies); while DCOM was developed and advocated by Microsoft alone.

Problems

• CORBA and DCOM both provide an infrastructure for defining, constructing, deploying, accessing objects in an distributed environment, but in different ways.

• Incompatibility: Objects residing in these two systems can not communicate directly.

• A dilemma for enterprises

Questions

• What differences are there between CORBA and DCOM ?

• Can these two systems work together?

• How can these two systems work together?

Agenda

• CORBA Overview

• COM/DCOM Overview

• A Comparison between CORBA and DCOM

• CORBA/DCOM Bridge

CORBA Overview

Object Request Broker

Application Objects

CORBAServices

Naming PersistenceLife cycleTrading Event Transaction ConcurrencySecurity

Relationship Query Licensing Properties ExternalizationEvent Time

CORBAFacilitiesVertical Facilities

Horizontal Facilities

UserInterface

InformationManagement

SystemsManagement

TaskManagement

CORBA Architecture

CORBA IDL

• The services that a CORBA object can provide are expressed in an interface with a set of methods

• The interface servers as a binding contract between clients and servers.

• CORBA uses OMG Interface Definition Language• Clients and Servers written in different languages

communicate through a mapping of IDL to these languages.

Client

Client Stub Code

Object Request Broker

ObjectSkeleton Code

Object

Function Call

Client Host Server Host

CORBA Static Method Invocation

Object Request Broker

ObjectSkeleton Code

Function Call

Client Host Server Host

DynamicInvocationInterface

Client Object

CORBA Dynamic Method Invocation

module AddressBook {

struct Address { string street; string city; string state; long zip; };

struct Entry { string name; Address address; long number; };

interface BookKeeper {

readonly attribute long numberOfEntries;

boolean addEntry(in string name, in Address addr, in longnumber); boolean removeEntry(in string name); long lookupNumber(in string name); Address lookupAddress(in string name); boolean changeNumber(in string name, in long new_number); boolean changeAddress(in string name, in Address new_address);

};};

ORB

Clients Object Implementations

Object Request Broker

Interface Repository Implementation Repository

DynamicInvocationInterface

Static IDLStubs

ORBInterface

ObjectAdapters

Static IDLSkeleton

DynamicSkeletonInterfaces

CORBA Application Development

• Define the object’s interface in OMG’s IDL

• Compile the IDL

• Implement the server (providing implementation code for the interface it supports

• Compile and register the server object

• Create and compile the client program

Approaches to Server Implementation

• Inheritance Approach: The IDL compiler generates an abstract base class for server implementation. A server implementation class must extend this abstract class. The server application can simply instantiate objects of the implementation class

• The TIE approach: Client invocations are routed to the TIE object and then the TIE object delegates the call to implementation object

Server Implementation - TIE approach

Client Operation Invocations

Client Operation Invocations

TIEObject

TIEObject

IDLInterface

ImplementationObject

ImplementationObject

_tie_BookKepper.java

BookKeeperImplementation.java

The CORBA Implementation of the Sample Application - AddressBook

• The application was implemented using OrbixWeb3.0, a product of IONA technology

• The IDL file of the application defines two structures, one attributes and six operations for adding, changing, deleting an entry as well as lookup entry by name

• The server is implemented using the Inheritance approach

• Two clients were created. One was written in plain Java application, and the other was written in Java applet

module AddressBook {

struct Address { string street; string city; string state; long zip; };

struct Entry { string name; Address address; long number; };

interface BookKeeper {

readonly attribute long numberOfEntries;

boolean addEntry(in string name, in Address addr, in longnumber); boolean removeEntry(in string name); long lookupNumber(in string name); Address lookupAddress(in string name); boolean changeNumber(in string name, in long new_number); boolean changeAddress(in string name, in Address new_address);

};};

COM/DCOM Overview

COM Basics • Access to an object only through interfaces• A COM interface is structured as a table of

pointer to functions (virtual function table)• COM defines a standard way to layout virtual

function tables (vtables) in memory and to call functions through the vtables

• COM defines a base interface (IUnknown) to provide lifetime management and query objects for functionality

• COM defines a mechanism to identify objects and their interfaces uniquely worldwide

Pointer tointerface

FuncA

FuncB

…

FuncC

pFuncA

pFuncB

…

pFuncC

vtable Object withmember functions

COM Interface Pointer and vtable

IUnknown Interface

Interface IUnknown{ HRESULT QueryInterface(IID& iid, void **ppv); ULONG AddRef(void); ULONG Release(void);}

COMClient

COMClient

COMLibrary

COMLibrary

SystemRegistry

SystemRegistry

ServerBinary Code

ServerBinary Code

CLSID

CLSID

Server binary code

Inte

rfac

e po

inte

r

Creation of COM Objects

HRESULT CoCreateInstance { REFCLSID clsid, LPUNKNOWN *pUnkOuter, DWORD dwClsCtx, REFIID riid, LPVOID *ppv, };

COM Library Function for Object Creation

DCOM - COM With a Longer Wire

Client ComponentProxy Object

DCE RPC

Protocol Stack

Stub

DCOM network-protocol

SecurityProvider

DCE RPC

Protocol Stack

SecurityProvider

SCM SCM

OLE32

"CoCreateInstance"

(Remote)Activation

"CoCreateInstance"

DCOM Architecture

API function for Creatinga COM object on Remote

MachinesHRESULT CoCreateInstanceEx ( REFCLSID clsid, LPUNKNOWN *pUnkOuter, DWORD dwClsCtx, COSERVERINFO * pServerInfo, ULONG cmq, MULTI_QI rgmq[]);

DCOM Application Development

• Define the object’s interface using MIDL

• Compile the IDL file to generate proxy/stub and other supporting files

• Implement the server by providing implementation code for the interface it supports

• Compile the server implementation code and register the server executable with the system registry

• Compile the proxy/stub code to generate the proxy/stub DLL and register it with system registry

• Create and compile the client program

The DCOM Implementation of the

Sample Application • The MIDL file for this application defines an interface

named IBookKeeper which inherits from IUnknown, a library named AddressBookLib, and implementation class named CBookKeeper that will implement the IBookKeeper interface

• The MIDL file was compiled using the MIDL compiler that comes with Visual C++

• The server implementation class implements methods that the interface IBookKeeper supports, the methods of IUnknown, and some methods of the class factory

• The client program was written in Visual C++

A Comparison between CORBA and DCOM

Object Model

• Both distinct interface from implementation, and clients invoke methods through a reference

• CORBA clients access object through object reference and DCOM through interface pointer

• Both CORBA and DCOM interfaces are language independent

• CORBA achieves it through language mapping, DCOM does it though binary standard

CORBA and DCOM Interface

• Naming systems: CORBA uses a mechanism like Java Package (class name + module name), DCOM uses UUIDs

• Association of class and interface(s) it supports: CORBA follows a standard model and specified in the interface’s implementation class; in DCOM, it is specified in the IDL file, and the association is purely arbitrary

• CORBA IDL supports user-defined exception types, DCOM does not.

• CORBA supports multiple inheritance of other interfaces at the IDL level, but DCOM does not

Client/Server Architecture

• Both provides RPC-style client/server communication(client - Client Stub - network - server stub - server)

• CORBA does not specify what wire protocol for the communication within same ORBs, but specifies TCP-based protocol (IIOP) for inter-ORB communication; DCOM can use any protocols that used in DCE RPC

Server Implementation and Registration

• In CORBA, the implementation class needs only to implement the interface it supports

• In DCOM, the implementation class needs, additionally, to provide implementation for the IUnKnown interface and IClassfFactory interface if COgetClassObject() is used to object creation

• Both CORBA and DCOM server need to be registered before clients can use its services. CORBA uses Implementation Repository, DCOM uses system registry.

Method Invocation

• Both CORBA and DCOM provide static and dynamic method invocations.

• No much differences in the way of static invocation• CORBA achieves the dynamic invocation through

the use of Interface Repository and Dynamic Invocation Interface (DII), there is no difference in object implementation for static or dynamic invocation; DCOM achieves the DI through Type Library and IDispatch interface, objects that supports DI must implements the IDispatch interface

Object Lifetime Management

• CORBA manages object lifetime through its Lifetime Service.

• DCOM manages object lifetime through counting methods provided in IUnknown interface

• CORBA specification does not attempt to track the number of clients communicating with a particular object; DCOM does

Security

• CORBA’s security is provided by CORBA’s Security Service. It defines three levels of security (from non-aware to full range). Different ORB products differ widely.

• DCOM uses NT mechanism as basis of its security control. Additional security service can be provided by adding Microsoft Transaction Server.

CORBA/DCOM Bridge

The Problems

• CORBA and DCOM have their own advantages and disadvantages (i.e. CORBA’s better platform independence and exception handling, DCOM’s better user interface)

• Relying on a single infrastructure can be risky since application systems are very dependent on their infrastructure

• Current application systems exist in many enterprises

The Solution is to make CORBA/DCOM

working together

How ?

COM/CORBA Interworking through Bridge

Object reference in B

Object Model A (client) Object Model B (Server)

Object reference in A

View of Target object

TargetObject

The Interworking Model

Bridge View Object

COM Interface

Automation Interface CORBA Object

DCOMObject

OrbixCOMet Bridge View Object

Building a DCOM Client that access an existing CORBA Server

• Obtain the MIDL definition for all types defined in the corresponding OMG IDL file in the CORBA server

• Compile the MIDL file (create proxy/stub code and other supporting files to be used by the client)

• Register types in the Bridge (cputidl AddressBook.idl)• Build the Proxy/Stub DLL• Implement the client

Implementation of DCOM Client accessing a CORBA Server

• The client obtains a COM View object in the Bridgethat can forward requests to the CORBA server

• The COM View object instantiates a CORBA Factory object in the Bridge by calling CoCreateInstanceEx(IID_ICORBAFactory, …)

• The client calls GetObject() on the CORBA factory object, passing the name of the target object in the CORBA server, and returns the object reference to the target object in the CORBA server

Bridge

CORBA Server

IIOP DCOM

DCOM Client

CORBA Object Reference

COM Interface pointer

COM View

TargetCORBA Object

DCOM Client to CORBA Server

DCOM Client

Reference to factory

Reference toBookKeeper

To BookKeeperobject in remoteCORBA server

Bridge

FactoryObject

COM ViewIBookKeeper

1

23

Binding the DCOM Client to a CORBA Object

A VB Client that Accesses the CORBA Server

A CORBA Client that Accesses the CORBA Server

Conclusions• Both CORBA and DCOM provides functions for

achieving the transparent activation and accessing of remote objects. However, they provides its own programming interfaces, uses its own IDL languages, support its own data type, and uses its own wire protocols. They have their own advantages and disadvantages.

• CORBA and DCOM can be bridged to work together

• The interworking of CORBA and DCOM can take the advantages of DCOM’s strength in visual component development and CORBA’s strength in flexibility and services

Future Work

• The Bridge solution to CORBA/DCOM interworking imposes a significant amount of communication overhead. A middleware that natively supports both CORBA and DCOM will be the future. This type of future middleware should support both CORBA and DCOM at the IDL level.