Programmazione distribuita - Fondamenti

SOCKET

• ServerSocket: per accettare connessioni (socket di connessione)
• Socket: per lo scambio di dati (socket di dati)

• ServerSocket(int port): crea un server socket su una specifica porta
• Socket accept() throws IOException: aspetta connessioni su questo socket e le accetta. Questo metodo è bloccante fino a quando non viene fatta una connessione. Viene creato un nuovo Socket e restituito.
• public void close() throws IOException: chiude il socket
• void setSoTimeout(int timeout) throws SocketException: setta un timeout (in ms) per una chiamata ad accept. Se il tempo passa senza una connessione, viene lanciata un'eccezione java.io.InterruptedIOException

• InputStream/OutputStream
• FileInputStream/FileOutputStream
• DataInputStream/DataOutputStream

<!-- Client -->
<ClientSocket socket = new Socket ("localhost", 9000);>
<ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream());>
<ObjectInputStream in = new ObjectInputStream(socket.getInputStream());>
<out.writeObject(obj);>
<in.readObject();>

<!-- Server -->
<ServerSocket serverSocket = new ServerSocket(9000);>
<Socket socket = serverSocket.accept();>
<ObjectOutputStream oS = new ObjectOutputStream(socket.getOutputStream());>
<ObjectInputStream iS = new ObjectInputStream(socket.getInputStream());>
<out.writeObject(obj);>
<in.readObject();>

<!-- JAVA REMOTE METHOD INVOCATION (JRMI) -->
<!-- Libreria che permette l'invocazione di metodi su oggetti remoti -->

<!-- Obiettivi di RMI -->
<!-- Invocazione trasparente di metodi remoti -->
<!-- offrire l'illusione che l'invocazione avvenga su un oggetto interno alla JVM -->
<!-- JVM dalla quale parte l'invocazione remota -->

<!-- Integrazione completa in Java -->
<!-- ambiente familiare -->
<!-- semantica di oggetti locali e distribuiti differente ma in maniera -->

limitata e resa esplicita• uso di politiche di garbage collection distribuita integrate con quelle locali

memory leak pericolosi per le applicazioni distribuite quanto (e più di) quelle locali- Memory leak: allocazione di memoria che non viene deallocata anche se non utilizzata

Sicurezza in Java

1. I livello: la sicurezza del linguaggio
2. II livello: Class loader
3. III livello: Bytecode Verifier
4. IV livello: Security Manager

Il modello ad Oggetti Distribuito di Java RMI

• Un oggetto remoto è un oggetto i cui metodi possono essere acceduti da un altro spazio di indirizzamento, e potenzialmente da un'altra macchina
• La descrizione dei servizi offerti da remoto da un oggetto remoto è contenuta all'interno di un'interfaccia remota che è un'interfaccia Java che dichiara i metodi remoti
• Un'invocazione di metodi remoti (Remote Method Invocation) rappresenta l'invocazione di un metodo su

Un oggetto remoto (specificato nell'interfaccia remota) ha la stessa sintassi di una invocazione di un metodo locale, i cui metodi sono accessibili da un altro oggetto remoto nello spazio di indirizzamento (quindi da un'altra macchina). L'interfaccia Java descrive i servizi dell'oggetto remoto.

L'interfaccia remota ha una struttura delle classi divisa in 5 package:

1. java.rmi: funzionalità di base
2. java.rmi.server: funzionalità di base
3. java.rmi.activation: oggetti attivabili
4. java.rmi.dgc: garbage collection
5. java.rmi.registry: servizio di naming

Aspetti importanti di RMI:

• Interfacce ed eccezioni remote
• Implementazioni remote
• Riferimenti remoti
• Localizzazione ed invocazione
• Passaggio di parametri
• Meccanismo di marshalling

Interfacce ed Eccezioni Remote:

Un'interfaccia remota per Java RMI deve estendere (implementare) l'interfaccia java.rmi.Remote, che è una cosiddetta interfaccia marker, ovvero una interfaccia vuota. In questo caso, serve solamente per poter segnalare che essa definisce dei metodi.

accessibili da remoto

Ogni metodo descritto in una interfaccia remota deve essere un metodo remoto cioè deve soddisfare le seguenti condizioni:

• dichiarare esplicitamente java.rmi.RemoteException
• checked exception dal compilatore
• la semantica diversa dei malfunzionamenti in locale impone al programmatore di rendere esplicita la natura del metodo
• parametri remoti dichiarati tramite interfaccia remota
• permette l’uso di riferimenti remoti come parametri/valori restituiti
• l’accesso remoto in qualche maniera aggiunge modifica di accesso ai tradizionali public, private, etc

Implementazioni remote

Per realizzare l’implementazione remota che deriva (implements) da una interfaccia remota per offrire verso l’esterno i metodi remoti in essa definiti, si può procedere in 2 modi:

1. riuso della implementazione remota prevede che la classe che contiene l’implementazione dell’oggetto derivi esplicitamente

