1 / 49

Distributed Computing

Distributed Computing. Chapter 05: Distributed Objects and Remote Invocation. Objectives of the lecture. Essence of distributed commuting To study communication between distributed objects and the integration of remote method invocation into a programming language.

loe
Télécharger la présentation

Distributed Computing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Distributed Computing Chapter 05: Distributed Objects and Remote Invocation

  2. Objectives of the lecture • Essence of distributed commuting • To study communication between distributed objects and the integration of remote method invocation into a programming language. • To be able to use Java RMI to program applications with distributed objects and how to use some aspects of reflection • To study the extension of the event-based programming model to apply to distributed event-based programs.

  3. Revision • Two alternative building blocks • Datagram Socket: based on UDP, efficient but suffer from failures • Stream Socket: based on TCP, reliable but expensive • Marshalling • CORBA’s CDR and Java serialization • Request-Reply protocol • Base on UDP or TCP • Group communication • IP multicast is a simple multicast protocol

  4. Chapter 5: Distributed objects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary

  5. Middleware • Layers of Middleware • Provide a programming model • Provide transparency • Location • Communication protocols • Computer hardware • Operating systems • Programming languages

  6. Middleware layers Applications RMI, RPC and events Middleware Request reply protocol layers External data representation Operating System

  7. Distributed programming model • Remote procedure call (RPC) • Birrel and Nelson (1984) • call procedure in separate process • Remote method invocation (RMI) • extension of local method invocation in OO model • invoke the methods of an object of another process • Event-based model • Register interested events of other objects • Receive notification of the events at other objects

  8. Conventional Procedure Call • Parameter passing in a local procedure call: the stack before the call to read • The stack while the called procedure is active

  9. Client and Server Stubs • Principle of RPC between a client and server program.

  10. Steps of a Remote Procedure Call • Client procedure calls client stub in normal way • Client stub builds message, calls local OS • Client's OS sends message to remote OS • Remote OS gives message to server stub • Server stub unpacks parameters, calls server • Server does work, returns result to the stub • Server stub packs it in message, calls local OS • Server's OS sends message to client's OS • Client's OS gives message to client stub • Stub unpacks result, returns to client

  11. Passing Value Parameters (1) • Steps involved in doing remote computation through RPC 2-8

  12. Passing Value Parameters (2) • Original message on the Pentium • The message after receipt on the SPARC • The message after being inverted. The little numbers in boxes indicate the address of each byte

  13. Interfaces • Interface • Specifies accessible procedures and variables • Inner alteration won’t affect the user of the interface • Interface in distributed system • Can’t access variables directly • Input argument and output argument • Pointers can’t be passed as arguments or returned results

  14. Interface cases • RPC’s Service interface • specification of theproceduresof the server • input and outputarguments of each procedure • RMI’s Remote interface • Specification of themethodsof an object that are available for objects in other processes • may passobjectsorremote object referencesas arguments or returned result • Interface definition languages • program language, e.g. Java RMI • Interface definition language (IDL), e.g. CORBA IDL, DCE IDL and DCOM IDL

  15. CORBA IDL example // In file Person.idl struct Person { string name; string place; long year; } ; interface PersonList { readonly attribute string listname; void addPerson(in Person p) ; void getPerson(in string name, out Person p); long number(); };

  16. Chapter 5: Distributed objects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary

  17. Discuss RMI under following headings • The object model • Distributed objects • The distributed object model • Design issues • semantics of remote invocations • Implementation • RMI above the request-reply protocol • Distributed garbage collections

  18. The object model • Object references • Objects can be accessed via object references • First-class values • Interfaces • A definition of the signatures of a set of methods • No constructers • A class can implement several interfaces, e.g. Java • Actions • Initiated by an object invoking a method in another object • Two affects • Change the state of the receiver • Further invocations on methods in other objects

  19. The object model • Exceptions mechanism • A clean way to deal with error conditions • Listexceptions at the method head • throwuser know exceptions • Catchexceptions • Garbage collection • Freeing the space occupied by cancelled objects • C++: collected by programmers • Java: collected by JVM

  20. Distributed objects • Natural extension • physical distribution of objects into different processes or computers in a distributed system • Benefits of distributed objects • Enforce encapsulation • can’t access variables directly • Support heterogeneous systems • Assume other architectural models then client/server • Replicated objects • Migrated objects

  21. local C remote E local invocation invocation remote invocation invocation F B local A invocation D Remote and local method invocations

  22. The distributed objects model • Remote object reference • Aunique identifierin a distributed system • May be passed asargumentsandresultsof remote method invocation • Remote interface • remote object class implementsthe methods of its remote interface • Actions in a distributed systems • may incur a chain of invocations on different computers • Garbage collection • Usually based on reference counting • Exception • notify the client and the client handle exceptions

  23. A remote object and its remote interface remote object Data remote interface m4 { m1 implementation m5 m2 m6 of methods m3

  24. Invocation Fault tolerance measures semantics Retransmit request Duplicate Re-execute procedure message filtering or retransmit reply No Not applicable Not applicable Maybe Yes No Re-execute procedure At-least-once Yes Yes Retransmit reply At-most-once Design Issues – Invocation semantics • Choices for different delivery guarantees • retry request message • duplicate filtering • retransmission of results • Three different semantics

  25. Different invocation semantics • Maybe • For invoker: executedonce, ornot at all ??? • Suffer from: (1) messagelost;(2) servercrash • Useful for app. in which occasional failed invocation are acceptable • At least once • For invoker: executeat least once, or anexception • Suffer from: (1) server crash; (2)arbitraryfailures for non-idempotent method • At most once • For invoker: receives result, or anexception • Prevent: omission failures by retrying, arbitrary failures

  26. Design Issues - Transparency • What can be made transparent • marshaling • message passing • object locating and contacting • What can’t be made transparent • vulnerable to failure • latency • Current consensus(Jim Waldo research paper) • Syntax of remote invocation should be same as of local invocation • Difference in remote and local objects should be expressed in their interfaces

  27. Implementation of RMI • The inner scene of RMI • Communication module • Request/reply between client and server • As discussed in chapter 4, figure 4.13 • Communication module at Server side Select dispatcher at server • Remote reference module • Translate between local and remote object reference • Create remote object reference • Remote object table • entries for remote objects held by the process • entries for local proxies • Actions of RRM • When a remote object is to be passed as argument or result for the first time the remote reference module is asked to create a remoteobject reference, which it adds to its table • When a remote object reference arrives in a request or reply message, the remote reference module is asked for the corresponding localobject reference, which may either refer to proxy or remote object

  28. messageType int (0=Request, 1= Reply) requestId int objectReference RemoteObjectRef methodId int or Method arguments array of bytes Request-reply message structure (fig 4.13)

  29. server client remote skeleton object A proxy for B object B & dispatcher Request for B’s class Reply Remote reference Communication Communication Remote module reference module module module The role of proxy and skeleton in remote method invocation

  30. Implementation of RMI – RMI software • Proxy • forwardinvocation to remote object • one remote object one proxy • implement the method in the remote interface • It marshals a reference to the target object , its own methodId and its arguments into request message and send it to the target, awaits the reply and message, unmarshals it and returns the results to invoker • Skeleton • implement the method in the remote interface • unmarshalthe arguments in the request • invokethe corresponding method in the remote object • waitfor the invocation complete • marshalthe result in the reply message • Dispatcher • Receive the request from communication module and select appropriate method in the skeleton • one dispatcher and skeleton for one remote object

  31. Implementation of RMI - execution • The classes for proxies, dispatchers and skeletons • generated automatically by an interface compiler, e.g. rmic • Server program • create and initialize at least one of the remote objects • register • Client program • look up the remote object references • Invoke • Factory methods • Remote object interface cannot have constructors • Remote objects are either created in initialization section or in remote methods designed for that purpose, called factory methods

  32. Implementation of RMI - Object state • The binder • A service that maintains mapping information of textual names to remote object references • Activation of remote objects • to avoid resource waste, the servers can be started whenever they are needed- FTP service • Activators: process that start server processes to host remote objects. • a remote object could beactive or passive • Passive object: consist of two parts • Implementation of its methods • Its state in marshaled form • Activation: Making a new object from corresponding passive object by creating a new instance of its class and initializing its variables from the stored state • Java RMI uses one activator on each server computer , which is responsible for activating objects on that computer.

  33. Implementation of RMI - Object state (cont..) • Persistent object stores • Persistent object • an object that is guaranteed to live between activations of processes • Persistent Object Store • Manage and store the state of persistent objects • different passivate strategies • at the end of a transaction • when the program exit • E.g., Persistent Java, PerDiS

  34. Distributed garbage collection • The aim of a distributed garbage collector • Retainthe object (local&remote) when it is still be referenced • Collect the object when none holds reference to it • Java distributed garbage collection algorithm • based onreference counting • Whenever a remote object enters a process, a proxy is created and will stay there for as long as needed. The process where the actual object lives (server) should be informed, then later when there is no longer a proxy at the client, server should be informed • Distributed Garbage collection works in corporation with local garbage collectors • server maintainprocesses setthat hold remote object references to it for each of its remote objects • clientnotifyserver to modify the process set • when the process set becomesempty, server local garbage collectorreclaimsthe space

  35. Distributed garbage collection (cont..) • Leases in Jini • lease: the granting of the use of a resource for aperiod of time • avoid to discoverwhether the resource users are still interested or their programs have not exited

  36. Chapter 5: Distributed objects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary

  37. client process server process Request Reply client stub server stub procedure procedure service client Communication Communication program procedure dispatcher module module RPC is very similar to RMI • Service interface: the procedures that are available for remote calling • Invocation semantics choice: at-least-onceorat-most-once • Generally implemented overrequest-replyprotocol • Building blocks • Communication module • Client stub procedure(as proxy in RMI): marshalling, sending, unmarshalling • Dispatcher: select one of the server stub procedures • Server stub procedure(as skeleton in RMI): unmarshalling, calling, marshalling

  38. Chapter 5: Distributed objects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary

  39. Event-notification model • Idea • one object react to a change occurring in another object • Event examples • modification of a document • A new doc added in an electronically tagged book • Publish/subscribe paradigm • event generator publish the type of events • event receiver subscribe to the types of events that are interest to them • When event occur, notify the receiver • Distributed event-based system – two characteristics • Heterogeneous • asynchronous

  40. Example - dealing room system • Requirements • allow dealers to see thelatest market price information • System components • Information provider • receivenew trading information • publish stocks prices event • stock price updatenotification • Dealer process • subscribe stocks prices event • System architecture

  41. External Dealer’s computer Dealer’s computer source Dealer Notification Notification Dealer Information Notification Notification provider Notification Notification Notification Dealer’s computer Dealer’s computer Notification Information provider Notification Notification Dealer Dealer External source Dealing room system

  42. Event service subscriber object of interest 1. notification object of interest observer subscriber 2. notification notification object of interest observer subscriber 3. notification Architecture for distributed event notification • Event service:maintain a database of published events and of subscribers’ interests • decouple the publishers from the subscribers

  43. The roles of the participating objects • The object of interest • its changes of state might be of interest to other objects • Event • the completion of a method execution • Notification • an object that contains information about an event • Subscriber • an object that has subscribed to some type of events in another object • Observer objects • the main purpose is to decouple an object of interest from its subscribers • Publisher • an object that declares that it will generate notifications of particular types of event

  44. Notification delivery • Delivery semantics • Unreliable • Reliable • real-time • Roles for observers • Forwarding • send notifications to subscribers on behalf of one or more objects of interests • Filtering of notifications • Patterns of events • Notification mailboxes • notification be delayed until subscriber being ready to receive

  45. Jini distributed event specification • EventGenerator interface • Provide register method • Event generatorimplement it • Subscriber invoke it tosubscribeto the interested events • RemoteEventListener interface • Providenotifymethod • subscriberimplement it • receivenotifications when the notify method is invoked • RemoteEvent • a notification that is passed as argument to the notify method • Third-party agents • interpose between an object of interest and a subscriber • equivalent of observer

  46. Chapter 5: Distributed objects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • RPC Case Study • Java RMI case study • Summary

  47. Chapter 5: Distributed objects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary

  48. Chapter 5: Distributed objects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary

  49. Summary • Two paradigms for distributed programming • RMI(RPC)/Event notification: sync./async. • RMI • Distributed object model • Remote interface, remote exception, naming service • Remote invocation semantics • Once, at-least-once, at-most-once • Sun RPC • Event-notification • Publish/subscribe • Event service • Example: dealing room

More Related