Introduction To DCOM
Tom Markiewicz, 1998
What is DCOM?
DCOM is an acronym that stands for Distributed Component Object Model. It is Microsoft’s solution for distributed computing. It allows one client application to remotely start a DCOM server object on another machine and invoke its methods. So, functionally it is similar to CORBA and RMI. Unlike RMI however, which is Java dependent, DCOM is language and platform independent - as is CORBA. The main difference between DCOM and CORBA lies in the implementation. DCOM is a binary standard whereas CORBA is only a specification: it defines the interfaces for how clients can use the objects but does not define the implementation itself. So different vendors are free to implement CORBA ORBs in many different ways, which makes CORBA possibly more flexible. Just because DCOM is a binary standard however, doesn’t mean it’s not platform independent. As a matter of fact, final ports for Sun Solaris 2.5 (Sparc), Digital UNIX 4.0 (Alpha), and IBM OS/390 are already available for download and other popular platforms are soon coming. (see:
http://www.sagus.com/prod-i~1/net-comp/dcom/dcom-avail.htm)
CORBA vs. DCOM
Why DCOM?
Because the vast majority of personal computers are PCs running Windows – the primary target of DCOM. DCOM provides the ability to use and reuse components dynamically, without recompiling, on any platform, from any language, at any time. This is perhaps the single most important aspect of DCOM. It also has a highly optimized marshaler for a set of common parameter types (oleautomation), which gives DCOM advantage over CORBA, whose marshaler is more general and therefore slower. It allows for static and dynamic invocation of objects, multithreading, callback events, object locator, remote server activation, security, and persistence. And most of all, it is already highly deployed in all Windows platforms since DCOM is really COM ‘with a longer wire’.
One widely criticized aspect of the DCOM model however, is that there is no absolute way of addressing an object instance – everything is done through object interfaces. As such, it can be difficult to manage a large set of worker object instances or temporarily disconnect and reconnect at a later time.
Another problem DCOM is facing is that currently there is no good solution to the problem of keeping track of possibly thousands of objects spread over thousands of computers on the network. The user has to supply the network address of the host machine for the server object, or that address must be hard-coded in the client application itself. [I’m not sure if CORBA has that problem solved]
Some also say that DCOM is hard to program but that depends entirely on the language being used and the level of support it offers for DCOM programming. Writing DCOM objects in VC++ can be pretty involving but allows for slimmer and faster implementations. Using VB5 or J++ for that purpose is really trivial and COM+ will soon make it trivial for VC++ as well.
Basic Theory
The BLOB
Interfaces: IUknown & IClassFactory
One or more per object
Binding Contracts
IUnknown – mother of all interfaces
Aggregation & Containment
GUIDs
IDL
Server Types
ActiveX Controls = Visual in-process COM object (ocx, dll, etc.)
ActiveX EXE Server = DCOM out-of-process server
ActiveX DLL Servers = non-visual in-process COM server
COM object = BLOB that implements IUnknown
Registry
Early Binding vs. Late Binding
Automation through IDispatch
Type Libraries
Containment and Delegation
VC++ Example
VB Example
J++ Example
References
Microsoft Web Sites:
One
Two
Three
Books
"Visual C++ 5 ActiveX COM Control Programming" – Sing Li and Panos Economopoulos
"Professional DCOM Programming" – Dr. Richard Grimes
"Doing Objects in Microsoft Visual Basic 5.0" – Deborah Kurata
Other...
Other???