Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Distributed Objects and Remote Invocation

57 views

Published on

Distributed Objects and Remote Invocation

Published in: Education
  • Be the first to comment

  • Be the first to like this

Distributed Objects and Remote Invocation

  1. 1. DISTRIBUTED SYSTEMS B. Tech IV/IV, II Semester COMPUTER SCIENCE & ENGINEERING 2/6/2017 © Copyright Material 1
  2. 2. UNIT III 2/6/2017 2 Distributed Systems Foundation Middleware Support Systems Algorithms & Shared Data Characterization of Distributed Systems System Models Inter Process Communication Distributed Objects Remote Invocation Operating System Distributed File System Coordination & Agreement Transactions & Replications © Copyright Material
  3. 3. What we learnt in Unit III 1. Introduction to Interprocess communication 2. The Characteristics of Interprocess communication 3. Understanding what is a Socket & its purpose 4. Fundamentals of programming using Internet Protocols 5. Types of Communication channels 1. UDP Datagram Communication 2. TCP Stream Communication 6. Need for External Data Representation & Marshalling 7. How to establish Client Server Communication 8. Introduction to Group Communication 9. IP Multicast- an implementation of group communication 10. Reliability and Ordering of Multicast. 2/6/2017 3© Copyright Material
  4. 4. Topic of Contents 1. Introduction of Programming Models 2. What is an Object Model & its role in communication 1. What are Remote Objects References? 2. What are Object References? 3. Actions, Exceptions 4. Garbage Collection 3. Understanding of Distributed Objects 4. Learning distributed object Model 5. Design issues of RMI 6. Implementation of RMI 7. Working of a Distributed Garbage Collection 8. Working of Remote Procedure Call 9. Role of Events & Notifications in Distributed Communication 10. Case Study: Java RMI 2/6/2017 4© Copyright Material
  5. 5. Learning Objective Upon completion of this unit, students will be able to: • Study communication between distributed objects • Understand integration of remote method invocation into a programming language. • Use Java RMI to program applications with distributed objects • Study the extension of the event-based programming model to apply to distributed event-based programs. • Learn about how to release resources with respect to distributed environment. • Create a piece of code to create a Distributed Communication 2/6/2017 5© Copyright Material
  6. 6. 1. Introduction 2/6/2017 6© Copyright Material MIDDLEWARE LAYERS What we have been introduced till now What we have learnt in Unit III What we learn in this Unit???
  7. 7. Programming Models for Distributed Communication 3 Types of Programming models – Remote Procedure Calls – Client programs call procedures in server programs – Remote Method Invocation – Objects invoke methods of objects present on distributed hosts – Event-based Programming Model – Objects receive notice of events in other objects in which they have interest 1. Introduction 2/6/2017 7© Copyright Material
  8. 8. Middleware: Software that allows a level of programming beyond processes and message passing – Uses protocols based on messages between processes to provide its higher-level abstractions such as remote invocation and events – Supports location transparency – Usually uses an Interface Definition Language (IDL) to define interfaces Interface: ”a common boundary or interconnection between systems , equipment, concepts” in English 1. Introduction 2/6/2017 8© Copyright Material
  9. 9. Interfaces in Programming Languages – Programming Languages allow programs to be developed as a set of modules that communicate with each other. Permitted interactions between modules are defined by interfaces – A specified interface can be implemented by different modules without the need to modify other modules using the interface Interfaces in Distributed Systems – When modules are in different processes or on different hosts there are limitations on the interactions that can occur. Only actions with parameters that are fully specified and understood can communicate effectively to request or provide services to modules in another process – A service interface allows a client to request and a server to provide particular services – A remote interface allows objects to be passed as arguments to and results from distributed modules Object Interfaces – An interface defines the signatures of a set of methods, including arguments, argument types, return values and exceptions. Implementation details are not included in an interface. A class may implement an interface by specifying behavior for each method in the interface. Interfaces do not have constructors 1. Introduction 2/6/2017 9© Copyright Material
  10. 10. 1. Introduction 2/6/2017 10© Copyright Material MIDDLEWARE LAYERS , IDL operates hereWe have learnt the layers of middleware INTERFACE DEFINITION LANGUAGE
  11. 11. • Can we have a System using which we can perform Very Heavy Calculations? Ex: Building massive search engines, MMOG’s, Banking Systems, WWW……??? • Can a small enterprise think of investing in buying such a system • How about maintaining such an Infrastructure? Is there any alternative???? 1. Can we share resources somehow  resources like processor, harddisk, network 2. How to handle parallel processing, without disrupting their (who shared resources) work? 2. What is an Object Model 2/6/2017 11© Copyright Material
  12. 12. Remote Method Invocation serves the purpose through an Object Model           Object Model: An object-oriented program consists of a collection of interacting objects consisting of a set of data and a set of methods – In a Distributed System, any Object’s data should be accessible only via its methods, generally passing arguments and receiving results – Objects can encapsulate their data and the code of their methods Object model involves 5 parts a) Object References b) Interfaces c) Actions d) Exceptions e) Garbage Collection 2. What is an Object Model 2/6/2017 12© Copyright Material
  13. 13. a) Object References: – Objects are accessed by object references – Object references can be assigned to variables, passed as arguments, and returned as the result of a method – Can also specify a method to be invoked on that object – If b1 refers to Box object, then b2 is a Reference to b1, sharing the properties of b1 2. What is an Object Model 2/6/2017 13© Copyright Material
  14. 14. b) Interfaces – Provide a definition of the signatures of a set of methods without specifying their implementation – Define types that can be used to declare the type of variables or of the parameters and return values of methods – An object defines the methods of an Interface – Using a Reference, we can call the implementation of the Object – An interface acts as a common reference across all the objects implementing this interface 2. What is an Object Model 2/6/2017 14© Copyright Material
  15. 15. c) Actions: – Objects invoke methods in other objects – An invocation can include additional information as arguments to perform the behavior specified by the method – Effects of invoking a method 1. The state of the receiving object may be changed 2. A new object may be instantiated 3. Further invocations on methods in other objects may occur 4. An exception may be generated if there is a problem encountered 2. What is an Object Model 2/6/2017 15© Copyright Material
  16. 16. d) Exceptions • Provide a clean way to deal with unexpected events or errors ex: inconsistent values in the object variables • A block of code can be defined to throw an exception when errors or unexpected conditions occur. Then control passes to code that catches the exception e) Garbage Collection • Provide a means of freeing the space that is no longer needed • Java does this automatically & in C++ user must explicitly handle it 2. What is an Object Model 2/6/2017 16© Copyright Material
  17. 17.  The process of distributing objects into different processes or computers across a distributed system creates Distributed Objects  State of an object consists of the values of its instance variables. Saving the state of an object helps restoring the application with minimal effort  Methods of an object can be invoked using the methodology of Remote Method Invocation (RMI), and this is the way of achieving the remote execution of the method, even by multiple systems at the same time. Usually, the systems adopt Client-Sever architecture & the basic model of approach would have • Objects managed by the Servers and • Their clients invoke the methods of these objects using RMI 3. Understanding Distributed Objects 2/6/2017 17© Copyright Material
  18. 18.  What are the steps involved in RMI? 1. The client sends the RMI request in a message to the server 2. The server executes the invoked method of the object 3. The server returns the result to the client in another message  There are other models as well like – Chains of related invocations: objects in servers may become clients of objects in other servers ex. DNS Server – Object replication: objects can be replicated for fault tolerance and performance ex. Hadoop Distributed File System – Object migration: objects can be migrated to enhancing performance and availability ex. VMWare VMotion 3. Understanding Distributed Objects 2/6/2017 18© Copyright Material
  19. 19. Having understood the Object Model (OM) & Distributed Objects, let us now apply them together and learn OM in Distributed space The 2 fundamental concepts of a Distributed Object Model are 1. Remote Object Reference 2. Remote Interface • From the diagram below: – Each process contains objects, some of which can receive remote invocations are called remote objects (B, F), others only local invocations – Objects need to know the remote object reference of an object in another process in order to invoke its methods, called remote method invocations – Every remote object has a remote interface that specifies which of its methods can be invoked remotely 4. Learning Distributed Object Model 2/6/2017 19© Copyright Material invocation invocation remote local local local invocation invocation B C D E A Finvocation remote
  20. 20. As discussed earlier, for a Distributed Object Model, these are the 5 essential requirements a) Remote Object References b) Remote Interfaces c) Actions d) Exceptions e) Distributed Garbage Collection a) Remote Object References: – Object references are used for accessing the remote objects – These references are the common identifiers throughout a distributed system – Object references can also be passed as arguments 4. Learning Distributed Object Model 2/6/2017 20© Copyright Material
  21. 21. b) Remote Interfaces: – Remote interfaces specify those methods which can be invoked remotely – These would only contain the name of the method, arguments, return type & constant variables – Interface Definition Language (IDL) is used for defining remote interface and instantiating remote objects 4. Learning Distributed Object Model 2/6/2017 21© Copyright Material Interface Remote m1 m2 m3 m4 m5 m6 Data Implementation Remote Object { of methods
  22. 22. c) Actions: • An action initiated by a method invocation may result in further invocations on methods in other objects located in difference processes or computers • Remote invocations could lead to the instantiation of new objects, i.e. objects M and N of the figure below 4. Learning Distributed Object Model 2/6/2017 22© Copyright Material C NM K invocation remote invocation remote L instantiate instantiate
  23. 23. d) Exceptions: New kinds of exceptions: like timeout exception – RMI should be able to raise exceptions such as timeouts that are due to distribution as well as those raised during the execution of the method invoked e) Distributed Garbage Collection – Distributed garbage collections is generally achieved by cooperation between the existing local garbage collector and an added module that carries out a form of distributed garbage collection, usually based on reference counting – More on Distributed Garbage collection is explained later in the unit 4. Learning Distributed Object Model 2/6/2017 23© Copyright Material
  24. 24. Two design issues that arise in extension of local method invocation for RMI a. The choice of invocation semantics • Although local invocations are executed exactly once, this cannot always be the case for RMI due to transmission error – Either request or reply message may be lost – Either server or client may be crashed b. The level of transparency • Make remote invocation as much like local invocation as possible 5. Design Issues of Communication 2/6/2017 24© Copyright Material
  25. 25. a. THE CHOICE OF INVOCATION SEMANTICS Error handling for delivery guarantees – Retry request message: whether to retransmit the request message until either a reply is received or the server is assumed to have failed – Duplicate filtering: when retransmissions are used, whether to filter out duplicate requests at the server – Retransmission of results: whether to keep a history of result messages to enable lost results to be retransmitted without re- executing the operations Choices of invocation semantics – Maybe: the method executed once or not at all (no retry nor retransmit) – At-least-once: the method executed at least once – At-most-once: the method executed exactly once The figure in the next slide illustrates the invocation semantics 5. Design Issues of Communication 2/6/2017 25© Copyright Material
  26. 26. a. THE CHOICE OF INVOCATION SEMANTICS 5. Design Issues of Communication 2/6/2017 26© Copyright Material Fault tolerance measures Invocation semantics Retransmit request message Duplicate filtering Re-execute procedure or retransmit reply No Yes Yes Not applicable No Yes Not applicable Re-execute procedure Retransmit reply At-most-once At-least-once Maybe
  27. 27. b. THE LEVEL OF TRANSPARENCY • Transparent remote invocation: as if the methods & variables are available in the current system. • Performing the below operations gives the impression of transparency – Marshalling/Unmarshalling – Locating remote objects: using remote references – Accessing using the same syntax of the remote methods Differences between local and remote invocations – Latency: a remote invocation is usually several order of magnitude greater than that of a local one – Availability: remote invocation is more likely to fail – Errors/Exceptions: failure of the network? server? hard to tell • syntax might need to be different to handle different local vs remote errors/exceptions – Consistency on the remote machine 5. Design Issues of Communication 2/6/2017 27© Copyright Material
  28. 28. Various components of a RMI Communication are 1. Communication module 2. Remote Reference Module 3. Servant 4. RMI Software – Proxy, Dispatcher, Skeleton The following diagram shows the architecture of RMI 6. Implementation of RMI 2/6/2017 28© Copyright Material object A object Bskeleton Request proxy for B Reply CommunicationRemote Remote referenceCommunication modulemodulereference module module for B’s class & dispatcher remote client server servant
  29. 29. Various components of a RMI Communication are 1. Communication module • Two cooperating communication modules carry out the request-reply protocols using message type, requestID & remote object reference – Transmit request and reply messages between client and server – Implement specific invocation semantics • The communication module in the server – Selects the dispatcher for the class of the object to be invoked – Passes on local reference from remote reference module – Returns request 6. Implementation of RMI 2/6/2017 29© Copyright Material
  30. 30. Various components of a RMI Communication are 2. Remote Reference Module • Responsible for translating between local and remote object references and for creating remote object references • Remote Object Table: records the correspondence between local and remote object references – Remote Objects held by the process (B on server) – Local Proxy (B on client) • When a remote object is to be passed for the first time, the module is asked to create a remote object reference, which it adds to its table 6. Implementation of RMI 2/6/2017 30© Copyright Material
  31. 31. Various components of a RMI Communication are 3. Servant: An instance of a class which provides the body of a remote object & this handles the remote requests 4. RMI Software: – Proxy: behaves like a local object, but represents the remote object – Dispatcher: look at the methodID and call the corresponding method in the skeleton – Skeleton: implements the method • Generated automatically by an interface compiler Binder is a separate service to locate service/object by name through table mapping for names and remote object references. – This is often called as RMI Registry, which is a service provided by Java 6. Implementation of RMI 2/6/2017 31© Copyright Material
  32. 32. Activation of Remote Objects Many server objects are not necessarily in use all of the time – Servers can be started whenever they are needed by clients, similar to inetd Therefore need the Object status: active or passive – Active: available for invocation in a running process – Passive: not running, state is stored and methods are pending How to activate objects: – Creating an active object from the corresponding passive object by creating a new instance of its class – initializing its instance variables from the stored state Responsibilities of activator – Register passive objects that are available for activation – Start named server processes and activate remote objects in them – Keep track of the locations of the servers for remote objects that it has already activated 6. Implementation of RMI 2/6/2017 32© Copyright Material
  33. 33. Persistent object stores: Where to get the objects from An object that is guaranteed to live between activations of processes is called a Persistent Object • Persistent object store is spefically used for managing the persistent objects – Stored in marshaled from on disk for retrieval – saved those that were modified • Deciding whether an object is persistent or not: – Persistent root: any object that is reachable from a persistent root(ex: Persistent Java, PerDiS) – Some classes are declared persistent (ex: Arjuna system) 6. Implementation of RMI 2/6/2017 33© Copyright Material
  34. 34. Object location: How to locate these objects – By specifying a location: ip address, port #, … – Location service for migratable objects • Map remote object references to their probable current locations • Cache/broadcast scheme (similar to ARP) – Cache locations – If not in cache, broadcast to find it How to improve it: By the use of Object Location Pointers, contains hints to the new location of an object,similar to mobile IP 6. Implementation of RMI 2/6/2017 34© Copyright Material
  35. 35. Step 1: Client calls proxy Step 2. Proxy obtains remote reference & updates remote references Step 3. Proxy marshalls the necessary parameters Step 4. Proxy forwards the request to clients communication module Step 5. Clients communication module sends request to server Step 6. Server communication module at server receives request Step 7. Server communication module forwards request to dispatcher for the requested class Step 8. Dispatcher calls requested method in skeleton Step 9. Skeleton unmarshalls parameters & updates remote reference module Step 10. Skeleton calls servant Step 11. Skeleton marshalls results and updates remote reference module Step 12. Skeleton forwards reply to server communication module Step 13. Server communication module sends reply Step 14. Clients communication module receives request & forwards it to proxy object Step 15. proxy unmarshalls & proxy updates remote reference module Step 16. proxy returns to result to client 6. Implementation of RMI 2/6/2017 35© Copyright Material
  36. 36. • Garbage Collection, as known already, releases memory from objects which don’t have any active references pointing • What is the worry with Distributed Garbage Collection? – Ensure that an object continues to exist if a local or remote reference to it is still held anywhere. How to know about active references? – Ensure that an object be collected as soon as no object any longer holds a reference to it. How to know about active references? • Solution: By maintaining a reference count for every object!! • What is the Java's way of attacking this problem – The server of an object keeps track of proxies – When a proxy is created for a remote object • addRef(B) tells the server to add an entry – when the local host's garbage collector removes the proxy • removeRef(B) tells the server to remove the entry – when no entries for object B, the object on server is deallocated 7. Distributed Garbage Collection 2/6/2017 36© Copyright Material
  37. 37. RMI Was kind of derived from RPC itself. With the understanding of RMI, RPC looks very similar • Client: "stub" instead of "proxy" (same function, different names) – local call, marshal arguments, communicate the request • Server: – Dispatcher: matches with the appropriate method declaration – "stub": unmarshal arguments, communicate the results back 8. Working of RPC 2/6/2017 37© Copyright Material client Request Reply CommunicationCommunication modulemodule dispatcher service client stub server stub procedure procedure client process server process procedureprogram
  38. 38. Sun RPC was the first version to service client-server in the SUN NFS (network file system) – It can be implemented on UDP or TCP – It was also called ONC (Open Network Computing) RPC • Interface Definition Language (IDL) – Initially External Data Representation (XDR) is for data representation which was later extended to be IDL – XDR is less modern than CORBA IDL and Java – Uses program numbers instead of Interface names, as was the case with RMI – Uses procedure numbers instead of procedure names, as was the case with RMI – Uses a single input parameter (structs) The Compiler used for XDR is “rpcgen” – It uses Client stub; server main procedure, dispatcher, and server stub 8. Working of RPC 2/6/2017 38© Copyright Material
  39. 39. • Binding is indeed done using a local binder – portmapper – Server registers its program/version/port numbers with portmapper – Client contacts the portmapper at a fixed port with program/version numbers to get the server port – Different instances of the same service can be run on different computers at different ports • Authentication – request and reply have additional fields like user credentials – unix style (uid, gid), shared key for signing, Kerberos 8. Working of RPC 2/6/2017 39© Copyright Material
  40. 40. const MAX = 1000; typedef int FileIdentifier; typedef int FilePointer; typedef int Length; struct Data { int length; char buffer[MAX]; }; struct writeargs { FileIdentifier f; FilePointer position; Data data; }; 8. Working of RPC 2/6/2017 40© Copyright Material struct readargs { FileIdentifier f; FilePointer position; Length length; }; program FILEREADWRITE { version VERSION { //Method Numbers void WRITE(writeargs)=1; Data READ(readargs)=2; }=2; //Version Number } = 9999; //Program Number
  41. 41. Why should there be events? – Because one object can react to a change occurring in another object Events – Notifications of events are generally asynchronous and determined by receivers what events are interested – Events are caused due to the change in the object state of the application – Subscription filtering allows the system to focus on certain values in the attributes Publish-subscribe paradigm – Publish: Process of sending all the marked events – Subscribe: Process of receiving all the marked events Main characteristics in a distributed event-based systems – Heterogeneous: a way to standardize communication in heterogeneous systems not designed to communicate directly – Asynchronous: notifications are sent asynchronously no need for a publisher to wait for each subscriber--subscribers come and go 9. Events & Notifications 2/6/2017 41© Copyright Material
  42. 42. Distributed Event Notification – Decouple publishers from subscribers via an event service (manager) Architecture: roles of participating objects – Object of interest (usually changes in states are interesting) – Event – Notification – Subscriber – Observer object (proxy) [reduce work on the object of interest] • Forwarding • Filtering of events types and content/attributes • Patterns of events (occurrence of multiple events, not just one) • Mailboxes (notifications in batches, subscriber might not be ready) – Publisher (object of interest or observer object) • Generates event notifications 2/6/2017 42© Copyright Material 9. Events & Notifications
  43. 43. Distributed Event Notification Three cases • Inside object without an observer: send notifications directly to the Subscribers • Inside object with an observer: send notification via the observer to the subscribers • Outside object (with an observer) – An observer queries the object of interest in order to discover when events occur – The observer sends notifications to the subscribers 9. Events & Notifications 2/6/2017 43© Copyright Material subscriberobserverobject of interest Event service object of interest object of interest observer subscriber subscriber 3. 1. 2. notification notification notification notification
  44. 44. Case Study: Jini Distributed Event Specification Jini Allow a potential subscriber in one Java Virtual Machine (JVM) to subscribe to and receive notifications of events in an object of interest in another JVM • Main objects – Event generators (publishers) – Remote event listeners (subscribers) – Remote events (events) – Third-party agents (observers) • An object subscribes to events by informing the event generator about the type of event and specifying a remote event listener as the target for notification 9. Events & Notifications 2/6/2017 44© Copyright Material
  45. 45. Java Remote Interfaces import java.rmi.*; import java.util.Vector; public interface Shape extends Remote { int getVersion() throws RemoteException; GraphicalObject getAllState() throws RemoteException; } public interface ShapeList extends Remote { Shape newShape(GraphicalObject g) throws RemoteException; Vector allShapes() throws RemoteException; int getVersion() throws RemoteException; } 10. Case Study: Java RMI 2/6/2017 45© Copyright Material
  46. 46. Implementation of the Interface import java.rmi.*; import java.rmi.server.UnicastRemoteObject; import java.util.Vector; public class ShapeListServant extends UnicastRemoteObject implements ShapeList { private Vector theList; // contains the list of Shapes private int version; public ShapeListServant()throws RemoteException{...} public Shape newShape(GraphicalObject g) throws RemoteException { version++; Shape s = new ShapeServant(g, version); theList.addElement(s); return s; } public Vector allShapes()throws RemoteException{...} public int getVersion() throws RemoteException { ... } } 10. Case Study: Java RMI 2/6/2017 46© Copyright Material
  47. 47. Client Program import java.rmi.*; public class ShapeListServer{ public static void main(String args[]){ System.setSecurityManager(new RMISecurityManager()); try{ ShapeList aShapeList = new ShapeListServant(); Naming.rebind("Shape List", aShapeList ); System.out.println("ShapeList server ready"); }catch(Exception e) { System.out.println("ShapeList server main " + e.getMessage());} } } 10. Case Study: Java RMI 2/6/2017 47© Copyright Material
  48. 48. Server Program import java.rmi.*; import java.rmi.server.*; import java.util.Vector; public class ShapeListClient{ public static void main(String args[]){ System.setSecurityManager(new RMISecurityManager()); ShapeList aShapeList = null; try{ aShapeList = (ShapeList) Naming.lookup("//bruno.ShapeList"); Vector sList = aShapeList.allShapes(); } catch(RemoteException e) {System.out.println(e.getMessage()); }catch(Exception e) {System.out.println("Client: " + e.getMessage());} } } 10. Case Study: Java RMI 2/6/2017 48© Copyright Material
  49. 49. Naming class of Java RMIregistry void rebind (String name, Remote obj) This method is used by a server to register the identifier of a remote object by name void bind (String name, Remote obj) This method can alternatively be used by a server to register a remote object by name, but if the name is already bound to a remote object reference an exception is thrown. void unbind (String name, Remote obj) This method removes a binding. Remote lookup(String name) This method is used by clients to look up a remote object by name. A remote object reference is returned. String [] list() This method returns an array of Strings containing the names bound in the registry. 10. Case Study: Java RMI 2/6/2017 49© Copyright Material
  50. 50. • Learned the concepts of object model in a distributed space • Applied the Distributed object model to create communication paradigm • Used Java RMI to program applications with distributed objects • Learned RPC and event-based programming model as the evolution for Distributed programming approaches • Learn about how to release resources in distributed programming • Practiced the case study for distributed communication through RPC SUMMARY 2/6/2017 50© Copyright Material
  51. 51. 1. Which of the following is not a programming model in a Distributed System a. RPC b. RMI c. XDR d. Event based Programming 2. _______ are designed to allow procedures implemented in different languages to invoke one another a. IDL b. XDR c. Marshalling d. Remote Objects 3. In any object model, objects are accessed by object references a. Interfaces b. References c. Actions d. Events 4. _______acts as a common reference across all the objects implementing it a. Sockets b. References c. Objects d. Interfaces 5. The process of releasing memory allocated to the objects, when they have no active references a. Garbage Collection b. Deallocation c. Unmarshalling d. Deserialization 6. RMI architecture has the following components a. Communication module, Remote Reference Module, Servant, RMI Software QUIZ 2/6/2017 51© Copyright Material
  52. 52. 6. RMI architecture has the following components a. Communication module, Remote Reference Module, Client Stub, RMI Software b. Communication module, Remote Reference Module, Servant, RMI Software c. Communication module, Server Stub, Servant, RMI Software d. Server Stub, Remote Reference Module, Servant, RMI Software 7. Spot the correct steps in the implementation of RMI 1. Server communication module at server receives request 2. Dispatcher calls requested method in skeleton 3. Skeleton unmarshalls parameters & updates remote reference module 4. Server communication module forwards request to dispatcher for the requested class a. 4-1-2-3 b. 1-2-3-4 c. 1-4-2-3 d. 2-1-3-4 QUIZ 2/6/2017 52© Copyright Material
  53. 53. 8. When does Distributed garbage collector , performs its functionality a. When a proxy is created for a remote object b. When the local host's garbage collector removes the proxy c. When the servers garbage collector removes the proxy d. When no entries for object B in server 9. Which of these in RPC is similar to a proxy in RMI a. Stub b. Communication Module c. Skeleton d. Dispatcher 10. XDR was later extended to as a. TCP/UDP b. RPC c. RMI d. IDL 11. The method used from Java RMIregistry class responsible for registering the identifier of a remote object by name is a. void rebind (String name, Remote obj) b. void bind (String name, Remote obj) c. void unbind (String name, Remote obj) d. Remote lookup(String name) QUIZ 2/6/2017 53© Copyright Material
  54. 54. 1. C 2. A 3. B 4. D 5. A 6. B 7. C 8. D 9. A 10.D 11.A KEY 2/6/2017 54© Copyright Material
  55. 55. Middleware: This layer uses protocols based on messages between processes to provide its higher level abstractions such as remote invocations & events. Location Transparency: Process of creating a uniform file name space which allows files to be relocated without changing their pathnames. A location transparent name contains no information about the named object’s physical location. Object Model: An object-oriented program consists of a collection of interacting objects consisting of a set of data and a set of methods Object Reference: is a first class value, meaning that they may, be assigned to variables, passed as arguments and returned as results of the methods Interface: defines the signatures of a set of methods, including arguments, argument types, return values and exceptions Garbage Collection: Process of releasing memory allocated to the objects, when they have no active references. Glossary 2/6/2017 55© Copyright Material
  56. 56. Remote Object Reference: It is a reference for invoking the methods of a remote object to which they have access to Remote Interface: An Interface that specifies which of its methods can be invoked remotely for every remote object Timeout Exception: the process containing the remote object may have crashed or may be too busy to reply, or the invocation or result message may be lost. Marshalling: is a process of assembling a collection of data items in a form suitable for transmission Unmarshalling: is a process of disassembling and recovery of original data items. Remote Reference Module: is responsible for translating between local and remote object references and for creating remote object references Binder: is a separate service to locate service/object by name through table mapping for names and remote object references Glossary 2/6/2017 56© Copyright Material
  57. 57. Activator: Processes that server processes to host remote objects Persistent Object: An object that is guaranteed to live between activations of processes Event Generator: It is an object that allows other objects to subscribe to its events & generates notifications Remote Event Listener: It is an Object that receives notifications Remote Events: It is an object that is passed by value to remote event listeners. It is equivalent to what is called as a notification Third-party Agents:: These maybe interposed between an object and a subscriber Interface Definition Language: are designed to allow procedures implemented in different languages to invoke one another Glossary 2/6/2017 57© Copyright Material

×