Transcript Kapitel8[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
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 appropiate format (integer, string,
float,..)
• eXternal Data Representation
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
Remote Server
getDate()
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;
}
• 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
Extends
The remote Object
Class definition
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
Server
getNumber()
1
getNumber()
Client
3
2
Client
getNumber()
Client
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(text)
newMessage(text)
Remote Object
Server
A Remote file server
Access to files
-open file read/write
-close file
-Read line
-Write line
Client
What happens if:
-open a file which does
not exists
-Read a line from a file
not opened
-Other exceptions
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
• See examples PideNumero ReparteNumeros
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
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.