See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/2341294

Distributed Component Object Model (DCOM)

Article · July 1997

Source: CiteSeer

CITATIONS READS
68 4,244

5 authors, including:

Chris Exton
University of Limerick
102 PUBLICATIONS   916 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

The Letter and Shape Drawing (LSD) test View project

All content following this page was uploaded by Chris Exton on 23 April 2013.

The user has requested enhancement of the downloaded file.

Distributed Component Object Model (DCOM)
Dean Thompson
Chris Exton
Leah Garrett
A.S.M. Sajeev
Damien Watkins
fdean,exton,leahg,sajeev,damieng@insect.sd.monash.edu.au

Department of Software Development

Faculty of Computing and Information Technology
Monash University
Melbourne, Australia
February 5, 1997
Contents
1 Overview of DCOM/OLE 3
2 History of DCOM/COM/OLE 5
2.1 Dynamic Data Exchange . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 OLE1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 OLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 DCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Architecture of DCOM 7
3.1 Overview of the DCOM Architecture . . . . . . . . . . . . . . . . 7
3.2 DCOM's notion of Interfaces . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Advantages of DCOM's Interfaces . . . . . . . . . . . . . 9
3.2.2 IUnknown Interface . . . . . . . . . . . . . . . . . . . . . 10
3.3 DCOM's Binary Standard . . . . . . . . . . . . . . . . . . . . . . 11
3.4 DCOM Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Microsoft Interface Denition Language (MIDL) 12

5 Comparison of CORBA to DCOM 14
6 DCOM Practical Example 15
6.1 Globally Unique Identiers . . . . . . . . . . . . . . . . . . . . . 15
6.2 Server-side Implementation . . . . . . . . . . . . . . . . . . . . . 16
6.3 Client-side Implementation . . . . . . . . . . . . . . . . . . . . . 17

7 Acknowledgment 18

2
Distributed Systems (DCOM vs. CORBA)

1 Overview of DCOM/OLE
The last decade has seen a number of changes take place in the way in which
both object-oriented and distributed component oriented paradigms operate.
To satisfy this demand Microsoft developed the Distributed Component Ob-
ject Model (DCOM). With DCOM being based around the Component Object
Model (COM) most if not all the issues relating to the COM architecture are
immediately relevant to DCOM as well. Both the object and component ori-
ented paradigms consist of many issues which need to be addressed with respect
to their infrastructures. These issues as identied in Dr. Dobbs Journal and
Microsoft Corporation (1994), Microsoft and Digital Equipment Corporation
(1995) and Microsoft and Digital Equipment Corporation (1996a) include:

 Interoperability
The growing trend when developing large systems is to break the entire
system into a series of modules or components. The challenge facing most
software buses is whether components written by one developer will inter-
operate with components written by others. Additionally, other issues that
need to be addressed include the ability for components to interoperate
across platform boundaries or across programming language boundaries.
With this the maintainability of these components also needs to be ad-
dressed. To date the use of standards has been the most eective solution
to this problem.
 Versioning
The concept of versioning brings with it two known challenges. These
include compatibility and naming. The rst challenge is to preserve the
functionality of the application through the introduction of new interfaces
while at the same time preserving the original functionality. The original
interfaces are preserved in order to provide backward compatibility with
the component and dependent clients. Traditionally, the previous inter-
faces are implemented in terms of the new functionality.
Secondly, the issue of naming interfaces and functions also needs to be
considered. Most component or object computing environments provide
little control over the naming and release control aspects of the system.
This complicates the issue as multiple developers can possibility use the
same name for a function. Problems such as these and other versioning
problems complicate the system's integration phase.
 Language Independence
A signicant issue is the large number of languages currently available for
developers to use. Traditionally, developers have had little choice when

3
 choosing the language of implementation due to the software bus prescrib-
ing a certain language and a certain methodology. An example of this is
Electra where the only bindings to the software bus are expressed in C++
(Maeis 1995). By making use of software buses which restrict the devel-
oper to a particular language or programming paradigm the architecture
will result in the developer being restricted to a number of programming
solutions.
 Size and Complexity of Systems
Distributed systems suer from a number of problems. These problems
include: the coordination of the entire system including the dierent com-
ponents into an eective and reliable network; the management of a dis-
tributed architecture especially where wide areas are concerned and the
problems of enforcing policies such as two-phase or three-phase locking
commits for transactions over the entire network.
Another challenge facing software developers today is the size and com-
plexity of most systems which were designed decades ago. These systems
were designed with little attention being paid to the modularity of the sys-
tem. As a consequence, making changes to these systems is very dicult,
due to the code being so intertwined throughout the entire application.
This has to be taken into account before the reverse engineering process
starts.

