Distributed Systems

1
Distributed Systems

• Session 4 RPCs (Remote Method Invocation) Java
  RMI.
• Christos Kloukinas
• Dept. of Computing
• City University London

2
Outline

• Motivation and Introduction to Java RMI
• Conceptual Framework
• RMI Details
• Example Implementation
• Summary

3
0 Motivation

• DS require computations running in different
  address spaces (different hosts) to communicate
• For basic communication Java Supports sockets
  Sockets APISEND RECV CALLS
• Sockets require Client Server engage in
  application level protocols to encode and decode
  messages for exchange
• Design of such protocols is cumbersome and error
  prone
• Alternative is Remote Procedure Call (RPC) (think
  of sin(), log(), static methods)

4
0.1 RPC

• RPC abstracts the communication interface to the
  level of procedure call i.e provides procedural
  interface to distributed (remote) services
• Instead of working directly with socket,
  programmer has illusion of calling a local proc.
  (transparency)
• BUT in reality arguments of the call are
  packaged and shipped to remote target of call
  (marshalling)
• RPC systems encode arguments and return values
  using an external representation such as XDR

5
0.2 RPC to RMI

• RPC does not translate well into distributed
  object systems (DOS)
• Communication between program-level objects
  residing in different address spaces is required
• To match the semantics of object invocation, DOS
  require remote method invocation or RMI
• Here, a local surrogate(stub) object manages
  invocation on remote object
• RPC Object Orientation

6
0.3 Middleware Layers
Application and services
RMI and RPC
Request-Reply protocol Marshalling and external
data Representation
Middleware layers
TCP and UDP
7
0.3 Java RMIThe Essence

• RMI provide you with an object Oriented mechanism
  to invoke a method on an object that exist
  somewhere else.
• Java RMI system assumes the homogeneous
  environment of the java virtual machines (JVM)
• therefore it takes advantage of the java
  platforms object model whenever possible.

8
0.4 Java

• Java is an object-oriented programming language
  developed by Sun Microsystems that is both
  compiled and interpreted A Java compiler creates
  byte-code, which is interpreted by a virtual
  machine (VM).
• Java is portable Different VMs interpret the
  byte-code on different hardware and operating
  system platforms.

9
0.5 RMI Rationale

• High-level primitive for object communication
  (not just UDP datagrams and TCP streams).
• RMI is tightly integrated with the rest of Java
  language specification, development environment
  and the Java VM.
• Reliance on Java VMs for the resolution of
  heterogeneity. RMIs can assume a homogeneous
  representation
• Java/RMI does not support RMI between Java
  objects and objects written in another OO
  language (unless you use the native interface for
  C/C)

10
0.6 Client-Service

• Before getting into the details, we should
  examine what an RMI system looks like in
  comparison to a standard strong-referenced object
  relationship.
• In a standard instantiate-and-invoke
  relationship, there are only the Client and
  Service objects.
• They both live in the same virtual machine.
• Method invocations are made directly on the
  Service object.

11
0.7 Client-Service
12
0.8 RMI

• In RMI, the Client object does not directly
  instantiate the Service,
• BUT gets a reference to its interface through the
  RMI Naming service.
• This interface hooks up the client system to the
  server through a series of layers and proxies
  until it reaches the actual methods provided by
  the Service object.

13
0.9 Remote Method Invocation
14
1.0 Conceptual Framework Aspects

• Architecture.
• Accessing components from programming languages.
• Interfaces to lower layers.
• Component identification.
• Service invocation styles.
• Handling of failures.

15
1.1 System Goals of RMI

• Seamless integration of objects on different VMs.
  
• Support callbacks from servers to applets.
• Distributed object model for Java
• Security, write once run everywhere,
  multithreaded
• Object Orientation
• Simplicity (learning curve)
• Safety (maintain Java standards)
• Flexibility (several invocation mechanisms and
  various reference semantics, distributed garbage
  collection)

16
Distributed Object Application Requirements

• Locate remote objects
• App can register its remote objects with RMI
  naming facility, the rmiregistry
• Communicate with remote objects
• Details of communication handled by
  RMI.(Transparency)
