1. Distributed Systems
Session 4: RPCs (Remote Method Invocation) Java RMI.
Christos Kloukinas
Dept. of Computing
City University London
Last session we have investigated different communication primitives that are extensively used in distributed systems.
This session we shall compare two different infrastructures for constructing distributed systems. The purpose of these infrastructures is to raise the level of abstraction application programmers have to worry about to the ISO/OSI application layer. The infrastructures we are going to compare are remote procedure calls (RPCs) and OMG/CORBA. This comparison will provide guidelines for the selection of an infrastructure when a distributed system has to be constructed.
RPCs were developed by Sun Microsystems in the early 80s as part of their SunOS operating systems. They were included in what was called at that time the Open Network Computing Architecture (ONC). Many other vendors of UNIX workstations have taken Sun´s ideas and developed their own RPC products. The result was quite a substantial heterogeneity and lack of interoperability between the different systems. The Open Software Foundation has remedied the problem by standardising RPCs within their Distributed Computing Environment (DCE), which is at the moment heavily used in industry to build distributed systems. With the wide spread of Java, Sun added RMI(remote method invocation) which is orthogonal to RPC.
CORBA has been devel oped in the early 90s by the Object Management Group with the vision of using object technology to achieve heterogeneous and distributed also on other platforms than UNIX workstations. The OMG has learned the lessons from the OSFand thus CORBA can be considered as a second generation distributed computing infrastructure.

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 API=SEND & 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 RMI:The 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 platform’s 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++)
High-level primitive for object communication (not just UDP datagrams and TCP streams).
RMI is defined in such a way that can be 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 an homogeneous represetation of data across all hardware and OS platforms.
Java/RMI does not support RMI between Java objects and object written in another OO programming language. Both client and server objects are written in Java and execute in a Java VM.

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.
In the conceptual framework that we use for the comparison of the two infrastructures we first take an architectural perspective. This will identify the different modules that are involved in a distributed system based on the respective infrastructure.
This architectural perspective then enables us to consider the way how the different modules of the architecture are derived and how they interface with modules that are coded by the application developer.
We then review how the infrastructures interface to implementations of lower layers of the ISO/OSI reference model.
We then review how the different infrastructures support the identification of distributed components. A major criterion here is how the infrastructures achieve location transparency.
After that we discuss the primitives that are available in the infrastructure for the invocation of services that are offered by remote components.
Finally, we consider what can go wrong during the invocation of a service and review how the infrastructures cope with these 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)
In the remainder of this lecturer we will consider Java RMI as an instance of the RPC concept. The main difference between RPC and RMI is that RPC is geared towards C and C++, where RMI comes with JAVA. Furthermore, RPC uses an interface definition language (similar to CORBA IDL) which is compiled to C code, whereas RMI is part of Java and compilation just creates additional classes needed.
RMI Objectives:
Support seamless remote invocation on objects in different virtual machines.
Support callbacks from servers to applets. Client programs often react to changes or updates that occur in a server. For example, a client graph or spreadsheet program might need to be updated with each stock price update on a stock market server. The client has two options in this scenario: (1) periodically ask for the stock price via a method request on the stock server or (2) ask to be notified by the server whenever a price change occurs. The second option is referred to as a "callback".
Integrate the distributed object model into the Java language in a natural way while retaining most of the Java language's object semantics.
Make differences between the distributed object model and local Java object model apparent.
Make writing reliable distributed applications as simple as possible.
Preserve the safety provided by the Java runtime environment.
Several invocation mechanisms; for example simple invocation to a single object or invocation to an object replicated at multiple locations. The system should also be extensible to other invocation paradigms.
Various reference semantics for remote objects; for example live (non-persistent) references, persistent references, and lazy activation.
The safe Java environment provided by security managers and class loaders.
Distributed garbage collection of active objects.
For details of RPC see [CDK] Chapter 5.

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
Locate remote objects
App can register its remote objects with RMI naming facility, the rmiregistry
OR the application can pass and return remote object references as part of its normal operation
Communicate with remote objects
Details of communication handled by RMI. To programmer remote communication looks like standard invocation
Load class bytecodes for objects that are passed as parameters or return values
Because RMI allows a caller to pass objects to remote objects, RMI provides the necessary mechanisms for loading an object’s code as well as transmitting data.

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.
The instantiation of this conceptual framework for Remote Method Invocation is sketched by the outline of the second part of this session.
We are going to give an overview of the RMI architecture that displays the various modules that are involved in handling a remote method invocation. We will see that two important modules are the client and the server stub.
In RPC, these stubs are generated from a higher-level definition that is written in the Remote Procedure Call Language (RPCL). The stubs use at a lower level an interface to TCP or UDP which is called the RPC interface.
In RMI, there is no need for an additional language. The necessary stubs are generated from the programmer’s Java code.
We are then going to review how an RMI client identifies a server in a network. A technique called binding is used for that.
We are then going to review how remote method invocations are handled. This will reveal that the synchronisation is identical to those of local method invocation. In addition, we discuss strategies for handling multiple concurrent invocations and availability of servers.
A major difference between local and remote procedure calls is the number of failures that may occur. We shall see how clients are informed about failures if they are detected during an invocation of an RMI.

