Lecture Notes for Client-Server Interfaces

27 March 2004 - Java RMI

Outline

• Objects, distributed computing, and Java.

• Java remote method invocation.

  • Service specification.

  • Server implementation.

  • Proxy generation.

  • Registration and discovery.

  • Client discovery.

• Fine points.

  • Dynamic loading, stubs, and security.

  • Marshalling arguments.

Objects and Distributed Computing

• Objects and distributed computing go together like chocolate and peanut butter.

• Good bits.

  • Separating interface from implementation is easy.

  • Encapsulation keeps state within single address spaces.

  • The message-sending paradigm maps well to distributed objects.

• Bad bits.

  • References and dynamic storage management.

Java and Distributed Computing

• Java defines a complete environment that accommodates distributed computing.

• It's object-oriented!

  • Many useful RPC concepts map directly into Java.

• It's got a JVM.

  • It defines a common architecture.

  • It's easily distributed.

  • It provides a mechanism for implementing security policies.

Java Remote Method Invocation

• RPC in Java is called remote method invocation or RMI.

• At a high level, RMI works pretty much like RPC.

  • The client locates a server.

  • The client calls a stub.

  • The stub marshals the arguments and sends them to the server.

  • The stub unmarshals the results and returns to the caller.

class AdderClient

  void adder(int a, int b)

    try 
      AdderInterface adder = 
        (AdderInterface) Naming.lookup("Adder")
      System.out.println(
	a + "+" + b + "=" + adder.add(a, b))

    catch Exception e
      System.err.println(
        "Exception" + e.getMessage())
      e.printStackTrace()

Service Specification

• An RMI service is specified by a Java interface.

  • An interface is like a C++ class declaration with only method prototypes and no definitions.

• The interface specifies a contract between client and server.

  • The client calls only the interface methods.

  • The server implements all the interface methods.

  • The contract is enforced by the compiler and JVM.

  import java.rmi.Remote
  import java.rmi.RemoteException
  
  public interface AdderInterface
  extends Remote
  
    int add(int a, int b) throws RemoteException
  

• Every RMI-service interface must extend Remote.

  • Such interfaces are known as remote interfaces.

• Every RMI-service method must throw RemoteException.

  • It's a checked exception and can't be ignored .

Server Implementation

• The server implementation has two parts:

  1. The remote-interface implementation (called the remote object), and

  2. the stub (called the remote-object proxy).

• Any class implementing the remote interface can be a remote object for the server.

  import java.rmi.RemoteException
  import java.rmi.server.UnicastRemoteObject
  
  public class AdderImplementation 
  extends UnicastRemoteObject 
  implements AdderInterface
  
    AdderImplementation() throws RemoteException
      super()
  
    int add(int a, int b) throws RemoteException
      return a + b
  

• UnicastRemoteObject uses TCP for point-to-point communication.

  • Other protocols are available from other remote objects.

Proxy Generation

• rmic creates remote-object proxies.

  
  * ls *.class
  AdderImplementation.class
  
  * rmic -v1.2 AdderImplementation
  
  * ls *.class
  AdderImplementation.class
  AdderImplementation_Stub.class
  
  * 
  

• Earlier RMI versions required both a stub (for the client) and skeleton (for the server).

Registration and Discovery

• Server registration and client discovery are left open.

• rmiresistry is a simple registration-lookup service.

  • It is itself an RMI service.

• rmiresistry maps a string to a remote object and its proxy.

• Any code will do to register a remote object and proxy.

  import java.rmi.Naming
  
  class AdderRegister
  
    public static void 
    main(String[] args)
  
      try 
        Naming.rebind(
          "Adder", new AdderImplementation())
  
      catch (Exception e)
        System.err.println(
          "rebind() error:  " + e.getMessage())
        e.printStackTrace()
  

Client Discovery

• Clients call rmiresistry remote objects via their proxies to return the proxy (if any) bound to a string.

• rmiresistry service names look like URLs.

  import java.rmi.Naming
  
  class Adder
  
    final AdderInterface adder
  
    Adder() 
      try 
        adder = (AdderInterface) Naming.lookup(
          "rmi://clayton.cs.monmouth.edu:5370/Adder")
      catch Exception e
        System.err.println(e.getMessage())
        e.printStackTrace()
  
    int adder(int a, int b)
      int sum = 0
      try 
        sum = adder.add(a, b)
      catch Exception e
        System.err.println(e.getMessage())
        e.printStackTrace()
      return sum
  

Dynamic Loading and Stubs

• The client locates the server to download the stub.

  • Before locating the server, the client has no stub.

• Loading stubs dynamically has several nice properties.

  • Low overhead for unused services.

  • Eliminates server versioning problems.

• It's got a few problems too.

  • Executing code from the network.

  • Versioning problems move to the interface.

    • Where it can, perhaps, be better handled.

Dynamic Loading and Security

• Loading arbitrary other code is dangerous.

• Java defines two main security policies: code verification and sand bagging.

• Code verification prevents low-level attacks via address abuse.

  • Byte-code are verified when loaded into the JVM.

  • Verification prevents unauthorized access to addresses.

  • Byte-code verification is largely static, with some dynamic checks .

• Sand bagging prevents unauthorized access to high-level resources.

  • This includes access to files, networks, and so on.

The Security Manager

• Sand bagging is implemented by security managers.

  • Instances of classes rooted at SecurityManager.

• Each security manager has a policy describing allowed resource accesses.

  grant { 
    permission 
      java.net.SocketPermission "*:1024-65535", 
      "connect,accept,resolve"; 
    };
  

• Applications install security manager instances to determine proper resource access.

  public static void
  main(String args[])
    if System.getSecurityManager() == null
      System.setSecurityManager(
        new RMISecurityManager())
  
    final AdderClient ac = new AdderClient()
    System.out.println("2+3 =", ac.add(2, 3))
  

Marshalling Arguments

• Three types of entities can be passed as RMI arguments.

  • Non-instance data; ints, bools, and so on.

  • Instances from classes implementing the Serializable interface.

  • Instances from classes implementing the Remote interface.

  • Instances from plain old classes can't be RMI arguments.

• Non-instance data are understood by all JVMs.

• The Serializable interface allows I-O on class instances.

  • Instances may be written to a stream and reconstituted by reading the data back.

  • This is traditional RPC marshaling .

• Sending remote instances sends the proxy for the instance.

Points to Remember

• The JVM supports is a useful platform for distributed computing.

  • It provides a common ground.

• Java RMI works by shipping around stub routines.

  • The stubs implement service interfaces.

• Java security involves access checking and sand bagging.

  • Access checking via class loading and sand bagging security managers.

This page last modified on 16 April 2004.