• Load class bytecodes for objects that are passed
  as parameters or return values
• RMI provides class loading

17
2.0 Remote Method Invocation

• Overview of RMI architecture.
• Generation of client/server stubs.
• RMI interface.
• Binding.
• Handling of remote methods.
• Failures of RMIs.

18
2.1 RMI Architecture
Client
Server
Local Call
send
receive
send
receive
Network
19
2.2 RMI Components

• Remote Object
• Interfaces
• Client
• Server
• Stub
• Skeleton

20
2.31 The Remote Object

• Remote object is a class that is designed to
  execute on a server but be treated by the client
  as if it were local.
• There are several reasons why you would want to
  implement a class as a remote object
• the object will run faster, security and
  proximity to necessary resources than it would on
  the client.
• If the above reasons dont apply then its
  probably not a good idea to implement a class as
  a remote object.

21
2.32 The interface

• An RMI remote object must extend java.rmi.Remote.
  When deploying the remote object, a stub is
  created that implements the same interface.
• The major purpose of the interface is to provide
  the template that is used by both the remote
  object and its stubs.
• The client never instantiates the remote object
  itself, and in fact doesnt even need the class
  file on its system.

22
2.33 The Interface Advantages

• There are several advantages to using an
  interface that makes RMI a more robust platform.
• Security by preventing decompiling
• The interface is significantly smaller than the
  actual remote objects class, so the client is
  lighter in weight.
• Maintainability If changes are made to the
  underlying remote object, it would need to be
  propagated to the clients, otherwise serious
  errors can occur.
• From an architectural standpoint, the interface
  is cleaner. The code in the remote object will
  never run on the client, and the interface acts
  appropriately as a contract between the caller
  and the class performing the work remotely.

23
2.34 The Client

• Users of remote objects .
• Use Naming Class to lookup() objects instead of
  creating them with the new keyword.
• However, the remote object is NOT returned, only
  a stub which happens to implement the same
  interface of the remote object.
• Once the client has an object which implements
  the remote object interface, it can make calls on
  it as if it was the real object.

24
2.35 The stub

• The client needs more than just the interface to
  call the methods on the remote object.
• Proxy for the remote object, obtained via naming
  service
• Implements all of the methods of its interface.
• The stubs major functionality is serializing
  objects between the client and server over the
  RMI port, i.e Marshalling and unmarshalling

25
2.36 The Skeleton

• On the other side of the connection is a skeleton
  of the remote object, as well as the remote
  object itself.
• When the server starts, it creates an instance of
  the remote object and waits for invocations.
• Each time a method is called on the stub from the
  client, the skeleton object receives a dispatch
  from the server .
• The Skeleton is responsible for dispatching the
  call to the actual object implementation.

26
2.37 The Server

• RMI server must be present and running on the
  network.
• Create with an instance of class that implement
  remote interface. I.e creates remote objects
• Can be used to start the RMI naming service.
• Binds an instance of the remote object to the
  naming service, giving it an alias in the
  process.

27
Implementation

• Hello World Program

28
3.0 How to Write RMI Applications
Client
1
Define yourremote interface
Server
2
Implement theinterface
(.java)
javac
3
(.class)
Server class (.class)
uses
8
4
rmic
Client Stub (.class)
Implement Client
Server skeleton (.class)
Run the Stub Compiler
(.java)
javac
9
Start RMI registry
5
(.class)
Start client
7


Register remote objects
6
Start Server objects
10
Client
29
3.0 How to write an RMI application

• To write an RMI application proceed as follows
• 1) Define a remote interface (Server Services) by
  extending java.rmi.Remote and have methods throw
  java.rmi.RemoteException
• 2) Implement the remote interface. You must
  provide a Java server class that implements the
  interface. It must be derived from the class
  java.rmi.UnicastRemoteObject
• 3) Compile the server class using javac
• 4) Run the stub compiler rmic. Run rmic against
  your (.class) file to generate client stubs and
  server skeletons for your remote classes.
  (REMEMBER proxies for marshalling
  unmarshalling)