dajava.rmi.server.UnicastRemoteObjectereditando di conseguenza il comportamento definito dalle classi• ejava.rmi.server.RemoteObjectjava.rmi.server.RemoteServer- classe di implementazione locale- permette che la classe derivi il comportamento da qualche altraclasse (non remota) e che si debba quindi occupare esplicitamentediesportare l’oggetto: tramite il metodo statico• di java.rmi.server.UnicastRemoteObjectexportObject()implementare la semantica di alcune operazioni di Object per•oggetti remoti che sono ridefiniti in ejava.rmi.server.RemoteObjectjava.rmi.server.RemoteServerRiferimenti remotiLo e lo forniscono la rappresentazionestub skeletondell’oggetto remoto- Lo stub gestisce la simulazione locale sul client e agendo comeproxy consente la comunicazione con l’oggetto remoto- Lo skeleton ne consente l’esecuzione sul server- I client interagiscono con l’oggetto stub• che rappresenta l’interfaccia remota dell’oggetto remoto

in locale sulla macchina (virtuale) del client

• espone localmente esattamente le stesse interfacce remote definite dall'oggetto remoto
• Possibile caricare dinamicamente lo stub
  • da un server WWW
  • a tempo di esecuzione, quando si ottiene il riferimento remoto
• Java Remote Method Invocation permette il passaggio di oggetti come parametri, valori restituiti o eccezioni, attraverso la serializzazione

Caricamento dinamico delle classi

• Questo si scontra con un'altra caratteristica di Java, quella del caricamento delle classi a tempo di esecuzione
• risulta essere più complesso nel momento in cui stiamo passando ad un metodo offerto da un server remoto (ad esempio) un parametro che è un'istanza di una sottoclasse della classe dichiarata nella firma del metodo
  • in questo caso, l'oggetto remoto può trovarsi nella situazione in cui non conosce esattamente come è strutturata la classe di cui l'oggetto passato è istanza

viene risolto da Java RMI attraverso il caricamento dinamico delle classi. Quando si fa il marshalling degli oggetti per la trasmissione (ad esempio, come parametri nella invocazione da client a server), essi vengono anche annotati con il codebase, cioè con la Uniform Resource Locator (URL) di un server WWW da dove è possibile trovare la definizione della classe (cioè il file .class).

Quando viene effettuato l'unmarshalling dell'oggetto, il ClassLoader cerca di risolvere il nome della classe nel suo contesto. In caso non sia possibile, viene acceduta la definizione della classe per poter ricreare l'oggetto all'altro capo della comunicazione (nel nostro esempio, sul server).

Questo meccanismo di caricamento dinamico permette anche il caricamento dinamico degli stub, con lo stesso meccanismo di annotazione che viene effettuato nel marshalling.

Marshalling: è il processo di trasformazione della memoria rappresentazione di un oggetto in

un dato formato adatto per la memorizzazione o trasmissione.

Localizzazioni e Invocazione

• Per poter invocare il metodo remoto di un oggetto remoto, l'oggetto client deve avere a disposizione il riferimento remoto, che può essere reperito in due maniere:
• ottenuto come risultato di altre invocazioni (locali o remote) di metodi
• attraverso un servizio di directory
• Servizio fornito da java.rmi.Naming
• Metodi statici lookup() bind() / rebind() / unbind() list()
• Accetta string della forma: //host:port/name
• Questo meccanismo è utilizzabile anche come tool da linea di comando (rmiregistry)
• eseguito sulla macchina sulla quale l'oggetto server si trova
• Un meccanismo di localizzazione più robusto verrà proposto successivamente quando tratteremo della implementazione di RMI su IIOP, basato su Java Naming and Directory Interface

Passaggio di Parametri

• Devono implementare l'interfaccia Serializable
• Oggetto locale: passato per

copia• cambiamento rispetto passaggio di parametri in metodi locali- IMPORTANTE• Quando si passano riferimenti allo stesso oggetto medianteinvocazioni diverse sulla macchina server saranno oggetto diversi• Integrità referenziale:se più riferimenti allo stesso oggetto vengono passati nella stessainvocazione allora viene garantito che punteranno allo stessooggetto sulla macchina server- Il codice per controllo uguaglianza deve dipendere dalla naturalocale/remota del server• Cambia l’uso di = ma anche di .equals( )di necessaria eventuale definizione o specializzazione- Meccanismo di marshalling usato da Java RMI• i riferimenti a stessi oggetti nella stessa invocazione verrannorisolti da un handle singolo• risultando in un unico oggetto sul serverMeccanismo di Marshalling- Fare il marshalling di un oggetto in Java significa• effettuare una serializzazione modificando la semantica deiriferimenti remotiinvece di un riferimento remoto

viene inserito lo stub dell'oggetto remoto e aggiungendo informazioni all'oggetto (il codebase della classe dell'oggetto)- Il meccanismo di marshalling di Java RMI si basa sulla specializzazione del meccanismo tradizionale di serializzazione effettuata da ObjectOutputStream.

Questa classe offre la possibilità di poter modificare il comportamento tramite il quale gli oggetti vengono scritti come stream di byte.