What is proxy/stub skeleton in COM client and server programming?
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 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).
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
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.