Java Space for Distributed Object System

1. Java Space for Distributed Object System Web Apps and Services

2. Main Module of a Distributed System • Global address space • global identifier • registry/ name service ( central, distributed, replicated) • Transportation system • Global Control flow (Invocation/Control flow Protocol) • parameter passing across address space • method invocation semantic • entity activation • Failure Behavior • exception • consistency and persistency

3. RMI Overview RMI provides distributed computing ability on the specific system(JVM) for the specific language(Java) • CORBA, RPC • System Heterogeneity • Language Heterogeneity • RMI based on homogeneity and strength it • Language Integration -- distributed object model • similar interface, preserve some behavior • exception • System Integration • garbage collection • mobile behavior • security

4. Java Object model Object Interface declare a set of methods for Java object without implementation Method Invocation primitive type passed by value object passed by reference Distributed Object model Remote object object whose methods can be accessed from another address space Remote interface an interface that declares the methods of a remote object Remote Implementation RMI non-remote object passed by value remote object passed by reference Language Integration -- Distributed Object Model

5. RMI Interfaces and Classes Object classes Interfaces Remote RemoteObject IOException RemoteServer RemoteException Client stub ... ... UnicastRemoteObject extension implementation

6. System Integration • Distributed Garbage Collection • Dynamic Stub loading • specialized class loader • security manager • pickling system • When marshalling remote object, marshal stream embeds URL info of the stub code • On demarshalling, marshal stream loads stub code if it’s not available locally

7. System Architecture Application Client Server • Stub/Skeleton layer • Remote reference layer • Transport layer Stubs Skeleton RMI System Remote Reference layer Transport

8. Distributed object Across Address Space • Name Service • URL based name lookup, no location transparency • Non-persistent database • java..rmi.registry.Registry • java.rmi.LocateRegistry • java.rmi.naming export export Remote Server Remote Server registry registry Locate Reg Locate Reg naming naming client client binding binding

9. Distributed object Across Address Space • Pickling -- Object transmission across address space • Serialized representation of objects: • object type • object persistent state • relationships between objects within a stream • object implementation info • Pickling remote object • remote interface • remote object reference

10. RMI Performance • RMI vs. Local call(PPro 200Mhz, NT, JDK no JIT) • Call time (no configuration available) • setup time: RMI 40% slower than CORBA • binding: RMI 200-1500ms slower than CORBA • CORBA vs. RMI • 1000 calls, one argument, JDK1.1.1

11. CORBA and RMI Performance(1000 calls, one argument)

12. RMI Performance • Scalability -- ability of handling multiple connections to one remote object • HelloImpl.sayHello() JDK1.1, Win95, 133-Pentium • 150 threads in 2 sec interval, 200 threads in 5 sec interval(RMI) • 1000 threads(Java IDL) • Serialization • 100 times, default serialization, buffered stream, primitive type, small array, small object array(10) • RMI 64500ms (object) • CORBA 3485ms (IDL struct) • different serialization schemes Object[1000], each 3 attributes(String, Double,util.Data)

13. Performance of different serialization scheme(Solaris2.5 Ultra-1 with attributes String, Double,Data)

14. Summary Pros • Integrating distribute object model seamlessly into Java object model • Homogeneity • Communication with non-Java object may work through JNI and JDBC Cons • Make distributed computing in Java easily to approach, but not efficiently • Heterogeneity • A primitive implementation currently

15. JavaSpace -- a new distributed computing paradigm • JavaSpace -- A reliable distributed storage system • Goal -- facilitating cooperate distributed computing • Utilization • Distributed algorithms as flow of object • establish connections between participants(Client/Server, RPC, RMI) • build interfaces and protocols between participants • establish connections with a broker(JavaSpace) • build interfaces and protocols with the broker • Distributed persistence

16. read Client Identities write JavaSpace Write event Client write Event Dispatcher Transaction notify take notify write JavaSpace JavaSpace

17. JavaSpace model • Entry basic unit of JavaSpace, a typed group of objects • Template a “partial” entry used to match entries with specific properties • Operation • read • write • take • notify

18. A reliable distributed storage system • Store and retrieve entries -- object • Weak query ability • Handle concurrent access • Global control flow across multiple JavaSpaces • asynchronous retrieval • distributed transaction mechanism

19. JavaSpacesTM By Stephan Roorda Source: JavaSpaces specification

20. Presentation Outline • Review of Linda • Overview of JavaSpaces • In depth description of JavaSpaces • Why is JavaSpaces better?

21. Review of Linda

22. Linda Basics • Tuple space is Linda's name for its shared data space • A Tuple is simply a list of fields, separated by commas and enclosed in parentheses • A tuple is accessed by specifying its contents • Associative memory model • There is no address associated with a tuple

23. Tuple Space Sender Sender Tuple Space Receiver Receiver

24. Linda Operations • There are four basic operations: • out • Generates a data (passive) tuple. • Each field is evaluated and put into tuple space. • in • Uses a template to retrieve tuple from tuple space • Once retrieved, the tuple is taken out of tuple space and is no longer • If no matching tuple is found process will block. Provides for synchronization between processes.

