Distributed Objects - Computer Scienceasharf/SPL/Distributed.pdf · distributed objects ......

66
SPL/2010 SPL/2010 Distributed Objects 1

Transcript of Distributed Objects - Computer Scienceasharf/SPL/Distributed.pdf · distributed objects ......

SPL/2010

SPL/2010

Distributed Objects

1

SPL/2010

SPL/2010

distributed objects

● objects which reside on different machines/ network

● architectures, benefits, drawbacks

● implementation of a remote object system

2

SPL/2010

SPL/2010

Why go distributed?

● large systems - avoid bottlenecks and single points of failure

● partition system into autonomic subsystems, self-contained

● Subsystem may be on different host, communicate by networking protocols

3

SPL/2010

SPL/2010

active object model

● objects reside on different RTE's

● send messages to one to another

● how objects communicate?

● remote method invocation: OO concept

● objects in different environments communicate=send messages

4

SPL/2010

SPL/2010

5

SPL/2010

SPL/2010

Distributed object applications do the following

● Locate remote objects - obtain references to remote objects.

● register remote objects with RMI's naming facility, the RMI registry.

● pass and return remote object references as part of remote invocations.

6

SPL/2010

SPL/2010

Distributed object applications do the following

● Communicate with remote objects. communication between remote objects handled by RMI. To programmer, looks similar to Java method invocations.

7

SPL/2010

SPL/2010

Distributed object applications do the following

● Load class definitions for objects that are passed around. mechanisms for loading object's class definitions and transmitting an object's data.

8

SPL/2010

SPL/2010

9

SPL/2010

SPL/2010

● server calls the registry to associate (or bind) a name with a remote object.

● client looks up the remote object by its name in the server's registry and then invokes a method on it.

● RMI system uses an existing web server to load class definitions, from server to client and from client to server

10

SPL/2010

SPL/2010

RMI Architecture in Java

● framework for remote method invocation

● abstract subsystem A providing a service = interface

● interface used by subsystem, B, in a different JVM - invoke methods of A.

11

SPL/2010

SPL/2010

● object becomes remote by implementing a remote interface,

● extends interface java.rmi.Remote.

● each method declares java.rmi.RemoteException in throws clause,

12

SPL/2010

SPL/2010

Stub

● No copy of the implementation object in client Java virtual machine

● RMI passes a remote stub for a remote object.

● acts as local representative (proxy) for remote object - remote reference to client

● client invokes a method on local stub - method invocation on the remote object.

13

SPL/2010

SPL/2010

14

SPL/2010

SPL/2010

example

● class, representing a printing service.

● support printing lines of text sent

● other objects reside on different JVMs, on different hosts

15

SPL/2010

SPL/2010

interface of the service

16

SPL/2010

SPL/2010

remote interface supports remote method invocations

17

SPL/2010

SPL/2010

communication throws section

18

SPL/2010

SPL/2010

Service Implementation

● implementing the remote interface

● how class communicates remotely

19

SPL/2010

SPL/2010

Make the Service Available

● instantiate Object of class

● wait for messages from other RTE:

1. Instantiate LinePrinterImpl Object, L.

2. Make L available for remote invocations

3. Wait for remote invocations, and call the appropriate methods of L.

20

SPL/2010

SPL/2010

21

SPL/2010

SPL/2010

● need to locate where on which host and JVM - printer object is located.

● process does not exit when the main function completes

● naming.rebind(name, object) - executor is created - waits for messages and executes

22

SPL/2010

SPL/2010

Naming Server

● keeps a mapping from abstract names, (strings) and their location

● class Naming - bind object to name and register with some name server.

● Naming.rebind("//names.cs.bgu.ac.il:2002/ALinePrinter", printer);

23

SPL/2010

SPL/2010

Naming Server

● rebind arguments:

1. URL - where to advertise the remote object and under what name

2. remote object (printer)

● URL: server + port + advertised object name:

● Host: names.cs.bgu.ac.il

● Port: 2002

● Bind remote object to name: ALinePrinter.

24

SPL/2010

SPL/2010

Naming Server

● Anyone contacting the same name server and looking for ALineServer will be referred to the correct host.

● Ports – contact a specific process on a host - host's name + port number

● name server implemented in Java

25

SPL/2010

SPL/2010

Naming Server

● invoke on command line prior to running PrintServer

● start the following command on the host (names.cs.bgu.ac.il):

● rmiregistry 2002 - started a naming server (rmiregistry) on port 2002

26

SPL/2010

SPL/2010

Skeleton

● Remote Object is now registered at the naming server.

● What happens when someone tries to contact remote Object?

● No code to handle remote invocations. just implemented LinePrinter interface

27

SPL/2010

SPL/2010

● Java compiler creates a new class, the skeleton of our remote Object

● contains code for handling the communications aspects

28

SPL/2010

SPL/2010

Skeleton

● communication details:

● receiving requests for remote invocations

● calling methods of remote Object

● sending the replies

● Skeleton - special code

● generated automatically from java.rmi.server.UnicastRemoteObject

● implement interface inherited from java.rmi.Remote

29

SPL/2010

SPL/2010

Skeleton code

30

SPL/2010

SPL/2010

● Upon call Naming.rebind(uri, printer) :

● Create an instance of class LinePrinterSkel - skel.

1. Set skel.remoteObject = printer.

2. Assign local port to skel, on which skel receives incoming messages - PORT.

3. Contact naming server and register under requested name:

● the local host, on which our printer resides,

● PORT on which skeleton waits for messages

31

SPL/2010

SPL/2010

32

SPL/2010

SPL/2010

Writing a Client

33

SPL/2010

SPL/2010

Client side needs to know

● Interface implemented by remote Object.

