1. OOMI
From COM to DCOM

2. Agenda
From COM to DCOM
DCOM architecture
DCOM How to program

3. From COM to DCOM “DCOM is just COM with a longer wire” ;-)
It’s possible to configure even an in-proc COM-server DLL to be accessed from a remote PC
But there are differences:
New kind of errors
Slower response times
Security becomes a very important subject
No GUI - server objects can’t access GUI on Client
Marshalling necessary – done in proxy-stub-DLL

4. Accessing COM Services
Client
Component
In the same process
Fast, direct function calls
Client
Component
COM
Client Process
Server Process
On the same machine
Fast, secure IPC
Across machines
Secure, reliable and flexible DCE-RPC
based DCOM protocol
COM
DCE
RPC
Client
Server Machine
Client Machine
Component

5. COM: Ubiquitous DCOM COM Client COM COM COM COM COM COM COM COM COM
Several other vendors besides Microsoft claims to have DCOM support
Sun Solaris (Sparc) 2.5 RC
HP/UX
COM
COM
Q3’97
Q4’97
Digital Unix 4.0 (Alpha) RC
Digital Open VMS
COM
COM
COM
Client
Q3’97
H1’98
DCOM
IBM MVS (OS390)
Siemens Nixdorf SINIX
COM
COM
Q1’98
H1’98
IBM OS/400
Linux 2.0 (Intel)
BETA
COM
COM
H1’98
Q4’97
IBM AIX
SCO UnixWare
COM
COM
H1’98
H1’98

6. DCOM Access Transparency
All COM components communicate in the same way
on the same machine
In-process or
Out-of-process
across a Local Area Network
across a Wide Area Network
across the Internet
Same tools, knowledge, code

7. DCOM Wire Protocol Wire Protocol Based on DCE RPC Specification
Interoperable with OSF DCE RPC implementations
MS call it “ORPC”
Efficient and Scalable
Documented in Internet-Draft
(ftp://ietf.org/internet-drafts/draft-brown-dcom-v1-spec-01.txt)

8. DCOM How to activate a server
Like all COM communication, everything starts when the client requests an interface from a server.
In DCOM, the client calls CoCreateInstanceEx(), passing in a description of the server computer and requesting a class identifier (CLSID) and Interface
This request is handled by the Service Control Manager (SCM), which is a part of Windows. The SCM is responsible for the creation and activation of the COM object on the server computer
In the case of DCOM, the SCM will attempt to launch the server on the remote computer (by contacting the SCM on the remote machine)

9. DCOM System Relationships
Once the remote COM server has been created, all calls will be marshaled through the proxy and stub objects.
The proxy and stub communicate using RPCs (Remote Procedure Calls), which handle all the network interaction.
On the server side, the stub object takes care of marshaling.
On the client, the proxy does the work.
The standard RPC protocol is UDP (User Datagram Protocol).
UDP is a connectionless protocol, which seems like a bad fit for a connection-oriented system like DCOM. This isn't a problem however; DCOM automatically takes care of connections.

10. The Server Doesn't Change (much)
Any COM server that runs as a program (EXE) will work across a network.
In general, you don't have to make any changes to a server to get it to work for DCOM.
You may, however, want to add some security to your server, which will involve some effort.
If you're using an in-process server (DLL), you will need to make some changes.
An in-process server is a DLL, which can't load across a network.
A DLL loads into the client program's address space, which will not work for remote connections.
There is a work-around called a surrogate, which wraps the DLL in an executable program
However, it is usually more appropriate to change the server DLL over to an EXE.

11. Adding DCOM to the Simple Client
The first thing you do in any COM program is call CoInitialize.
This initializes the COM Runtime
Simple clients use the default threading model, which is apartment threading STA.
Basically this is a single threaded model separating the client requests
// initialize COM
hr = CoInitialize(0);

12. Specifying the Server with COSERVERINFO
When making a remote DCOM connection you must specify the server computer.
The name of the computer can be a standard UNC computer name or a TCP/IP address.
char name[32]; …
// remote server info
COSERVERINFO cs;
// Init structures to zero
memset(&cs, 0, sizeof(cs));
// Allocate the server name in the COSERVERINFO struct
// use _bstr_t copy constructor
cs.pwszName = _bstr_t(name);

13. Specifying the Interface with MULTI_QI
Normally, we get an interface pointer by calling CoCreateInstance.
For DCOM we need to use the extend version, CoCreateInstanceEx.
This extended function works perfectly well for local COM servers as well.
CoCreateInstanceEx has several important differences.
it lets you specify the server name
it allows you to get more than one interface (proxy) in a single call.
// structure for CoCreateInstanceEx
MULTI_QI qi[2];
// Array of structures
// set to zero
memset(qi, 0, sizeof(qi));
// Fill the qi with a valid
// interface
qi[0].pIID = &IID_IGetInfo;
qi[1].pIID = IID_ISomeOtherInterface;
// get the interface pointer
hr = CoCreateInstanceEx(
CLSID_GetInfo, // clsid
NULL, // outer unknown
CLSCTX_SERVER, // server context
&cs, // server info
2, // size of qi
qi ); // MULTI_QI array

14. The MULTI_QI structure
The MULTI_QI structure holds three pieces of information:
a pointer to the IID
the returned interface pointer
an HRESULT (also returned)
typedef struct tagMULTI_QI {
// pass this one in
const IID *pIID;
// get these out
IUnknown *pItf;
HRESULT hr;
} MULTI_QI;

15. The rest is just normal COM client code
There's nothing special about DCOM clients once you've connected to the server.
There is one big difference though: errors.
// pointer to interface
IGetInfo *pI;
if (SUCCEEDED(hr)) {
// Basic style string
BSTR bsName;
// Extract the interface from the MULTI_QI structure
pI = (IGetInfo*)qi[0].pItf;
// Call a method on the remote server
hr = pI->GetComputerName( &bsName );
pI->Release();
...

16. Registration on the Server
If you're working on a single machine, registration for DCOM is identical to standard COM.
The server program will typically register itself when you run it with the -REGSERVER switch.
ATL-generated servers will have registration code built into them
When the EXE is run with the -REGSERVER switch, it registers itself in the system registry and exits.
C:\> remoteServer –regserver C:\> REGSVR32 remoteserverps.dll

17. Registration on the Client
If you use custom interfaces then the proxy/stub DLL is required on the client machine.
The proxy/stub is the component that will send all information between the client and server over the network.
To use a proxy/stub DLL, you need to register it on the client so DCOM can automatically activate it.
If you're using an IDispatch (or dual) based automation client, you won't have a proxy/stub DLL.
In this case, you'll use a type library to register.
C:\> REGSVR32 remoteserverps.dll

18. Security is a major issue
But we will ignore it – for now
You can manipulate security settings for both the client and sever in your program
This is done with the CoInitializeSecurity API call
You can use this call to either:
Add security
Turn off security
You call this method immediately after calling CoInitialize
// turn off security - overrides defaults
hr = CoInitializeSecurity(NULL, -1, NULL, NULL,
RPC_C_AUTHN_LEVEL_NONE,
RPC_C_IMP_LEVEL_IMPERSONATE,
NULL,
EOAC_NONE,
NULL);