1. COMPARISON AND BRIDGE
BETWEEN CORBA AND DCOM
Wenjie Lin
Directed by Dr. W. Homer Carlisle
Nov. 18, 1998

2. 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.

3. 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

4. Questions
• What differences are there between CORBA
and DCOM ?
• Can these two systems work together?
• How can these two systems work together?

5. Agenda
• CORBA Overview
• COM/DCOM Overview
• A Comparison between CORBA and
DCOM
• CORBA/DCOM Bridge

6. CORBA Overview

7. CORBAFacilities
Vertical Facilities
Application
Horizontal Facilities
Objects
User Information Systems Task
Interface Management Management Management
Object Request Broker
Naming Trading Life cycle Persistence Event Transaction Security Concurrency
Relationship Query Event Licensing Properties Time Externalization
CORBAServices
CORBA Architecture

8. 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.

9. CORBA Static Method Invocation
Client Host Server Host
Client Object
Client Object
Stub Skeleton
Code Code
Function
Call Object Request Broker

10. CORBA Dynamic Method Invocation
Client Host Server Host
Client Object
Dynamic Object
Invocation Skeleton
Interface Code
Function
Call Object Request Broker

11. 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 long
number);
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);
};
};

12. Clients Object Implementations
Static Dynamic ORB Object Static Dynamic
IDL Invocation IDL Skeleton
Interface Adapters
Stubs Interface Skeleton Interfaces
Object Request Broker ORB
Interface Repository Implementation Repository

13. 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

14. 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

15. Server Implementation - TIE approach
Client
Client
Operation Implementation
Implementation
Operation Object
Invocations
Invocations Object
BookKeeperImplementation.java
IDL TIE
TIE
Interface Object
Object
_tie_BookKepper.java

16. 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

17. 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 long
number);
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);
};
};

19. COM/DCOM Overview

20. 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

21. COM Interface Pointer and vtable
pFuncA FuncA
pFuncB FuncB
Pointer pFuncC FuncC
to
interface
… …
Object with
vtable member functions

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

23. Creation of COM Objects
COM
COM
Client Server
Server
Client
Binary
Binary
Interface pointer
Code
Code
CLSID
CLSID
COM
COM System
System
Library
Library Registry
Registry
Server binary code

24. COM Library Function for Object Creation
HRESULT CoCreateInstance
{
REFCLSID clsid,
LPUNKNOWN *pUnkOuter,
DWORD dwClsCtx,
REFIID riid,
LPVOID *ppv,
};

25. DCOM
- COM With a Longer Wire

26. Client Proxy Object Stub Component
Security Security
"CoCreateI DCE RPC DCE RPC
Provider Provider
nstance"
Protocol Stack Protocol Stack
OLE32 "CoCreateInstance"
(Remote)
Activation
SCM SCM
DCOM network-
protocol
DCOM Architecture

27. API function for Creating
a COM object on Remote
Machines
HRESULT CoCreateInstanceEx (
REFCLSID clsid,
LPUNKNOWN *pUnkOuter,
DWORD dwClsCtx,
COSERVERINFO * pServerInfo,
ULONG cmq,
MULTI_QI rgmq[]
);

28. 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

29. 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++

30. A Comparison
between CORBA and DCOM

31. 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

32. 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

33. 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

34. 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.

35. 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

36. 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

37. 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.

38. CORBA/DCOM Bridge

39. 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

40. The Solution is
to make CORBA/DCOM
working together

41. How ?

42. COM/CORBA Interworking through Bridge

43. The Interworking Model
Object Model A (client) Object Model B (Server)
Object reference in A
View of Target
Target Object
object
Object reference in B

44. OrbixCOMet Bridge View Object
COM Interface
DCOM CORBA
Automation Interface
Object Object
Bridge View Object

45. 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

46. Implementation of DCOM Client
accessing a CORBA Server
• The client obtains a COM View object in the Bridge
that 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

47. DCOM Client to CORBA Server
CORBA Server DCOM Client
Target
IIOP Bridge DCOM
CORBA
Object
COM Interface pointer
CORBA Object
COM View
Reference

48. Binding the DCOM Client to a CORBA Object
DCOM Client
To BookKeeper
Reference Reference to object in remote
to factory BookKeeper CORBA server
2
3
Factory 1 COM View
Object IBookKeeper
Bridge

49. A VB Client that Accesses the CORBA Server

50. A CORBA Client that Accesses the CORBA Server

51. 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

52. 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.