You are on page 1of 14

1

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

CHAPTER-5 Distributed Objects & Remote Invocation
A distributed programming model is as an abstraction layer above
communication protocols details.
Different Programming models provided by middleware to support
distributed applications include:
 Remote Procedure Call (RPC):
• Allows Client programs to call procedures in server
programs running in separate processes and generally in
different computer from client
 Remote Method Invocation (RMI):
• An extension of local method invocation that allows an
object living in one process to invoke the methods of an
object living in another process
 Event-based processing and event notification:
• The behavior of the system is driven by events, which
represent local state changes within objects.
• Objects receive notifications of events at other objects
in which they have registered interest.

MIDDLEWARE
 Software that provides a programming model above the basic
building blocks of processes and message passing is called
middleware
 It uses protocols based on messages between processes to provide
its higher level abstractions such as remote invocations and events
 Example remote invocation abstraction is based on the request
reply protocol
 The important aspects of middleware are
D.ABHISHEKH MSSE

SV COLLEGES

It is not possible for a module running in one process to access the variables in a module in another process.ABHISHEKH MSSE SV COLLEGES .  Transparency of programming language used  e. request/reply protocol used to implement RPC can use either transport protocols (UDP or TCP). use of external data representations. INTERFACES IN DISTRIBUTED SYSTEMS In a distributed program.  Transparency of computer hardware and operating system:  e. however the attributes are not accessed directly but by means of some getter and setter procedures added automatically to the interface DISTRIBUTED OBJECTS  The logical partition of object-based programs into objects is naturally extended by the physical distribution of objects into different processes or computers in a distributed system. the modules can run separate process..g.  Distributed object systems adopt the client-server architecture:  Objects are managed by servers and their clients invoke their methods using remote method invocation. by use of programming language independent Interface Definition Languages.2 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION  Middleware is the provision of transparency and heterogeneity challenges:  Location transparency:  RMI and RPC invoked without knowledge of the location of invoked method/procedure.  Transport protocol transparency:  e.g. such as CORBA IDL... Therefore the interface of a module that is intended for RPC or RMI cannot specify direct access. D.g.

3 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION  The client’s RMI request is sent in a message to the server managing the invoked method object.  Objects in servers are allowed to become clients of objects in other servers.  Objects in other processes can invoke only the methods that belong to the remote interface of the remote object.  The method of the object at the server is executed and its result is returned to the client in another message.  Local objects can invoke the methods in the remote interface as well as other methods of the remote object.  Other objects need to know the remote object reference in another process in order to invoke its methods. DISTRIBUTED OBJECT MODEL  Each process contains a collection of objects.ABHISHEKH MSSE SV COLLEGES .  A remote object reference is an identifier that can be used through a distributed system to refer to a particular unique remote object. D. some of which can receive both local and remote invocations and others can receive only local invocations.  Every remote object has a remote interface to specify which of its methods can be invoked remotely.  Objects that can receive remote invocations are called remote objects.

different choices of fault-tolerance measures can be applied:  Retry request message until a reply is received or the server is assumed to be failed  Duplicate filtering when a retransmission are used whether to filter out duplicate request at the server.4 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION  Object B and F are remote objects and they must have remote interface  the remote object to receive a remote method invocation is specified by the invoker as a remote object reference DESIGN ISSUES FOR RMI  RMI usually applied via request/reply protocol which can suffer from many types of failure:  Message omission and duplication can occur if implemented over UDP.  Retransmission of results when retransmitted request arrives or result retransmission (requires keeping a history at the server).ABHISHEKH MSSE SV COLLEGES .  Process failures (crash or arbitrary) are also possible. D.  Combinations of fault-tolerance choices lead to a variety of invocation semantics for the reliability of remote invocation.  Therefore.

 At-least-once invocation semantics:  Uses only retransmission of request messages – masks omission failures. • Crash failures if the server containing the remote object fails. D.  The invoker cannot tell if a remote method has been executed or not. • Arbitrary failures when re-execute the method more than once which causing wrong values to stored or returned (non-idempotent operations).ABHISHEKH MSSE SV COLLEGES .  The invoker receives either a result (after at least one execution) or an exception informing no result was received.  Suffer from the following types of failure: • Omission failures if invocation or result message is lost.  At-most-once invocation semantics:  Uses all the fault-tolerance measures.5 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION  Maybe invocation semantics:  No fault-tolerance measure is applied.  Suffer from the following types of failure: • Crash failure if the server containing the remote object fails.

