Remote Method Invocation

1
Remote Method Invocation

• CMT3332
• Lecture 8

2
Message Passing Paradigm

• The message-passing paradigm is a natural model
  for distributed computing, in the sense that it
  mimics inter-human communications.
• It is an appropriate paradigm for network
  services where processes interact with each other
  through the exchanges of messages.
• However, the abstraction provided by this
  paradigm does not meet the needs of the
  complexity of sophisticated network applications.
  

3
Message Passing Paradigm (cont'd)

• Message passing requires the participating
  processes to be tightly-coupled
• throughout their interaction, the processes must
  be in direct communication with each other.
• If communication is lost between the processes,
  the collaboration fails.
• The message-passing paradigm is data-oriented.
• Each message contains data marshaled in a
  mutually agreed upon format
• Messages are interpreted as requests or responses
  according to the protocol.
• The receiving of each message triggers an action
  in the receiving process.
• It is inadequate for complex applications
  involving a large mix of requests and responses.
  
• In such an application, the task of interpreting
  the messages can become overwhelming.

4
Distributed Object Paradigm

• The distributed object paradigm is a paradigm
  that is based on objects in a distributed system.
  
• In object-oriented programming environment (e.g.
  using Java), objects are used to represent an
  entity significant to an application. Each
  object encapsulates
• The state or data of the entity In Java, such
  data is contained in the instance variables of
  each object
• The operations of the entity, through which the
  state of the entity can be accessed or updated.

5
Distributed Object Paradigm (cont'd)

• In a distributed object paradigm, network
  resources are represented by distributed objects.
  
• A distributed object is one whose methods can be
  invoked by a remote process
• To request service from a network resource, a
  process invokes one of its methods, passing data
  as parameters to the method.
• The method is executed on the remote host, and
  the response is sent back to the requesting
  process as a return value.
• The distributed objects paradigm is
  action-oriented
• the focus is on the invocation of the operations,
  while the data passed takes on a secondary role.

6
Distributed Object Paradigm (cont'd)
7
The Distributed Object Paradigm

• A process running in host A makes a method call
  to a distributed object residing on host B,
  passing with the call data for the parameters, if
  any.
• The method call invokes an action performed by
  the method on host B, and a return value, if any,
  is passed from host B to host A.
• A process which makes use of a distributed object
  is said to be a client process of that object,
  and the methods of the object are called remote
  methods to the client process.

8
An Archetypal Distributed Objects System
9
Distributed Object System

• A distributed object is provided by a process
  called the object server.
• A facility, called an object registry, must be
  present in the system architecture for the
  distributed object to be registered.
• To access a distributed object, an object client
  looks up the object registry for a reference to
  the object. This reference is used by the object
  client to make calls to the methods.

10
Distributed Object System (cont'd)

• Logically, the object client makes a call
  directly to a remote method.
• In reality, the call is handled by a client
  proxy, which interacts the software on the client
  host that provides the runtime support for the
  distributed object system.
• The runtime support is responsible for the
  interprocess communication needed to transmit the
  call to the remote host, including the
  marshalling of the argument data that needs to be
  transmitted to the remote object.

11
Distributed Object System (cont'd)

• A similar architecture is required on the server
  side, where the runtime support for the
  distributed object system handles the receiving
  of messages and the unmarshalling of data, and
  forwards the call to a server proxy.
• The server proxy interfaces with the distributed
  object to invoke the method call locally, passing
  in the unmarshalled data for the arguments.
• The method call results in the performance of
  some tasks on the server host.
• The outcome of the execution of the method,
  including the marshalled data for the return
  value, is forwarded to the client proxy by the
  server proxy, via the runtime support and network
  support on both sides.

12
Distributed Object Protocols

• The distributed object paradigm has been widely
  adopted in distributed applications. The most
  well known distributed object mechanisms are
• Java Remote Method Invocation (RMI),
• The Common Object Request Broker Architecture
  (CORBA) systems,
• Enterprise Java Beans (EJB),
• The Distributed Component Object Model (DCOM),
• Mechanisms that support the Simple Object Access
  Protocol (SOAP).
• Of these, the most straightforward is the Java
  RMI

13
Remote Procedure Calls (RPC)

• Remote Method Invocation has its origin in a
  paradigm called Remote Procedure Call (RPC)
• In RPC, a procedure call is made by one process
  to another, with data passed as arguments.
• Upon receiving a call, the actions encoded in the
  procedure are executed, and the caller is
  notified of the completion of the call.
• A return value, if any, is then transmitted from
  the callee to the caller.

14
(No Transcript)
15
Remote Method Invocation

• Remote Method Invocation (RMI) is an
  object-oriented implementation of the Remote
  Procedure Call model.
• Using RMI, an object server exports a remote
  object and registers it with a directory service.
  
• The object provides remote methods, which can be
  invoked in client programs.
• Syntactically
• A remote object is declared with a remote
  interface, an extension of the Java interface.
• The remote interface is implemented by the object
  server.
• An object client accesses the object by invoking
  the remote methods associated with the objects
  using syntax provided for remote method
  invocations.

16
The Java RMI Architecture
17
Object Registry

• The RMI API allows a number of directory services
  to be used for registering a distributed object.
• Example Java Naming and Directory Interface
  (JNDI)
• We will use a simple directory service called the
  RMI registry, rmiregistry, which is provided with
  the Java Software Development Kit (SDK).
• The RMI Registry is a service provided by a
  server that runs on the object servers host
  machine by default on the TCP port 1099.
• The port number can also be set manually

18
Interactions between Stub and Skeleton
Client Proxy
Server Proxy
Server Object
19
The API for the Java RMI

• The Remote Interface
• needs to import java.rmi package
• The Server-side Software
• The Remote Interface Implementation
• needs to import both java.rmi and java.rmi.server
  packages
• The Object Server
• needs to import java.rmi package
• may need to import java.rmi.registry package
• Stub and Skeleton Generations
• use rmic to generate the stub and skeleton
• The Client-side Software
• needs to import java.rmi package

20
The Remote Interface

• A remote interface is an interface that inherits
  from the Remote inteface, which allows the
  interface to be implemented using RMI syntax.
• A remote interface has the same syntax as a
  regular or local Java interface, except
• It extends the Remote interface
• All methods in a remote interface must throws
  java.rmi.RemoteException
• Here is a sample remote interface for RMI
  (Hello.java)
• import java.rmi.
• public interface Hello extends Remote
• String sayHello() throws RemoteException

21
RMI Remote Exception

• The java.rmi.RemoteException must be listed in
  the throws clause of each method signature.
• This exception is raised when errors occur during
  the processing of a remote method call, and the
  exception is required to be caught in the method
  callers program.
• Causes of such exceptions include exceptions that
  may occur during interprocess communications,
  such as access failures and connection failures,
  as well as problems unique to remote method
  invocations, including errors resulting from the
  object, the stub, or the skeleton not being found.

22
The Server-side Software

• An object server is an object that provides the
  methods of and the interface to a distributed
  object. Each object server must
• implement each of the remote methods specified in
  the interface,
• register an object which contains the
  implementation with a directory service.
• It is recommended that the two parts be provided
  as separate classes.

23
UML Diagrams for the Hello Application
24
Remote Interface Implementation

• The following shows a class which implements the
  remote interface should be provided. The syntax
  is similar to a class that implements a local
  interface.
• import java.rmi.
• import java.rmi.server.
• public class HelloImpl extends
  UnicastRemoteObject implements Hello
• public HelloImpl() throws RemoteException
• super()
• public String sayHello()
• return "Hello World!"

25
UML Diagram for HelloImpl
Hello (Interface)
sayHello
HelloImpl
sayHello
26
The Object Server

• The object server class is a class whose code
  instantiates and exports an object of the remote
  interface implementation.

27
Code for Object Server

• import java.rmi.
• import java.rmi.registry.
• public class HelloServer
• public static void main(String args)
• try
• // code for port number value to be supplied
• HelloImpl exportedObj new HelloImpl()
• int portNum Integer.parseInt(args0)
• startRegistry(portNum)
• // register the object under the name
  hello
• registryURL "rmi//localhost"
  portNum "/hello"
• Naming.rebind(registryURL, exportedObj)
• System.out.println("Hello Server
  ready.")
• // end try
• // end main

28
Code for Object Server (cont'd)

• // This method starts a RMI registry on the local
  host, if it
• // does not already exists at the specified port
  number.
• private static void startRegistry(int
  RMIPortNum) throws RemoteException
• try
• Registry registry LocateRegistry.getRegistry(
  RMIPortNum)
• registry.list()
• // The above call will throw an exception
• // if the registry does not already exist
• catch (RemoteException ex)
• // No valid registry at that port.
• System.out.println(
• "RMI registry cannot be located at port "
  RMIPortNum)
• Registry registry LocateRegistry.createR
  egistry(RMIPortNum)
• System.out.println(
• "RMI registry created at port "
  RMIPortNum)
• // end startRegistry

29
The Object Server

• In our object server, the code for exporting an
  object is as follows
• // register the object under the name hello
• registryURL "rmi//localhost" portNum
  "/hello"
• Naming.rebind(registryURL, exportedObj)
• The Naming class provides methods for storing and
  obtaining references from the registry.
• In particular, the rebind method allow an object
  reference to be stored in the registry with a URL
  in the form of
• rmi//lthost namegtltport numbergt/ltreference namegt
• port number in the URL is optional. If not
  provided, default port (1099) will be used
• The rebind method will overwrite any reference in
  the registry bound with the given reference name.
  
• If the overwriting is not desirable, there is
  also a bind method.
• The host name should be the name of the server
  (or localhost).
• The reference name is a name of your choice, and
  should be unique in the registry.

30
The RMI Registry

• A server, called the RMI Registry, is required to
  run on the host of the server which provides
  remote objects.
• The RMI Registry is a server located at port 1099
  by default
• It can be invoked dynamically in the server
  class
• import java.rmi.registry.LocateRegistry
• ...
• LocateRegistry.createRegistry ( 1099 )
• Alternatively, an RMI registry can be activated
  by hand using the rmiregistry utility which comes
  with the Java SDK
• rmiregistry ltport_numbergt
• If no port number is specified, port 1099 is used
  by default.
• The registry will run continuously until it is
  shut down (via CTRL-C, for example)

31
Execution of Object Server

• When an object server is executed, the exporting
  of the distributed object causes the server
  process to begin to listen and wait for clients
  to connect and request the service of the object.
  
• An RMI object server is a concurrent server each
  request from an object client is serviced using a
  separate thread of the server.
• If a client process invokes multiple remote
  method calls, these calls will be executed
  concurrently unless provisions are made in the
  client process to synchronize the calls.

32
Stub and Skeleton Generations

• In RMI, each distributed object requires a proxy
  each for the object server and the object client
• Server proxies are known as the skeletons
• Client proxies are known as the stubs
• These proxies are generated from the
  implementation of a remote interface using a tool
  provided with the Java SDK, the RMI compiler -
  rmic.
• For example rmic v1.2 SomeImpl
• As a result of the compilation, two proxy files
  will be generated, each prefixed with the
  implementation class name SomeImpl_skel.class
  and SomeImpl_stub.class.

33
Stub File for the Object

• The stub file for the object, as well as the
  remote interface file, must be shared with each
  object client these file are required for the
  client program to compile.
• A copy of each file may be provided to the object
  client by hand.
• In addition, the Java RMI has a feature called
  stub downloading which allows a stub file to be
  obtained by a client dynamically.

34
The Client-side Software

• The program for the client class is like any
  other Java class except that
• we will lookup for the remote object instead of
  creating a local object through the constructor
• The syntax needed for RMI involves
• locating the RMI Registry in the server host,
• looking up the remote reference for the server
  object the reference can then be cast to the
  remote interface class and the remote methods
  invoked.

35
Sample Code for Hello Client

• import java.rmi.
• public class HelloClient
• public static void main(String args)
• try
• String registryURL "rmi//localhost"
  portNum "/hello"
• Hello h (Hello) Naming.lookup(registryUR
  L)
• String message h.sayHello()
• System.out.println(message)
• // end try
• catch (Exception e)
• System.out.println("Exception in
  HelloClient " e)
• //end main
• // Definition for other methods of the class,
  if any.
• //end class
•  

36
Looking up the Remote Object

• The lookup method of the Naming class is used to
  retrieve the object reference previously stored
  in the registry by the object server.
• The retrieved reference must be cast to the
  remote interface Hello (not its implementation
  HelloImpl) class.
• String registryURL "rmi//localhost"
  portNum "/hello"
• Hello h (Hello)Naming.lookup(registryURL)

37
Invoking the Remote Method

• The remote interface reference can be used to
  invoke any of the methods in the remote
  interface,
• String message h.sayHello()
• System.out.println(message)
• Note that the syntax for the invocation of the
  remote methods is the same as for local methods.
• It is a common mistake to cast the object
  retrieved from the registry to the interface
  implementation class or the server object class.
  Instead it should be cast as the interface class.

38
Placement of Files for a RMI Application
39
Compilation and Execution

• Server Side
• Compile the Interface (Hello.java), Implmentation
  (HelloImpl.java) and the Server
  (HelloServer.java) classes
• Compile the implementation class with the rmic
  compiler (rmic v1.2 HelloImpl)
• Start the RMI registry (rmiregistry)
• Start the server (java HelloServer)
• Client Side
• Compile the Interface (Hello.java) and the Client
  (HelloClient.java) classes
• Place the skeleton class (HelloImpl_Stub.class)
  generated by rmic in the client side
• Start the client (java HelloClient)

40
Testing and Debugging an RMI Application

• Build a template for a minimal RMI program.
  Start with a remote interface with a single
  method, its implementation using a stub, a server
  program which exports the object, and a client
  program which invokes the remote method. Test
  the template programs on one host until the
  remote method can be made successfully.
• Add one signature at a time to the interface and
  the implementation. With each addition, modify
  the client program to invoke the added method.
  Fill in the definition of the added remote
  method. Test and thoroughly debug the newly added
  method before proceeding with the next one.
• After all remote methods have been thoroughly
  tested, develop the client application using an
  incremental approach. With each increment, test
  and debug the programs.

41
Using RMI Meaningfully

• In a realistic RMI application, multiple methods
  and objects will be employed.
• With such real-world application, there are two
  possible strategies that may be adopted
• Use a single instance of the implementation class
  to hold instance(s) of a class whose method are
  to be called remotely.
• Example A vector containing the accounts that to
  be used. The methods in account objects are
  called as if they are local objects
• Use the implementation class directly for storing
  required data and methods, creating instances of
  this class rather than using separate class(es)
• Individual objects are stored in the object
  server
• Client requests for the exact object they want to
  use

42
RMI Stub Downloading

• RMI is designed to allow stubs to be made
  available to the client dynamically. Doing so
  allows changes to be made in the remote methods
  without affecting the client program.
• The stub can be filed with an web server and be
  downloaded using HTTP.
• Security measures are needed to prevent both the
  client side and the server side
• A java security policy file needs to be set on
  the server host and also on the client host.
• A Java Security Manager should be instantiated in
  both the client and server programs.

43
Java RMI Client Server Interaction
44
Starting Object Server with Stud Download

• When starting the server, the java.rmi.server.code
  base property must be specified, so that the stub
  class can be dynamically downloaded to the
  registry and then to the client
• the codebase property to be the location of the
  implementation stubs
• There are four things that need to go on the same
  command line
• the "java" command
• followed by three property namevalue pairs for
  codebase, hostname and policy file
• and then the fully-qualified package name of the
  server program.
• java -Djava.rmi.server.codebasehttp//host/user/
  myclass/-Djava.rmi.server.hostnamelocalhost-Dja
  va.security.policy/myfolder/policyexamples.hello
  .HelloServer

45
java.policy File

• The RMI security manager does not permit network
  access. Exceptions can be made via the
  specification in java.policy file.
• grant
• // permits socket access to all common TCP ports,
• // including the default RMI registry port (1099)
  
• // need for both the client and the server.
• permission java.net.SocketPermission
  "1024-65535", "connect,accept,resolve"
• // permits socket access to port 80, the default
  HTTP
• // port needed by client to contact an HTTP
  server
• // for stub downloading
• permission java.net.SocketPermission "80",
  "connect"
• This file should be placed in the same directory
  as the server class as well the client class
• When starting the client, a java.policy file
  should also be specified
• java -Djava.security.policyjava.policy
  HelloClient

46
RMI File Placement with Stub Downloading
47
RMI Security Manager

• Since RMI involves access to/from a foreign host,
  and possibly object downloading, it is important
  for both the server and the client to protect its
  system from malicious access.
• The RMISecurityManager is a class provided Java,
  and can be instantiated in both the client and
  the server for limiting access priviledges.
• You can write your own security manager, if so
  desired.
• try
• System.setSecurityManager(new
  RMISecurityManager())
• catch

48
Comparison of the RMI and the Socket APIs

• The remote method invocation API is an efficient
  tool for building network applications. It can
  be used in lieu of the socket API in a network
  application.
• Some of the tradeoffs between the RMI API and the
  socket API are as follows
• The socket API is closely related to the
  operating system, and hence has less execution
  overhead. For applications which require high
  performance, this may be a consideration.
• The RMI API provides the abstraction which eases
  the task of software development. Programs
  developed with a higher level of abstraction are
  more comprehensible and hence easier to debug.