SPL/2010 SPL/2010 Distributed Objects 1
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
Related Documents
