Changing the way of

Download Report

Transcript Changing the way of

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 a schema
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
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 appropriate format (integer, string,
float,..)
• eXternal Data Representation, serialization
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
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
Uses Interface
for compiling
Implements
interface
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
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
Client program
•
•
•
Define a particular class
for implementing remote
objects and implements the
interface
Create a remote-able
object
Make it publicly available
Server program
An Example: Remote Date Server
• The only method will be Date getDate(), the
server will answer with the local Date
DateServer
getDate()
getDate()
DateClient
Tue Jun 12 17:20:24
The interface file
import java.rmi.*;
import java.util.Date;
public interface DateInterface extends Remote {
public Date getDate() throws RemoteException;
}
• It must import java.rmi.*
• It must extend Remote
• Every declared method should throw a
RemoteException
Define a class for implementing
remote date objects
Remote
Extends
RemoteObject
Remote Interface
Implements
The remote Object
Class definition
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
• 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
Client
Stub
Remote Object
Server
Skel
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
Which file where ?
• A client needs the stub file and the interface file
• The server needs the Stub & Skel file
Client
DateClient.class
RemoteDate.class
DateServer_stub.class
Remote Object
Server
DateServer.class RemoteDate.class
DateServer_stub.class
DateServer_skel.class
How to generate stub & skel
• The compiled implementation class should be
compiled (again) with the rmic command
RemoteDate.java
DateServer.java
DateClient.java
javac
javac
javac
RemoteDate.class
DateServer.class
rmic
DateClient.class
DateServer_skel.class
DateServer_stub.class
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
Server2
getNumber()
1
getNumber()
Client
3
2
Client
getNumber()
Client
What do I get when calling a
remote object ?
• A reference to the remote object
• If the object has references to other not remote
objects, the callers gets a COPY of these objects
• If the remote object has a reference to other
remote object, the caller gets a reference to these
objects
• See ListServer, ListClient, List Interface and
MyList
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
addClient(this)
Remote
Object Client
sendMessage(String)
refreshList(String[])
newMessage(String)
Remote Object
Server
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=http://hostname/filelocation
ClientProgram
Automatic distribution (stub)
• The downloading of the stub class is made via
URL protocol
• A “web-server” must be running at the server side
• We can use a small server which “serves” only
class files for this purpose
• ClassFileServer (extends ClassServer)
• Steps :
– Download RFSClient.class, RFSInterface.class,
policy.txt
– Server start ClassFileServer port path
– Server start Remote Object server
– Client contacts server (with policy and codebase
parameters
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
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
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=http://hostname:port/ Setup
• Run the client
Java -Djava.security.policy=policy.txt
–Djava.rmi.server.codebase=http://hostname:port/ 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 !.
Homework
• Implement an unifyed RMI-based FFS and Directory Server based on the
interfaces shown before
• The remote object shuold implement the following methods:
– byte[] read(FileId, i, n) : attempts to read up to n bytes from a file starting from the byte
in the position i.
– boolean write(FileId, i, Datos): writes a data sequence starting from the position i into
the specified file
–
–
–
–
FileId create() : creates a new file (empty) and returns its FileId
boolean delete(FileId) : deletes the file
FileId lookup(Dir, File) : localises the name of the file in the directory UFID
boolean addName(Dir, Name, File) : If Name was not in the directory, the
pair(Name,File) is added modifying the corresponding file
– boolean unName(Dir, Name) : the pair (Name, file) is deleted from the directory
– String[] getNames(Dir) : returns the list of names in the directory
• It is up to you how to implement the FileId
• For trying your system implement