Programmazione distribuita - Intranet DEIBhome.deib.polimi.it/morzenti/IngSw/RMI.pdf ·...

25
1 Programmazione distribuita

Transcript of Programmazione distribuita - Intranet DEIBhome.deib.polimi.it/morzenti/IngSw/RMI.pdf ·...

1

Programmazione distribuita

2

Architettura client-server• È il modo classico di progettare applicazioni

distribuite su rete• Server

– offre un servizio "centralizzato"– attende che altri (client) lo contattino per ottenere

un servizio• esempio: web server

• Client– si rivolge ad apposito/i server per ottenere certi

servizi• esempio: browser www (Netscape, Explorer, …)

3

Middleware

• Per programmare un sistema distribuito vengono forniti servizi specifici, come estensione del sistema operativo

• Il middleware viene posto tra il sistema operativo e le applicazioni

4

Architettura del server

• Single-threaded– quando accetta una connessione, la serve

fino a che questa viene chiusa

• Multi-threaded– quando accetta una connessione, genera il

socket relativo e lo fa gestire da un task

5

RMI—Remote Method Invocation

• Possono essere invocati metodi su oggetti remoti

• Aspetti innovativi– passaggio dei parametri per valore e

indirizzo– possibilità di scaricare (download)

automaticamente dalla rete le classi necessarie per la valutazione remota

6

Architettura client-server usando RMI

• Caso tipico– Server crea oggetti remoti, li rende visibili e

aspetta che i client invochino metodi su di essi– Client ottiene riferimenti a oggetti remoti e invoca

metodi su di essi• RMI fornisce il meccanismo con cui server e

clients comunicano per costituire l'applicazione distribuita– tipicamente client ottiene servizi dal server

invocando metodi di oggetti remoti con una sintassi identica a quella per gli oggetti locali(residenti sulla stessa JVM), ma con una semantica un po’ diversa

7

Funzionalità di RMI (1)• Localizzazione di oggetti remoti

– Gli oggetti remoti sono registrati presso un registro di nomi (rmiregistry) che fornisce una "naming facility", oppure

– Le operazioni passano come parametri e/o restituiscono riferimenti a oggetti remoti

• Comunicazione con oggetti remoti– gestita da RMI, per i programmi accedere a

oggetti remoti non fa differenza rispetto agli oggetti "normali"

8

Funzionalità di RMI (2)

• Dynamic class loading– essendo possibile passare oggetti ai metodi

di oggetti remoti, e poiche` (come vedremo) gli oggetti (non remoti) vengono passati per valore, RMI oltre a trasmetterei valori dei parametri, consente di trasferire il codice degli oggetti a run timeÈ un esempio di codice mobile

9

Vincoli

• Le interfacce che definiscono le funzionalita`degli oggetti remoti (cioe`resi accessibili da altri oggetti non locali tramite il sistema RMI) devono ereditare da java.rmi.Remote

• I metodi definiti in tali interfacce devono dichiarare l'eccezione java.rmi.RemoteException

10

Modus operandi

• Grazie all'eredità multipla fra le interfacce, i metodi definiti in una qualsiasi interfaccia MyInterface che non era stata pensata per oggetti remoti possono essere forniti in maniera remota creando una nuova interfaccia che eredita da MyInterface e dall’interfaccia predefinita Remote

11

viene usato anche un normale server web per caricare (dinamicamente) le classi (in bytecode), da client a server e da server a client

Architettura "esterna"

12

Architettura "interna"• Il client colloquia con un proxy locale del

server, detto stub– lo stub rappresenta il server sul lato client– implementa l'interfaccia del server– è capace di fare forward di chiamate di metodi– il client ha un riferimento locale all'oggetto stub

• Esiste anche un proxy del client sul lato server, detto skeleton– è una rappresentazione del client– chiama i servizi del server– sa come fare forward dei risultati– lo skeleton ha un riferimento all'oggetto

13

Livello applicazioni

programma CLIENT programma SERVER

Stubs Skeletons

Java virtual machine

Rete IP

chiamata di un metodo

risposta

Architettura di RMI

Java virtual machine

rmiregistry

14

Creazione di interfaccia remota

package distrib1.rmi;import java.rmi.*;public interface PerfectTimeIntrfc extends Remote {

long get PerfectTime() throws RemoteException;}

Un'interfaccia remota1. deve essere pubblica2. deve estendere java.rmi.Remote3. ogni metodo deve dichiarare java.rmi.RemoteException4. ogni oggetto remoto passato come parametro o

valore di ritorno deve essere dichiarato di tipo interf. remota

15

Dal lato server occorre…• Dichiarare la classe dell’oggetto server, affinche`esso sia

accessibile via RMI, in modo che – estenda UnicastRemoteObject e – implementi l'interfaccia remota– definisca esplicitamente il costruttore, che deve dichiarare

RemoteException nella clausola throws

• creare e installare RMISecurityManager, che gestisce RMI sul lato server

• creare uno o più oggetti remoti• registrare almeno uno di questi nel "registry"

– Per eventuali altri oggetti si possono ottenere riferimenti a essi come risultato di chiamate di metodi di quelli gia` registrati, evitando cosi` di passare ancora attraverso il registry

16

Registry• È un task concorrente, sotto Windows

lanciato con start rmiregistry o (se si è sicuri di essere i soli a usare il registry) all'interno del codice del server col comando LocateRegistry.createRegistry();

• È un programma di rete che ascolta su una porta, per default "1099"

• Occorre dargli comando per realizzare il binding tra il l'oggetto locale esportato come remoto e il nome che a esso dà il client

17

package distr1.java;import java.rmi.*;import java.rmi.server.*;import java.rmi.registry.*;import java.net.*;public class PerfectTime extends UnicastRemoteObject

implements PerfectTimeIntrfc {public long getPerfectTime() throws RemoteException;

return System.currentTimeMillis();}public PerfectTime() throws RemoteException {

super(); //inutile, peraltro}public static void main (String{} args) throws Exception {

System.setSecurityManager(new RMISecurityManager());PerfectTime pt = new PerfectTime();Naming.rebind ("//pc-morze/PerfectTime", pt);System.out.println("Ready to do time");

}}

