OBJECT COMMUNICATION USING STUB SERVER
[
attachment=26564]
Functioning
The caller invokes a method on the local stub which is responsible for carrying out the method call on the remote object.
In RMI, a stub for a remote object implements the same set of remote interfaces that a remote object implements..
Stub Operation
Package identifier of Remote Object
Package Method Identifier
Marshal Parameter
Send Package to Server Skeleton
Client Object calls client stub in normal way
Client stub builds message, calls local OS
Client's OS sends message to remote OS
Remote OS gives message to server stub
Server stub unpacks parameters, calls server
COM is designed to allow clients to transparently communicate with objects, regardless of where those objects are running in the same process, on the same computer, or on a different computer. This provides a unique programming model for all object types and object clients and object servers.
From a client's point of view, all objects are accessed through interface pointers. A pointer must be in progress. In fact, any call to an interface function always reaches some part of the code in process first. If the object is in process, the call reaches it directly, without any intermediate system infrastructure code. If the object is out of process, the call first reaches what is called the "proxy" object provided by COM or by the object (if the implementor so wishes). Proxy packets call the parameters (including any interface pointers) and generate the appropriate remote procedure call (or other communication mechanism in the case of custom generated proxies) to the other process or to the other machine where the implementation is located of the object. This process of packaging pointers for transmission across the process boundaries is called marshaling.
From the point of view of a server, all calls to the interface functions of an object are made through a pointer to that interface. Again, a pointer has context only in a single process, and the caller must always be a piece of code in process. If the object is in process, the caller is the client. Otherwise, the caller is a "stub" object provided by COM or by the object itself. The stub receives the remote procedure call (or other communication mechanism in the case of custom generated proxies) from the "proxy" in the client process, deselects the parameters and calls the appropriate interface on the server object. From the point of view of both clients and servers, they always communicate directly with some other code in process.
COM provides a marshaling implementation, known as standard marshaling. This implementation works very well for most objects and greatly reduces programming requirements, making the classification process transparent.
However, the clear separation between the interface and the implementation of transparency of the COM process may hamper in some situations. Designing an interface that focuses on its function from the customer's point of view can sometimes lead to design decisions that conflict with the efficient implementation of that interface over a network. In cases like these, what is needed is not pure transparency of the process but "transparency of the process, unless necessary." COM provides this capability by allowing an object implementor to support custom marshaling (also called IMarshal marshaling). Standard marshaling is, in fact, a custom marshaling instance; is the default implementation that is used when an object does not require custom marshaling.
You can implement marshaling customization to allow an object to take different actions when using a network than it takes under local access and is completely transparent to the client. This architecture allows designing client / object interfaces without taking into account network performance problems and subsequently addressing network performance problems without disrupting the established design.
COM does not specify how components are structured; specifies how they interact. COM leaves the concern about the internal structure of a component to programming languages and development environments. By contrast, programming environments do not have established standards for working with objects outside the immediate application. Microsoft Visual C ++, for example, works great for manipulating objects within an application, but it does not support working with objects outside the application. Generally, all other programming languages are the same in this regard. Therefore, to provide interoperability at the network level, COM, through independent language interfaces, picks up where programming languages are left.
The double indirection of the vtbl structure means that the pointers in the function pointers table do not need to point directly to the actual implementation on the actual object. This is the heart of the transparency of the process.