Changing the the way of designing distributed applications Communication design orientation: The design of the protocol goes first and then the development of the system is done based on the protocol. Application design orientation: The development and design of the system is done like if everything is local and then the application is divided into modules that will be running on different machines. This first strategy has a more complicated design but the programming will use less resources. The second is better when the communications are complicated, at the point to make the application difficult.

Alternative Technologies Development of networks => Development of distributed systems Development of middleware (libraries,tools,services, etc..) that support the programming of distributed systems Based on TCP/IP protocol The programming language is more high- level The problem of the distributed applications is not a particular case.

Remote Procedure Calls (RPC) Motivation: Development of NFS (SUN) A client can call a function in an application running on a server just like if it is locally implemented. Sends the parameters and receives the results in a correct format(Integer,String,float...) eXternal Data Representation Serialization.

Remote Procedure Calls The client stops the execution until the results are received. Call(parameters) Receive results RPC Server RPC Client Server framework: provided by the middleware

The Interface file Specifies the protocol of the remote function: name, required parameters (how many, and what type), result (type) It is called “interface” file because server and the client get the needed information. The client uses the interface to compile The server implements it RPC Server RPC Client Interface definition file

Remote Objects As the object orientation paradigm developed the “remote object” approach replaced the previous paradigm. An Application can call a method of an object located on another JVM. The interface file is the key concept of the implementation. RemoteObjectServer Invokes the method Gets the result

Necessary files Gets a reference to the remote object. Use the method and, Receives the results as if it is locally located. Client program Server program Defines a particular class to implement the methods specified in the interface Creates the remote object from this class. It is published in some registry service, to be located by the clients. Defines the methods (just the header) that could be remotely invoked. Implements Use for compilation interface

Example: Remote Date Server The only method of the object will be getDate(), this method will return as a result the date of the computer where it is located. Remote Server getDate () Tue Jun 12 17:20:24

The interface file import java.rmi.*; import java.util.Date; public interface RemoteDate extends Remote { public Date getDate() throws RemoteException; } Must import java.rmi.* Must extend the Remote class Each declared method must throw a RemoteException

Defining a class to implement remote objects. Definition of the class for the remote object Remote Interface RemoteObject Implements Remote Extends DateServer.java

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); } }

The Stub and Skel files The communications are implemented by the stub and skel files. They are generated when the sourcecode is compiled using the rmic command. With the 1.5 version of java they are generated automatically Client Stub Remote Object Server Skel

The name registry server It is a server for registring and making public the remote objects. The server of the remote object registers the object in it and the clients obtain a reference to the object from it. Must run in the host server, and have access to the stub and skel files. Must be reinitialized before the server registers the object. Client Remote Object Server rmiregistry

¿ What file and where? The client need the interface and stub file. The server need the Stub and Skel file. Client Remote Object Server DateClient.class RemoteDate.class DateServer_stub.class DateServer.class RemoteDate.class DateServer_stub.class DateServer_skel.class

Generating stub & skel The class file of the implementation must be compiled again with the rmic command. DateClient.java RemoteDate.java DateClient.class DateServer.class DateServer_stub.cl ass DateServer_skel.class DateServer.java RemoteDate.class javac rmic

Initiating the rmiregistry from the application. It is possible to initiate the rmiregistry from an application calling a java method. The following example will also demostrate concurrent problems. Remote Number Server Clie nt getNumber() 1 2 3

The RMI based chat The client must receive the messages of the server. The client implements a remote object wich is passed to the server as a parameter!!! The server does not need to locate the client Remote Object Client Remote Object Server addClient(this) sendMessage(text) newMessage(text)

A remote file server Access to files Client -open file read/write -close file -Read line -Write line What happends if: - It is asked to open a non- existing file. - It is asked to read a non- opened file. - More errors are generated.

Automatic Distribution (stub) The stub file can be distributed atomaticly but it is necessary to add a safety controller. For this it is necessary to write in a security policy file. When the server is initialized it is necessary to specify an URL to tell the server where the policty file is located. java –Djava.security.policy=policy.txt -Djava.rmi.server.codebase= ClientProgram Se examples: PideNumero ReparteNumeros (askNumber) (GiveNumber)

Automatic Distribution (stub) The stub file is obtained using the URL protocol A “web-server” must be running. A small class server can be used. ClassFileServer (extends ClassServer) Steps : –Download RFSClient.cass, RFSInterface.class, policy.txt –Run the class Server with the command ClassFileServer port path. –Run the remote object server. –The client contacts the server (with the policy and codebase parameters)

Automatic activation of the remote server Sometimes it is not convienient to have many servers running at the same time, just when it is necessary. RMI provides a schema to activate objects. Only one server is always running (the rmideamon), that will wakeup the objects when it is necesary. (Call from a client ) It is necessary to write and run a “set-up” program to registry the sleeping server with the rmid that will wake it up. For the client there is no difference.

Steps to write an activable server Rewrite the Server to extend an “activable” class instead of the RemoteUnicastObject. import java.rmi.activation.*; public class MyRemoteClass extends Activable implement MyInterface Replace the constructor to one that has 2 parameters. public MyRemoteClass(ActivationID id, MarshalledObject data) throws RemoteException { super(id, 0); } Compile it with javac and rmic. Write and compile the Setup program

Steps to run it Run the ClassFileServer and rmiregistry Run 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. Java -Djava.security.policy=policy.txt – Djava.rmi.server.codebase= client