evita il rischio di "bind"qualora esista già un oggetto registrato con lo stesso nome

stringa di registrazione: un URL con la forma [rmi:][//][host][:port][/name]

18

Vita degli oggetti remoti

• Se main() termina, l'oggetto remoto registrato continua ad esistere finchè rmiregistry resta running

• Ecco perché è necessario fare rebind (potrebbe esistere un oggetto con lo stesso nome)

• Si può anche fare – Naming.unbind() ("…");

19

Uso dell'oggetto remoto

package distrib1.rmi;import java.rmi.*;import java.rmi.registry.*;public class DisplayPerfectTime {

public static void main(String[] args) throws Exception {System.setSecurityManager(new RMISecurityManager());//lega oggetto locale a remotoPerfectTime t=(PerfectTime) Naming.lookup("//pc-morze/PerfectTime");for(int i=0; i<10; i++)

System.out.println("Perfect time = "+ t.getPerfectTime());}

}

20

Semantica: passaggio dei parametri

• nell'invocazione di un metodo remoto m(obj)– se obj remoto (i.e., esportato al sistema RMI),

normale semantica (passato riferimento remoto)– se oggetto non remoto, m opera su una copia

serializzata (passaggio per valore con deep copy)di obj; eventuali modifiche alla copia di obj hanno effetto solo sulla copia, non sull'originale

• tipi primitivi passati comunque per valore

21

Serializzazione• Oggetti passati a, o ritornati da, un oggetto

remoto devono implementare l'interfaccia Serializable– se invece si passano riferimenti remoti, basta

estendere Remote• Stubs e skeletons effettuano

automaticamente la serializzazione e deserializzazione– si dice che fanno il "marshal" (schieramento) di

argomenti e risultati

22

Che cosa dobbiamo fare noi?

• Il tool rmic (rmi compiler) crea i files necessari per stub e skeletonrmic distrib1.rmi.PerfectTime

genera due classi:PerfectTime_Stub.classPerfectTime_Skel.class

23

Ciclo di sviluppo di una semplice applicazione

• Definizione dell’interfacciaremota– Deve estendere

java.rmi.Remote

• Definizione del codice dell’oggetto remoto– deve implementare

l’interfaccia remota – deve estendere la classe java.rmi.server.UnicastRemoteObject

• Creazione di stub e skeleton– si usa il comando rmic

• Definizione del codice del server– istanzia l’oggetto remoto e

lo registra presso il registry

• Definizione del codice del client– deve richiede al registry un

riferimento all’oggetto remoto– lo assegna ad una variabile

che ha l’interfaccia remota come tipo

24

Security manager e file di policy

• Perchè client e server possano istanziarecorrettamente le classi scaricate, è necessarioconfigurare il security manager

• Questo impedisce alle classi scaricate di eseguireazioni non legali

• SecurityManager è una classe in java.lang cheoffre metodi per controllare la possibilità di accesso a varie risorse (file, socket,...)

• RMI usa un security manager per controllare i permessi di uso dei socket da parte di un’applicazione

• Un utente può definire le politiche di sicurezzaeditando un file di policy

25

Esempi di file di policygrant {

permission java.net.SocketPermission “*”,“connect”;//il client puo` collegarsi a qssi host, dominio o port

permission java.net.SocketPermission “*”,“accept”;//il server accetta connessioni da qssi indirizzo e port

permission java.io.FilePermission “/tmp/*”,“read”;//puo` leggere file (fuori dalle sue sottodirectory)//solo su /tmp/*}

grant {permission java.security.AllPermission;

//massimamente permissiva, accettabile in fase di test, //non in produzione}