Applicazioni Distribuite
Permettono di ottimizzare l’uso delle risorse in
una rete. Sono realizzate attraverso
architetture client-server su tre livelli:
(Interfaccia, elaborazione, archiviazione)
DCOM e il modo Microsoft
(Distributed Component Object Model).
COM è un’istanza di una classe su un server a cui si può accedere solo
attraverso i metodi. DCOM permette agli oggetti COM in esecuzione su un
computer di creare altri oggetti COM su un’altra macchina. Gli oggetti remoti
vengono poi usati come oggetti locali.
In Windows tutte le classi sono registrate nel registro di sistema, quindi lo
devono essere anche gli oggetti remoti. Gli oggetti remoti comunicano tra loro
attraverso un meccanismo RPC (Remote Procedure Call) che poggia sul protocollo
UDP o sul protocollo TCP. Inoltre DCOM prevede un’elevata gestione della
sicurezza.
L’SDK Java di Microsoft consente l’utilizzo di DCOM.
CORBA
(Common Object Request Broker Architecture).
CORBA è simile DCOM object oriented, ma è uno standard aperto. Un oggetto
client può utilizzare i metodi di un oggetto server attraverso ORB.
L’interfaccia tra ORB e i due lati della comunicazione passa attraverso un IDL
(Interface Definition Language) indipendente dal linguaggio di implementazione.
L’oggetto client richiama in realtà un oggetto dello Stub IDL corrispondente al
metodo remoto.
Server Obj Client Obj
Stub IDL Model IDL
ORB
SOAP
(Simple Object Access Protocol)
Nonostante il SOAP sia un’ innovazione per le comunicazioni, non introduce nuovi
concetti in quanto si basa su tecnologia gia esistente e funzionante, e utilizza per il
trasporto dei messaggi di richiesta/risposta il protocollo HTTP nel quale i parametri e i
comandi sono codificati con XML; inquesto modo si riesce a eliminare il problema della
differenza di piattaforma, in quanto XML hauna tecnologia Web estremamente flessibile
ed estensibile.
Server Obj Client Obj
XML XML
HTTP
Esempio richiesta SOAP
POST /StockQuote HTTP/1:1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset=”utf-8”
Content-Lenght: nnnn
SOAPAction: “Some-URI”
<SOAP-ENV:Envelope>
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m=”Some-URI”>
<symbol>DIS</symbol>
<m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Esempio risposta SOAP
HTTP/1.1 200 OK
Content-Type: Text/xml; charset=”utf-8”
Content-Lenght: nnnn
<SOAP-ENV:Envelope>
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m=”Some-URI”>
<Price>1000$</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Java RMI
(Remote Method Invocation).
E’ una tecnologia tutta Sun che tuttavia possiede tutti i benefici di CORBA.
Anche in RMI si ha dal lato Client uno STUB che funge da Proxy per gli oggetti
remoti. Rispetto a CORBA non si ha però IDL e ORB, che invee garantivano con
CORBA l’indipendenza dal linguaggio.
A livello di trasporto RMI utilizza un normale socket TCP.
Sul server gli oggetti devono essere registrati in un registro che deve essere
lasciato in esecuzione .
Marshalizzazione
Tutti gli oggetti che viaggiano su uno stream devono essere serializzati, questo
vale ovviamente anche per gli eventuali parametri passati ai metodi e per i valori di
ritorno. Ma anche i dati numerici o primitivi devono sempre possedere un formato
adatto al trasporto da una JVM all’altra.
1- Impostazioni server (interfaccia)
Il client deve in qualche modo disporre degli oggetti remoti. Si crea a tale scopo
una interfaccia che come noto non contiene alcuna implementazione, ma permette
di definire un ‘prototipo’
import java.rmi.*;
public interface Product extends Remote //sia sul client che sul server
{
public String getDescription() throws RemoteException;
}
Si noti che viene estesa la classe Remote e che il metodo remoto lancia un
eccezione RemoteException (ad esempio la connessione potrebbe cadere)
2-Impostazioni server
Implementazione
Implementiamo il metodo che restituirà il risultato
import java.rmi.*;
import java.rmi.server.*;
public class ProductImpl extends UnicastRemoteObject implements Product {
public String getDescription() throws RemoteException
{ return name;}
/***********************************************/
public ProductImpl(String n) throws RemoteException
{ name=n;}
/***********************************************/
private String name;
}
Si noti che viene estesa la classe UnicastRemoteObject
3-Impostazioni server
classe Server
Infine è necessario istanziare e registrare gli oggetti sul server
import java.rmi.*;
import java.rmi.server.*;
public class ProductServer {
public static void main(String args[])
{ try {
ProductImpl p1=new ProductImpl(“Lavatrice REX”);
ProductImpl p2=new ProductImpl(“Forno Ariston”);
Naming.rebind(“lavatrice”,p1);
Naming.rebind(“forno”,p2);
}
catch(Exception e){ e.printStackTrace();}
}
}
Si noti soprattutto la registrazione degli oggetti attraverso un nome.
4-Impostazioni server
Avvio
Innanzi tutto è opportuno settare il CLASSPATH in modo che contenga la
directory dove si troveranno le classi compilate.
Set classpath=c:rmiprodotti
Compilate tutte le classi javac *.java
è necessario creare lo stub rmic –v1.2 ProductImpl
avviare quindi il registro RMI
start rmiregistry
(in UNIX rmiregistry &)
Quindi avviare la nostra applicazione come servizio
start java ProductServer
(in UNIX java ProductServer &)
1-Impostazioni client
Avvio
Sul client dovrà risiedere l’interfaccia Product, lo Stub e la classe ProductClient.
import java.rmi.*;
import java.rmi.server.*;
public class ProductClient
{ public static void main(String[] args)
{ System.setProperty("java.security.policy", "client.policy");
System.setSecurityManager(new RMISecurityManager());
String url = "rmi://localhost/";
try
{ Product c1 = (Product)Naming.lookup(url + “lavatrice");
Product c2 = (Product)Naming.lookup(url + “forno");
System.out.println(c1.getDescription());
System.out.println(c2.getDescription());
}
catch(Exception e) { e.printStackTrace(); }
}
}
Si noti in particolare il gestore della sicurezza e l’uso del metodo remoto.
Esecuzione: java ProductClient
1-Impostazioni client
file client.policy
grant
{
permission java.net.SocketPermission
"*:1024-65535", "connect,accept";
permission java.net.SocketPermission
"localhost:8080", "connect";
};
Installazione Client-Server
Preparare 3 directory:
Server
(Product.class, ProductImpl.class,ProductServer.class,PuductImpl_Stub.class)
download
(Product.class, PuductImpl_Stub.class)
Client
(Product.class, ProductClient.class,client.policy)
La directory download dovrà essere una directory pubblica del server web. Ad
esempio se si usa Tomcat conviene spostarla all’interno della cartella webapps, quindi
copiare al suo interno la cartella WEB-INF prelevata dalla cartella ROOT.
Si verifichi poi dal browser scrivendo http://localhost:8080/download
Avvio Server – Test del Client
Avviare rmiregistry da una shell, non dalla directory server.
Spostarsi nella directory server ed avviare ProductSrever
start java –Djava.rmi.server.codebase=http://localhost:8080/download/ ProductServer
Avviare il client dalla cartella Client
java ProductClient
Se tutto funziona saremo pronti per l’installazione reale su due macchine
Ricordarsi però di cambiare sul client l’indirizzo del server sia nel sorgente di
ProductClient sia nel file di policy
Esercizio
Server: realizzare una classe denominata Corso che, oltre ad altri attributi
contiene un elenco di studenti. Con i metodi:
Studente getStudente(String codice)
TreeSet getLista()
Client: ha un’interfaccia grafica
-inserire il codice studente e mi
visualizza tutte le informazioni dello
studente premendo ‘Cerca’
- premendo ‘Lista’ mostra la lista
completa e ordinata degli studenti

Java lezione 14

  • 1.
    Applicazioni Distribuite Permettono diottimizzare l’uso delle risorse in una rete. Sono realizzate attraverso architetture client-server su tre livelli: (Interfaccia, elaborazione, archiviazione)
  • 2.
    DCOM e ilmodo Microsoft (Distributed Component Object Model). COM è un’istanza di una classe su un server a cui si può accedere solo attraverso i metodi. DCOM permette agli oggetti COM in esecuzione su un computer di creare altri oggetti COM su un’altra macchina. Gli oggetti remoti vengono poi usati come oggetti locali. In Windows tutte le classi sono registrate nel registro di sistema, quindi lo devono essere anche gli oggetti remoti. Gli oggetti remoti comunicano tra loro attraverso un meccanismo RPC (Remote Procedure Call) che poggia sul protocollo UDP o sul protocollo TCP. Inoltre DCOM prevede un’elevata gestione della sicurezza. L’SDK Java di Microsoft consente l’utilizzo di DCOM.
  • 3.
    CORBA (Common Object RequestBroker Architecture). CORBA è simile DCOM object oriented, ma è uno standard aperto. Un oggetto client può utilizzare i metodi di un oggetto server attraverso ORB. L’interfaccia tra ORB e i due lati della comunicazione passa attraverso un IDL (Interface Definition Language) indipendente dal linguaggio di implementazione. L’oggetto client richiama in realtà un oggetto dello Stub IDL corrispondente al metodo remoto. Server Obj Client Obj Stub IDL Model IDL ORB
  • 4.
    SOAP (Simple Object AccessProtocol) Nonostante il SOAP sia un’ innovazione per le comunicazioni, non introduce nuovi concetti in quanto si basa su tecnologia gia esistente e funzionante, e utilizza per il trasporto dei messaggi di richiesta/risposta il protocollo HTTP nel quale i parametri e i comandi sono codificati con XML; inquesto modo si riesce a eliminare il problema della differenza di piattaforma, in quanto XML hauna tecnologia Web estremamente flessibile ed estensibile. Server Obj Client Obj XML XML HTTP
  • 5.
    Esempio richiesta SOAP POST/StockQuote HTTP/1:1 Host: www.stockquoteserver.com Content-Type: text/xml; charset=”utf-8” Content-Lenght: nnnn SOAPAction: “Some-URI” <SOAP-ENV:Envelope> xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m=”Some-URI”> <symbol>DIS</symbol> <m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
  • 6.
    Esempio risposta SOAP HTTP/1.1200 OK Content-Type: Text/xml; charset=”utf-8” Content-Lenght: nnnn <SOAP-ENV:Envelope> xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m=”Some-URI”> <Price>1000$</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
  • 7.
    Java RMI (Remote MethodInvocation). E’ una tecnologia tutta Sun che tuttavia possiede tutti i benefici di CORBA. Anche in RMI si ha dal lato Client uno STUB che funge da Proxy per gli oggetti remoti. Rispetto a CORBA non si ha però IDL e ORB, che invee garantivano con CORBA l’indipendenza dal linguaggio. A livello di trasporto RMI utilizza un normale socket TCP. Sul server gli oggetti devono essere registrati in un registro che deve essere lasciato in esecuzione . Marshalizzazione Tutti gli oggetti che viaggiano su uno stream devono essere serializzati, questo vale ovviamente anche per gli eventuali parametri passati ai metodi e per i valori di ritorno. Ma anche i dati numerici o primitivi devono sempre possedere un formato adatto al trasporto da una JVM all’altra.
  • 8.
    1- Impostazioni server(interfaccia) Il client deve in qualche modo disporre degli oggetti remoti. Si crea a tale scopo una interfaccia che come noto non contiene alcuna implementazione, ma permette di definire un ‘prototipo’ import java.rmi.*; public interface Product extends Remote //sia sul client che sul server { public String getDescription() throws RemoteException; } Si noti che viene estesa la classe Remote e che il metodo remoto lancia un eccezione RemoteException (ad esempio la connessione potrebbe cadere)
  • 9.
    2-Impostazioni server Implementazione Implementiamo ilmetodo che restituirà il risultato import java.rmi.*; import java.rmi.server.*; public class ProductImpl extends UnicastRemoteObject implements Product { public String getDescription() throws RemoteException { return name;} /***********************************************/ public ProductImpl(String n) throws RemoteException { name=n;} /***********************************************/ private String name; } Si noti che viene estesa la classe UnicastRemoteObject
  • 10.
    3-Impostazioni server classe Server Infineè necessario istanziare e registrare gli oggetti sul server import java.rmi.*; import java.rmi.server.*; public class ProductServer { public static void main(String args[]) { try { ProductImpl p1=new ProductImpl(“Lavatrice REX”); ProductImpl p2=new ProductImpl(“Forno Ariston”); Naming.rebind(“lavatrice”,p1); Naming.rebind(“forno”,p2); } catch(Exception e){ e.printStackTrace();} } } Si noti soprattutto la registrazione degli oggetti attraverso un nome.
  • 11.
    4-Impostazioni server Avvio Innanzi tuttoè opportuno settare il CLASSPATH in modo che contenga la directory dove si troveranno le classi compilate. Set classpath=c:rmiprodotti Compilate tutte le classi javac *.java è necessario creare lo stub rmic –v1.2 ProductImpl avviare quindi il registro RMI start rmiregistry (in UNIX rmiregistry &) Quindi avviare la nostra applicazione come servizio start java ProductServer (in UNIX java ProductServer &)
  • 12.
    1-Impostazioni client Avvio Sul clientdovrà risiedere l’interfaccia Product, lo Stub e la classe ProductClient. import java.rmi.*; import java.rmi.server.*; public class ProductClient { public static void main(String[] args) { System.setProperty("java.security.policy", "client.policy"); System.setSecurityManager(new RMISecurityManager()); String url = "rmi://localhost/"; try { Product c1 = (Product)Naming.lookup(url + “lavatrice"); Product c2 = (Product)Naming.lookup(url + “forno"); System.out.println(c1.getDescription()); System.out.println(c2.getDescription()); } catch(Exception e) { e.printStackTrace(); } } } Si noti in particolare il gestore della sicurezza e l’uso del metodo remoto. Esecuzione: java ProductClient
  • 13.
    1-Impostazioni client file client.policy grant { permissionjava.net.SocketPermission "*:1024-65535", "connect,accept"; permission java.net.SocketPermission "localhost:8080", "connect"; };
  • 14.
    Installazione Client-Server Preparare 3directory: Server (Product.class, ProductImpl.class,ProductServer.class,PuductImpl_Stub.class) download (Product.class, PuductImpl_Stub.class) Client (Product.class, ProductClient.class,client.policy) La directory download dovrà essere una directory pubblica del server web. Ad esempio se si usa Tomcat conviene spostarla all’interno della cartella webapps, quindi copiare al suo interno la cartella WEB-INF prelevata dalla cartella ROOT. Si verifichi poi dal browser scrivendo http://localhost:8080/download
  • 15.
    Avvio Server –Test del Client Avviare rmiregistry da una shell, non dalla directory server. Spostarsi nella directory server ed avviare ProductSrever start java –Djava.rmi.server.codebase=http://localhost:8080/download/ ProductServer Avviare il client dalla cartella Client java ProductClient Se tutto funziona saremo pronti per l’installazione reale su due macchine Ricordarsi però di cambiare sul client l’indirizzo del server sia nel sorgente di ProductClient sia nel file di policy
  • 16.
    Esercizio Server: realizzare unaclasse denominata Corso che, oltre ad altri attributi contiene un elenco di studenti. Con i metodi: Studente getStudente(String codice) TreeSet getLista() Client: ha un’interfaccia grafica -inserire il codice studente e mi visualizza tutte le informazioni dello studente premendo ‘Cerca’ - premendo ‘Lista’ mostra la lista completa e ordinata degli studenti