25. Linda Templates • Specifies tuple to retrieve • Consists of sequence of typed fields • Two kinds of fields • Actuals • Variables, constants or expression that resolve to constant • Formals • Holders for data to retrieve • Preceded by a question mark • Assigned values of corresponding fields in matched tuple

26. Matching Templates • In order for a template to match a tuple: • Have to have the same number of fields • Actuals must have same type, length and values as those in corresponding tuple fields • Formals in template must match type and length of corresponding fields in tuple • If several tuples match the template, impossible to predict which will be selected • The order of evaluation of fields within a tuple or template is undefined.

27. Linda Operations • rd • Uses a template to copy data without removing it from tuple space. • Once read, the tuple is still available for others. • If no matching tuple is found process will block. • eval • Generates process (active) tuple • Control is immediately returned to invoking program • Logically, each field is evaluated concurrently, by a separate process and then placed into tuple space

28. Overview of JavaSpaces

29. Mapping Linda to JavaSpaces • JavaSpace = Tuple Space • entry = tuple • write = out • take = in • read = rd

30. Differences between Linda and JavaSpaces • Entries in Java are typed as objects • associates behavior with entries • JavaSpaces allows matching of subtypes • result of having typed entries • Fields in an entry are objects in Java • systems built with this are object-oriented

31. Differences • Support for multiple JavaSpaces • transactions can span multiple threads and spaces • Leasing • frees system from garbage left behind from crashes • JavaSpaces does not provide eval

32. JavaSpaces Design Goals • Provide a simple platform for designing and implementing distributed systems • Thin clients • simple • quick to download • run on limited local memory

33. JavaSpaces Design Goals • Variety of server implementations • relational databases • object oriented databases • It should be possible to create a replicated JavaSpaces service

34. Requirements for Application Clients • Must be possible to write a 100% Pure Java client • Clients implementation must be independent of the implementation details of the Server

35. Key features of JavaSpaces • Spaces are shared • handles the details of concurrent access • Spaces are persistent • objects can outlive the processes that created them • Spaces are associative • associative lookup is used to locate objects • this is based on content and not memory location

36. Key features • Spaces are transactionally secure • transaction model ensures that an operation on a space is atomic • supported for one or more spaces • Spaces allow us to exchange executable content • objects are passive in the space( immutable ) • when removed we can change their attributes and invoke methods on them

37. Entry • Collection of typed objects package net.jini.core.entry; public interface Entry extends java.io.Serializable { // this interface is empty }

38. Example Entry import net.jini.core.entry.*; public class SpaceShip implements Entry { public Integer score; public String name; public MessageEntry() { } public SpaceShip( String n, int s ) { score = s; name = n; } }

39. JavaSpace Interface • All of the operations have to be invoked on an object that implements the JavaSpace interface • Not a remote interface • Exports objects that implement the JavaSpace interface locally on the client

40. JavaSpace Interface package net.jini.space; <import statements> public interface JavaSpace { public final long NO_WAIT = 0; Lease write( Entry e, Transaction txn, long lease ) Entry read( Entry tmpl, Transaction txn, long timeout ) Entry take( Entry tmpl, Transaction txn, long timeout ) EventRegistration notify( Entry tmpl, Transaction txn, RemoteEventListener listener, long lease, MarshalledObject handback ) }

41. Accessing a JavaSpace • Space might be registered as a Jini lookup service • Space might register with an RMI registry

42. Operations • Write • Read • Take • Notify

43. write • Write the given entry into this JavaSpaces service public void writeShip( SpaceShip ship ) { try { space.write( ship, null, Lease.FOREVER ); } catch( Exception e ) { e.printStackTrace(); } }

44. read and readIfExists • Read an entry from the JavaSpaces service that matches the given template • Passing a null reference for the template will match any Entry • Multiple read requests may return different Entry objects even if no changes are made to the space in between each

45. read and readIfExists public int getScore( String name ) { SpaceShip template = new SpaceShip(); template.name = name; try { SpaceShip ship = (SpaceShip)space.read( template, null, Long.Max_VALUE ); return ship.score.intValue(); } catch( Exception e ) { e.printStackTrace(); return -1; } }

46. Silly Sample public static void main( String args[] ) { JavaSpace space = SpaceAccessor.getSpace(); SpaceGame game = new SpaceGame( space ); // create an entry SpaceShip enterprise = new SpaceShip( “enterprise”, 10 ); // demonstrate read and write game.writeShip( enterprise ); System.out.println(enterprise.name + “ written into space”); System.out.println(“The “ + enterprise.name + “’s score is “ + game.getScore(“enterprise”) ); }

47. take and takeIfExists • Same as Read operations, except that the entry is removed from the space • Will never return copies of the same Entry

48. take and Exceptions • RemoteException - may or may not have been successful • UnusableEntryException - removes the unusable entry from the space • Any other exception - take did not occur and no entry was removed from the space

49. notify • Notify a specific object when entries that match the given template are written into this JavaSpaces service • A lease time is given which is how long you want the registration to be remembered by the server

50. Events in Java • Event Source • Event Object • Event Listener