1. OOMI A short introduction to Microsoft's COM From COM to DCOM

2. Ingeniørhøjskolen i Århus Slide 2 af 24 Agenda From COM to DCOM DCOM architecture DCOM How to program

3. Ingeniørhøjskolen i Århus Slide 3 af 24 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. Ingeniørhøjskolen i Århus Slide 4 af 24 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 protocolCOM DCE RPC Client Server Machine Client Machine COM Component Accessing COM Services

5. Ingeniørhøjskolen i Århus Slide 5 af 24 DCOM: Multiple Network Transports TCP, UDP IPX, SPX HTTP Server Machine Client Machine COMCOM Queued Clients COMCOM COMObject

6. Ingeniørhøjskolen i Århus Slide 6 af 24 DCOM: Flexible Security TCP, UDP IPX, SPX HTTP COMCOM Queued NT4 Security SSL/Certificates Kerberos IPSEC COMCOM COMObject Clients Client Machine Server Machine

7. Ingeniørhøjskolen i Århus Slide 7 af 24 COM Client Linux 2.0 (Intel) BETA COM HP/UX COM Digital Open VMS COM Siemens Nixdorf SINIX COM SCO UnixWare COM Digital Unix 4.0 (Alpha) RC COM IBM MVS 5.2.2 (OS390) COM IBM OS/400 COM IBM AIX COM DCOM Sun Solaris (Sparc) 2.5 RC COM Q3’97 Q1’98 H1’98 Q4’97 H1’98 Q4’97 COM: Ubiquitous

8. Ingeniørhøjskolen i Århus Slide 8 af 24 Threading model: STA Alternative: Free Threading model – hard to master

9. Ingeniørhøjskolen i Århus Slide 9 af 24 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

10. Ingeniørhøjskolen i Århus Slide 10 af 24 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)

11. Ingeniørhøjskolen i Århus Slide 11 af 24 Server Client Efficient and Scalable Multiplexing - Single Port per-protocol, per server process, regardless of # of objects Scalable - Connection-Less Protocols like UDP Preferred Established Connection-Oriented (TCP) Sessions Reused by same client Client

12. Ingeniørhøjskolen i Århus Slide 12 af 24 Server Machine Client Machine Server Client #1 Client #2 Keep-Alive Traffic for all connections Logical “ Connections ” or “Sessions” Efficient and Scalable Low Bandwidth –Header is 28 bytes over DCE-RPC –Keep-Alive Messages bundled for all connections between Machines

13. Ingeniørhøjskolen i Århus Slide 13 af 24 Scorecard

14. Ingeniørhøjskolen i Århus Slide 14 af 24 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.

15. Ingeniørhøjskolen i Århus Slide 15 af 24 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.

16. Ingeniørhøjskolen i Århus Slide 16 af 24 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.

17. Ingeniørhøjskolen i Århus Slide 17 af 24 Adding DCOM to the Simple Client The first thing you do in any COM program is call CoInitialize. Simple clients use the default threading model, which is apartment threading STA. // initialize COM hr = CoInitialize(0);

18. Ingeniørhøjskolen i Århus Slide 18 af 24 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);

19. Ingeniørhøjskolen i Århus Slide 19 af 24 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 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

20. Ingeniørhøjskolen i Århus Slide 20 af 24 The MULTI_QI structure The MULTI_QI structure holds three pieces of information: –a pointer to the IID –the returned interface pointer –an HRESULT. typedef struct tagMULTI_QI { // pass this one in const IID *pIID; // get these out (must set NULL before calling) IUnknown *pItf; HRESULT hr; } MULTI_QI;

21. Ingeniørhøjskolen i Århus Slide 21 af 24 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();...

22. Ingeniørhøjskolen i Århus Slide 22 af 24 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. If you use custom interfaces then the proxy/stub DLL is required on both the server and the client machine. C:\> remoteServer –regserver C:\> REGSVR32 remoteserverps.dll

23. Ingeniørhøjskolen i Århus Slide 23 af 24 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

24. Ingeniørhøjskolen i Århus Slide 24 af 24 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);