Upload
aqua
View
22
Download
3
Embed Size (px)
DESCRIPTION
Remote Objects. From notes originally prepared by Gareth Lee Department of Electrical and Electronic Engineering, University of Western Australia. Overview. First - look at remote loading of software components Then - adapt the example to use RMI Finally - the RemoteWorker system - PowerPoint PPT Presentation
Citation preview
Remote Objects
From notes originally prepared by
Gareth LeeDepartment of Electrical and Electronic Engineering,
University of Western Australia
Overview
• First - look at remote loading of software components
• Then - adapt the example to use RMI
• Finally - the RemoteWorker system• Using a network of PEs for solving problems
• Distributes a task from a master to a set of workers (slaves)
• Programmers write a Solver class• Actually solves the problem (or sub-problem)
• System handles distribution of these classes
• Slaves can be started on remote machines and left running
Network becomes a powerful computing resource!
Example Application - Image viewer
• Requirements• Able to display a wide range of image formats
• Imaging a picture library• Extensible
• Support new image formats without redistributing the entire application
• New image decoders prepared by the IT department (or external suppliers)
• Allow bug fixes to the existing code without updating every desk machine
Software components
• Allows designers to build applications from substitutable (reusable) components
• Components can be loaded as they are needed, not when the application is started• Minimizes memory footprint at any time• Maximizes versatility of application• Makes an application extensible• Minimises development cost (by allowing
reuse)
Remote Class loading
• Remote Class Loading is a half way house• Deploy a simple shell application onto
clients’ desks• This shell loads software components on
demand from a shared server• Users never need know that this is going
on behind the scenes• Demonstrated by the picture viewer
example
Implementing components
• We need a way of abstracting Java classes• We cannot mention a component class
directly otherwise it will be loaded at the outset
• An indirect way of creating components• Components must implement agreed interface• We must be able to create a component without
hard-coding its name in the source
• Here we create a specific family of software component• Java generalizes components as JavaBeans
The ImageCreator interface
• We need to create a family of software components that know how to decode various image file formats
• ImageCreator is the standard interface for accessing components. . .
• . . . so each of the components must implement the interface
The ImageCreator interface/** This provides an interface for components which are able to create image objects from files.
@author Gareth Lee @version 0.1, March 11th, 2000.*/public interface ImageCreator { /** Read the contents of the specified source file and create an Image object containing the file contents */ public Image createImage(File source);}
Abstracting Java classes
• Java provides us with a pool of objects of type java.lang.Class
• These abstract the data types that Java supports• Class types as found in the standard libraries
(API classes)• User defined classes
• Software components written by users• Built in primitive types
•int, boolean, etc
Remote Class Loading
? Deploy applications using applets• Overcomes distributions costs for bug
fixes and upgrades• Downside:
• Most browsers don’t trust applets and impose severe restrictions
• Severe UI restrictions when running applets• Difficult to deploy groups of applets which are
able to cooperate (for example a word processor and a spell checker)
java.lang.Class
• Allows types (classes) to be accessed by name• Strings giving the fully qualified name• Class name must be prefixed by the package in
which it is loaded• eg java.lang.Integer
• Objects may be created (instantiated) from the instances of the Class• Zero argument construction is trivial• Constructors with arguments a little trickier
• java.lang.Class API • Has methods which allow properties of the
class type to be obtained• Constructors, fields, methods, etc
java.lang.Class
• Constructing (loading) a class• Class forName(String qualifiedName)
eg• Class c = Class.forName( “RemoteWorker” );
• Reflection API methods• Object newInstance() // construct obj• Constructor[] getConstructors()• Method[] getMethods()• Field[] getFields()• Class[] getInterfaces()
. . but this is local loading
• When we call Class.forName(String) we use the default class loader• The JVM uses objects of type java.lang.ClassLoader to load classes dynamically
• The default loader uses the standard class path• Specified by
• Environment variable CLASSPATH• Command line option -classpath
Remote class loading - using HTTP
• To load classes from some remote source we must create a new class loader that can load remotely
• java.net.URLClassLoader is able to load classes from URLs• Allows us to load classes using the HTTP
protocol from any web server
java.net.URLClassLoader
• Constructor• URLClassLoader(URL[] classPath)
• Useful methods:• Class findClass(String qualifiedName)
• Does the same job as Class.forName()• URL[] getURLs()
• … and a few others
java.net.URL
• Abstracts a universal resource locator• Constructor
• URL(String urlName)
eg new URL(“http://asp/index.html”)
• Methods to take the URL apart, such as• String getHost()• int getPort()• String getPath()
Different ImageCreators
• Assume we have different ImageCreator objects available on some remote system
• ImageCreator_GIF• Decodes GIF image formats
• ImageCreator_JPG• Decodes JPEG format images
• ImageCreator_BMP• Decodes (256 colour) MS-Windows Device
Independent Bitmap files• We want to be able to download and use the
appropriate one on demand
Loading Viewer classespublic ImageCreator loadImageCreator(String type) { try { // Get a URL as a text string from ... String urlTextString = sourceURLText.getText(); // Form an array of URLs URL[] sourceURLs = new URL[] { new URL(urlTextString) }; // Construct the class loader URLClassLoader loader = new URLClassLoader(sourceURLs); // Load the class Class componentType = loader.loadClass( "ImageCreator_" + type); // Make an object of the class return (ImageCreator) componentType.newInstance(); } catch (Exception e) { e.printStackTrace(); }}
Exceptions, exceptions!
• java.net.MalformedURLException• The (complex) format of the URL is invalid
• java.lang.ClassNotFoundException• The class could not be loaded from the remote
location• java.lang.ClassCastException
• The loaded class does not implement the interface that we require
Remote loading alternative ...
• Remote Procedure Calls• Idea has been around for at least 20 years
since Sun introduced RPC to SunOS• RPC involves hiding a network communication
protocol so that programmers appear to simply be calling procedures
• This idea adapts very easily to OO programming as distributed objects
A Little History
• IBM lead the way with DSOM (late 80s)• Microsoft developed this into the
distributed common object model (DCOM) (ca.1995)
• Common Object Request Broker Architecture (CORBA) developed by OMG to provide platform and language independence (1991/94)
• Sun developed Remote Method Invocation (RMI) as a simpler alternative (1997)
Remote Method Invocation
• First introduced into JDK 1.1• Java specific protocol aimed at simplicity
• Java is already platform independent
• Closely linked to the idea of client/server• A server application provides some form of
service to zero or more clients• A client program uses the service• A Java interface defines the contract between
the two
The Object Registry• Server advertises its services using a service label
• A string naming the service
• It registers the label with a object registry (rmiregistry) which runs as a daemon
• Clients connect to the object registry and ask for the service they require• Identifying it with the service label• Clients must know where the object registry is located
(unlike in JINI)
• Clients obtain a reference to the desired interface and can then call its methods
Loading remote components using RMI
• As an alternative we can use RMI to allow us to load remotely
• We will look at the following parts:• The service interface
•ImageCreatorService• A server implementation class
•RMIComponentServer• A client implementation class
•RMIClientViewer
RMI versus HTTP
• HTTP is really intended for document downloads
• Using HTTP POST you can provide parameters as part of a request
• Too specific for communication between distributed objects
• RMI allows any object to• Call any method in another object (locally or
remotely)• Pass any list of parameters (not just Strings)• Receive back any Java type as the return value
The ImageCreatorService interface
public interface ImageCreatorService extends java.rmi.Remote{ /** Deliver the byte codes for an ImageCreator component which will deal with images of the specified type. */ public byte[] loadClassData(String compName) throws RemoteException;}
The component server
• Just a few simple steps to write the server:
• STEP ONE: Create a server class which implements your interface and subclasses java.rmi.server.UnicastRemoteObject
• STEP TWO: Make the server register itself with the object registry
• STEP THREE: Implement the methods cited in the service interface
The RMIComponentServer class
public class RMIComponentServer extends java.rmi.server.UnicastRemoteObject implements ImageCreatorService{ public RMIComponentServer() throws RemoteException { try { java.rmi.Naming.rebind( "rmi://localhost/ImageCreatorService", this); } catch (MalformedURLException mue) { mue.printStackTrace(); } }
. . . .
STEP ONE
STEP TWO
Service label
The RMIComponentServer class
public byte[] loadClassData(String className) throws RemoteException{ // Implementation edited out for brevity. . .}
public static void main(String[] args){ try { System.out.println("RMIComponentServer: started."); RMIComponentServer server = new RMIComponentServer(); } catch (Exception e) { e.printStackTrace(); }}
STEP THREE
The client viewer implementation• This is in the form of RMIClientViewer
but the interesting part is the inner class called RMIClassLoader
• This subclasses java.lang.ClassLoader• The parent of all classes capable loading byte
codes
• RMIClassLoader loads byte codes with RMI
• Rather than HTTP (as in the previous example)• Distributed memory space (all parameters are
passed by value, rather than by reference)
• RMI requires a different design discipline
Reliability Issues• When calling a method locally there are
only two possible outcomes:• The method succeeds• The method fails with an exception
• When calling an RMI method there is a third category:• It was impossible to call the method, since the
RMI mechanism failed in some way
How does RMI work?
• It uses proxy classes called stubs and skeletons
• RMI calls from the client are intercepted by a proxy class called a stub
• They are passed to another proxy called a skeleton residing on the server which calls the server class on the client’s behalf
• Stubs and skeletons can be generated using rmic
Proxy stubs
• Implements the chosen service interface so it looks like the remote server as far as the client is concerned
• Packages up (marshals) arguments for dispatch across the network
• Sends them using the Java Remote Method Protocol (JRMP)
• Waits for and unpacks the return value
Proxy skeletons
• Waits for JRMP request to be received from a TCP/IP connection
• Unmarshals the arguments and passes them on to server implementation
• Awaits a return value and marshals it to be returned through the TCP/IP connection
• Not needed by JDK 1.2
How it all fits together
Client VM Server VM
Client Obj
x=if.m()
Skeleton Server Impl.
TCP/IPlink
Service Interface Service Interface
Call
Retn
int m() { . . . .}
Stub
rmic
• Remote interface compiler• Specify your server implementation class
as a command line argumenteg rmic -classpath . RMIComponentServer
• Ascertains the service interfaces• Creates a stub and a skeleton class for
each interfaceeg RMIComponentServer_Stub.class RMIComponentServer_Skel.class
• Recreate stubs and skeletons when you modify the interfaces for your server
RMI Method Arguments
• What restrictions are there on RMI arguments?
• By default parameters are passed by value• NOTE: This is the opposite of the conventions
when calling a local method
• This is the normal behavior for primitive types: byte, short, char, int, long, float, double, boolean
• Objects must be pickled before being sent!• They are marked as implementing the Serializable interface
java.io.Serializable
• Contains no methods!• Just a marker for those classes which are
may be serialized • Into a file or • Sent across the net to a different VM by RMI
• Many Java classes implement java.io.Serializable
• Some notable exceptions: Runtime system and Reflection API classes and some I/O classes
Passing objects by reference
• It is possible to pass objects be reference, but only if you design them specifically for RMI
• STEP ONE: Make the object implement the java.rmi.Remote interface
• STEP TWO: Export the object by registering it using methods in java.rmi.Naming
• In other words you are turning the object into another RMI server in its own right
Inner class RMIClassLoader
• Part of the client side application which wants to load the appropriate viewer class
• STEP ONE• Create a reference to the required service
interface
• STEP TWO • Lookup the service by connecting to the
chosen object registry
• STEP THREE• Call a method through the interface
sea.picturelib.RMIClientViewer
public class RMIClassLoader extends ClassLoader{ ImageCreatorService remoteService = null; public RMIClassLoader(String serverName) throws NotBoundException, MalformedURLException, RemoteException { remoteService = (ImageCreatorService) java.rmi.Naming.lookup( "rmi://" + serverName + "/ImageCreatorService"); } . . . .
STEP ONE
STEP TWO
sea.picturelib.RMIClientViewer
public Class findClass(String name) throws ClassNotFoundException{ try { byte[] byteCodes = remoteService.loadClassData(name); return defineClass( name, byteCodes, 0, byteCodes.length); } catch (RemoteException re) { throw new ClassNotFoundException( "failed to load class " + name + " using RMI"); } }}
STEP THREE
It’s that simple. . .
• STEP ONE• Define the service interface
• STEP TWO• Write a server that implements the interface
• STEP THREE• Make the server register with an object registry
• STEP FOUR• Write a client that looks up the desired service
in the object registry
• STEP FIVE• The client can call methods in its interface
. . . not quite!
• Some general RMI issues …• RPC (RMI) can lull the designer into a false
sense of security!• Beware! They may look like method calls but
they’re really network communications• You will need a design that take into account
• Reliability issues• Latency issues
Reliability Issues
• When a remote method cannot be called it throws an exception in the java.rmi.RemoteException hierarchy
• java.rmi.ConnectionException when the network connection could not be established
• java.rmi.ConnectionIOException when the network connection failed
• . . . and there are plenty of things that can go wrong (17 other exception types)
Latency Issues
• Calling methods locally • 100% reliable and • only requires a few nanoseconds
• Not true for RMI• Network might be congested (or down)• Remote server may be busy (or down)
• RMI calls take a long time:• About 1 ms in the best scenario (one million
times as long as a local method call!)• Up to a 3 minute time-out
• DNS lookup fails
Latency Issues
• It is unwise to make RMI method calls from any time-sensitive code• User interface callback handlers• Process/hardware controllers
• Control the network environment• Make RMI calls in a separate thread• Design an interface with coarse-grained
methods to minimize round trip delays
Accessing remote objects
• Why does an object need to be called remotely?
• Only because it needs some resource that the remote machine can offer• Some custom peripheral (a scanner?)• CPU/Memory resources• Intimate access to a database• Some other resource that you wish to manage
centrally
• If not, then copy back the bytes codes and execute locally!• This is starting to sound like JINI
Design Issues
• Work out where objects need to be within the system architecture
• Why not get the RMI server to support the ImageCreator interface directly?
• We could have passed the File object across to the server but not the file!• File implements Serializable• We could need to create a remotely accessible
stream object
• Must then pass the image object back to the client• It is expensive to transfer large arrays of bytes
Other sources of information
• Lots of RMI information at Sun’s site http://www.javasoft.com/products/jdk/rmi
• JRMP (RMI’s wire protocol) is described in the downloadable documentation available for each Java 1.2.X or 1.3.X VM or from http://java.sun.com/j2se/1.3/docs/guide/rmi/..spec/rmi-protocol#60
RemoteWorker
• Model• Master + n slave processors• Slaves do the work• Master distributes it and receives results• Work is done in a class which implements the Solver interface
RemoteWorker
• Solver methods• public void init( TaskDescriptor init_parms )
• Set up initial parameters (if any)• public Result executeTask( TaskDescriptor td )• Solve the problem
• TaskDescriptor• Marker interface• Wrapper for arguments for init and executeTask
• Result• Marker interface• Wrapper for return value(s) from executeTask
RemoteWorker
• Setting up• Start rmiregistry on each slave
•start rmiregistry• Start RemoteWorker on each slave
•java -cp . scl.RemoteWorker.RemoteWorker
• On master• Run program which
• creates task descriptors
• puts them in a Q
• fires up a proxy for each slave
• send solver class to slave
• extract task descriptors from Q and send them to slaves
Creating a Class object
public ImageCreator loadCreator(String className)throws ClassNotFoundException{ Class type = Class.forName(className); Class imageCreatorType = ImageCreator.class;
ImageCreator component = null; Class[] interfaces = type.getInterfaces(); for (int i = 0; i < interfaces.length; i++) { if (interfaces[i].equals(imageCreatorType)) { return (ImageCreator) type.newInstance(); } } return null;}
Alternative approaches
• There are two other ways to test this:
• Or:
if (ImageCreator.class.isAssignableFrom(type)) return (ImageCreator) type.newInstance();else return null;
try { return (ImageCreator) type.newInstance();} catch (java.lang.ClassCastException cce) { return null;}
The price of deferred loading
• Compiler errors become exceptions!• java.lang.ClassNotFoundException
• no (byte code) definition for the specified class can be found
• java.lang.IllegalAccessException• the constructor/method is private
• java.lang.InstantiationException• the class does not have a valid constructor or
an attempt was made to instantiate a primitive:• int i = new int(); // this is an error!