The Distributed Component Object Model (DCOM) aims to address each of

these issues by introducing an Object Based Environment in which programmers
can write individual components and be able to plug them into applications and
start using them straight away. The DCOM architecture also aims to address
each of the issues mentioned above.
Even though the DCOM architecture has addressed some of the challenges facing
component oriented systems there are still a number of problems which DCOM
has not been able to solve completely or has not even addressed. These problems
and the dierent approaches taken by DCOM are detailed in Katiyar (1994),
IBM (1994) and Brando (1995). A comparison between the DCOM architecture
and other similar architectures can be found in section 5.
Originally both the COM and Distributed COM (DCOM) architectures were
written and controlled by the Microsoft corporation, but recently both archi-
tectures were handed over for the independent ActiveX Consortium to manage
and control. ActiveX has endeavoured to make both the architectures open and
freely available to all those who would like to develop applications conforming
to the standard.
The next section traces the preliminary history of COM/DCOM/OLE 1 by
examining the history of COM/OLE and how the new architecture of DCOM
will provide the same benets but in a distributed domain.
1 In the next section COM/DCOM/OLE will be referred to as DCOM

4
2 History of DCOM/COM/OLE
The development of DCOM began with the introduction of a concept introduced
with the earlier graphical user interfaces. This concept placed a heavy emphasis
on the interoperability and seamless exchange of objects related to documents.
The concept was known as Dynamic Data Exchange (DDE).

2.1 Dynamic Data Exchange

The DDE protocol was designed originally for Microsoft Windows (TM) 2.1 to
allow applications to exchange data of any particular type (Rodent 1992). The
way in which this was achieved was through the use of a shared resource within
the Windows(TM) package known as the clipboard.
In an attempt to support backward compatibility with older applications the
clipboard and DDE technology are still supported today even though the tech-
nology was superseded by OLE1. As the DDE protocol is very complex and
was interpreted by dierent software vendors discussed in Rodent (1992) the
Dynamic Data Exchange Management Library (DDEML) was created. This
library is aimed to simplify the interfacing with the DDE protocol as well as
providing a common interface for all developers.

2.2 OLE1
OLE1 is an acronym for Object Linking and Embedding Version 1.0. It is
designed around the technology of DDE but at the same time was designed to
get around some of the limitations that existed with the DDE technology.
The OLE1 technology as described in Brockschmidt (1996) was principally de-
signed to greatly enhance the creation and management of objects within com-
pound documents. The OLE1 technology introduced the notion of "embedded
objects" or objects which had links associated with them.
In OLE1 the notion of an \embedded object" is where the actual object is phys-
ically stored within the compound document. This means that as the document
is moved from site to site, the object and all the associated information moves
with it as well. A linked object is where a reference to the actual object is stored.
This form of linking makes the compound document less portable because as
the document moves the object must be moved as well or else the link will be
broken. The advantage to using this style of linking is that it reduces the size
of the document. Additionally this concept also reduces the amount of data
reduction which exists within an organisation. This can be very helpful in such
areas where the data is constantly changing but at the same time people need
to have access to it.
With OLE1 the complexity of editing the object within the compound docu-
ment is simplied to a double click with the mouse pointer over the object. Once
selected the object can make use of inplace activation (ie. the menus change to

5
re ect the editing of another object) or the application which is responsible for
the actual object will be loaded and the changes will be made within that pro-
gram. Upon the termination of that program the changes will then be updated
back to the host document.
As more developer companies made use of this technology and were able to
interact with components within documents, the developers of OLE1 identied
that there was a need to share more than just the standard document objects. It
was recognised that the need to share other objects such as video and sound were
just as important as manipulating the standard document objects. Additionally
the OLE1 architecture was also starting to become unmaintainable. After much
deliberation it was decided to develop a totally new object model.

