Client Call Back

1. 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

2. 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

3. 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

4. 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

5. 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)

6. 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

7. 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

8. 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 HTTP-encapsulated 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.

9. 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

10. 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

11. 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

12. 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

13. Reference • Sun RMI Page • http://java.sun.com/products/jdk/rmi/index.html • Sun online training • http://developer.java.sun.com/developer/onlineTraining/rmi/RMI.html • Java World • http://www.javaworld.com • jGuru • http://www.jguru.com

14. Demo • Client Call Back • Automatic Distribution of Classes • Distributed Garbage Collection