Transcript Ying Chen

Client Call Back

Client Call Back is useful for multiple clients to keep
up to date about changes on the server
Example:
 One auction server and several auction clients
 When one client makes a higher bid, all the other clients
need to be informed

RMI is Synchronous

Client Call Back provides a way to make it Asynchronous
Client Call Back Steps


RMI Client acts as a RMI Server, RMI Server acts as RMI
Client
Server:



provide a method in remote interface for client to register for
events
implement the method
Client:





provide a remote interface for server to invoke
implement its remote interface
call UnicastRemoteObject.exportObject(this) to export the
client object
call server's registration method
create stubs and skeletons on the client side of the client
implementation class
Distribution of Classes

For the server, the following classes must be available to its
class loader:






Remote service interface definitions
Remote service implementations
Skeletons for the implementation classes (JDK 1.1 based servers
only)
Stubs for the implementation classes
All other server classes
For the client, the following classes must be available to its class
loader:




Remote service interface definitions
Stubs for the remote service implementation classes
Server classes for objects used by the client (such as return values)
All other client classes
Automatic Distribution of Classes


The RMI design extends the concept of class loading to include
the loading of classes from FTP servers and HTTP servers
dynamically
Classes can be deployed in one, or only a few places, and all
nodes in a RMI system will be able to get the proper class files
from the servers




Downloading stub for RMI Client
Downloading parameter and return value classes for RMI Client and
RMI Server
Use java.rmi.server.codebase to specify a URL which points to
the location that supplies classes
Use java.security.policy to set the security policy file
Distributed Garbage Collection





The RMI system provides a reference counting distributed
garbage collection algorithm
Server keep track of which clients have requested access to
which remote objects
A live client reference has a lease with a specified time
If a client does not refresh the connection to the remote object
before the lease term expires, the reference is considered to be
dead and the remote object may be garbage collected.
The lease time is controlled by the system property
java.rmi.dgc.leaseValue (defaults to 10 minutes)
Distributed Garbage Collection (Cont.)



The interface to the distributed garbage collector is
hidden in the stubs and skeletons layer
A remote object can implement the interface
java.rmi.server.Unreferenced and get a notification
via the unreferenced method when there are no
longer any clients holding a live reference
Because of these garbage collection semantics, a
client must be prepared to deal with remote objects
that have disappeared
Firewall Issues




Firewalls are sometimes encountered by networked
enterprise application
Typically firewall blocks all network traffic except
those intended for certain "well-known" ports
RMI communication between client and server is
typically blocked by most firewall implementations
To get across firewalls, RMI makes use of HTTP
tunneling by encapsulating the RMI calls and reply
within HTTP protocol
Firewall Scenarios




RMI transport layer automatically
encapsulate the RMI call within an HTTP
POST request

HTTP-encapsulated data is decoded and
dispatched by the RMI transport layer in the
server

Reply is then sent back to client as HTTPencapsulated data
RMI transport layer places RMI call inside the
HTTP packets and send those packets to port
80 of the server
On the Server unbundle the HTTP packet and
forwards the call to the server process on the
designated port
Repliy from the server are sent back as HTTP
REPLY packets to the originating client port
where RMI again unbundles the information
and sends it to the appropriate RMI stub.
Thread in RMI



Remote method invocation on the same remote
object may execute concurrently
remote object implementation needs to make sure its
implementation is thread-safe
A method invocation dispatched by the RMI runtime
to a remote object implementation may or may not
execute in a separate thread
Proxy Pattern in RMI


RealSubject in one context is represented by another (the proxy)
in a separate context. The proxy knows how to forward method
calls between the participating objects
The Stub class plays the role of the proxy, and the remote service
implementation class plays the role of the RealSubject
Applying Factory Pattern in RMI



Provide a way to control
and manage the access
to ProductImpl Objects
Reduce the objects that
needed to be registered
with RMI Registry
Database Connection
Pool
Applying Adapter Pattern in RMI



Adapt a local class to a remote class
Separate the local behavior and
remote behavior
Reuse the local class, remote
interface doesn't match the class
interface
Reference




Sun RMI Page
 http://java.sun.com/products/jdk/rmi/index.html
Sun online training
 http://developer.java.sun.com/developer/onlineTraining/rmi/R
MI.html
Java World
 http://www.javaworld.com
jGuru
 http://www.jguru.com
Demo

Client Call Back

Automatic Distribution of Classes

Distributed Garbage Collection