2.3 COM
The `Component Object Model'2 was given its name when it became apparent
that the model was going to be designed to promote the interoperability of
components. This approach to components was taken to encourage developers
to write in such a way as to allow components to be able to interoperate with
one another. The adoption of this architecture results in components being able
to be integrated into the model straight away.
In addition to re-engineering the entire architecture, the developers of COM also
took the opportunity to x up some of the problems that had been identied
while using OLE1 with regard to component management and creation.
The COM infrastructure was designed to be more powerful and to make use
of general purpose object technology rather than adopting technology specic
to just one domain. An example of this was OLE1 which concentrated on the
document aspects. As a result of adopting this more general approach, the
model is capable of providing a more powerful environment for developers.
A common concept pervading COM technology is the use of `interfaces' which
is explained in detail in section 3.
In order to make use of the COM architecture a totally new programming
environment was developed called OLE. The new version of OLE is a total
rewrite of OLE1. Both OLE models share very little in common. With the
new version of OLE providing more support than just objects being linked and
embedded together, it was decided to drop the acronym of \Object Linking and
Embedding" which had previously been associated with OLE.

2.4 OLE
This current version of OLE is written with a general and re-usable architecture,
implying that modications to the architecture might not be needed to the OLE
2 The acronym COM for a short period in 1994 stood for `Common Object Model' as a
result of a collaboration between Digital and Microsoft (Kruglinski 1995)

6
architecture. The COM software bus mentioned previously is currently the only
model used to program OLE because of the tight integration that the models
share.
This programming environment is also used to write distributed components
with the release of the Distributed Component Object Model (DCOM).

2.5 DCOM
The DCOM model is a set of extensions to the COM environment and was de-
veloped and shipped after the COM system was deployed into the market place.
DCOM provides distributed component communications. One of the major
aims of the DCOM architecture is to intercept all the local inter-process com-
munication messages and substitute them with a network protocol based on the
Distributed Computing Environment (DCE). Additionally the protocol might
also be responsible for routing the request through a network environment.
The main advantages of DCOM as outlined in Microsoft and Digital Equipment
Corporation (1996a) is the capability of providing a shared memory management
scheme which can be used between components; the way in which it interacts
with the network with regard to network interoperability and communications
transparency; the ability to be able to provide dynamic loading and unloading
of components as required; and providing a rich error and status reporting
environment for developers.

3 Architecture of DCOM
3.1 Overview of the DCOM Architecture
The DCOM architecture is designed around promoting software interoperability.
The architecture supports a `software bus' on which reusable software compo-
nents can be used and integrated with one another seamlessly. This makes the
architecture robust in its design and provides a basis on which developers can
modularise their applications.
In order to provide support for these reusable software components the entire
object model is based on an object based programming model as opposed to an
object oriented model. This object model was selected because of its inability
to provide inheritance. This means that the architecture is capable of avoiding
the fragile base class syndrome which exists in other models.
The fragile base class syndrome appears when one class inherits the members
and behaviour of another class. The class which provides the behaviour and
member functions is known as the base class while the other class is known as
the derived class. If the members and/or functionality of the base class change
then the behaviour and member functions of the derived class change. Changes
like this result in having to modify the base class which in turns requires the

7
recompilation of all dependent classes.
Apart from this programming model supporting the concept of reusable com-
ponents, the model was also selected on the basis that it makes use of pointers
and hence is capable of providing a reasonable amount of performance.
Like other component models, an overhead from which DCOM suers, is when
a connection is required between a component and a client. This results in the
COM architecture having to be responsible for negotiating a protocol between
the client and the component. In the case of a in-process DLL call once the
negotiations are complete the COM overhead is removed while the DLL makes
in-process calls.
The DCOM architecture possesses a unique infrastructure as it provides support
for persistent storage. It is capable of doing this through the use of interfaces
(explained in section 3.2) which components can implement from in order to
save its persistent state. When saved, the data is structured in a specic order
known as Structured Storage as is mentioned in Brockschmidt (1994). This
ordering of the data makes it easier for other applications and components to
browse through the component and extract data which is relevant.
In addition to DCOM being able to store the data it also provides the capability
of assigning a \smart-name", known as a \Moniker" to a particular instantiation
of a component. This name can then be used by the component at a later stage
to reconnect to the exact same component again. This component contains the
exact same values of all the data members. This form of technology provides
a level of indirection in the DCOM architecture allowing a component to be
changed in the background without aecting the current links to it.
In order to provide this service the DCOM architecture makes use of `Monikers'
which are smart names and which can be associated with an instantiation of an
object. These identiers are capable of matching up the internal reference of an
object with the identier that the developer gave. It is through this software
bus that the capability of persistent storage is possible. A Moniker is used to
match the identier that the developer gave to the internal reference that was
assigned to the component at instantiation time.
The infrastructure in DCOM also provides a set of standard interfaces known
as the `Uniform Data Transfer'. This interface provides a way for the client
and the component to communicate with one another using strict data and
type denitions. These interfaces are commonly used by the client to pass
information to the component informing the object the data that it is looking
at has changed. This can be very useful if one party needs to be informed of an
event which has happened to the other party.
The structure of the data which ows through these interfaces is strongly dened
with regard to type and layout so as to facilitate the exchange of data between
the client and object.