ABHISHEKH MSSE SV COLLEGES . request id.  Remote reference modules: • Translate between local and remote object references and create remote object references. D. • Select the dispatcher software for the invoked object class in the server. • Use only the first three items of the request and reply messages: message type.6 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION  The invoker receives either a result (after exactly one execution) or an exception informing no result was received.  An entry for each local proxy held by the client in its table.  Prevents arbitrary failures by ensuring that a method is never executed more than once for the same RMI. RMI IMPLEMENTATION  Several separate objects and modules are involved to achieve a remote method invocation:  Communication modules: • Responsible for providing a specified invocation semantics. • Have a remote object table in each process to support the translation. • Carry out the request-reply protocol to transmit request and reply messages between the cooperating server and client.  An entry for all the remote objects held by the server in its table. and the invoked remote object reference.

 Forward the call in a message to the remote object and hiding all in-between operations (send. its own methodId and its arguments into a request message and send it to the target then await the reply message to unmarshal it and return the result to the invoker. receive.  A client has one proxy for each remote object to hold its remote reference and implement the methods in its remote interface. • Translate the remote object reference to the corresponding local object reference which refer either to a remote object (in the server) or to a proxy (in the client).ABHISHEKH MSSE SV COLLEGES .  RMI Software: • Proxy:  Make remote method invocation transparent to clients by behaving like a local object to the invoker.  Receive the request message from the communication module and use the methodId to select the appropriate method in the skeleton and passing on the request message. D. and unmarshalling) from the client.  Marshal a reference to the target object.7 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION • Create a remote object reference and add it to the table when a remote object is passed in a request or a replay message for the first time. • Dispatcher:  A server has one dispatcher for each class representing a remote object. marshalling.

• The classes of the proxy.  Unmarshal the argument in the request message and invoke the corresponding method in the remote object.8 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION • Skeleton:  Each class representing a remote object has a skeleton in the server to implement each method in the remote interface.  Await the invocation to complete to marshal the result in the reply message to the client proxy’s method.ABHISHEKH MSSE SV COLLEGES . and dispatcher used in RMI are generated automatically by an interface complier. • The client program contains the classes of the proxies for all the remote objects that it will invoke and use a binder to look up remote object references. skeleton. • The server program contains the classes for the dispatchers and skeletons together with the implementations of the classes of all remote objects that it supports – servant classes. D.

 The contents of request and reply messages are the same as RMI except that the object reference field is omitted.  The client and server stub procedures and the dispatcher are generated by an interface compiler from the definition of the service interface.  Implemented to have one of the choices of invocation semantics.  The supported software is similar except that no remote reference modules are required and client proxies and server skeletons are replaced by client and server stub procedures.  The service interface of the server defines the procedures that are available for calling remotely. D.9 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION Remote Procedure Call (RPC)  Very similar to a remote method invocation  A client process calls a procedure in a server process.  Implemented over a request-reply protocol .ABHISHEKH MSSE SV COLLEGES .  Servers may be clients of other servers to allow chains of RPCs.