18. 2.1 RMI Architecture Client Server Network Remote Object Method
Local Call
Server
Stub
Server
Skeleton
RMI
Interface
RMI
Interface
There are usually three processes involved in an RMI. The client process invokes the procedure from the server process. In order to contact a server process the client first talks to a network process which looks for the server process and establishes the connection.
The RMI call at the client side is implemented by invoking a client stub, which is a proxy for the remote method in the client process, through a local method call.
The client stub marshals/unmarshals the parameters using JAVA serialisation
The RMI interface sends the call using HTTP’s POST method, (the use of HTTP enables RMI to HTTP-tunnel firewalls. For details seehttp://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmiTOC.html) and receives the reply.
In contrast to RPC which uses XDR, the external data representation, RMI uses the JAVA data representation given by the serialisation.
Thus, the stub invokes operations from the RMI interface, a lower level interface using HTTP to send and receive messages on the basis of TCP.
On the server side, the RMI interface receives a message (In case of a firewall, this messages was forwarded by a CGI script). The server stub unmarshals parameters and invokes the RMI implementation, which has to be provided by the application developer.
The client/server stubs are generated by a compiler (rmic) from the JAVA source code.
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 don’t apply then it’s 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 doesn’t even need the class file on its system.
The design of an RMI remote object must include an interface that extends 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 stub.
The client never instantiates the remote object itself, and in fact doesn’t even need the class file on its system. The client thinks it has the real object because it has an object that implements its interface.

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 object’s 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.
By eliminating the method bodies from the class that the client possesses, you can prevent someone from unpacking the class file, decompiling it and potentially revealing secrets about the back end that would allow someone to circumvent otherwise robust security.
The interface is significantly smaller than the actual remote object’s class, so the client is lighter in weight.
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.
Clients that make use of remote objects are only different in that they get the instances of remote objects. Instead of creating them with the new keyword, the client makes a call to the static lookup() method of the Naming class. However, they don’t actually return the object, 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, it can make calls on it as if it were 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 stub’s major functionality is serializing objects between the client and server over the RMI port, i.e Marshalling and unmarshalling
The client needs more than just the interface to call the methods on the remote object.
The client doesn’t actually get the remote object from the naming service, it gets a stub. The stub performs the duties of proxy for the remote object, so it implements all of the methods of its interface. And since an interface is likened to a contract, the stub is guaranteeing that it will provide the same services as the remote object would if it were local.
The stub’s major functionality is serializing objects between the client and server over the RMI port. For each method of the interface which it implements, the stub obtains an output stream to the RMI server, serializes the parameters, invokes the remote method, gets and input stream and reads the result.
When Stub’s method is invoked, it does the following
initiates a connection with the remote JVM containing the remote object
marshals ( writes and transmits) the parameters to the remote JVM
Waits for the results of the method invocation
unmarshals (reads) the return value or exception returned
returns the value to the caller

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.
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 containing a reference to the remote object, a method id, a Remote­Call object representing the connection and a hash code used to verify that the skeleton and the stub match. It is imperative that these two classes match perfectly in order for the RMI connection to work at all.
When skeleton receives an incoming method invocation, it does the following
Unmarshals (reads) the parameters for the remote method
invokes the method on the actual remote object implementation and
marshals (writes and transmits) the results (return value or exception) to caller

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.
In order to make the remote object available, an RMI server must be present and running on the network with an instance of that class in its registry.
Only two things need to be done here. The first is to start the RMI service. This is done by calling the static method createRegistry() on Locate­Registry and passing it the port number.
The second thing is to bind an instance of the remote object to the naming service, giving it an alias in the process. The instance your server creates here will be the actual object that gets remotely called

27. Implementation
Hello World Program

28. 3.0 How to Write RMI Applications1
Client
Define your remote interface
Server 2
Implement the interface
(.java) 3
javac
(.class)
Server class
(.class) 4
uses 8
rmic
Client Stub
(.class)
Implement Client
Server skeleton
(.class)
To write an RMI application proceed as follows:
Define a remote interface by extending java.rmi.Remote and have methods throw java.rmi.RemoteException
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
Compile the server class using javac
Run the stub compiler rmic. It generates the server skeleton and the client stub. (rmic knows the same parameters as javac, e.g. -d for the target directory)
Start the RMI registry on your server (call rmiregistry &). The registry retrieves and registers server objects. In contrast to CORBA it is not persistent.
Start the server object and register it with the registry using the bind method in java.rmi.Naming
Write the client code using java.rmi.Naming to locate the server objects.
Compile the client code using javac
Start the client
Run the Stub Compiler
(.java)
javac 9
Start RMI registry 5
(.class) 7
Start client 6
Register remote
objects
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 object: public interface Hello extends java.rmi.Remote {String sayHello() throws java.rmi.RemoteException; }
Implementation of server (declaration): import java.rmi.*; import java.rmi.server.UnicastRemoteObject; public class HelloImpl extends UnicastRemoteObject implements Hello { private String name; ...
RemoteException are for exceptions specific to remote objects (broken connection, a reference mismatch, e.g.)
The Remote interface embraces all remote objects
The RemoteObject class corresponds to Java’s 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)
UnicastRemoteObject 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-base protocol
parameters, invocations etc. are communicated via streams

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 Java’s 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
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 = s;} public String sayHello() throws RemoteException {return "Hello World!";} public static void main(String args[]){ System.setSecurityManager(new RMISecurityManager()); try { HelloImpl obj = new HelloImpl("HelloServer"); Naming.rebind("//myhost/HelloServer",obj); } catch (Exception e) {…}
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://host:port/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.
Instead of myhost, if you’re running both the client and the server on the same host you can use “localhost”.
Alternatively, you can execute the server in unix thus: java helloSrv `hostname` <- note the backquotes (NOT single quotes!!!)
“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://host:port/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 = null; Hello myHello = null; System.setSecurityManager( new RMISecurityManager()); try { remoteHello = Naming.lookup("//myhost/HelloServer"); myHello = (Hello) remoteHello; }…
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

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.
The RMI interface is used by client programs, procedure implementations in servers, as well as client and server stubs.
The client uses the RMI interface during startup to locate a server and to choose a transport protocol.
The server may use the RMI interface for security and authentication purposes.
A client can also use the RMI interface to dynamically invoke a remote methods.
The client/server stubs use the RMI interface to send and receive messages through the transport protocol.
In order to do so, the RMI interface provides facilities for generating unique message identifiers.
These are required to maintain a message history, i.e to keep track of which messages have been sent successfully and for which messages an answer is still to be expected.

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).
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 slide 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.
Java provides limited support for dynamical server location with the LocateRegistry class: This class is used to obtain the bootstrap Registry on a particular host (including your local host). The following example demonstrates usage (minus exception handling): Server wishes to make itself available to others: SomeService 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"); SomeService service = (SomeService)registry.lookup("I Serve"); service.requestService(...);
Programs can then easily be migrated from one server to another and be replicated over multiple hosts with full transparency for clients.

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)
Remote procedure calls are handled synchronously, i.e. the client stub does not return until it has received the result from the server stub or an indication for a failure. Hence, from a client's perspective remote procedure calls are synchronised in the same way as local procedure calls.
Different clients may invoke a remote procedure at the same time. A question is how the server reacts to this.
A server may queue requests and execute them one after another in a serialised manner or
A server may spawn processes or threads for each separate request.
It is application dependent which of these two approaches is most appropriate and therefore cannot be decided in general.
Another design choice is whether a remote procedure program is always available or has to be started on demand.
In contrast to RPC and CORBA, the JAVA registry is not persistent and therefore can only run continuously.
For startup on demand the RPC server is started by the inet daemon as

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!
Quite a number of things can go wrong during the invocation a remote method. Request messages can be lost, reply messages can be lost, the server may fail during the execution or the client may fail while it is waiting for the remote procedure call to return.
The semantics that RMIs usually have is at most once. This means that the remote method is invoked and in case of a failure the requester is notified of the failure. Note that with respect to failures remote method invocations are totally different from local method calls.
While RPC returns only values and “codes” a failure into returning a null pointer, RMI uses exceptions which give more information about the nature of the failure.
RPC’s coding of failures into the return value, leads to a maybe semantics if the client does not evaluate the return value. Hence failure transparency is not achieved by remote procedure calls. To this extent RMI is better since an exception is raised, but it still depends on the client to achieve failure transparency

43. Summary 1
The client process’s 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. RMI = Sockets + Object Serialization + Some Utilities
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/ /
Tutorials at //engronline.ee.memphis.edu/advjava/online.htm
short tutorial at //
Next Session:
CORBA & COMPARISON WITH RMI