8
3.2 DCOM's notion of Interfaces
An interface is merely a collection of function pointers which are used by the
software bus to activate member functions. The consequence of having these
interfaces implemented as pointers means that they can only be used to invoke
methods on DCOM components and not used to edit the data within them.
DCOM also uses interfaces as a method for components to interact with one
another. The architecture was designed in such a manner as to prevent DCOM
objects from ever having direct access to one another.
Due to the lack of direct access between components, the model is able to pre-
serve the encapsulation of data as well as the data processing. This design
decision was not implemented by accident. The developers of DCOM decided
that in order to make the model more exible it should preserve the encapsula-
tion of the components.
One important concept to remember about interfaces is that they can never
be instantiated. The reason is because there is no implementation associated
with it. DCOM components must implement the interface and as a result the
component can then be created and used.
DCOM is also capable of providing polymorphism by providing the ability for
two or more components to implement an interface dierently. The only condi-
tion needed to achieve polymorphism is for the DCOM components to preserve
the behaviour of the interface.
It is also possible for a DCOM component to implement multiple interfaces. A
typical example of this might be a component which is responsible for dealing
with a car rental booking. The DCOM component might provide an interface
for dealing with a booking with a visa card as well as dealing with a booking
using a cheque.
Another key component that the DCOM architecture addresses as was men-
tioned in section 1 is that of versioning. In DCOM all interfaces are immutable,
meaning that once an interface has been implemented it can not be changed. If
a change has to be made to the interface, then a new interface is created. There
is no concept of versioning interfaces. This is done so as to provide backward
compatibility. A new interface would be responsible for adding new functional-
ity to the interface but also preserving the original functionality which existed
before the upgrade. In order to achieve this, most developers implement the old
functionality in terms of the new functionality added to the interface.

3.2.1 Advantages of DCOM's Interfaces

The decision to implement interfaces has lead to DCOM being able to provide
the ability for the functionality of applications to evolve over time. DCOM
provides this through the use of an interface named `QueryInterface'. This
interface, when implemented for DCOM compliance allows a component to make
a dynamic look up on a component to see if an interface is supported. If the

9
interface is supported then QueryInterface returns a pointer to that interface.
If that interface is not supported the QueryInterface returns a NULL pointer
indicating that this component doesn't support that feature. This approach
enables the evolution of functionality in an application as all the components
which the application uses are connected to and bound dynamically. This means
that as new components are added to the system the applications can make
direct use of them. All that happens is that the application tries to nd a
component and if it does not exist yet, the application falls back to one that it
knows how to use by default.
The problem of using the same name for interfaces is avoided in DCOM through
the use of generated a unique identier which signies each interface. These
identiers are based o the same principle used in the DCE protocol (Microsoft
and Digital Equipment Corporation 1995).
From a network transparency perspective, the use of interfaces makes it much
easier for DCOM to intercept any local interface call and substitute it with a
network protocol. This kind of approach requires little if no intervention from
the local architecture and hence makes the integration totally seamless.
Interfaces, even though they are only pointers, provide developers with the
choice of selecting a language which is relevant to them. With DCOM the only
restriction on language choice is that it must be capable of dealing with pointers
and must conform to the specications regarding the interface map and method
invocation. This is explained in section 3.3.
For every DCOM component which is developed it must inherit from the `IUn-
known' interface (Kindel 1995). The next section discusses the three major
interface methods which need to be implemented in order to conform to being
a DCOM component.

3.2.2 IUnknown Interface

The IUnknown interface provides the basis for other interfaces developed within
the DCOM system to interoperate. This interface consists of three functions
which in C++ would be termed pure virtual and hence must be implemented
in any component written.
The rst method and probably the most important method is QueryInterface.
The aim of this function is to provide clients with a means of being able to
determine what functionality a component possess. The QueryInterface takes
an interface name to search for as well as a reference point to start the search
from.
If the QueryInterface method can nd a match then the QueryInterface will
add one to the reference counter for that interface and return the pointer to the
component. If the QueryInterface is unable to nd what it was searching for it
returns a null pointer.
The QueryInterface method only serves as a lookup function as DCOM compo-

