CS 141a Distributed Computation LaboratoryJava RMI, JavaSpaces

1
Recap

• Sockets, and Java Interface to Sockets
• Remote Procedure Calls
• Distributed Objects

2
Today

• Java Remote Method Invocation (RMI)
• JavaSpaces

3
Java Remote Method Invocation

• Remote objects are part of all current Java
  distributions, in the form of Java Remote Method
  Invocation (RMI).
• Clients make method calls on proxy objects.
• Important differences between remote objects and
  local objects in Java
• clone() on a proxy clones the object on the
  server and returns a new proxy instead of cloning
  the proxy.
• Synchronized methods are synchronized on the
  proxy, not on the remote object distributed
  synchronization must be done explicitly in other
  ways.

4
Java Remote Method Invocation

• Any primitive type or Serializable object type
  can be passed as a parameter to a remote method.
• Local objects (and primitive types) are passed by
  value, while remote objects are passed by
  reference.
• Additional exceptions must be handled when
  calling remote methods.
• Bytecode (or a pointer to bytecode) is sent for
  classes that dont have implementations at the
  destination - this works because the (virtual)
  machines have identical binary architectures.

5
RMI Classes and Interfaces Overview
6
Marker Interfaces

• java.io.Serializable
• Interface that must be implemented by any class
  used as a parameter in a remote interface.
• Many classes in the standard Java class library
  implement Serializable.
• No methods.
• java.rmi.Remote
• Interface that must be implemented by all remote
  interfaces.
• No methods.

7
Remote Exceptions

• All methods in remote interfaces must be declared
  to throw java.rmi.RemoteException (or a
  superclass, such as java.io.IOException or
  java.lang.Exception)
• Methods in remote interfaces may throw
  application-specific exceptions other than
  RemoteException.
• When an application-specific exception is thrown
  on the server side, it is wrapped in a
  RemoteException and returned to the client side,
  where it is unwrapped automatically.

8
Example Remote Interface

• interface RemoteHashtableInterface extends Remote
• public Serializable put(Serializable key,
  Serializable value)
• throws RemoteException, NullPointerException
• public Serializable get(Serializable key)
• throws RemoteException
• public void clear()
• throws RemoteException

9
RMI Core Classes

• java.rmi.server.RemoteObject
• Includes implementations of the java.lang.Object
  methods hashCode(), equals() and toString() for
  remote objects.
• java.rmi.server.UnicastRemoteObject
• Includes methods needed to create and export
  simple remote objects (references are only valid
  for the lifetime of the server).
• Most remote interface implementations are
  subclasses of UnicastRemoteObject.

10
RMI Example Implementation (Part 1)

• public class RemoteHashtable extends
  UnicastRemoteObject
• implements RemoteHashtableInterface
• private Hashtable hashtable new Hashtable()
• public Serializable put(Serializable key,
  Serializable value)
• throws RemoteException, NullPointerException
• return (Serializable) hashtable.put(key,
  value)

11
RMI Example Implementation (Part 2)

• public Serializable get(Serializable key)
• throws RemoteException
• return (Serializable) hashtable.get(key)
• public void clear() throws RemoteException
• hashtable.clear()

12
RMI Core Classes

• java.rmi.activation.Activatable
• Includes methods needed to create and export
  activatable objects that are executed by an
  activation daemon when methods are invoked on
  them.
• Activatable objects can easily be made persistent
  - loaded into memory when needed, saved to disk
  when not being used.
• We may or may not actually use the activation
  framework in future projects.

13
Naming

• java.rmi.Naming
• Static methods for binding and unbinding names to
  remote objects, looking up remote objects by
  name, and listing all bound objects on a
  particular server.
• Examples
• Naming.bind(//localhost8888/hashtable,
  hashtable)
