OOMI

OOMI

A short introduction to

Microsoft's COM

From COM to DCOM

Ingeniørhøjskolen i ÅrhusSlide 2 af 24

Agenda

• From COM to DCOM• DCOM architecture• DCOM How to program


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


ClientClient ComponentComponentIn the same process In the same process Fast, direct function calls

ClientClient ComponentComponentCOMCOM

Client ProcessClient Process Server ProcessServer ProcessOn the same machineOn the same machineFast, secure IPC

Across machinesAcross machinesSecure, reliable and flexible DCE-RPCbased DCOM protocol

COMCOMDCERPC

ClientClient

Server MachineServer MachineClient MachineClient Machine

COMCOM ComponentComponent

Accessing COM Services


DCOM: Multiple Network Transports

TCP, UDPTCP, UDP

IPX, SPXIPX, SPX

HTTPHTTP


COM

QueuedQueued

ClientsClients

COM

COMCOMObjectObject


DCOM: Flexible Security

TCP, UDPTCP, UDP

IPX, SPXIPX, SPX

HTTPHTTP

COM

QueuedQueued

NT4 SecurityNT4 Security

SSL/SSL/CertificatesCertificates

KerberosKerberos

IPSECIPSEC

COM

COMCOMObjectObjectClientsClients

Client MachineClient Machine Server MachineServer Machine


COMClient

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

Q3’97

Q1’98

H1’98

H1’98 H1’98

Q4’97

H1’98

H1’98

Q4’97

COM: Ubiquitous


Threading model: STA

Alternative: Free Threading model – hard to master


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


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)


ServerServerClientClient

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

ClientClient



ServerServerClient #1Client #1

Client #2Client #2

Keep-Alive Keep-Alive TrafficTrafficfor all for all

connectionsconnections

Logical

“

Logical

“Connec

tions

Connectio

ns””

or “Ses

sions”

or “Ses

sions”

Efficient and Scalable

• Low Bandwidth– Header is 28 bytes over DCE-RPC– Keep-Alive Messages bundled for all connections between

Machines


ScorecardFFeeaattuurree CCOOMM//DDCCOOMM

Security NTLM, MIT Kerberos, SSL/Public Key

DCE

Languages C, C++, VB, JAVA, Fortran, Cobol, Perl,

REXX, Javascript, many others

Multiple Transports TCP IP, IP, IPX, SPX, HTTP, and others

Distributed Garbage Collection

Mature Development Tools

Easy to Manage

In-proc Components

Additional Services Transactions, Queuing


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.


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.


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.


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 COMhr = CoInitialize(0);


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 infoCOSERVERINFO cs;// Init structures to zeromemset(&cs, 0, sizeof(cs));// Allocate the server name in the COSERVERINFO struct// use _bstr_t copy constructorcs.pwszName = _bstr_t(name);


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 CoCreateInstanceExMULTI_QI qi[2];// Array of structures// set to zeromemset(qi, 0, sizeof(qi));// Fill the qi with a valid // interfaceqi[0].pIID = &IID_IGetInfo;qi[1].pIID = IID_ISomeOtherInterface;

// get the interface pointerhr = CoCreateInstanceEx( CLSID_GetInfo, // clsid NULL, // outer unknown CLSCTX_SERVER, // server context &cs, // server info 2, // size of qi qi ); // MULTI_QI array


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;


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 interfaceIGetInfo *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(); ...


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 –regserverC:\> REGSVR32 remoteserverps.dll


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


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 defaultshr = CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_NONE, RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL);

Documents

OOMI