objects that represent events is called notifications Dealing with room system External source Dealer’s Dealer Dealer’s Notification Notification Notification Information provider Notification Notification Dealer’s Notification Notification Notification Dealer Notification Dealer Dealer’s Information provider Notification Dealer Externa sourc D.ABHISHEKH MSSE SV COLLEGES .10 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION EVENTS & NOTIFICATIONS The idea behind the use of events is that one object can react to a change occurring in another object. Notifications of events are essentially asynchronous & determined by their receivers Distributed events. Objects that want to receive notifications from an object that has published its events subscribe to the types of events that are of interest to them.based systems extend the local event model by allowing multiple objects at different locations to be notified of events taking place at an object they use PUBLISH-SUBSCRIBE PARADIGM . in which an object that generates events publishes the type of events that it will make available for observation by other objects.

11 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION Client Server Stubs Skeletons Remote Reference Remote Reference Transport There are three layers that comprise the basic remoteobject communication facilities in RMI: 1. D.ABHISHEKH MSSE SV COLLEGES . which provides the interface that client and server application objects use to interact with each other. The stub/skeleton layer.

3. The remote reference layer. The server object receives this request from a server-side object skeleton. The client uses the client-side stub to make a request of the remote object. or a user defined object) is checked as it is marshaled. The stub maintains an internal reference to the remote object it represents and forwards the method invocation request through the remote reference layer by marshaling the method arguments into serialized form and asking the remote reference layer to forward the method request and arguments to the appropriate remote object. If it does. If it isn’t a Remote object but is rather a Serializable object. 3. 2. its remote reference is used as its marshaled data. which is the middleware between the stub/skeleton layer and the underlying transport protocol. the object is serialized into bytes that are sent to the remote host and reconstructed into a copy of the local object. which is the binary data protocol that sends remote object requests over the wire. Description of the architecture: 1.Remote interface. The transport protocol layer. A client initiates an RMI invocation by calling a method on a stub object. Marshaling involves converting local objects into portable form so that they can be transmitted to a remote process. Each object (e. to determine whether it implements the java.12 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION 2.rmi. a String object.ABHISHEKH MSSE SV COLLEGES . an array object. If the object is D.g.

8. If the marshaling of method arguments succeeds. the server-side remote reference layer receives the transport-level request and converts it into a request for the server skeleton that matches the referenced object. i. On the server. the client-side remote reference layer receives the remote reference and marshaled arguments from the stub.ABHISHEKH MSSE SV COLLEGES .e. 5.MarshalException back to the client.. The result is sent back using the appropriate transport protocol (e. Socket API using TCP/IP). 6.13 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION neither Remote nor Serializable. the skeleton marshals the object for transport back to the client and forwards it through the server reference layer. D. and arguments sent as serialized objects are converted into local copies of the originals. The remote reference layer converts the client request into lowlevel RMI transport requests. If the method calls generates a return value or an exception.g. into a single network-level request and sends it over the wire to the sole remote object that corresponds to the remote reference passed along with the request. where it passes through the client reference layer and stub. This involves unmarshaling the method arguments into the server environment and passing them to the server object. 7. the stub throws a java. The skeleton converts the remote request into the appropriate method call on the actual server object.rmi. 4. is unmarshaled by the stub. and is finally handed back to the client thread that invoked the remote method. Arguments sent as remote references are converted into local stubs on the server.

 FORMAT: rmi//ComputerName/ObjectService D.ABHISHEKH MSSE SV COLLEGES . If the registry finds the object. it generates a remote reference to the object and delivers it to the client process.  A client can obtain a stub reference to the remote object by asking for the object by name through the Naming interface. The object’s name is in a URL-like syntax that includes the name of the object’s host and the object’s registered name. where it is converted into a stub (local) reference that is returned to the caller.lookup() method takes the name of a remote object and locates the object on the network. it consults the RMI registry on the host and asks for the object by name.  Once the lookup() method locates the object’s host. The Naming.14 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION RMI REGISTRY Naming/Registry Service  A server process needs to register one (or more) RMIenabled objects with its local RMI registry (represented by the Registry interface) using a name that clients can use to reference it.