• RemoteHashtable remoteTable
• (RemoteHashtable) Naming.lookup
• (//rmi.caltech.edu8888/hashtable)

14
Registries

• Name lookups are done on an RMI registry
  (analogous to portmapper for RPC).
• Class java.rmi.registry.LocateRegistry contains
  methods to create registries.
• URL passed to Naming methods contains hostname
  and port number of a registry, and identifier of
  an object.
• Interface java.rmi.registry.Registry contains
  methods to interact directly with a registry
  without going through the Naming class.

15
Compilation

• RMI compiler, rmic, generates stubs and skeletons
  from remote object implementations.
• Example the command that generates the stubs and
  skeletons for our RemoteHashtable class
• rmic caltech.cs141.cs141.RemoteHashtable
• This is handled automatically by Ant, when
  properly configured in the build file.

16
JavaSpaces

• RMI is used to implement another communication
  model called JavaSpaces.
• An integral part of Suns Jini technology for
  building dynamic distributed systems.
• The idea a shared data space containing special
  objects called entries, where each entry is
  essentially a Serializable object with a bunch of
  fields.
• Based on generative communication, also often
  referred to as tuple spaces, developed by David
  Gelernter at Yale in the early 1980s.

17
JavaSpaces

• A JavaSpace supports the following operations
• Put an entry in the space.
• Take an entry from the space.
• Search the space for entries that match a
  specified template.
• You provide a partially-filled-in version of the
  entry youre looking for, and the JavaSpace gives
  you whatever it has that matches.
• Register to be notified (by means of an RMI call)
  whenever an entry that matches a specified
  template is put into the space.

18
JavaSpaces Motivation

• Why would we want a communication method like
  this?
• Only need to know object types of interest,
  rather than other processes mailbox names or RMI
  interfaces.
• Only need to know the location of the JavaSpace,
  not the locations of other processes on the
  network.
• If the JavaSpace is distributed, you might even
  have a local access point to it.
• Persistence
• Asynchrony

19
A Problem

• When an object is put into a JavaSpace, its
  possible that nobody will ever remove it.
• Maybe nobody wants it.
• Maybe theres a deadlock
• Any number of reasons
• This is a big problem if the JavaSpace is
  persistent (its going to run for years,
  perhaps).
• How do we solve it?

20
Leases

• JavaSpaces solves the problem by associating a
  lease - a time period during which an entry is
  guaranteed to remain available (if it isnt
  removed by another process) - with each entry in
  the space.
• When a process puts an entry in a JavaSpace, it
  gets a lease object from the JavaSpace as a
  return value.
• It can then use this object to renew the lease,
  or cancel the lease, as necessary.
• You may recognize this concept from DHCP
• When you get an IP address automatically, its
  good for a specific amount of time. Your computer
  then repeatedly renews the lease, as long as you
  leave it on the network.

21
Transactions

• JavaSpaces support transactions - the ability to
  perform multiple operations that appear, to
  outside observers, as a single atomic operation.
• Well discuss transactions in more detail next
  class.
• The basic idea
• If a process starts a transaction, and then
  decides to abort the transaction, then the
  effects of any operations it performed during the
  transaction are nullified.
• Until the process commits the transaction, no
  outside observer can tell that the transaction is
  in progress.
• When the process commits the transaction, all the
  state changes appear within it appear
  simultaneous to an outside observer.

22
Equivalence of Communication Models

• JavaSpaces is implemented with RMI.
• RMI and message passing systems (like your
  router) are usually implemented with TCP sockets.
• (ignoring the low-level technical details for the
  moment)
• Given only JavaSpaces (or, more generally, tuple
  spaces), can you implement a message passing
  system?
• Given only a message passing system, can you
  implement RMI (or, more generally, RPC)?
• We already know that JavaSpaces can be
  implemented with RMI, because thats what Sun did

23
Equivalence of Communication Models

• If you can show that all those implementations
  are possible, then youve proven that those three
  communication models are equivalent in a sense -
  anything you can do with one, you can do with
  either of the others.
• So why would we want to have all 3? Why not just
  choose one and implement all the worlds
  distributed systems with it?

24
Equivalence of Communication Models

• Answer different communication models are
  appropriate for different situations.
• Its easier to implement systems containing only
  remote Java objects with RMI than with message
  passing or JavaSpaces.
• Its easier to implement systems with persistent,
  loosely synchronized communication with
  JavaSpaces than with RMI or message passing.
• Its easier to implement purely asynchronous
  systems with message passing than with JavaSpaces
  or RMI.

25
Next Class

• Transactions