1. Changing the way of designing distributed applications
Communication oriented design: FIRST design the communication protocol for the distributed system and then the program is developed accordingly
Application oriented design: Develop the application as if everything were locally and then divide the application in modules which will run in remote machines
The first approach is harder to design but simpler to implement
The second one is better when there is a framework supporting the implementation of such

2. Alternative Technologies
Development of networks => development of distributed systems
Development of middleware (libraries, tools, etc..) supporting easy programming of distributed systems
Based on TCP/IP protocols
Higher level programming language for distributed systems
The distributed case is not a problem anymore

3. Remote Procedure Calls
Motivation: NFS development (SUN)
A client application can call a procedure (function) in a server application running on another computer as it were locally implemented
Handle over parameters, receiving results in an appropiate format (integer, string, float,..)
eXternal Data Representation

4. Remote Procedure Calls
The client stops until the procedure call returns
RPC Client
RPC Server
Call(parameters)
Receive results
Server framework: provided by the system

5. The Interface File
Specifies the protocol of the remote procedure: name, required parameters (number and type), result (type).
It is called the interface file because it holds the information the client needs to use
RPC Client
Interface definition file
RPC Server
Implements
interface
Uses Interface
for compiling

6. Remote Objects
This paradigm was rapidly replaced by the remote object paradigm
An application can invoke a method of an object located in another JVM
The interface file remains the key to describe the object protocol to the clients
RemoteObjectServer
Invoke method
Receive result

7. Files Involved Interface Define the methods (only the header)
Which will be able to called remotely
implements
Use for compiling
Obtain reference to remote object
Apply method as usually
Receive results as usually
Define a particular class for implementing remote objects and implements the interface
Create a remote-able object
Make it publicly available
Server program
Client program

8. An Example: Remote Date Server
The only method will be Date getDate(), the server will answer with the local Date
Remote Server
getDate()
getDate()
Tue Jun 12 17:20:24

9. The interface file It must import java.rmi.* It must extend Remote
import java.util.Date;
public interface RemoteDate extends Remote {
public Date getDate() throws RemoteException; }
It must import java.rmi.*
It must extend Remote
Every declared method should throw a RemoteException

10. Define a class for implementing remote date objects
RemoteObject
Remote Interface
Extends
Implements
Extends
The remote Object
Class definition
DateServer.java

11. The Client Program import java.rmi.*; import java.rmi.server.*;
import java.util.Date;
public class DateClient {
public static void main( String args[] ) {
try {
RemoteDate dateobj = (RemoteDate)Naming.lookup(
"rmi://"+args[0]+"/DateServer" );
Date datum = dateobj.getDate();
System.out.println( “Server Date : " + datum ); }
catch ( Exception e ){ System.out.println(e); }

12. The Stub and Skel Files
Communication is implemented by the stub and skel files
They are generated by compiling the class files of the remote object implementation with the rmic command
Remote Object
Server
Client
Stub
Skel

13. The name registry server
A server to register and make public remote objects
Server register the object by this server, clients ask this server for a reference to a certain object
It should run at the server‘s computer and have access (like any java program) to the stub file.
It must be started before the remote object is registered
rmiregistry
Client
Remote Object
Server

14. Which file where ? A client needs the stub file and the interface file
The server needs the Stub & Skel file
Client
Remote Object
Server
DateClient.class
RemoteDate.class
DateServer_stub.class
DateServer.class RemoteDate.class
DateServer_stub.class
DateServer_skel.class

15. How to generate stub & skel
The compiled implementation class should be compiled (again) with the rmic command
DateServer.java
RemoteDate.java
DateClient.java
javac
javac
DateServer.class
javac
RemoteDate.class
rmic
DateClient.class
DateServer_skel.class
DateServer_stub.class

16. Starting rmiregistry from program
It is possible to start a registry server from the program
A number server will illustrate this and the concurrency problem
Remote Number
Server
getNumber() 1 3 2
getNumber()
getNumber()
Client
Client
Client

17. The RMI-based Chat
The client must also receive messages from the server
It also implements a remote object, which is passed as parameter !!!
The server does not need to locate the client
Remote
Object Client
addClient(this)
Remote Object
Server
sendMessage(text)
newMessage(text)

18. A Remote file server Access to files open file read/write close file
Read line
Write line
What happens if:
open a file which does not exists
Read a line from a file not opened
Other exceptions
Client

19. Automatic distribution (stub)
The stub can be distributed automatically but then the code needs to include a security policy statement
A security policy file must be provided, which must be specified in the command line
When starting the server, a URL for retrieving the stub file must be specified
java –Djava.security.policy=policy.txt
-Djava.rmi.server.codebase=
ClientProgram
See examples PideNumero ReparteNumeros

20. Automatic distribution (stub)
The downloading of the stub class is made via URL
A “web-server” must be running at the server side
We can use a small server to server only class files for this purpose
ClassFileServer (extends ClassServer)
Steps :
Download RFSClient.cass, RFSInterface.class, policy.txt
Server start ClassFileServer port path
Server start Remote Object server
Client contacts server (with policy and codebase parameters

21. Activation of the server
Sometimes it is not convenient to have all server objects running waiting for a client
RMI provides an activation schema for remote object servers
There is only one “server” running (the rmideamon), who will “wake up” the server when a client requests a service
It is necessary then to write and run a set-up program, which will register the “sleeping” server with the rmid
For the client, there is no difference

22. Steps for writing an activable server
Rewrite the server so it extends the activable class´instead of RemoteUnicastObject
import java.rmi.activation.*;
public class MyRemoteClass extends Activable implement MyInterface
Remove the original constructor and write one which receives two parameters:
public MyRemoteClass(ActivationID id, MarshalledObject data)
throws RemoteException {
super(id, 0); }
Compile with javac and rmic
Write and compile the set-up program which will register the activable class to the rmi daemon
See under kapitel 8/ rmid

23. Steps for running this Start the ClassFileServer and rmiregistry
Start the rmid
rmid –J-Djava.security.policy=policy.txt
Run the Setup program
Java -Djava.security.policy=policy.txt
– Djava.rmi.server.codebase= Setup
Run the client
– Djava.rmi.server.codebase= client
Look where the output of the server program is given
The code of the client does not change. Activation is strictly a server-side implementation decision.