Notes

Outline

RMI – Remote Method Invocation Introduction What is RMI and its goals? RMI System Architecture How does RMI work? Distributed Garbage Collection RMI & the OSI Reference Model Security Programming with RMI

Introduction Low-level sockets can be used to develop client/server distributed applications But in that case, a protocol must be designed Designing such a protocol is hard and error-prone (how to avoid deadlock?) RMI is an alternative to sockets

What is RMI? A core package of the JDK1.1+ that can be used to develop distributed applications Similar to the RPC mechanism found on other systems In RMI, methods of remote objects can be invoked from other JVMs In doing so, the programmer has the illusion of calling a local method (but all arguments are actually sent to the remote object and results sent back to callers)

Local v. Remote method invocation

Features supported by RMI They are the most valuable for building distributed applications Transparent invocations (since they are identical to local ones) Distributed garbage collection Convenient access to streams NOTE: in RMI, all objects must be written in Java!

Goals of RMI RMI has a number of goals, some of these are: Support seamless object remote invocations Support callbacks from server to client Integrate the distributed object model into Java Make writing distributed applications as simple as possible Refer to book (pp. 107)

RMI System Architecture Built in three layers (they are all independent): Stub/Skeleton layer Remote reference layer Transport layer

The Stub/Skeleton layer The interface between the application layer and the rest of the system Stubs and skeletons are generated using the RMIC compiler This layer transmits data to the remote reference layer via the abstract of marshal streams (that use object serialization) This layer doesn’t deal with the specifics of any transport

The Stub/Skeleton l Client stub responsible for: Initiate remote calls Marshal arguments to be sent Inform the remote reference layer to invoke the call Unmarshaling the return value Inform remote reference the call is complete Server skeleton responsible for: Unmarshaling incoming arguments from client Calling the actual remote object implementation Marshaling the return value for transport back to client

The Remote Reference Layer The middle layer Provides the ability to support varying remote reference or invocation protocols independent of the client stub and server skeleton Example: the unicast protocol provides point-to-point invocation, and multicast provides invocation to replicated groups of objects, other protocols may deal with different strategies… Not all these features are supported….

The Transport Layer A low-level layer that ships marshal streams between different address spaces Responsible for: Setting up connections to remote address spaces Managing connection Listening to incoming calls Maintaining a table of remote objects that reside in the same address space Setting up connections for an incoming call Locating the dispatcher for the target of the remote call

How RMI works? An invocation will pass through the stub/skeleton layer, which will transfer data to the remote reference layer (marshal streams) The semantics of the invocation are carried to the transport layer The transport layer is responsible for setting up the connection

Distributed Garbage Collection RMI provides a distributed garbage collector that deletes remote objects no longer referenced by a client Uses a reference-counting algorithm to keep track of live references in each Virtual Machine When a live reference enters VM ++, and when unreferenced --, when reaches 0 garbage col’ct RMI keeps tracks of VM identifiers, so objects are collected when no local OR remote references to them

RMI and the OSI reference model How RMI can be described by this model?

Security While RMI is a straightforward method for creating distributed applications, some security issues you should be aware of: Objects are serialized and transmitted over the network in plain text No authentication: a client requests an object, all subsequent communication is assumed to be from the same client No Security checks on the register No version control

Programming with RMI Anatomy of an RMI-based application Define a remote interface Implement the remote interface and server Develop a client Generate stubs and skeletons Start the RMI registry Run the client and server

Define a remote interface It specifies the characteristics of the methods provided by a server and visible to clients Method signatures (method names and the type of their parameters) By looking at the interface, programmers know what methods are supported and how to invoke them Remote method invocations must be able to handle error messages (e.g. can’t connect to server or server is down)

Characteristics of  remote interface Must be declared public To make an object a remote one, the interface must extend the java.rmi.Remote interface Each method declared in the interface must declare java.rmi.RemoteException in its throws clause. Example: public interface Arith extends java.rmi.Remote {   int [] add(int a[], int b[]) throw java.rmi.RemoteException; }

Implement the remote interface The implementation needs to: Specify the remote interface being implemented Define the constructor of the remote object Implement the methods that can be invoked remotely Create an instance of the security manager and install it Create an instance of a remote object Register it with the RMI registry Example: ArithImpl.java

Develop a client Example: ArithApp.java

Generate stubs and skeletons Use the rmic compiler They are determined and dynamically loaded They connect the client and server together

Start the RMI registry It is a naming service that allows clients to obtains references to remote objects

Run the server and client Run the rmi registery (default port: 1099) Run the server Run the client Example: Arithmetic Server

Working with the RMI Registry Refer to the book (pp. 120 – 121) for examples on how to list objects, remove objects, and rebind them….

What else? Refer to the book for more advanced topics: Chapters 9 & 10 from the book: Implementing factories Implementing callbacks How to sign objects over RMI How to create custom RMI socket factories SSL sockets Remote object activation