Docstoc

Recap

Document Sample
Recap Powered By Docstoc
					Recap

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




       CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
       http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                              1
Today

   Java Remote Method Invocation (RMI)
   JavaSpaces




      CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
      http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                             2
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.

       CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
       http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                              3
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 don’t have implementations at the destination - this
    works because the (virtual) machines have identical
    binary architectures.


       CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
       http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                              4
RMI Classes and Interfaces Overview




   CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
   http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                          5
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.


     CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
     http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                            6
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.




       CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
       http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                              7
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;
}




        CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
        http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                               8
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.

     CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
     http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                            9
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);
  }




      CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
      http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                             10
RMI Example Implementation (Part 2)
    public Serializable get(Serializable key)
      throws RemoteException
    {
      return (Serializable) hashtable.get(key);
    }

    public void clear() throws RemoteException
    {
      hashtable.clear();
    }
}




        CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
        http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                               11
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.


     CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
     http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                            12
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(“//localhost:8888/hashtable”, hashtable);

   RemoteHashtable remoteTable =
     (RemoteHashtable) Naming.lookup
       (“//rmi.caltech.edu:8888/hashtable”);


     CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
     http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                            13
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.



        CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
        http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                               14
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.




       CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
       http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                              15
JavaSpaces

   RMI is used to implement another communication model
    called JavaSpaces.
       An integral part of Sun’s 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.


        CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
        http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                               16
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 you’re 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.

        CS 141a - Distributed Computation Laboratory    Java RMI, JavaSpaces
        http://www.cs.caltech.edu/~cs141/                    25 February 2003
                                                                                17
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


        CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
        http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                               18
A Problem…

   When an object is put into a JavaSpace, it’s possible that
    nobody will ever remove it.
      Maybe nobody wants it.

      Maybe there’s a deadlock

      Any number of reasons…

   This is a big problem if the JavaSpace is persistent (it’s
    going to run for years, perhaps).
   How do we solve it?



       CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
       http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                              19
Leases

   JavaSpaces solves the problem by associating a lease -
    a time period during which an entry is guaranteed to
    remain available (if it isn’t 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, it’s good for a
        specific amount of time. Your computer then repeatedly renews
        the lease, as long as you leave it on the network.

        CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
        http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                               20
Transactions

   JavaSpaces support transactions - the ability to perform
    multiple operations that appear, to outside observers, as
    a single atomic operation.
   We’ll 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.


        CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
        http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                               21
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 that’s what Sun did…

     CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
     http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                            22
Equivalence of Communication Models

   If you can show that all those implementations are
    possible, then you’ve 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 world’s distributed
    systems with it?




       CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
       http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                              23
Equivalence of Communication Models

   Answer: different communication models are appropriate
    for different situations.

   It’s easier to implement systems containing only remote
    Java objects with RMI than with message passing or
    JavaSpaces.
   It’s easier to implement systems with persistent, loosely
    synchronized communication with JavaSpaces than with
    RMI or message passing.
   It’s easier to implement purely asynchronous systems
    with message passing than with JavaSpaces or RMI.

       CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
       http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                              24
Next Class

   Transactions




      CS 141a - Distributed Computation Laboratory   Java RMI, JavaSpaces
      http://www.cs.caltech.edu/~cs141/                   25 February 2003
                                                                             25

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:10
posted:10/27/2011
language:English
pages:25
xiaohuicaicai xiaohuicaicai
About