● Naming server where remote Object is registered.

● Name under which the remote object is registered.

34

SPL/2010

SPL/2010

Client side ● asks for object, (representing remote

object) registered as ALinePrinter.

● if no such object registered in name server, -java.rmi.NotBoundException exception

● Naming.lookup returns object=stub - contacts remote object bound to "ALinePrinter",

● stub implements same interface as remote Object - LinePrinter interface!

● client invokes method print transparently

35

SPL/2010

SPL/2010

36

SPL/2010

SPL/2010

The Stub

● when we compiled LinePrinter interface, Java compiler created the stub for us

37

SPL/2010

SPL/2010

● When we called Naming.lookup(uri), the following took place:

● naming server (uri) contacted and asked for the remote object (uri).

● naming server returns the address and port of the relevant skeleton.

● LinePrinterStub instantiated, with given address/port returned to the caller.

38

SPL/2010

SPL/2010

● should the client need to hold, a priory, a copy of the LinePrinterStub class's code?

39

SPL/2010

SPL/2010

System Overview

40

SPL/2010

SPL/2010

Parameter Passing

● how arguments are passed to remote methods

● how return values are actually returned.

41

SPL/2010

SPL/2010

Serializable objects

● argument to, or return value from, a remote object

● primitive types

● remote objects

● non-remote objects that implement java.io.Serializable interface.

42

SPL/2010

SPL/2010

Serialization

● process of converting an object into a format that can be stored

● saving an object onto file, memory

● transmit object across network

● serialization format: re-create an identical object in internal state to original object (clone).

43

SPL/2010

SPL/2010

● Serialization: process of serializing an object is called deflating or marshaling an object

● Deserialization: opposite operation, extracting a data structure from a series of bytes, is (which is also called inflatingor unmarshalling).

44

SPL/2010

SPL/2010

● reasons why objects are not serializable by default:

● Not all objects can be serialized

● example, a Thread object is tied to the state of the current JVM.

● Serialization allows access to non-transient private members of a class

45

SPL/2010

SPL/2010

Primitive Parameters

● passed/returned by value.

● RMI send parameter copy to remote method.

● return value's data is copied, and sent to the calling JVM.

46

SPL/2010

SPL/2010

Object Parameters ● passed object to remote method - RMI

sends the object itself

● object passed by value

● RMI returns copy of the whole object to the calling program.

● Nontrivial: object refer to other Java objects in a complex graph-like structure

● different JVMs dont share heap memory

47

SPL/2010

SPL/2010

● RMI must send the referenced object and all objects it references.

● Serialization: transform object into a linear format to sent over network

● flattens an object and any objects it references.

● Serialized objects can be de-serialized in remote JVM

48

SPL/2010

SPL/2010

Remote Object Parameters

● Passing objects by value has its own inefficiencies.

● referenced graph of objects is very large?

● large state to send across the network?

● network lag (delay)

● RMI can simulate a pass-by-reference

● arguments are not. remote method works with the original object.

49

SPL/2010

SPL/2010

● receive a reference to a remote object,

● invoking Naming.lookup()

● remote object as a parameter or a return value

50

SPL/2010

SPL/2010

● LinePrinter object is a return value of a remote method invocation.

● printer factory

51

SPL/2010

SPL/2010

52

SPL/2010

SPL/2010

53

SPL/2010

SPL/2010

what exactly is passed as a parameter when passing a remote object by reference?

● remote object's stub object.

● Stubs = network-aware references to remote objects;

● remote reference to a remote object

● java.rmi.RemoteStub objects are the manifestation of those remote references

54

SPL/2010

SPL/2010

● all parameters in Java RMI are passed by value

● pass-by-remote-reference is only implemented for remote object which extends the UnicastRemoteObject class

55

SPL/2010

SPL/2010

● a remote object reference is returned back to the server

● parameter of a method invocation.

● In this case, would the server work with the stub or the local implementation?

56

SPL/2010

SPL/2010

● If an object implements a RemoteInterface but is not exported (does not extend UnicastRemoteObject),

● object will always be passed by value.

● it is possible to obtain a stub for that remote object via a call to the method java.rmi.server.RemoteObject.toStub

57

SPL/2010

SPL/2010

DVD example for parameter passing in RMI

● A DVD support the method fix which fixes it.

● simple DVD (Serializable) can be sent (copied) over the network

● DVD that supports remote fixing (a UnicastRemoteObject)

● only a reference (a stub) sent on the network, not the physical device (copied)

58

SPL/2010

SPL/2010

● DVDRemoteFixer will act as server that can fix a simple DVD or a RemoteDVD.

● fix client will create instance of both kinds of DVDs and will send them to the DVDRemoteFixer twice each.

● for simple DVD - state is not saved (dvd doesnt know its fixed the second time)

● for RemoteDVD state is saved.

59

SPL/2010

SPL/2010

60

SPL/2010

SPL/2010

61

SPL/2010

SPL/2010

62

SPL/2010

SPL/2010

63

SPL/2010

SPL/2010

64

SPL/2010

SPL/2010

Summary of parameter passing in RMI

● primitive data types are passed by value.

● changes to data on remote host are not reflected at original host.

● to pass an object to a remote method by value, the object must implement the java.lang.Serializable interface.

– changes to the object's copy will not propagate to the local object.

65

SPL/2010

SPL/2010

● pass an object over the network by remote reference:

– must be an exported remote object (extend the UnicastRemoteObject),

– must implement a remote interface (which extends java.rmi.Remote).

– stub for remote object will be serialized and passed to the remote host.

– remote host can use stub to invoke methods of our remote object.

– only one copy of the data at any time, which means that all hosts are updating the same data.

66