10
nents are not able to directly access one another.
The second method which is indirectly called from QueryInterface if the result is
successful is AddRef. This method is responsible for incrementing the reference
count which is controlling how many clients are using this component.
The third and nal method which belongs to the IUnknown interface is Re-
lease. This method is responsible for decrementing and checking the number
of references there are to any one component. When the reference count for a
component returns to zero the component is dynamically unloaded.

3.3 DCOM's Binary Standard

One of the strong points in DCOM's architecture is that it prescribes a binary
standard. The binary standard prescribes a certain layout which an object must
take in order to conform with DCOM. The layout of the objects refers to the way
in which the binary memory map which points to the functions is represented
in memory. In C++ this is called a `vtable' for a virtual table. In DCOM the
equivalent is the interface map.
By following these guidelines a developer has the choice of any language which
is capable of making use of pointers. DCOM components make extensive use of
pointers in the interface map and this is why it is important for the language
to provide support for pointers. Currently the following languages provide sup-
port for pointers and hence are capable of writing DCOM components: C++;
Smalltalk; ADA; C; BASIC; Visual Basic.
Below is a pictorial representation of how the pointers link up between the
component, the interface map and the actual function itself.

Figure 1: Illustrates the interface map/vtable arrangements in DCOM

By adopting this layout it is possible to conserve the amount of memory which

is used when multiple instantiations of the same component exist. Instead
of having two dierent components with two dierent interface maps pointing
to the same functions, it is possible to have the second component point to
the interface map of the rst component. This in itself introduces problems
regarding reference counting but the DCOM concept of interfaces manages to
solve this problem.

11
3.4 DCOM Protocol
The DCOM protocol is an application level protocol for object oriented remote
procedure calls based on the Distributed Computing Environment (DCE) RPC
specication. It species the representation and communication of object refer-
ences (Microsoft and Digital Equipment Corporation 1996b).
DCOM utilises DCE RPC's Network Data Representation for arbitrary data
types in its data marshalling. The protocol supports versioning of interfaces
through universally unique identiers (UUID's). Each version of a published
interface will have a unique identier.
Distributed communication in terms of object calls are implemented using two
more identiers: an Interface Pointer Identier (IPID) and an object export
identier (OXID). A standard remote reference (STDOBJREF) of an interface
of an object contains IPID and OXID as two of its elds. An IPID is a 128-
bit identier which represents a particular interface of a particular object in a
particular server. IPID's are like UUID's except that the former is specied only
relative to the machine on which the server is located. An IPID however does not
indicate the binding information necessary to carry out the actual invocation.
This information is represented in the object export identier OXID. An OXID
is used to determine the RPC string bindings required for a call to reach its
target IPID. Before a call is made, the calling process has to translate an OXID
into a set of bindings that the underlying RPC implementation understands
(Microsoft and Digital Equipment Corporation 1996b).
Each machine has a unique object export service to coordinate the management
of all OXID's on that machine. It caches and returns to clients on request the
string bindings necessary to connect to OXIDs of exported objects. It also
receives pings (described below) from remote clients to keep its own objects
alive. The object exporter optimally resides at the same endpoints as the DCE
RPC Endpoint Mapper.
The DCOM protocol provides for remote reference counting as well as pinging.
Reference counting will be inadequate in cases where clients terminate abnor-
mally. Remote abnormal termination is detected by periodic pings. To reduce
the number of pings and thereby network trac, DCOM relies on the client ob-
ject exporter to do the local management of detecting liveness of local clients;
the pings therefore need to be send only on a machine to machine basis.

4 Microsoft Interface Denition Language (MIDL)

The Microsoft Interface Identication Language (MIDL) is an extension of Dig-
ital Equipment Corporation's (DCE) IDL. DCE IDL was originally submitted
to Open Software Foundation (OSF) to be part of the DCE by HP and Digital.
The MIDL compiler supplied by Microsoft allows both the denition of DCOM
and DCE RPC interfaces. As MIDL is based on the DCE IDL standard it is
not fully contained within the COM specication and is viewed by Microsoft

12
as orthogonal to the DCOM interface. In fact MIDL in not required for the
use of DCOM however it has been supplied as a tool which provides a more
automated approach to DCOM development. The MIDL compiler (see gure
2) can generate appropriate implementation language source les from a MIDL
denition. The output les include a header le, server stub le, client stub le,
and auxiliary les. This allows a DCOM interface to be represented in a lan-
guage independent manner. DCOM interfaces are signied by a new interface
attribute \object". Once this keyword is present, the MIDL extensions to DCE
IDL are enabled.

Client Source

IDL Source IDL Compiler

Server Source

Figure 2: MIDL Compiler

DCOM interfaces are normally named beginning with a capital I (e.g. IAccInfo),
the interface name is a valid data type and as such can be used as a parameter
within a method declarations, this provides for static type checking during the
MIDL compile phase. Every DCOM interface inherits from a interface known
as IUnknown. This interface implements 3 methods: AddRef, Release and
QueryInterface.
The AddRef and Release, are used for \garbage collection". As clients gain
access to an object, AddRef is called, this increments the reference counter.
When a client no longer requires access, Release is called, decrementing the
counter. When the reference counter becomes 0, the object can be \garbage
collected". The QueryInterface method is used for interrogating the server to
nd out which interfaces it supports. The client code can invoke QueryInterface
for a particular interface name and nd out if the named interface is implemented
by the server. Once the a client has a pointer to the object's IUnknown interface,
it can use QueryInterface to request pointers to other interfaces.
// Bank account interface
[object, uuid(...)] interface IBankAcc
{
void getCurrentBalance(double *balance);
void deposit ([in] double amount);
void withdraw([in] double amount);
...
}

Figure 3: Sample MIDL code

The universally unique identier attribute \uuid" (see gure 3), assigns an In-

13
terface ID (IID) to the interface. The IID is used for globally unique run-time
identication of the interface. Once dened and assigned an IID, an interface
is considered immutable, there is no versioning concept implemented for MIDL
with any changes requiring assignment of a new IID.
Multiple inheritance is not supported, single inheritance is supported using simi-
lar semantics to C++. Semantics for pointers are included in MIDL this includes
the use of void pointers that are qualied using a iid_is pointer attribute. The
iid_is is a construct identies the pointer as an interface pointer whose exact
type can only be reconciled at runtime. The facility for asynchronous method
calls is provided as part of the DCOM standard. Any asynchronous method
declarations must return a void, all others must return a HRESULT.

5 Comparison of CORBA to DCOM

Many people view CORBA and DCOM as competing technologies. Indeed, both
support the development of distributed object systems. Although this is true,
OMG has dened a COM-CORBA inter-working specication which allows for
COM-CORBA communication. It is worth noting that both technologies are
still in their infancy. The CORBA specication has existed since 1990, and com-
mercial implementations of CORBA have been available since 1992. DCOM was
made available in late 1996. Both DCOM and CORBA are undergoing continu-
ous change and in many respects much of this change will surely lessen many of
the current dierences as each technology grows to provide more features and
services.
We have provided a comparison on two levels: the rst is a table which presents a
summary overview; the second level contains a more detailed comparison which
covers the listed table entries, but in addition discusses each point in greater
depth.
The table comparison has been made on several areas, including Inheritance,
Distributed Garbage Collection (DBC), Multiple Interfaces, Overloaded func-
tions, Supports IIOP and Vendor Specic. When presenting this information,
it is necessary to use a scale, as specic features are often provided to varying
degrees in the dierent implementations.

Feature CORBA DCOM

DGC * ****
Exceptions *****
Inheritance **** **
Multiple Inheritance **** *
Multiple Platforms ***** **
Overloaded Functions *****
Supports IIOP *****
Vendor Specic ***** *

14
Perhaps the fundamental dierence between CORBA and DCOM is that DCOM
was designed to provide a exible runtime binary standard for a distributed ob-
ject system, while CORBA has taken a more static architectural view. CORBA
provides a greater amount of abstraction and encapsulation while DCOM sac-
rices some of these benets for a more exible runtime environment. The
CORBA specication currently provides mapping for C++, C, Smalltalk, Ada
and Java. This selection encompasses both dynamically and statically typed
languages. DCOM is extremely C++ and C centric. Whilst not restricted
to these languages, the implementation must generate a structure at runtime
that roughly corresponds to a vtable as implemented in C++. Because of this,
DCOM may in some instances provide better performance in local environments,
as it does not have to deal with many of the complexities of a true multi-language
environment. However, many CORBA implementations also provide automatic
short cuts for local environments by providing the object's actual address in-
stead of a proxy handle. Methods in CORBA are permitted to return any legal
type whilst in DCOM, methods are only permitted to return a 32-bit result
(HRESULT or SCODE). This result encompasses a 16-bit eld, which can be
used for any pertinent information while the remainder is made up of a single
success/failure bit ag, as well as a 15-bit facility eld that is dened by Mi-
crosoft. CORBA also provides the ability to include user exception denitions
as well as having a comprehensive list of possible system exceptions which are
included in the CORBA specication as part of the interface denition.

6 DCOM Practical Example

The following example looks at implementing a Car object using DCOM3 .

6.1 Globally Unique Identiers

Implementation begins with generating a globally unique identier for the Car
class. The identier is generated by running the utility program, uuidgen at an
operating system prompt. This generates a 128 byte globally unique identier
for the class, in this example the identier value was
82f7b2e0-77dc-11d0-ab45-0000c0b8fe96.

The identier must then be entered into the system registry using the program
regedit. The regedit program can accept a script le to automate the process,
the le for registering our identier is shown in Figure 4.
The result of registering the class can be seen by running regedit interactively.
After starting regedit all the Class Identiers (CLSIDs) are stored in CLSID
section under the HKEY CLASSES ROOT section. The CLSID entry contains
information on the server including the path to the le that implements the
class.
3 Some ideas and source code used in this example come from (Brockschmidt 1994),
(Kruglinski 1995), .. and http://www.microsoft.com/oledev/olemkt/oledcom/simple.htm.

15
REGEDIT4

[HKEY_CLASSES_ROOT\CLSID\{82f7b2e0-77dc-11d0-ab45-0000c0b8fe96}]
@="Car Object Server"

[HKEY_CLASSES_ROOT\CLSID\{82f7b2e0-77dc-11d0-ab45-0000c0b8fe96}]
"AppID"="{82f7b2e0-77dc-11d0-ab45-0000c0b8fe96}"

[HKEY_CLASSES_ROOT\CLSID\{82f7b2e0-77dc-11d0-ab45-0000c0b8fe96}
\LocalServer32] @="d:\dcom\test\sserver.exe"

[HKEY_CLASSES_ROOT\APPID\sserver.exe]
"AppID"="{82f7b2e0-77dc-11d0-ab45-0000c0b8fe96}"

[HKEY_CLASSES_ROOT\APPID\{82f7b2e0-77dc-11d0-ab45-0000c0b8fe96}]
@="Car Object Server"

Figure 4: Regedit Script File

6.2 Server-side Implementation

The macro DEFINE GUID is used in both the server and client programs to
identify and access a class object with the identier value, via the system reg-
istry.
The server code starts by creating a class, in our example called CCar4, which
inherits from IPersist. IPersist is one of the simplest interfaces in DCOM im-
plementing only one member function called GetClassID5.
IPersist inherits from the IUnknown interface as do all interfaces in DCOM. This
means that our class must implement the IUnknown methods QueryInterface,
AddRef and Release, as well as the IPersist method GetClassID.
class CCar : public IPersist
{
public:
STDMETHODIMP QueryInterface (REFIID iid, void **ppv);
STDMETHODIMP_(ULONG) AddRef(void);
STDMETHODIMP_(ULONG) Release(void);
STDMETHODIMP GetClassID(LPCLSID className);
...
};

Figure 5: A sample CCar implementation class

Once the CCar is completed, a class factory for the CCar class must be im-
4 The class implementing the car object is abbreviated to CCar.
5 Three other DCOM classes inherit from IPersist, namely IPersistStorage, IPersistStream
and IPersistFile. Normally classes implement one of the derived classes and not IPersist.

16
plemented. Class factories inherit from IClassFactory, an interface that inherits
from IUnknown and adds the member functions CreateInstance and LockServer.
CreateInstance accepts three parameters, an IUnknown pointer, a reference to
the interface required which are both in parameters, and an indirect pointer to
the interface itself. This third parameter will contain a pointer to the interface if
the object is correctly instantiated. The rst parameter, an IUnknown pointer,
is used if the object being created is an aggregate object contained within an-
other object. CreateInstance will create an object of the type requested and
then query that object for to a pointer the requested interface, which is then put
into the out parameter. This method, like most methods in DCOM, returns a
HRESULT structure. A HRESULT structure is a standard return value imple-
menting standard error return codes. There are a number of standard macros
dened which extract the bit values of the HRESULT.
LockServer, the other member function in the IClassFactory interface, deals
with maintaining the factory object in memory even when currently not in use,
making it quicker to instantiate objects. This function is not often called on
most ClassFactory objects.
Next in the sever le, a global instance of the Car class factory is created. This
object instance will be used to instantiate all Car objects while the server is
running.
With all the classes declared and a global factory object instantiated, the main
function is dened. The main function rstly calls CoInitializeEx which takes
two parameters, an in parameter that is reserved for future use and an enumer-
ated type that species which thread model is being used, both Apartment or
Multi-Threaded models are supported.
The main function now calls CoRegisterClassObject which has four in param-
eters, a CLSID identifying the class being registered, a pointer to the class fac-
tories IUnknown interface, the context for execution and a connection ag. The
third parameter identies the execution context which can be either in-process,
local or remote. The fourth parameter identies the type of connection, either
single-user or mutli-user. The last parameter is an out parameter that can be
used to revoke the registration of the class object. Now the server waits in a
loop for incoming connections.
Finally the server's main function calls CoUninitialize. This function closes
DCOM, frees any local resources held by the program and terminates any RPC
connections.

6.3 Client-side Implementation

The client side starts by checking if a server name has been passed as a command
line parameter. If it has, a COSERVERINFO structure is then used to hold
requested servers name6.
6 In Windows NT, Unicode is fully supported and so strings (char *) often have to be
converted

17
Next CoInitializeEx is called, as it was in the server.
In order to improve performance over a distributed network DCOM (unlike
COM) allows users to request a number of interfaces when instantiating an
object rather than having to make repeated RPC calls to obtain pointers to
dierent interfaces. This is done with the function CoCreateInstanceEx which
takes six parameters. The rst parameter is the CLSID of the object required,
the second parameter is an IUnknown pointer which is used if the object being
created is an aggregate in another object, the same as in CreateInstance when
used on the server side, the third parameter is the context for execution, as
described earlier. The fourth parameter is a pointer to the COSERVERINFO
which may hold a machine name if one was supplied. The fth parameter
identies how many elements there are in the MULTI QI array. Each element
in the MULTI QI array identiers an interface to which a client requires a
interface pointer. The nal parameter is the address of the MULTI QI array.
After the call to CoCreateInstanceEx, the client extracts the interface pointers
from the MULTI QI array and use them to access the Car object. At this stage
the reference counter on the Car object is two as we have two separate interfaces
to the same Car object. This would allow Release to be called once through
one of the interfaces without removing the server. When AddRef is called on the
IUnknown interface in the sample program, the reference counter is incremented
to three.
Using the IPersist interface the member function GetClassID is called. The
CLSID returned is not printable and is therefore turned into a string with the
StringFromCLSID function. This function dynamically allocates memory to
hold the string and therefore it is the caller's responsibility to release this mem-
ory. Each task has two specic memory allocators, one for local memory and
one for global memory. The function CoGetMalloc is used to get a pointer to
the interface for the memory allocation object. Which is then used to free the
memory.
Finally the client calls Release twice to free the Car object.

7 Acknowledgment
Authors would like to thank Prof. Heinz Schmidt of Monash University, who
gave valuable comments and assistance.

18
 References
Brando, T. J. (1995, March). Comparing DCE and CORBA. Technical Report
MP 95B-93, MITRE.
Brockschmidt, K. (1994). Inside OLE2. Microsoft Press.
Brockschmidt, K. (1996, July). What OLE Is Really About. Microsoft Devel-
opment Network Library .
Dr. Dobbs Journal and Microsoft Corporation (1994, December). The Com-
ponent Object Model: Technical Overview. Dr. Dobbs Journal .
IBM, C. O. (1994, January). OpenDoc vs. OLE 2.0, Superior by Design - A
Developer's View. Technical report, IBM.
Katiyar, D. (1994). OLE vs. CORBA.
Kindel, C. (1995, October). The Rules of the Component Object Model.
Microsoft Development Network Library .
Kruglinski, D. J. (1995). Inside Visual C++. Microsoft Press.
Maeis, S. (1995). Run-Time Support for Object-Oriented Distributed Pro-
gramming. Ph. D. thesis, University of Zurich.
Microsoft and Digital Equipment Corporation (1995, October). Component
Object Model Specication (Draft Version 0.9 ed.). Microsoft and Digital
Equipment Corporation.
Microsoft and Digital Equipment Corporation (1996b). Distributed Compo-
nent Object Model Protocol (Version 1.0 ed.). Microsoft and Digital Equip-
ment Corporation.
Microsoft and Digital Equipment Corporation (1996a, October). Distributed
Component Object Model Specication (Draft Version 1.0 ed.). Microsoft
and Digital Equipment Corporation.
Rodent, H. (1992, October). Supporting the DDE System Topic. Microsoft
Development Network Library .

19

View publication stats