Originally found here.
DCOM is very large topic. This short article can not cover even small part of DCOM theory. It only explains suggested in this example architectural solution.
DCOM is powerful protocol of interprocess communication within local area network between two computers or same computer. Along with ATL COM where basic codes are generated by wizards, there may be simple C coding solution. Such solution is very convenient for incorporation into finished client-server programs with minimal changes. It fits situation when you need relatively thin client communicating to large application sitting in LAN.
Software contains three components that are placed in three projects
- Client
- Server
- Proxy/Stub
Client and Server are executables and proxy/stub is DLL. There is no mystery in DCOM connections. It is only a network protocol running over socket connections. Server is program that is sitting on particular computer and identified by global unique identifier (GUID). This GUID is recorded in registry of client computer along with the name of server computer. Client program has same GUID known in one or another form. When DCOM client starts it extracts name of the server according to GUID, finds server computer and instantiate server executable remotely via special protocol that is used then to supports communications. The same DLL that is called proxy/stub and used by OS for communication must be sitting and registered on both computers. On the client side it is called proxy. On the server side it is called stub.
We start explanation from proxy/stub.
The project is called DOSProxy. It has practically one main file DOSProxy.idl that contains signatures of three interface functions. IDL stands for interface definition language. The project has make file that list all commands. Make file is part of the project and is executed from project build menu. When build command is executed the IDL compiler generates 3 'c' files DOSProxy_i.c, dlldata.c and DOSProxy_p.c. These files are compiled, DLL is then built and registered. The location of this DLL is recorded in registry after build command. When transferred to other computer it must be registered by 'regsvr32' command. The interface functions create object on server 'createBoss', destroys this object 'destroyBoss' and extract Id, random number associated with every object. When client application is running these three functions on server side are called and simple report is produced, that is looking like follows:
DCOM client report
DOSClient is simple and straight forward project. It illustrates advantage of simple approach to DCOM architecture, because interface functions are simply called as if it was part of DOSClient.
pDOSServer->createBoss();
pDOSServer->getBossId(&nId);
pDOSServer->destroyBoss();
Two files generated by MIDL compiler along with GUID are included in build. The pointer to server interface functions pDOSServer is obtained by CoCreateInstance function. This is, probably, all that is necessary to know about DOSClient project.
DOSServer is, possibly, the most complicated piece of application. It understanding needs general knowledge of DCOM architecture that we don't explain in this paper and presume that reader is familiar with it. The purpose of this architectural approach is to show how DCOM can be created as a wrapper for finished program and used for remote calls from client. The class CBoss is the one that has no specific DCOM functions and presumed existed as part of certain program before DCOM wrapper was written. The class CEntry is DCOM wrapper that has three already mentioned interface functions and necessary DCOM specific stuff (AddRef, Release and QueryInterface). This class needs DOSProxy.h file that is generated by proxy/stub application during build. The DCOM part in CEntry class can be preserved as is for other application and this class can be used as template. Another DCOM specific class is CFactory. The purpose and usage of this class takes chapters in DCOM literature, so we will not even try to explain it and address reader to recommended book. The good thing is that this class can be reused as template with changes in a few lines concerning inclusion of files and GUID. File glof.cpp contains some independent global 'c' functions that are called from different part of application. Several of them are used for registration of server i.e. making correspondent registry keys and values. These functions are called from entry point when program is called for self-registration. The registration/unregistration and help commands are
DOSServer /REGSERVER
DOSServer /UNREGSERVER
DOSServer /h
As it was already mentioned server must be registered before it start functioning as DCOM application. When called by OS as DCOM application it executes RegisterClassFactory() and switch to loop of monitoring windows messages. When client is connected and served it breaks the loop executes RevokeClassFactory and terminate self.