OOMI

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

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