• 5) Start the RMI registry on your server (call
  rmiregistry ). The registry retrieves and
  registers server objects. In contrast to CORBA it
  is not persistent.
• 6) Start the server object and register it with
  the registry using the bind method in
  java.rmi.Naming
• 7) Write the client code using java.rmi.Naming to
  locate the server objects.
• 8) Compile the client code using javac
• 9) Start the client

30
3.1 Implementing RMI

• Interface for remote objectpublic interface
  Hello extends java.rmi.Remote String sayHello()
  throws java.rmi.RemoteException
• Implementation of server (declaration)import
  java.rmi.import java.rmi.server.UnicastRemoteOb
  jectpublic class HelloImpl extends
  UnicastRemoteObject implements Hello private
  String name...

31
3.2 Implementing RMI RMI Core

• RemoteException superclass for exceptions
  specific to remote objects thrown by RMI runtime
  (broken connection, a reference mismatch, e.g.)
• The Remote interface embraces all remote objects
  (Does not define methods, but serves to flag
  remote objects)
• The RemoteObject class corresponds to Javas
  Object class. It implements remote versions of
  methods such as hashCode, equals, toString
• The class RemoteServer provides methods for
  creating and exporting servers (e.g.
  getClientHost, getLog), I.e. common superclass to
  server implementations and provides the framework
  to support a wide range of remote reference
  semantics.
• UnicastRemoteObject Your server must either
  directly inherit or indirectly extend the class
  and inherit its remote behaviour implements a
  special server with the following
  characteristics
• all references to remote objects are only valid
  during the life of the process which created the
  remote object
• it requires a TCP connection-based protocol
• parameters, invocations etc. are communicated via
  streams

32
3.3 Interfaces and Classes
Classes
Interfaces
Remote
RemoteObject
IOException
RemoteServer
RemoteException
UnicastRemoteObject
Activatable
extension
implementation
33
3.4 Implementing RMI (Server)

• Impl. of server (constructor, method,
  main)public HelloImpl(String s)throws
  RemoteException super() name spublic
  String sayHello() throws RemoteException return
  "Hello World!"public static void main(String
  args)System.setSecurityManager(new RMISec
  urityManager())try HelloImpl obj new
  HelloImpl("HelloServer")
  Naming.rebind("//myhost/HelloServer",obj)
  catch (Exception e)

localhost or run Java like this java helloSrv
hostname
34
3.5 Implementing RMI (Server)

• The class Naming is the bootstrap mechanism for
  obtaining references to remote objects based on
  Uniform Resource Locator (URL) syntax. The URL
  for a remote object is specified using the usual
  host, port and name rmi//hostport/name host
  host name of registry (defaults to current
  host) port port number of registry (defaults
  to the registry port number) name name for
  remote object
• A registry exists on every node that allows RMI
  connections to servers on that node. The registry
  on a particular node contains a transient
  database that maps names to remote objects. When
  the node boots, the registry database is empty.
  The names stored in the registry are pure and are
  not parsed. A service storing itself in the
  registry may want to prefix its name of the
  service by a package name (although not
  required), to reduce name collisions in the
  registry.

35
3.6 Implementing RMI (Client)

• Remote remoteHello nullHello myHello
  nullSystem.setSecurityManager( new
  RMISecurityManager())try remoteHello
  Naming.lookup("//myhost/HelloServer") myHell
  o (Hello) remoteHello

36
3.7 Implementing RMI Summary

• To summarise the above example
• The server creates the server object and binds it
  to a name
• The client uses lookup to get an object reference
  and then has to perform a cast to turn a
  RemoteObject into an object of the proper type

37
4.0 RMI Interface

• Used by client or server directly
• Locating servers.
• Choosing a transport protocol.
• Authentication and security.
• Invoking RMIs dynamically.
• Used by stubs for
• Generating unique message IDs.
• Sending messages.
• Maintaining message history.

38
5.0 Binding

• How to locate an RMI server that can execute a
  given procedure in a network?
• Can be done
• statically (i.e. at compile-time) or
• dynamically (i.e. at run-time).

39
5.1 Binding

