DCOM Client server model

DCOM client and server can be in same host or located in two hosts which are connected via network. In COM In-Proc COM DLL server and client talk directly to each other in same address space. DCOM as the name suggests are distributed in nature and client and server are decoupled by an abstraction layer.

Marshalling and transport

MIDL compiler generates the proxy and stub skeleton files which are the part of this abstraction layer. Marshalling and DCOM framework components helps in exchanging parameters between client and server with the help of proxy/stub layer.

Local procedure call or LPC mechanism is used for the DCOM in same host. This local procedure call uses shared memory between two applications to exchange parameters and returns. Remote procedure call or RPC mechanism is used for the DCOM where client and server are in different network host. Socket communication network protocols is used as the transport layer in RPC calls. Client side takes the paraments and constructs network byte streams. These bytes reaches to the server. Server reforms the byte streams to caller arguments and posts to the server. Again the return values and paraments are converted to byte streams and send back to client. It is then deconstructed to parameters and returned to caller.

marshalling unmarshalling

Marshalling is the overall mechanism name used in DCOM where arguments to byte streams are formed. Unmarshalling is the opposite process where byte streams are converted to arguments. Invoking a method on a remote object is also known as remote method invocation (RMI) or remote invocation, and is the object-oriented programming analog of a remote procedure call (RPC).

Stub proxy interface

Proxy Interface

Client is coupled with the proxy interface and passes parameters to proxy. Proxy interface talks to Marshalling and DCOM framework. Here these parameters are serialize to network friendly stream and sent to the server side.

The proxy is responsible for:

  • initiating the communication towards the server
  • translating calls from the caller object
  • marshalling of the parameters
  • informing the stub that the call should be invoked
  • passing arguments to the stub over the network
  • unmarshalling of the response from the server
  • informing the caller that the call is complete

Stub Interface

DCOM Server is coupled with stub interface. The parameters from client reached to the DCOM framework of the server side through LPC or RPC. Then it de-serialized to stub interface and reached to server. Server returns the call and parameters to stub. Stub hands over the parameters to DCOM framework. The return parameters again serialized and travels back to client side. Now they reach the client side and de-serialized to proxy and then returns to client.

The stub is responsible for:

  • translating incoming data from the stub to the correct up-calls to server objects
  • unmarshalling of the arguments from received bytes
  • passing arguments to server objects
  • marshalling of the returned values from server objects
  • passing values back to the client stub over the network

Stub proxy

Protocols like stub/proxy approach

The stub proxy design is used in Distributed Component Object Model (DCOM) and this is from Microsoft. However there are similar models there in -

  • Portable Distributed Objects (PDO) - Objective-C
  • Common Object Request Broker Architecture (CORBA) – inter-language
  • Java remote method invocation (Java RMI) – Java
  • .NET Remoting – Microsoft, inter-language
  • DDObjects – Borland Delphi
  • Distributed Ruby (DRb) – Ruby

About our authors: Team EQA

You have viewed 1 page out of 67. Your COM/DCOM learning is 0.00% complete. Login to check your learning progress.

Learn on Youtube

#