mercoledì 19 novembre 2008

ABSTRACT: Community portal integrato

Realizzazione di un'applicazione di community portal aziendale conforme allo standard JSR-168, con integrazione di funzionalità di Customer Relationship Management

Il tirocinio in oggetto è stato svolto presso l’azienda Silnet S.A.S., con sede a S. Martino Ulmiano (PI) e ha come obiettivo la realizzazione di un portale integrato con un CRM (Customer relationship management).

Gli obiettivi prefissati erano di raccogliere le informazioni inerenti le attività degli utenti del portale e analizzarle, per poi far avere un comportamento proattivo ad esso.

Per arrivare alla produzione del prodotto in questione, si sono susseguite varie fasi: analisi dei requisiti, progettazione, installazione e configurazione del software di terze parti necessario, studio della tecnologia riguardante le portlet e i CRM, realizzazione del portale e integrazione di esso con il CRM, testing e rilascio.

Per quanto riguarda i software di terze parti, sono stati utilizzati:

  • eXo platform: per la realizzazione del portale
  • SugarCRM: come strumento di CRM
  • Hibernate: come framework di comunicazione con il database.

Tali software, sono stati scelti dal tutore aziendale. L’azienda aveva già precedenti esperienze con il framework Hibernate e con SugarCRM. Il software eXo platform, invece, è stato utilizzato per la prima volta durante il lavoro di tirocinio.

Bisogna sottolineare che, pur esistendo una qualche forma di comunicazione tra strumenti di CRM e portal container, di comune accordo con il tutore aziendale è stato scelto di utilizzare solamente software open source e di realizzare tale integrazione partendo da zero.

In particolare, eXo, pur fornendo una grande varietà di portlets, non mette a disposizione nessuna applicazione preesistente che permetta di raggiungere gli scopi richiesti. È stato scelto, quindi, di implementare ex novo una portlet che permetta il recupero dei dati dell’utente e il salvataggio di questi in un database. Tale portlet viene aggiunta in ogni pagina e ha un comportamento totalmente invisibile per l’utente del portale, in quanto essa non fornisce una pagina di visualizzazione, o meglio ne fornisce una vuota.

I dati così raccolti sono stati resi persistenti tramite l’uso di un database. È stato scelto di utilizzare un database MySQL per la sua semplicità di installazione e configurazione, per le “esigue” risorse necessarie, ma soprattutto per il suo pieno supporto da parte del software di CRM preso in esame. Si sarebbe potuto, però, usare un qualsiasi altro database, open source o meno, purché compatibile con il framework Hibernate, dato che la persistenza dei dati è stata resa possibile dall’uso di quest’ultimo.

Alla fine del tirocinio, sono stati raggiunti gli obiettivi prefissati, se pur sotto alcune ipotesi che verranno discusse in seguito, come l’ipotesi che esista già un’associazione tra lo username di un utente del portale e la sua anagrafica, memorizzata nel CRM. Tali ipotesi sono state assunte poiché la creazione di questa associazione esula dagli obiettivi del tirocinio.

Questa relazione di tirocinio è divisa in varie sezioni.

Nel primo capitolo si descrivono brevemente i requisiti del sistema, sorti dopo un’analisi fatta in collaborazione con il tutore aziendale.

Nella seconda vengono illustrati i software di terze parti utilizzati, quindi vengono presi in esame eXo platform e SugarCRM.

Nel terzo capitolo vi è un’ampia e approfondita analisi delle tecnologie con cui ho avuto a che fare: le portlets (descrizione approfondita delle portlet 1.0 e cenni di portlet 2.0), i CRM e il framework Hibernate.

Nel quarto capitolo viene descritto il lavoro effettivamente svolto.

Il capitolo conclusivo include gli obiettivi raggiunti, il grado di soddisfacimento, le competenze acquisite e eventuali sviluppi futuri.

Seguono una sezione riguardante la bibliografia/sitografia e un’appendice che raccoglie il codice.

martedì 15 luglio 2008

AWT, Swing, SWT

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.

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);

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:

% ssh [opzioni] nomeutente@host [comando]


dove con "%" si intende il prompt della shell utilizzata.
Alcuni esempi di utilizzo:

ssh nomeutente@host


E' la forma più semplice: si apre una connessione verso l'host specificato, autenticandosi come utente nomeutente.

ssh host1 -L 10022:host2:22


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.

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?