• A problem that arises is to locate that server in
  a network which supports the program with the
  desired remote procedures.
• This problem is referred to as binding.
• Binding can be done statically or dynamically.
  The binding we have seen in the last example was
  static because the hostname was determined at
  compile time.
• Static binding is fairly simple, but seriously
  limits migration and replication transparency.
• With dynamic binding the selection of the server
  is performed at run-time. This can be done in a
  way that migration and replication transparency
  is retained.

40
5.1 Binding

• Limited support for dynamical server location
  with the LocateRegistry class to obtain the
  bootstrap Registry on some host. Usage (minus
  exception handling)
• // Server wishes to make itself available to
  others SomeSRVC service ... // remote object
  for service Registry registry
  LocateRegistry.getRegistry() registry.bind("I
  Serve", service) // The client wishes to make
  requests of the above service Registry registry
  LocateRegistry.getRegistry("foo.services.com")
  SomeSRVC service (SomeSRVC)registry.lookup("I
  Serve") service.requestService(...)
• Programs can be easily migrated from one server
  to another and be replicated over multiple hosts
  with full transparency for clients.

41
6.0 Handling of Remote Methods

• Call handled synchronously by server.
• Concurrent RMIs
• serial or
• concurrently.
• Server availability
• continuous or
• on-demand.
• (RMI CORBA support both)

42
7.0 Failures of RMIs

• Machines or networks can fail at any time.
• At most once semantics.
• RMI return value indicates success.
• Up to the client to avoid maybe semantics!

43
Summary 1

• The client processs role is to invoke the method
  on a remote object. The only two things that are
  necessary for this to happen are the remote
  interface and stub classes.
• The server, which owns the remote object in its
  address space, requires all parts of the RMI
  interchange.
• When the client wants to invoke a method on a
  remote object, it is given a surrogate that
  implements the same interface, the stub. The
  client gets this stub from the RMI server as a
  serialized object and reconstitutes it using the
  local copy of that class.

44
Summary 2

• The third part of the system is the object
  registry. When you register objects with the
  registry, clients are able to obtain access to it
  and invoke its methods.
• The purpose of the stub on the client is to
  communicate via serialized objects with the
  registry on the server. It becomes the proxy for
  communication back to the server.

45
Summary

• The critical parts of a basic RMI system include
  the client, server, RMI registry, remote object
  and its matching stub, skeleton and interface.
• A remote object must have an interface to
  represent it on the client, since it will
  actually only exist on the server. A stub which
  implements the same interface acts as a proxy for
  the remote object.
• The server is responsible for making its remote
  objects available to clients by instantiating and
  registering them with Naming service.

46
Critique
The Remote Method Invocation (RMI) is a Java
system that can be used to easily develop
distributed object-based applications. RMI, which
makes extensive use of object serialization, can
be expressed by the following formula RMI
Sockets Object Serialization Some
Utilities The utilities are the RMI registry and
the compiler to generate stubs and skeletons. If
you are familiar with RMI, you would know that
developing distributed object-based applications
in RMI is much simpler than using sockets. So
why bother with sockets and object serialization
then?
47
Critique

• The advantages of RMI in comparison with sockets
  are
• Simplicity RMI is much easier to work with than
  sockets
• No protocol design unlike sockets, when working
  with RMI there is no need to worry about
  designing a protocol between the client and
  server -- a process that is error-prone.
• The simplicity of RMI, however, comes at the
  expense of the network.
• There is a communication overhead involved when
  using RMI and that is due to the RMI registry and
  client stubs or proxies that make remote
  invocations transparent. For each RMI remote
  object there is a need for a proxy, which slows
  the performance down.

48
Online Resources Reading

• Chapter 4 of Course textbook
• Chapter 5 of Coulouris Dollimore
• Examples at //web.archive.org/web/20031220223738/h
  ttp//www.churchillobjects.com/c/11086.html
• Tutorials at //engronline.ee.memphis.edu/advjava/o
  nline.htm
• short tutorial at //www.eg.bucknell.edu/cs379/Dis
  tributedSystems/rmi_tut.html
• Next Session
• CORBA COMPARISON WITH RMI