Agenti Mobili in Java RMI

Transcript

1 Agenti Mobili in Java RMI Un agente è una computazione che agisce per conto di un host presso un altro host. Gli agenti in Java RMI sfruttano due peculiarità di Java: Serializzazione, attraverso cui gli oggetti vengono trasmessi per valore (per deep copy). Polimorfismo, che consente di utilizzare una sottoclasse B laddove è previsto l utilizzo di una superclasse A (con B<A). Questo perchè la segnatura di una sottoclasse estende quella di una sua superclasse, sebbene l implementazione dei metodi può essere completamente diversa. In Java RMI, un agente può essere passato dal client al server come parametro di un invocazione remota, oppure può essere il valore tornato dal server al client attraverso un invocazione remota. Massimo Merro Programmazione di Rete 194 / 213

2 In Java RMI è possibile modellare per lo meno tre diverse forme di agenti: Mobile Agents Callbacks Mobile Servers. Massimo Merro Programmazione di Rete 195 / 213

3 Mobile Agents Un mobile agent è un oggetto locale serializzabile passato attraverso un invocazione remota. Poichè è serializzabile esso verrà trasmesso per deep copy ed andrà in esecuzione a destinazione. Ovvero, presso il server, se l agente è stato passato come parametro dal client, presso il client, se l agente è stato passato come risultato dal server. L utilizzo di agenti mobili richiede che entrambi, mittente e destinatario, siano a conoscenza di una classe astratta o di un interfaccia dell agente mobile. Questa condizione è simile a quella per cui un server ed un client devono condividere l interfaccia remota del server remoto. Vediamo uno schema dell entità coinvolte quando si lavora con agenti mobili. In questo esempio, l agente viene passato dal client al server come parametro di un invocazione remota. L agente viene perciò eseguito presso il server: Massimo Merro Programmazione di Rete 196 / 213

