Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27CS 425/ECE 428/CSE 424Distributed Systems(Fall 2009)CS 425/ECE 428/CSE 424Distributed Systems(Fall 2009)Lecture 18Distributed Objects (II)Sections 4.3-4.4, Chapter 5.1-5.4[Indy Gupta]AcknowledgementAcknowledgement•The slides during this semester are based on ideas and material from the following sources: –Slides prepared by Professors M. Harandi, J. Hou, I. Gupta, N. Vaidya, Y-Ch. Hu, S. Mitra. –Slides from Professor S. Ghosh’s course at University of Iowa.Administrative Administrative •ECE students (and CS) students – if you were refused an Android earlier by Paula Welch, please ask her again (the confusion has been cleared up)Administrative Administrative •MP2 posted October 5, 2009, on the course website, –Deadline November 6 (Friday)–Demonstrations , 4-6pm, 11/6/2009 –You will need to lease one Android/Google Developers Phone per person from the CS department (see lease instructions on the web site)!!–Tutorial for MP2 planned for October 28 evening if students send questions to TA by October 25. Send requests what you would like to hear in the tutorial. –During October 15-25, Thadpong Pongthawornkamol ([email protected]) will held office hours and respond to MP2 questions for Ying Huang (Ying is going to the IEEE MASS 2009 conference in China)Administrative Administrative •MP3 proposal instructions –You will need to submit a proposal for MP3 on top of your MP2 before you start MP3 on November 9, 2009–Deadline for MP3 proposal: October 25, 2009, email proposal to TA–At least one representative of each group meets with instructor or TA during October 26-28 during their office hours ) watch for extended office hours during these days.6Plan for TodayPlan for Today•Remote Method Invocation (RMI)•Remote procedure call (RPC)•Publish/Subscribe Paradigm•Distributed Event–based Systems7Proxy and Skeleton in Remote Method InvocationProxy and Skeleton in Remote Method Invocationobject Aobject BskeletonRequestproxy for BReplyCommunicationRemote Remote referenceCommunication module modulereference module modulefor B’s class& dispatcherremoteclient serverProcess P1Process P2Architecture attempts to ensure transparency when possibleRemote Method Invocation (RMI) Remote Method Invocation (RMI) Object AObject BComm. ModuleComm. ModuleSkeletonfor B’s ClassServer ProcessClient ProcessProxyObjectB Remote Reference ModuleDispatcherProxy object is a hollow container of Method names.Remote Reference Module translates between local and remote object references.Dispatcher sends the request to Skeleton ObjectSkeleton unmarshals parameters, sends it to the object, & marshals the results for returnRemote Reference ModuleMIDDLEWAREGeneration of Proxies, Dispatchers and SkeletonsGeneration of Proxies, Dispatchers and Skeletons•In CORBA, programmer specifies interfaces of remote objects in CORBA IDL•Then, from this IDL, the interface compiler automatically generates code for proxies, dispatchers and skeletons.•For instance, in Java RMI–The programmer defines the set of methods offered by a remote object as a Java interface implemented in the remote object.–The Java RMI compiler generates the proxy, dispatcher and skeleton classes from the class of the remote object.10Main components of CORBA architectureMain components of CORBA architectureclient server proxyor dynamic invocationimplementation repositoryobjectadapterORBORB skeletonor dynamic skeletonclient programinterface repositoryRequestReplycorecore for AServant ABinder and ActivatorBinder and Activator•Binder: A separate service that maintains a table containing mappings from textual names to remote object references. (sort of like DNS, but for the specific middleware)–Used by servers to register their remote objects by name. Used by clients to look them up. E.g., Java RMI Registry, CORBA Naming Svc.•Activation of remote objects–A remote object is active when it is available for invocation within a running process.–A passive object consists of (i) implementation of its methods; and (ii) its state in the marshalled form (a form in which it is shippable).–Activation creates a new instance of the class of a passive object and initializes its instance variables. It is initiated in an on-demand manner.–An activator is responsible for»Registering passive objects, e.g., with the binder (recording the names of the servers against the names of the passive objects)»Starting named server processes and activating remote objects in them.»Keeping track of the locations of the servers for remote objects it has already activated–E.g., Activator=Inetd, Passive Object/service=FTP (invoked on demand)Etc.Etc.•Persistent Object = an object that survives between simultaneous invocation of a process. E.g., Persistent Java, PerDIS, Khazana.•If objects are persistent or migrate, may not be a good idea to have remote object reference=IP+port–Location service= maps a remote object reference to its current location –Allows the object to migrate from host to host, without changing remote object reference–Example: Akamai is a location service for web objects. It “migrates” web objects using the DNS location serviceRemote Procedure Call (RPC) Remote Procedure Call (RPC)  Uniform, reusable, user-friendly, and action based. Provide a familiar interface for the application developer Implements the request-reply primitive Format of the message is standard Supports code reuse Client process calls for invocation of a procedure at the server process. Semantics are similar to RMIs – at least once, at most once, maybe Standard interface, independent of applications A library of reusable procedures, distributed over all sites.Client and Server Stub Procedures in RPCClient and Server Stub Procedures in RPCclient procedureRequestReplyCommunicationCommunication module moduledispatcherservice client stub server stubprocedureprocedureclient process server process procedureStubs Stubs  Stubs are generated automatically from interface specifications. Stubs hide details of (un)marshalling from application programmer & library code developer. Client Stubs perform marshalling into request messages and unmarshalling from reply messages Server Stubs