Distributed Objects
Introduction
A distributed object-based system is a collection of objects that isolates the requesters of services (clients) from the providers of services (servers) by a well-defined encapsulating interface.
In other words, clients are isolated from the implementation of services as data representations
and executable code.
This is one of the main differences that distinguishes the distributed object-based model from the pure client/server model.
In the distributed object-based model, a client sends a message to an object, which in turns interprets the message to decide what service to perform.
This service, or method, selection could be performed by either the object or a
broker. The Java Remote Method Invocation (RMI) and the Common Object
Request Broker Architecture (CORBA) are examples of this model.
The Roles of Client & Server
Client Server
Send request data
Return response data
Transmitting objects between client and server
The client/server model is a form of distributed computing in which one program (the client) communicates with another program (the server) for the purpose of exchanging information.
In this model, both the client and server usually speak the same language -- a protocol that both
the client and server understand -- so they are able to communicate.
While the client/server model can be implemented in various ways, it is typically done using low-level sockets.
Using sockets to develop client/server systems means that we must design a protocol, which is a set of commands agreed upon by the client and server through which they will be able to
communicate.
As an example, consider the HTTP protocol that provides a method called GET, which must be implemented by all web servers and used by web clients (browsers) in order to retrieve
documents.
The Distributed Objects Paradigm
Remote Method Call with Proxies
A distributed object is provided, or exported, by a process, here called the object server. A facility, here called an object registry, must be present in the system architecture for the distributed object to be registered.
To access a distributed object, a process –an object
client–looks up the object registry for a reference to the object. This reference is used by the object client to make calls to the methods.
A reference is a “handle”for an object; it is a representation through which an object can be located in the computer
where the object resides.
Logically, the object client makes a call directly to a remote method.
In reality, the call is handled by a software component, called a client proxy, which interacts with the software on the client host that provides the runtime support for the distributed object system.
The runtime support is responsible for the inter-process-communication needed to transmit the call to the remote host, including the marshalling of the
argument data that needs to be transmitted to the remote object.
A similar architecture is required on the server side, where the runtime support for the
distributed object system handles the receiving of messages and the unmarshalling of data, and forwards the call to a software component called the server proxy.
The server proxy interfaces with the distributed object to invoke the method call locally, passing in the unmarshalled data for the arguments.
The method call results in the performance of some tasks on the server host. The outcome of
the execution of the method, including the marshalled data for the return value, is forwarded by
the server proxy to the client proxy, via the runtime support and network support on both sides.
The distributed object paradigm has been widely adopted in distributed applications, for which a large number of mechanisms based on the paradigm are available. Among the most well known of such mechanisms are:
◦ Java Remote Method Invocation(RMI),
◦ the Common Object Request Broker Architecture(CORBA) systems,
◦ the Distributed Component Object Model(DCOM),
◦ mechanisms that support the Simple Object Access Protocol(SOAP).
Of these, the most straightforward is the Java RMI
RMI
RMI is a distributed object system that enables you to easily develop distributed Java applications.
Developing distributed applications in RMI is simpler than developing with
sockets since there is no need to design a protocol, which is an error-prone task.
In RMI, the developer has the illusion of calling a local method from a local class file, when in fact the arguments are shipped to the remote target and
interpreted, and the results are sent back to the callers.
Remote Method Invocation (RMI) is an object-oriented implementation of the Remote Procedure Call model. It is an API for Java programs only.
Using RMI, an object server exports a remote object and registers it with a directory service. The object provides remote methods, which can be invoked in client programs.
Syntactically:
◦ A remote object is declared with a remote interface, an extension of the Java interface.
◦ The remote interface is implemented by the object server.
◦ An object client accesses the object by invoking the remote methods associated with the objects using syntax provided for remote method invocations.
Stubs and Parameter Marshalling
When client wants to invoke a remote method on a remote object, it actually calls an ordinary method on proxy object called a stub.
Stub resides on the client machine.
Stub packages the parameters used in the remote method into a block of bytes.
This packaging uses the device independent encoding for each parameter.
The process of encoding the parameters is called parameter marshalling.
The purpose of parameter marshalling is to convert the parameters into a format suitable for
transport from one virtual machine to another.
The stub method on the client machine builds an information block that consists of:
◦ An identifier of the remote object to be used
◦ A descriptor of the method to be called
◦ The marshalled parameter
The stub then send this information to the server.
Server side, a receiver object performs the following actions for every remote method call:
◦ It unmarshals the parameters
◦ It locates the object to be called
◦ It calls the desired method
◦ It capture and marshals the return value or exception of the call
◦ It sends a package consisting of the marshalled return back to the stub on the client.
The client stub un-marshals the return value or exception from the server.
This value becomes the return of the stub call.
Or, if the remote method threw an exception, the stub rethrows it in the process space of the
caller.
Client Stub Skeleton Server
Call stub method locally
Send marshalled parameters Call Server method locally
Return method result Send marshalled return value
or exception Return value or
throw exception
Parameter marshalling
