Transcript DCOM

OOMI
A short introduction to
Microsoft's COM
From COM to DCOM
Agenda
• From COM to DCOM
• DCOM architecture
• DCOM How to program
Slide 2 af 24
Ingeniørhøjskolen i Århus
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
Slide 3 af 24
Ingeniørhøjskolen i Århus
Accessing COM Services
In the same process
Client
Fast, direct function calls
On the same machine
Client Process
Fast, secure IPC
Client
Secure, reliable and
flexible DCE-RPC
based DCOM protocol
Client
COM
Slide 4 af 24
Server Process
Component
COM
Client Machine
Across machines
Component
Server Machine
DCE
COM
RPC
Component
Ingeniørhøjskolen i Århus
DCOM: Multiple Network Transports
Clients
C
O
M
TCP, UDP
IPX, SPX
HTTP
C
O
M
COM
Object
Queued
Server Machine
Client Machine
Slide 5 af 24
Ingeniørhøjskolen i Århus
DCOM: Flexible Security
Clients
C
O
M
TCP,
UDP
NT4
Security
SSL/
IPX, SPX
Certificates
Kerberos
HTTP
C
O
M
COM
Object
IPSEC
Queued
Server Machine
Client Machine
Slide 6 af 24
Ingeniørhøjskolen i Århus
COM: Ubiquitous
Sun Solaris (Sparc) 2.5
HP/UX
COM
COM
RC
COM
Client
DCOM
Q3’97
Q4’97
Digital Unix 4.0 (Alpha)
RC
COM
Q3’97
Digital Open VMS
IBM MVS 5.2.2 (OS390)
Siemens Nixdorf SINIX
COM
COM
Q1’98
IBM OS/400
COM
Slide 7 af 24
H1’98
H1’98
Linux 2.0 (Intel)
H1’98
IBM AIX
COM
COM
BETA
COM
Q4’97
SCO UnixWare
H1’98
COM
H1’98
Ingeniørhøjskolen i Århus
Threading model: STA
Alternative: Free Threading model – hard to master
Slide 8 af 24
Ingeniørhøjskolen i Århus
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
Slide 9 af 24
Ingeniørhøjskolen i Århus
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)
Slide 10 af 24
Ingeniørhøjskolen i Århus
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
Slide 11 af 24
Ingeniørhøjskolen i Århus
Efficient and Scalable
• Low Bandwidth
– Header is 28 bytes over DCE-RPC
– Keep-Alive Messages bundled for all connections between
Machines
Client Machine
Client #1
Keep-Alive
Traffic
for all
connections
Server Machine
Server
Client #2
Slide 12 af 24
Ingeniørhøjskolen i Århus
Scorecard
Feature
COM/DCOM
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
Slide 13 af 24
Ingeniørhøjskolen i Århus
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.
Slide 14 af 24
Ingeniørhøjskolen i Århus
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.
Slide 15 af 24
Ingeniørhøjskolen i Århus
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.
Slide 16 af 24
Ingeniørhøjskolen i Århus
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);
Slide 17 af 24
Ingeniørhøjskolen i Århus
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);
Slide 18 af 24
Ingeniørhøjskolen i Århus
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
Slide 19 af 24
Ingeniørhøjskolen i Århus
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;
Slide 20 af 24
Ingeniørhøjskolen i Århus
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();
...
Slide 21 af 24
Ingeniørhøjskolen i Århus
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
Slide 22 af 24
Ingeniørhøjskolen i Århus
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
Slide 23 af 24
Ingeniørhøjskolen i Århus
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);
Slide 24 af 24
Ingeniørhøjskolen i Århus