JDC_Lecture19 - Computer Science
Download
Report
Transcript JDC_Lecture19 - Computer Science
UMass Lowell Computer Science 91.460
Java and Distributed Computing
Prof. Karen Daniels
Fall, 2000
Lecture 19
Advanced Java Concepts
Multithreading (continued)
Remote Method Invocation (RMI)
[Deitel: Chapter 20]
Fri. 11/3 – Mon. 11/6
Homework Status
HW# Assigned Due
Graded
Submitted
Pending
1
2
3
4
5
6
7
Fri, 9/8
Fri, 9/15
Fri, 9/22
Fri, 10/6
Fri, 10/13
Fri, 10/20
Fri, 10/27
9/15, 9/18
Fri, 9/22
Fri, 9/29
Fri, 10/13
Fri, 10/20
Fri, 10/27
Fri, 11/3 & 11/6
Finishing our “Thread”...
Code/Demos
Monitors/Synchronization
Java’s Monitor Concept
• Java provides a monitor for
each object and class
• Unique lock for each object
and class
• Monitor controls access to
synchronized code (method,
block
•block must specify object
• Unsynchronized code is not
regulated by monitor
Figure Source: Operating
Systems: Advanced Concepts
The Class class
Objects of this class, called class
descriptors, are automatically created by the
JVM when a class (or interface) is loaded
Accessed
by an Object’s getClass method
Can get the class’s name, superclass, interfaces
Can be locked for thread synchronization
purposes
A class lock is a lock on a class Class object
synchronized Static Methods
You can get a lock on a class (actually, the
class’s Class object) by creating a
synchronized static method
Only one thread can execute a (any)
synchronized static method at a time
Remote Method Invocation
(RMI)
Distributed Computing
High-Level Definition
Pieces
of some computation run on separate
processing units (potentially across a network)
Goal: as close to seamless distribution as
possible
Minimize
the code changes required to split
apart an application such that it runs in a
distributed environment
Distributed Computing requires a modular design
Distributed Objects
Distributed computing (without objects) has been
around awhile, e.g.:
Socket-based interprocess communication (IPC)
Remote Procedure Calls (RPC)
Distributed Computing Environment (DCE)
But objects can be distributed as well
Common Object Request Broker Architecture (CORBA)
Microsoft OLE, COM/DCOM, Active-X, ???
Java RMI
Granularity of Distributed
Computing
Coarse-grained distribution (more common
by far)
Single
objects representing a client and a server
Fine-grained distribution
Potentially
every object (e.g., a delivery, an
airplane) is distributed
There are key performance, modularity,
flexibility trade-offs to make when deciding
on an appropriate degree of granularity
Client-Server Model
Servers are providers of a service
Data
providers (files, databases, images, ...)
Computing providers
Clients are users of a service
Generally
think of clients being “in front of the
human user”
RMI Example: Deitel Chapter 20
Weather
Use the National Weather Service Web site:
http://iwin.nws.noaa.gov/iwin/us/traveler.html
RMI At-A-Glance
Objects in one Java Virtual Machine (JVM) invoke
the methods of objects in another JVM
Invoking
objects (clients) are often called local objects
Invoked objects (servers) are often called remote
objects
Chapter 20 Weather Example:
TemperatureServer
RMI Server
TemperatureClient
RMI Client
RMI - Not Just for Networks
Local and remote objects can be on the
same machine (but in different processes)
Local and remote objects can be on
different machines across a network
Note: a single Java program can contain
both client and server objects
Similar to Remote Procedure Call (RPC)
Java Interfaces: A Key Ingredient
If a class implements an interface, then an object
of that class can be “cast” to that interface “type”
Can declare an “object reference” that uses an
interface instead of a class type
When “client code” invokes an interface method
on this reference, the JVM (at run-time)
determines
which class (that implements the interface)
the reference really refers to
operates on the object of that class
Polymorphism via interfaces!
“Client code” only needs to know about interface,
not implementation!
Remote Objects: Key Ideas
Remote interface describes server object’s behavior
Server object and its name are registered with a “lookup
service”: rmiregistry
Client knows:
Client asks rmiregistry for server object (by name)
Client receives a remote interface reference:
remote interface
name of server object
proxy/“stub”/representative of remote server object
Client invokes methods of remote interface on the remote
interface reference
Remote Interfaces
The declaration of behavior (the interface) is
different from implementation of behavior (class)
Built separately (often by different programmers)
Run separately (often on different machines)
Servers implement behavior and expose interfaces
Clients rely on interfaces to invoke servers
Chapter 20 Weather Example:
Interface
TemperatureServer
Implementation TemperatureServerImpl
RMI Server
TemperatureClient
RMI Client
RMI Registry
Associates server object instances with names
Runs on each server machine
Uses port 1099 as a default
Started by the rmiregistry utility program
Accessed by the client to get a proxy (stub) to
the server object
The Java RMI Mechanism
RMI is built on top of (uses) the JVM
Activates remote objects
Manages and monitors communication connections
Tracks invocable objects
Typically based on TCP sockets
Stream-based, IP address (DNS name), port number
Uses unicast (point-to-point)
Is being extended to use Internet Inter-ORB Protocol (IIOP)
Laying the foundation for greater CORBA compatibility
Most of this happens “behind the scenes”
RMI Layered Architecture
RMI
System
Client Program
Server Program
Stubs & Skeletons
Stubs & Skeletons
Remote Reference Layer
Remote Reference Layer
Transport Layer
Based on http://developer.java.sun.com/developer/onlineTraining/rmi
Using RMI
Define interfaces
Implement servers
Build clients that use the servers
Compile the pieces and run them
Server Side
The server class implements a remote
interface
A remote
interface is one that extends the
java.rmi.Remote interface
e.g., public interface myInterface extends Remote
java.rmi.Remote
is a “tagging” interface (i.e., it
has no methods, like the Serializable interface)
Each declared method throws
java.rmi.RemoteException
Server Side (continued)
A server class typically extends
java.rmi.UnicastRemoteObject
Could alternatively invoke java.rmi.UnicastRemoteObject static
exportObject() method
Either approach makes instances of the class known to the RMI
mechanism
UnicastRemoteObject manages
networking/communications details for server
also
keeps JVM running while server “waits” for
remote method calls
Constructor has to throw RemoteException
Generally
also address security issues associated with
downloadable code (more later)
Server Side (concluded)
In main() (typically)
Create
an instance of the class as needed
Register the instance with the RMI Registry
Use Naming.rebind(serverObjName, objRef) where
serverObjName is a concatenation of the hostname
(or IP address) and a name by which clients will find
the server
Implement the server logic exactly as you
would for any local class
RMI Example: Deitel Chapter 20
Interactions
National Weather Service Web Site
traveler.html
sunny.jpg
sunny.jpg
sunny.jpg
(Serializable)
WeatherInfo
Remote Interface
WeatherItem
TemperatureServer
Implementation
RMI Registry
TemperatureServerImpl
RMI
Proxy/Stub
TemperatureServerImpl_Stub
RMI Server
TemperatureClient
Remote method
calls
RMI Client
RMI Example: Deitel Chapter 20
Examine Server-Side Code
National Weather Service Web Site
traveler.html
WeatherInfo.class
Interface
TemperatureServer.class
Implementation
TemperatureServerImpl.class
Proxy/Stub
TemperatureServerImpl_Stub.class
RMI Server
Deitel & Deitel Chapter 20 RMI Example
Changes
The National Weather Service changed the format of their Traveler's Forecast web
page slightly. Make the following changes to the file
TemperatureServerImpl.java to fix the problem:
Line 35 should be changed from
String separator = "</PRE><HR> <BR><PRE>";
to
String separator = "TAV12";
Line 58 should be changed from
From http://www.deitel.com
while ( !inputLine.equals( "" ) ) {
to
while ( inputLine.length() > 28 ) {
Recompile the file and regenerate your stub file before running the server.
Client Side
All a client JVM knows how to do is to make local
method invocations
Client
objects invoke server objects via “stubs”
A “stub” is a local proxy for a remote object
The stub knows how to deal with the RMI mechanism
The client code treats the proxy as if it were the remote
object
Other than that, the client just has to know where
to look for a remote object of a specific name
Client Side (concluded)
Contact the registry to find the object
Make sure that what you get is what you want
(i.e., implements the desired interface)
Install a Security Manager as needed
Find the remote object on the server ()
Naming.lookup(serverObjName)
Returns a ref to a Remote (an object that implements
a Remote interface)
if (ref instanceof myInterrface) { }
Use it as desired
Be sure to do the above in a try - catch (to get
RemoteException)
RMI Example: Deitel Chapter 20
Examine Client-Side Code
sunny.jpg
sunny.jpg
sunny.jpg
WeatherItem.class
TemperatureClient.class
RMI Client
RMI Example: Deitel Chapter 20
Examine National Weather Service .html
National Weather Service
Web Site
TAV12
traveler.html
TRAVELERS FORECAST TABLE
NATIONAL WEATHER SERVICE - WASHINGTON D. C.
TEMPERATURES INDICATE DAYTIME HIGH..NIGHTTIME LOW
B INDICATES TEMPERATURES BELOW ZERO
FORECAST
FORECAST
MON....MAR 20 TUE....MAR 21
CITY
WEA
HI/LO WEA
HI/LO
ALBANY NY
PTCLDY 50/32 MOCLDY 48/31
ANCHORAGE
RNSNOW 39/30 RNSNOW 41/25
ATLANTA
PTCLDY 61/42 PTCLDY 72/47
Process #1: rmiregistry
Process #2: server
Process #3: client
Compilation & Execution
Compilation:
Compile pieces as normal using javac
Compile the server (a second time) using the RMI
compiler rmic
If client and server in separate directories, need class file
provider (http or ftp server)
Produces a stub class for the client (could be made available
via a download)
Execution:
3 Processes:
rmiregistry
server
client
RMI Example: Deitel Chapter 20
Class and File Dependencies
National Weather Service Web Site
traveler.html
WeatherInfo.class
sunny.jpg
sunny.jpg
sunny.jpg
Remote Interface
TemperatureServer.class
WeatherItem.class
Implementation
TemperatureServerImpl.class
Proxy/Stub
TemperatureServerImpl_Stub.class
RMI Server
TemperatureClient.class
RMI Client
Serialization & RMI
RMI uses serialization to pack/unpack
arguments and return values (via a process
known as marshalling)
All
primitive types are serializable
User-defined classes must:
Implement/extend the Serializable interface
Have a public null constructor
Only have references to serializable objects
Static
variables are not transmitted
Ramifications of RMI
Serialization
Local arguments and return values are passed
by value
If
it has to be serialized to travel from one process
(JVM) to another, it is copied
Remote objects passed to or returned from a
remote object’s methods
Actually
get a reference to the stub for that remote
object
Thus get a pass-by-reference semantics for this case
What About Polymorphism?
Serialization only works for data, not
methods
We occasionally want server types of
mechanisms to invoke mechanisms we
create using polymorphism (e.g., the paint()
method of a JFrame)
RMI supports the dynamic loading of code
Dynamic Loading of Code
Server side can accept unknown (at compile time)
subclasses as arguments to method invocations
Requires such a class to create a codebase
Tells the JVM where to get the code from (just like
moving applets around in the Web!)
Contains a URL that can be used to download the code
All RMI does is annotate the serialized data with the
URL
Is used to transmit stubs around as well as customized
code
The client does not have to receive stubs ahead of time
Security Issues
RMI supports downloading code at runtime
E.g.,
getting stubs, remote polymorphism
RMI provides a SecurityManager to enable
the use of downloadable code
Implements
a rudimentary security policy (e.g.,
all code signed by Bill can write to this
directory)
See system.getSecurityManager(), system.
setSecurityManager(), and class
RMISecurityManager for more details
RMI Activation Framework
Mechanism for starting server-side objects
from the client side
Activate
remote objects when needed
Deactivate them when not needed
Useful when:
Have
rarely used remote objects
Have many remote objects
To reconstitute remote services after a crash
Requires special code
Some Notes About RMI
The distributed environment is more fragile (need to
worry more about exceptions)
Network connections can go down
Remote machines can go down
Garbage collection
Remote references have a lease period
If no local and no remote references, becomes a candidate for
GC
Invokes the unreferenced method of the Unreferenced interface
(if implemented) vs finalize
Some Notes About RMI
(continued)
A remote object can be richer than the interface it
presents to the outside world
A remote object can expose multiple sets of interfaces
Base classes become servers
Java does not use a separate Interface Definition
Language (IDL)
E.g., an admin interface and a functional interface
Higher parts of inheritance hierarchies can be remoted
Not all of its methods have to be exposed
JAVA RMI is specific to Java
Java does not use an Object Request Broker (ORB)
Some typical ORB services are built into the RMI mechanism
(e.g., naming, security)
A Short RMI Quiz
http://developer.java.sun.com/developer/Quizzes
/rmi
For More RMI Information...
http://developer.java.sun.com/developer/onlineTraini
ng/rmi
- RMI Tutorial
- RMI Exercises