Distributed object communication

In adistributed computingenvironment,distributed object communicationrealizes communication betweendistributed objects.The main role is to allow objects to access data and invokemethodson remote objects (objects residing in non-localmemory space). Invoking a method on a remote object is known asremote method invocation(RMI) orremote invocation,and is theobject-oriented programminganalog of aremote procedure call(RPC).

Class stubs and skeletons

The widely used approach on how to implement the communication channel is realized by usingstubsandskeletons.They are generated objects whose structure and behavior depends on chosen communication protocol, but in general provide additional functionality that ensures reliable communication over the network.

In RMI, a stub (which is the bit on the client) is defined by the programmer as aninterface.The rmic (rmi compiler) uses this to create the class stub. The stub performs type checking. The skeleton is defined in a class whichimplementsthe interface stub.

When a caller wants to perform remote call on the called object, it delegates requests to itsstubwhich initiates communication with the remoteskeleton.Consequently, the stub passes caller arguments over the network to the server skeleton. The skeleton then passes received data to the called object, waits for a response and returns the result to the client stub. Note that there is no direct communication between the caller and the called object.

In more details, the communication consists of several steps:

1. caller calls a localprocedureimplemented by the stub
2. stubmarshallscall type and the input arguments into a request message
3. client stub sends the message over the network to the server and blocks the current executionthread
4. server skeleton receives the request message from the network
5. skeleton unpacks call type from the request message and looks up theprocedureon the called object
6. skeletonunmarshallsprocedure arguments
7. skeleton executes theprocedureon the called object
8. called object performs a computation and returns the result
9. skeleton packs the output arguments into a response message
10. skeleton sends the message over the network back to the client
11. client stub receives the response message from the network
12. stub unpacks output arguments from the message
13. stub passes output arguments to the caller, releases executionthreadand caller then continues in execution

The advantage of this architecture is that neither the caller nor the called object has to implement network related logic. This functionality, that ensures reliable communication channel over the network, has been moved to thestuband theskeletonlayer.

Stub

The client side object participating in distributed object communication is known as astuborproxy,and is an example of aproxy object.

The stub acts as a gateway for client side objects and all outgoing requests to server side objects that are routed through it. The stub wraps client object functionality and by adding the network logic ensures the reliable communication channel between client and server. The stub can be written up manually or generated automatically depending on chosen communication protocol.

The stub is responsible for:

• initiating the communication towards the serverskeleton
• translating calls from the caller object
• marshallingof the parameters
• informing theskeletonthat the call should be invoked
• passing arguments to theskeletonover the network
• unmarshallingof the response from theskeleton
• informing the caller that the call is complete

Skeleton

The server side object participating in distributed object communication is known as askeleton(or stub; term avoided here).

A skeleton acts as gateway for server side objects and all incoming clients requests are routed through it. The skeleton wraps server object functionality and exposes it to the clients, moreover by adding the network logic ensures the reliable communication channel between clients and server. Skeletons can be written up manually or generated automatically depending on chosen communication protocol.

The skeleton is responsible for:

• translating incoming data from thestubto the correct up-calls to server objects
• unmarshallingof the arguments from received data
• passing arguments to server objects
• marshallingof the returned values from server objects
• passing values back to the clientstubover the network

Protocols using stub/skeleton approach

• Portable Distributed Objects(PDO) -Objective-C
• Common Object Request Broker Architecture(CORBA) – inter-language
• Java remote method invocation(Java RMI) – Java
• Distributed Component Object Model(DCOM) – Microsoft, inter-language

  (note that the stub is called "proxy" and the skeleton is called "stub")

• .NET Remoting– Microsoft, inter-language
• DDObjects–Borland Delphi
• Distributed Ruby(DRb) –Ruby

See also

• Object request broker
• Distributed object

References

• Plášil, František and Stal, Michael."An Architectural View of Distributed Objects and Components in CORBA, Java RMI, and COM/DCOM"Archived2007-06-24 at theWayback Machine,Software Concepts & Tools (vol. 19, no. 1),January, 1998.
• Druschel, Peter"Distributed Program Construction"Archived2016-03-04 at theWayback Machine
• Farley, Jim.Java Distributed Computing,O'Reilly, January, 1998.
• Research PapersArchived2008-02-12 at theWayback Machine,Distributed Systems Research Group, Charles University Prague