4 public interface MobileAgent { public void act(); public interface Receiver extends Remote { public void receive(agent agent); public class ConcreteAgent implements MobileAgent, Serializable { public void act() {... public class Sender { public void send(receiver rcvr) { rcvr.receive(new ConcreteAgent());... public class ConcreteReceiver extends UnicastRemoteObject implement Receiver { public void receive(mobileagent agent) { agent.act();... Massimo Merro Programmazione di Rete 197 / 213

5 Callback Un callback è un server remoto ed esportato di cui viene passata come parametro una referenza remota, oppure ritornata come risultato di un invocazione remota. Poichè un server remoto esportato è passato per referenza remota (si passa lo stub), l agente vero e proprio rimane dietro (cioè non si muove) ed agisce alla sorgente. Vediamo un esempio di callback: Massimo Merro Programmazione di Rete 198 / 213

6 public interface Callback extends Remote { public void callback() throws RemoteException; public interface Receiver extends Remote { public void receive(callback agent) throws RemoteException; public class CallbackClient extends UnicastRemoteObject implements Callback { public void callback () {...; public void main(string[] args) { Receiver rcv =...lookup... rcv.receive(this);... public class ServerReceiver extends UnicastRemoteObject implements Receiver { public void receive(callback agent) { agent.callback();... Massimo Merro Programmazione di Rete 199 / 213

7 Notate che il client invoca un metodo remoto del server che a sua volta reinvoca il client, attraverso il metodo callback. Situazioni del genere sono auspicabili quando durante l esecuzione del metodo remoto del server si rende necessario un interazione col cliente per ricavare informazioni che possono essere state acquisiti successivamente. Oppure informazioni in possesso del client che all inizio dell invocazione del metodo del server non si ritenevano necessarie. Le callback funzionano senza problemi ogni qual volta si lavora con oggetti locali. Se invece lavoriamo con server remoti, allora possono insorgere problemi di stallo. Ad esempio, consideriamo la variante dello schema precedente in cui l agente callback contiene due metodi run e callback entrambi synchronized. Massimo Merro Programmazione di Rete 200 / 213

8 public interface Callback extends Remote { public void callback() throws RemoteException; public interface Receiver extends Remote { public void receive(callback agent) throws RemoteException; public class CallbackClient extends UnicastRemoteObject implements Callback { public synchronized void run(receiver rcv) {... rcv.receive(this); public synchronized void callback () {...; public class ServerReceiver extends UnicastRemoteObject implements Receiver { public void receive(callback agent) { agent.callback(); public void main (String[] args) Callback cb =...lookup...; cb.run(this); Massimo Merro Programmazione di Rete 201 / 213

9 In una tale situazione, se ServerReceiver fosse un oggetto locale, allora il metodo callback verrebbe invocato nello stesso thread del metodo run, senza che ciò provochi problemi di deadlock. Ma visto che ServerReceiver è un server remoto, il sistema RMI invoca il metodo callback all interno di un nuovo thread. Tale thread si blocca nel tentativo di entrare nel metodo callback visto che il thread originale è ancora in attesa all interno del metodo synchronized run. In questo modo viene bloccato anche il thread originale sulla run. Quindi abbiamo uno stallo! Massimo Merro Programmazione di Rete 202 / 213

10 Mobile Server In questo caso l agente in questione è un server remoto serializzabile ma non esportato nel momento in cui viene passato. In tal caso sappiamo che il server viene passato per deep copy. A destinazione, ci sono due possibilità: Se il mobile server è un UnicastRemoteObject de-esportato, allora al momento della deserializzazione il server viene automaticamente esportato sulla medesima porta dov era esportato originalmente e funziona come un server remoto presso l host in cui è stato ricevuto. Se invece il mobile server è un qualche server remoto che non è stato esportato al momento della spedizione. Allora a destinazione bisognerà esportarlo esplicitamente. Massimo Merro Programmazione di Rete 203 / 213

11 La struttura di un mobile server è, in un certo qual modo simile a quella vista per le callback eccetto per il fatto che l oggetto CallbackClient non è esportato nel momento in cui si invoca il metodo receive. Vediamo un esempio di Mobile Server del secondo tipo. Massimo Merro Programmazione di Rete 204 / 213

12 public interface MobileServer extends Remote { public void remotemethod() throws RemoteException; public interface Receiver extends Remote { public void receive(client agent) throws RemoteException; public class ImplMobileServer extends UnicastRemoteObject implements MobileServer,Serializable{ public void remotemethod () {...; public class ClientSender { public void main(string[] args) { ImplMobileServer ms = new ImplMobileServer(); unexport(ms,true); Receiver rcv =...lookup..; rcv.receive(ms); public class ServerReceiver extends UnicastRemoteObject implements Receiver { public void receive(mobileserver agent){ agent.remotemethod(); Massimo Merro Programmazione di Rete 205 / 213

13 Si noti che l invocazione agent.remotemethod() avviene presso l host in cui gira ServerReceiver ed in cui è stato esportato un server remoto ImplMobileServer. In pratica, il client lancia un server remoto presso un altra JVM (su un altra macchina). Similmente un server può lanciare un altro server presso il client. Massimo Merro Programmazione di Rete 206 / 213

14 Proxy In Java RMI uno schema di agente molto diffuso è quello del proxy. Un proxy è un server che viene interposto tra il client ed il vero server. Un proxy ed il suo server sono compatibili dal punto di vista dei tipi, ovvero un proxy può implementare una delle interfacce implementate dal server o estendere una delle classi base del server. Un proxy mantiene sempre una referenza al server con cui comunicherà in maniera trasparente al client, il quale crederà di intergire direttamente col server. I proxy vengono usati ogni qual volta sia necessario introdurre un entità intermedia di controllo. Vediamo adesso alcune forme di proxies. Massimo Merro Programmazione di Rete 207 / 213

15 Remote Proxy Un remote proxy è un rappresentante locale di un server remoto (che si trova in un altro host). Uno stub RMI è esattamente un remote proxy. Infatti uno stub contiene (o meglio nasconde al client) il meccanismo attraverso cui è possibile comunicare col server remoto. Uno stub implementa la medesima interfaccia del server remoto. In tal modo il client pensa di interagire direttamente col server remoto. Massimo Merro Programmazione di Rete 208 / 213

16 Smart Proxy Uno smart proxy può essere usato per nascondere al client la presenza di un interazione remota. Il client infatti interagisce con un oggetto locale (privo di interfacce remote) senza sapere che questo è in realtà uno smart proxy che delega certe funzionalità ad un server remoto mentre altre sono svolte localmente. Questo è un meccanismo efficiente ed elegante per distribuire l implementazione tra macchina locale e server remoto, in maniera del tutto trasparente al client. Massimo Merro Programmazione di Rete 209 / 213

17 Smart Remote Proxy In tale schema il client, invece di interagire con uno stub interagisce con un proxy locale che implementa l interfaccia remota e che opera da proxy verso lo stub al server remoto. Quando il client richiede una referenza ad un server remoto, invece di ricevere uno stub, riceve per deep copy, uno smart remote proxy. Uno smart remote proxy è un oggetto serializzabile che contiene al suo interno una referenza al server remoto, ovvero uno stub. Quindi, al momento della serializzazione il client riceverà sia il proxy che lo stub remoto; sebbene potrà direttamente interagire solo col primo. Questo schema è utile quando il server vuole che alcune operazioni siano eseguite localmente presso il client mentre altre siano inoltrate al server. Questo schema ha delle ovvie ripercussioni sulla sicurezza visto che l implementazione del proxy è fornita interamente dal server, ed il client deve fornire permessi adeguati per le operazioni eseguite dal proxy. Massimo Merro Programmazione di Rete 210 / 213

18 Schemi di programmazione distribuita Client-server Client e server giocano un ruolo diverso. Il client interroga il server richiedendo un servizio. Il server riceve richieste e ritorna risultati. Solitamente è il client ad iniziare la connessione ed anche quello che chiude la connessione quando ha ottenuto quanto desiderato. Client-dispatcher-server In questo caso esiste un dispatcher che media tra client e server. Il client comunica col dispatcher per accedere al server indicandone il nome. Il dispatcher si prende cura di inoltrare la richiesta al server con quel nome. Il sistema RMI implementa tale schema utilizzando stubs e skeletons. Massimo Merro Programmazione di Rete 211 / 213

19 Peer to Peer In tale schema non vi è distinzione tra client e server. Tutte le entità coinvolte possono fornire e richiedere servizi. Singleton Una classe viene detta Singleton se ne esiste una sua sola istanza. Una classe singleton viene spesso usata per incapsulare un processo che deve essere sequenzializzato tra più utenti (ad esempio, lo spooler di una stampante) oppure per rappresentare una risorsa di cui esiste una sola istanza (ad esempio un file systems o un database). La classe java.lang.runtime è un esempio di singleton, che rappresenta il sistema a runtime di Java. In generale una classe singleton è priva di stato. I server registrati sul registro RMI sono in generale singleton perchè la medesima istanza viene usata da più clients. Massimo Merro Programmazione di Rete 212 / 213

20 Abstract Remote In tale schema vi è un classe astratta che implementa un interfaccia remota: public interface RemoteService extends Remote {... public abstract class AbstractService implement RemoteServer { public AbstractService() throws RemoteException {... public class ConcreteService extends AbstractService {... Una classe astratta non deve fornire il codice dell implementazione, eccezion fatta per il costruttore. In particolare non deve reiterare la dichiarazione dei metodi remoti. Una classe astratta remota può essere compilata da rmic. Le implementazioni concrete non vengono toccate da rmic. In fase di sviluppo posso cambiare l implementazione del server senza dover ricompilare con rmic. La compilazione rmic dovrà essere rieseguita solo se si cambia l interfaccia remota. Massimo Merro Programmazione di Rete 213 / 213