OOMI

1
OOMI

• A short introduction to
• Microsoft's COM
• 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 -)
• Its 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 cant access GUI on
  Client
• Marshalling necessary done in proxy-stub-DLL

4
Accessing COM Services
5
DCOM Multiple Network Transports
C O M
C O M
COM Object
Clients
Server Machine
Client Machine
6
DCOM Flexible Security
C O M
C O M
COM Object
Clients
Client Machine
Server Machine
7
COM Ubiquitous
HP/UX
Sun Solaris (Sparc) 2.5 RC
Q397
Q497
Digital Open VMS
Digital Unix 4.0 (Alpha) RC
COM Client
Q397
H198
DCOM
Siemens Nixdorf SINIX
IBM MVS 5.2.2 (OS390)
Q198
H198
Linux 2.0 (Intel) BETA
IBM OS/400
COM
H198
Q497
SCO UnixWare
IBM AIX
COM
H198
H198
8
Threading model STA
Alternative Free Threading model hard to master
9
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
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-v
  1-spec-01.txt)

11
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

Server
Client
Client
12
Efficient and Scalable

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

Server Machine
Client Machine
Keep-Alive Traffic for all connections
Client 1
Server
Client 2
Logical Connections or Sessions
13
Scorecard
14
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
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
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
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
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 name32 // 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
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
qi2 // Array of structures // set to
zero memset(qi, 0, sizeof(qi)) // Fill the qi
with a valid // interface qi0.pIID
IID_IGetInfo qi1.pIID IID_ISomeOtherInterfac
e
// 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
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
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)qi0.pItf
// Call a method on the remote server hr
pI-gtGetComputerName( bsName ) pI-gtRelease()
...
22
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\gt remoteServer regserverC\gt REGSVR32
remoteserverps.dll
23
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\gt REGSVR32 remoteserverps.dll
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_IMPER
SONATE, NULL, EOAC_NONE, NULL)