Per java sono disponibili ben tre diversi gui toolkit.
Voglio segnalare tale articolo che illustra pregi e difetti di ognuno di essi: http://www.ibm.com/developerworks/grid/library/os-swingswt/ .
La scelta ovviamente ricade sul gui toolkit più adatto alle nostre esigenze; non è solo una questione di gusto personale.
martedì 15 luglio 2008
mercoledì 11 giugno 2008
Schermare le RemoteException
Consideriamo un'applicazione architettura client server basata su RMI.
Il client deve accedere dialoga con il server usando l'interfaccia remota di quest'ultimo. Per fissare le idee supponiamo che il server abbia la seguente interfaccia:
public interface League extends Remote {
void addTeam(String name) throws RemoteException;
void removeTeam(String name) throws RemoteException;
List getTeamList() throws RemoteException;
int getTeamsCount() throws RemoteException;
}
Come richiesto da RMI, per ogni metodo è specificato che può sollevare una RemoteException. Le RemoteException dovrebbero essere gestita dal client, ovvero le chiamate dei metodi dovrebbero essere racchiuse in un blocco try/catch come il seguente:
TeamManager manager = ...; try { n = manager.getTeamsCount(); } catch(RemoteException ex) { // gestione dell'eccezione }
Se le chiamate al server sono sparse in varie parti del codice del client la gestione delle eccezioni potrebbe diventare tediosa e ripetitiva.
Utilizzando la tecnica descritta di seguito è possibile concentrare la gestione delle RemoteException in un unico punto.
L'idea è quella di interfacciare il codice client con interfaccia simile a quella remota che però non richieda la gestione delle RemoteException, nel nostro caso:
public interface LocalLeague { void addTeam(String name); void removeTeam(String name); List getTeamList(); int getTeamsCount(); }
La soluzione si basa sul concetto di adapter.
Creiamo un oggetto 'adapter' che implementa l'interfaccia locale e delega le chiamate al server remoto. La gestione delle RemoteException e gestita dall'adapter che di fatto le intercetta prima che possano arrivare al client.
La situazione che si vuole ottenere e schematizzata in figura.

Il client utilizza l'interfaccia semplificata (senza RemoteException).
L'adapter inoltra le chiamate al server, e nel caso gestisce la RemoteException catturandola prima che arrivi al client. Dato che il client richiede comunque una risposta nel caso di un'eccezione l'adapter interroga un oggetto fallback che fornisce il valore da restiuire in questi casi.
Nel nostro caso l'oggetto di fallback è il seguetne:
LocalLeague fallback = new LocalLeague() { public void addTeam(String name) { // nothing } public void removeTeam(String name) { // nothing } public List getTeamList() { return Collections.emptyList(); } public int getTeamsCount() { return 0; } };
In oltre l'adapter è in grado di segnalare le eccezioni interfacciandosi con un oggetto ExceptionListener. L'interfaccia ExceptionListener è definita nel package java.beans nel seguente modo:
public interface ExceptionListener { void exceptionThrown(Exception e); }
Fornedo la propria implementazione di ExceptionListener il client può gestire tutte le RemoteException in un unico punto.
La creazione dell'oggetto adapter avviene nel seguente modo:
LocalLeague adapter = AdapterFactory.adapt(LocalLeague.class, remoteServer, fallback, exceptionListener);
Il client deve accedere dialoga con il server usando l'interfaccia remota di quest'ultimo. Per fissare le idee supponiamo che il server abbia la seguente interfaccia:
public interface League extends Remote {
void addTeam(String name) throws RemoteException;
void removeTeam(String name) throws RemoteException;
List
int getTeamsCount() throws RemoteException;
}
Come richiesto da RMI, per ogni metodo è specificato che può sollevare una RemoteException. Le RemoteException dovrebbero essere gestita dal client, ovvero le chiamate dei metodi dovrebbero essere racchiuse in un blocco try/catch come il seguente:
TeamManager manager = ...; try { n = manager.getTeamsCount(); } catch(RemoteException ex) { // gestione dell'eccezione }
Se le chiamate al server sono sparse in varie parti del codice del client la gestione delle eccezioni potrebbe diventare tediosa e ripetitiva.
Utilizzando la tecnica descritta di seguito è possibile concentrare la gestione delle RemoteException in un unico punto.
L'idea è quella di interfacciare il codice client con interfaccia simile a quella remota che però non richieda la gestione delle RemoteException, nel nostro caso:
La soluzione si basa sul concetto di adapter.
Creiamo un oggetto 'adapter' che implementa l'interfaccia locale e delega le chiamate al server remoto. La gestione delle RemoteException e gestita dall'adapter che di fatto le intercetta prima che possano arrivare al client.
La situazione che si vuole ottenere e schematizzata in figura.

Il client utilizza l'interfaccia semplificata (senza RemoteException).
L'adapter inoltra le chiamate al server, e nel caso gestisce la RemoteException catturandola prima che arrivi al client. Dato che il client richiede comunque una risposta nel caso di un'eccezione l'adapter interroga un oggetto fallback che fornisce il valore da restiuire in questi casi.
Nel nostro caso l'oggetto di fallback è il seguetne:
LocalLeague fallback = new LocalLeague() { public void addTeam(String name) { // nothing } public void removeTeam(String name) { // nothing } public List
In oltre l'adapter è in grado di segnalare le eccezioni interfacciandosi con un oggetto ExceptionListener. L'interfaccia ExceptionListener è definita nel package java.beans nel seguente modo:
public interface ExceptionListener { void exceptionThrown(Exception e); }
Fornedo la propria implementazione di ExceptionListener il client può gestire tutte le RemoteException in un unico punto.
La creazione dell'oggetto adapter avviene nel seguente modo:
LocalLeague adapter = AdapterFactory.adapt(LocalLeague.class, remoteServer, fallback, exceptionListener);
giovedì 10 aprile 2008
Salvatore Aranzulla: un hacker, un esperto di sicurezza informatica o solo un ciarlatano ??
Vi rimando alla pagina dell'autore originale:
http://www.linuxedintorni.org/archives/80
http://www.linuxedintorni.org/archives/80
lunedì 25 febbraio 2008
Zimbra

lunedì 17 settembre 2007:
Yahoo! acquisisce Zimbra client web email opensourceYahoo! ha annunciato l’acquisizione di Zimbra, la società che ha creato la web suite che, in un client email sul web, integra contatti, calendari condivisi, supporto mobile, ricerca, e VoIP.
Zimbra, che rimarrà ad essere un progetto open source, verrà acquisita per 350 milioni di dollari in contanti.
Un vero colpo di mercato, in un momento in cui Google sta spingendo per promuovere le sue applicazioni web collaborative in ambiti aziendali: Zimbra è attualmente utilizzato in università, aziende, e rappresenta certamente una alternativa con cui Yahoo! può competere contro Google, che sembra stia per lanciare una versione offline di Gmail.
Realizzato con tecnologia AJAX, Zimbra è in grado di funzionare anche offline, permette di creare mashup grazie agli Zimlets, che permettono l’integrazione del sistema di collaborazione di Zimbra con altri software e servizi, da Skype a Salesforce.
PS:scusate il ritardo, ma questo software l'ho "scoperto" solo ora.
lunedì 15 ottobre 2007
SSH: qualche esempio
SSH (Secure SHell) è un protocollo che permette di stabilire una sessione remota cifrata ad interfaccia a linea di comando con un altro host.Il client SSH ha una interfaccia a linea di comando simile a quella di telnet e rlogin, ma l'intera comunicazione (ovvero sia l'autenticazione che la sessione di lavoro) avviene in maniera cifrata. Per questo motivo, SSH è diventato uno standard de facto per l'amministrazione remota di sistemi unix e di dispositivi di rete, rendendo obsoleto il protocollo telnet, giudicato troppo pericoloso per la sua mancanza di protezione contro le intercettazioni e gli attacchi Man In The Middle (MITM). Il client ed il server SSH sono installati, o è possibile installarli, su molte versioni di UNIX, tra cui Linux e Mac OS X, ma anche su Microsoft Windows, ed è inoltre disponibile come strumento di amministrazione su alcuni apparati di rete.
La sintassi su sistemi UNIX-like è la seguente:
dove con "%" si intende il prompt della shell utilizzata.
Alcuni esempi di utilizzo:
E' la forma più semplice: si apre una connessione verso l'host specificato, autenticandosi come utente nomeutente.
Questa funzionalità è nota come port forwarding. Con questo comando ci si collega ad host1, inoltrando la porta 10022 della macchina in cui lanciamo il client ssh alla porta 22 di host2 attraverso un canale sicuro tra client e host1.
Un esempio d'uso è il seguente. È possibile creare un tunnel se SERVER SSH ha abilitato il forwarding. Questo è normalmente possibile senza installare nessun pacchetto aggiuntivo.Ad esempio, nel seguente scenario
CLIENT --[rete insicura]--> ssh server --[rete sicura]--> TERZA MACCHINA
Se vogliamo utilizzare un desktop remoto sulla terza macchina basta che ci connettiamo al server ssh includendo un tunnel tra una porta locale della macchina dove lavoriamo e la porta 3389 della TERZA MACCHINA. Dopo di che basterà avviare il client RDP e connettersi a localhost:(porta scelta). Il client ssh locale stabilirà una connessione criptata con il server, creerà un tunnel all'interno di questa connessione criptata, ed invierà la connessione RDP su questo tunnel. Il server a sua volta stabilirà una normale sessione TCP con la terza macchina sulla porta richiesta. Come risultato, il client RDP verrà messo in comunicazione con la terza macchina. La connessione tra ssh server e terza macchina non sarà criptata, per cui è opportuno che la comunicazione tra queste due macchine non sia a rischio di intercettazione. La terza macchina vedrà la connessione TCP provenire dal server ssh invece che dal client.
La sintassi su sistemi UNIX-like è la seguente:
% ssh [opzioni] nomeutente@host [comando]
dove con "%" si intende il prompt della shell utilizzata.
Alcuni esempi di utilizzo:
ssh nomeutente@hostE' la forma più semplice: si apre una connessione verso l'host specificato, autenticandosi come utente nomeutente.
ssh host1 -L 10022:host2:22Questa funzionalità è nota come port forwarding. Con questo comando ci si collega ad host1, inoltrando la porta 10022 della macchina in cui lanciamo il client ssh alla porta 22 di host2 attraverso un canale sicuro tra client e host1.
Un esempio d'uso è il seguente. È possibile creare un tunnel se SERVER SSH ha abilitato il forwarding. Questo è normalmente possibile senza installare nessun pacchetto aggiuntivo.Ad esempio, nel seguente scenario
CLIENT --[rete insicura]--> ssh server --[rete sicura]--> TERZA MACCHINA
Se vogliamo utilizzare un desktop remoto sulla terza macchina basta che ci connettiamo al server ssh includendo un tunnel tra una porta locale della macchina dove lavoriamo e la porta 3389 della TERZA MACCHINA. Dopo di che basterà avviare il client RDP e connettersi a localhost:(porta scelta). Il client ssh locale stabilirà una connessione criptata con il server, creerà un tunnel all'interno di questa connessione criptata, ed invierà la connessione RDP su questo tunnel. Il server a sua volta stabilirà una normale sessione TCP con la terza macchina sulla porta richiesta. Come risultato, il client RDP verrà messo in comunicazione con la terza macchina. La connessione tra ssh server e terza macchina non sarà criptata, per cui è opportuno che la comunicazione tra queste due macchine non sia a rischio di intercettazione. La terza macchina vedrà la connessione TCP provenire dal server ssh invece che dal client.
Ubuntu pronta al salto sui server?
Non contenta dell’epocale accordo con Dell per la vendita di PC desktop equipaggiati con Ubuntu 7.04, Canonical sta ora proponendo ai produttori di hardware la preinstallazione dell’edizione server della sua distribuzione. Malgrado la società di Mr. Shuttleworth sia estremamente interessata al raggiungimento di un accordo, è conscia che, come per i desktop, anche per i server la decisione finale dei produttori sarà basata sulle richieste dei clienti più che sulla bontà della distribuzione.
E voi, richiedereste specificatamente Ubuntu per un vostro server o la considerereste come semplice alternativa al bundling di Windows?
E voi, richiedereste specificatamente Ubuntu per un vostro server o la considerereste come semplice alternativa al bundling di Windows?
Something about me
ciao a tutti. ho aperto questo blog spinto dalla curiosità.
ovviamente inizio presentandomi: sono uno studente di informatica presso l'università di pisa e sono appassionato di tutto ciò che riguarda l'informatica.
in questo blog, quindi, raccoglierò un pò di cose riguardanti questa mia passione.
ovviamente inizio presentandomi: sono uno studente di informatica presso l'università di pisa e sono appassionato di tutto ciò che riguarda l'informatica.
in questo blog, quindi, raccoglierò un pò di cose riguardanti questa mia passione.
Iscriviti a:
Post (Atom)