Universit degli Studi di PadovaFacolt di Scienze Matematiche, Fisiche e Naturali Corso di Laurea in Informatica

Tesi di Laurea

Sviluppo di unintranet aziendale realizzata con Liferay nellambito del Web 2.0

Relatore: Prof.ssa Francesca Rossi

Candidato: Mattia Bazzega

Anno Accademico 2011-2012

Alla mia famiglia

Indice1 Introduzione 1.1 Scopo dello stage . . . . . . . . . . . 1.2 Motivazioni allorigine del progetto . 1.2.1 Il Web 2.0 . . . . . . . . . . 1.2.2 Intranet aziendali e Web 2.0 1.3 Ambiente aziendale . . . . . . . . . . 2 Elementi e funzionamento di un portale 2.1 Definizioni generali . . . . . . . . . . 2.2 Esempio di una sequenza di eventi . 2.3 Creazione di una pagina del portale . 2.4 Linterfaccia Portlet . . . . . . . . . 2.5 Ciclo di vita di una portlet . . . . . . 2.5.1 Caricamento e istanziazione 2.5.2 Inizializzazione . . . . . . . 2.5.3 Portlet Window . . . . . . 2.5.4 Gestione delle richieste . . . 2.5.5 Distruzione della portlet . . 2.6 Modello dei dati della portlet . . . . 2.7 Limiti della specifica JSR-168 . . . . 9 9 10 10 11 13 15 15 18 18 19 19 21 21 22 23 26 26 27 29 29 31 33 34 35 36 36 36 37 38 38 39 40

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 La piattaforma Liferay Portal 3.1 Introduzione a Liferay Portal . . . . . . . . 3.2 Panoramica delle caratteristiche del portale 3.3 Funzioni di collaborazione . . . . . . . . . . 3.4 Gestione degli utenti e gruppi . . . . . . . . 3.4.1 Utenti . . . . . . . . . . . . . . . . 3.4.2 Gruppi di utenti . . . . . . . . . . 3.4.3 Organizzazioni . . . . . . . . . . . 3.4.4 Comunit . . . . . . . . . . . . . . 3.4.5 Ruoli . . . . . . . . . . . . . . . . 3.5 Scope . . . . . . . . . . . . . . . . . . . . . 3.6 Architettura e framework . . . . . . . . . . 3.6.1 Service Oriented Architecture . . . 3.6.2 Enterprise Service Bus . . . . . . . 5 di 113

INDICE 3.6.3 Spring . . . . . . . . . . Strategie di sviluppo del portale . 3.7.1 Ambiente Plugins SDK 3.7.2 Ambiente Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 41 42 43 45 45 46 47 49 49 50 51 51 52 53 53 53

3.7

4 Analisi dei requisiti 4.1 Euris Due.Zero . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Problemi e mancanze . . . . . . . . . . . . . . . . . . 4.1.2 Lista dei requisiti . . . . . . . . . . . . . . . . . . . . 5 Ambiente e strumenti di lavoro 5.1 Installazione e configurazione del portale 5.1.1 Ambiente Ext . . . . . . . . . . 5.1.2 Ambiente Plugins SDK . . . . 5.2 Strumenti utilizzati . . . . . . . . . . . . 5.2.1 Requisiti per linstallazione . . 5.2.2 Database . . . . . . . . . . . . 5.2.3 Application server . . . . . . . 5.2.4 IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Stabilizzazione dellapplicazione web 55 6.1 Modifica del messaggio di benvenuto . . . . . . . . . . . . . . 55 6.2 Redirect dopo lautenticazione dellutente . . . . . . . . . . . 59 6.3 Filtraggio attivit di modifica pagine Wiki . . . . . . . . . . . 67 7 Sviluppo di nuove funzionalit 7.1 Sistema per la modifica dei documenti . 7.1.1 Realizzazione dellapplet . . . . 7.2 Visualizzazione di un documento . . . . 7.3 Sviluppo portlet . . . . . . . . . . . . . . 7.3.1 Portlet per le informazioni . . . 7.3.2 Portlet per la pagina daccesso 7.3.3 Portlet per gli interessi utente . 7.3.4 Portlet per i feedback . . . . . 8 Conclusioni Glossario Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 71 77 82 88 93 94 97 100 107 109 113

6 di 113

Elenco delle figureRaffigurazione di una pagina formata da portlet. . . . . . . . . . . . Creazione di una pagina del portale. . . . . . . . . . . . . . . . . . Package javax.portlet che contiene linterfaccia Portlet. . . . . Diagramma di macchina a stati che specifica il ciclo di vita di una portlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Caricamento di una pagina del portale. . . . . . . . . . . . . . . . . 2.6 Process di unaction. . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Organizzazione delle risorse umane e loro gruppi nel portale. . . . . 3.2 Architettura di Liferay Portal. . . . . . . . . . . . . . . . . . . . . . 3.3 Strategie di sviluppo di Liferay. . . . . . . . . . . . . . . . . . . . . 3.4 Funzionamento dellambiente Plugins SDK. . . . . . . . . . . . . . 3.5 Funzionamento dellambiente Extension. . . . . . . . . . . . . . . . 6.1 Messaggio di benvenuto visibile nel pulsante del pannello di controllo in diverse situazioni. . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Diagramma di interazione del pattern architetturale MVC. . . . . . 6.3 Portlet di autenticazione al portale. . . . . . . . . . . . . . . . . . . 6.4 Portlet per il tracciamento delle attivit. . . . . . . . . . . . . . . . 7.1 Applet per la modifica dei documenti. . . . . . . . . . . . . . . . . . 7.2 Finestra informativa dellapplet. . . . . . . . . . . . . . . . . . . . . 7.3 Richiesta delle credenziali per la modifica di un documento. . . . . 7.4 Viewer incorporato nella pagina. . . . . . . . . . . . . . . . . . . . 7.5 Portlet per le informazioni su una comunit. . . . . . . . . . . . . . 7.6 Portlet per laccesso alle comunit. . . . . . . . . . . . . . . . . . . 7.7 Singola comunit visualizzata dalla portlet. . . . . . . . . . . . . . . 7.8 Categorie associate agli interessi/competenze di un utente. . . . . . 7.9 Portlet per gli interessi/competenze di un utente. . . . . . . . . . . 7.10 Portlet per linvio di feedback. . . . . . . . . . . . . . . . . . . . . . 2.1 2.2 2.3 2.4 . 16 . 18 . 19 . . . . . . . . . . . . . . . . . . . . . . 20 24 25 35 39 42 43 44 58 62 66 67 80 80 81 87 94 95 96 97 98 101

7 di 113

ELENCO DELLE FIGURE

8 di 113

Capitolo 1IntroduzioneIn questo primo capitolo si spiegheranno le motivazioni e gli scopi che hanno portato alla realizzazione di questo stage. In particolare si introdurr brevemente il contesto web sul quale si poggia la piattaforma Liferay Portal e come questa possa essere utilizzata al fine aziendale. Nel secondo capitolo verranno riportati i concetti principali sui quali si fonda lapplicazione web, facendo una panoramica sul suo funzionamento generale. Larchitettura verr poi illustrata dettagliatamente nel terzo capitolo, nel quale si descriveranno anche le varie funzionalit offerte dalla piattaforma in questione. Nel quarto capitolo, invece, si evidenzieranno i diversi problemi, pi o meno significativi, e le mancanze riscontrate allinterno dellapplicazione web. Nel capitolo 5 si parler dellambiente e degli strumenti di lavoro necessari ad eseguire le dovute modifiche al portale. I capitolo 6 e 7 saranno invece dedicati alla stabilizzazione dellapplicazione web con conseguente correzione dei problemi in essa rilevati e alla successiva implementazione di nuove funzionalit richieste dallazienda. Lultimo capitolo sar destinato alle conclusioni e alle considerazioni personali sullattivit di stage.

1.1

Scopo dello stage

Lo scopo dello stage stato quello di esplorare il grado di stabilit e completezza funzionale della piattaforma utilizzata per la realizzazione dellintranet aziendale che ingloba funzionalit tipiche del Social Network con funzionalit strettamente aziendali. Lattivit ha sfociato quindi nello sviluppo di alcune delle funzionalit necessarie per soddisfare le esigenze dellazienda e nellintegrazione della suddetta piattaforma con strumenti aziendali di frequente utilizzo. 9 di 113

CAPITOLO 1. INTRODUZIONE

1.2

Motivazioni allorigine del progetto

Per parlare delle motivazioni allorigine dello sviluppo dellintranet aziendale, necessario innanzitutto definire al meglio il contesto duso della piattaforma. Infatti, questultima fondata sul paradigma del cosiddetto Web 2.0, in quanto lintranet sta divenendo sempre pi sociale. Si pu parlare, come si vedr in seguito, di Intranet 2.0 nella quale integrato il famoso strato 2.0. Socializzare linformazione ci che sta alla base di questo nuovo modo di comunicare, consentendo agli utenti di condividere e promuovere qualunque contenuto della Intranet con i colleghi, interagire con essi e fare in modo cos di migliorare la comunicazione top-down: questultima non scomparir, ma ha bisogno di rinnovarsi per diventare pi utente-centrica ed interattiva.

1.2.1

Il Web 2.0

La piattaforma Liferay Portal strettamente legata al concetto di Web 2.0 di cui qui di seguito ne verr data una panoramica, traendo come fonte principale un importante articolo di Tim OReilly su questo tema [1]. In questo articolo, lautore, che in effetti uno degli inventori della formula, cerca di ripercorrere la nascita del termine, proposto nellambito dellincontro tra la OReilly stessa e Medialive International, volto ad organizzare la prima conferenza riguardo il Web 2.0. Lidea di promuovere una conferenza con tale titolo nata dalla presa di coscienza, sostiene OReilly, che, dopo lesplosione della Bolla di Internet nel 2001, sia gradualmente emerso un nuovo modo di concepire il Web. Il fatto che dopo la crisi di molte societ, gettatesi a capofitto nella rete sperando di trarne veloci e facili profitti, alcuni abbiano sostenuto che lera del Web fosse giunta al termine, mentre altri ancora che il fenomeno fosse proprio di tutte le rivoluzioni industriali, , secondo i promotori della conferenza, caratteristico di una tecnologia che sta per entrare in una nuova fase. Ben lontano dallessere in declino, il Web non sarebbe mai stato cos importante dato che, di giorno in giorno, con una regolarit sorprendente, compaiono nuovi siti e applicazioni dal carattere innovativo. Inoltre, le societ che erano sopravvissute al collasso, sembravano avere alcune caratteristiche in comune. Quindi, le due societ concordarono sullanalisi per cui il collasso delle dot-com 1 avesse segnato per la rete un punto di svolta tale che un richiamo allazione definito come Web 2.0 potesse avere senso. OReilly cerca di dare una definizione compatta del concetto in questione. Infatti, specifica che il Web 2.0 la rete come piattaforma, attraverso tutti i dispositivi ad essa connessi. Inoltre, le applicazioni Web 2.0 sono quelle che potenziano i vantaggi intrinseci di tale piattaforma: fornendo programmi come servizi continuamente aggiornati che migliorano man mano che le persone nedot-com: societ di servizi che sviluppano la maggior parte del proprio business tramite un sito web1

10 di 113

1.2. MOTIVAZIONI ALLORIGINE DEL PROGETTO fanno uso, consumando e rimescolando dati da molteplici sorgenti, includendo i singoli utenti, distribuendo i loro stessi dati e servizi in una forma che ne permette il rimescolamento da parte di altri, creando una comunit attraverso unarchitettura della partecipazione, e superando la metafora della pagina del Web 1.0 per offrire allutente ricche esperienze. Nellarticolo OReilly cerca di chiarire gli aspetti di tale mutamento e i principi fondanti del Web 2.0, ponendo a confronto una serie di siti ed applicazioni, che potrebbero essere considerati i portabandiera di una nuova concezione della Rete, contro altri, che esemplificherebbero i paradigmi precedenti alla Bolla del 2001, dimostratisi, questi s, superati. I punti cardine di questa evoluzione del Web risultano quindi essere la partecipazione degli utenti (e di conseguenza il formarsi di unintelligenza collettiva), la trasformazione dei dati (remixability) e la loro creazione da parte degli utenti (user-generated content) ed infine il cambiamento di rotta del design centrato sulle esigenze dellutente. Se, dunque, la prima forma di Internet stata caratterizzata da una partecipazione passiva degli utenti, in quanto concepita come modo per la visualizzazione di soli documenti ipertestuali statici, il Web 2.0 rappresentato da tutta una generazione di funzioni e di servizi contraddistinti da una cooperazione attiva e creativa degli utenti, i quali contribuiscono a produrre conoscenze. Le strutture del Web 2.0 si costruiscono dal basso, per effetto di apporti minimi ma costanti in continuo confronto e interazione. Il protagonismo partecipativo degli utenti e la crescente mediazione tecnologica dellattivit comunicativa giustificano in pieno la nozione di intelligenza collettiva, anzi connettiva, distribuita ovunque, coordinata nella dimensione sincronica, che alcuni hanno proposto per indicare le attivit cognitive che si svolgono in rete e grazie alla rete.

1.2.2

Intranet aziendali e Web 2.0

Le intranet aziendali, grazie al Web 2.0, stanno cambiando per trasformarsi in nuovi spazi sociali nei quali lavoro, comunicazione e condivisione si sovrappongono e dove relazioni e processi si intersecano per dare vita a vere community. Si pu dunque riferirsi ad unIntranet 2.0, intendendo, innanzitutto, levoluzione delle tradizionali intranet verso un modello e degli standard di eccellenza guidati dalle migliori pratiche a livello mondiale. Si pu parlare di nuovi standard che tutte le intranet dovrebbero adottare per avere successo. Per quanto riguarda gli utilizzi dellintranet 2.0, si pu dire che la sua vera sfida quella di traghettare gli scambi dai canali alle piattaforme, valorizzando insieme le potenzialit di comunicazione, partecipazione e condivisione allo scopo di lavorare meglio. necessario tenere in considerazione che ci possono essere varie situazioni aziendali e che, quindi, la struttura deve supportare ciascun membro nelle diverse fasi delloperare (lavorare, collaborare, condividere, 11 di 113

CAPITOLO 1. INTRODUZIONE contribuire) allinterno dei diversi contesti (da solo, team, dipartimento, community, ecosistema). In tutte queste condizioni distinte, infatti, cambiano i contenuti e gli obiettivi, ma anche limpegno che richiesto e il tipo di contributo che le persone possono dare (lavorare diverso da collaborare che diverso da condividere che diverso da contribuire). Anche i parametri della partecipazione variano: in alcuni casi gli oggetti dellIntranet servono ad una specifica risorsa, in altri sono a disposizione di tutti i dipendenti e in alcuni casi sono dedicati a piccoli gruppi che interagiscono. Sempre pi spesso, al momento di riprogettare o semplicemente rinnovare la propria intranet molte imprese oggi si pongono la questione di quanto e come sia opportuno integrare dimensioni pi sociali, partecipate, collaborative allinterno delliniziativa. Questa esplosione in direzione Enterprise 2.0 2 riproposta con forza dai risultati dellIntranet 2.0 Global Survey 2010 [2] pubblicato da Toby Ward e Prescient Digital Media che ha coinvolto 526 aziende di ogni dimensione, settore e localizzazione geografica. Le indicazioni pi rilevanti estrapolate da questo studio si possono elencare di seguito: i social media sono ormai sdoganati allinterno delle intranet con una qualche presenza nell87% dei casi, mentre solo il 10% delle organizzazioni non sta nemmeno considerando tali modalit per il futuro; in compenso la partecipazione dei dipendenti lascia ancora molto a desiderare; i bisogni che vengono raccolti sono guidati innanzitutto dalla collaborazione tra i dipendenti (77%) e la gestione della conoscenza (71%). A seguire il coinvolgimento dei dipendenti (56%) e le comunicazioni dallalto (40%); circa met (47%) dei progetti riguardo lintranet 2.0 hanno meno di due anni e questo conferma il lungo lavoro ancora da fare sulladozione e sul raffinamento degli strumenti; si inizia a diffondere lidea che non introdurre gli strumenti collaborativi rischi di precludere significative opportunit allazienda. In cima alla lista degli strumenti pi usati ci sono blog (53%), forum (52%), istant messaging (51%), wiki (49%) mentre il social networking si attesta al 27%, ma anche la componente in crescita maggiore; per quanto riguarda le tecnologie di riferimento, pi di tre quarti delle aziende (77%) si avvalgono di un sistema di gestione dei contenuti (CMS) per le loro intranet; relativamente al livello di soddisfazione, il 46% delle organizzazioni giudicano buono il servizio offerto dallintranet 2.0 e questo numero indicaEnterprise 2.0: luso di specifiche applicazioni del nuovo web riadattate allinterno dellorganizzazione per gestire, in genere, la conoscenza aziendale2

12 di 113

1.3. AMBIENTE AZIENDALE unevoluzione sia degli strumenti, che della comprensione da parte degli utenti che non pu che far bene alla sua maturazione allinterno del contesto aziendale. Quindi, in definitiva, da quanto detto si comprende che, cos come per i servizi del Web 2.0 si assistito ad un sostanziale cambiamento dei flussi di origine dellinformazione, la gestione della conoscenza aziendale sta prendendo spunto da fenomeni di condivisione sociale di nuova concezione per trasformarsi. Infatti, da intranet intese come classici sistemi di gestione documentale in cui le informazioni vengono elaborate da redazioni od organi istituzionali e veicolate verso la base di utenti, oggi si parla sempre pi spesso di architetture flessibili di Knowledge Management e di e-learning molecolare in cui il sapere viene prodotto e codificato dagli stessi utilizzatori finali che, a seconda delle specifiche competenze, permettono ai colleghi di accedere a informazioni trasmesse generalmente solo per via informale.

1.3

Ambiente aziendale

Lo stage stato svolto presso lazienda Gruppo Euris S.p.A. nella sua sede di Padova. Questultima opera da pi di ventanni nel settore IT, con lobiettivo di realizzare software customizzati per organizzazioni di media e grande dimensione. Durante la permanenza in azienda sono stato supportato dalla mia tutor, Nicoletta Bressan, la quale ha dimostrato grandi capacit e conoscenze. Infatti, mi ha seguito nello svolgimento del progetto, dandomi dei feedback su quanto fatto ed aiutandomi in tutte le varie fasi percorse. Lazienda, inoltre, mi ha messo a disposizione risorse hardware e software sufficienti per svolgere al meglio il lavoro affrontato.

13 di 113

CAPITOLO 1. INTRODUZIONE

14 di 113

Capitolo 2Elementi e funzionamento di un portaleIn questo capitolo ci si occuper di fornire alcune nozioni fondamentali necessarie ad introdurre la piattaforma Liferay Portal. In particolare, i concetti che si illustreranno verranno corredati da figure e descrizioni utili a far comprendere non solo la loro funzione, ma anche altri aspetti ad essi correlati per avere unampia visione sullargomento.

2.1

Definizioni generali

Sono sostanzialmente tre i concetti base che consentono di presentare questo argomento, ossia: portale; portlet; portlet container. Innanzitutto, necessario specificare cosa sintende con il termine portale. Confrontando pi fonti si ottenuto di poter identificare il portale con un servizio che opera da mediatore di informazione (infomediario) a favore degli utenti della rete, permettendo a questi di raggiungere, tramite un particolare punto di ingresso nella rete, una grande quantit delle risorse esistenti. Un portale sostanzialmente un aggregatore di informazione che offre un servizio di navigazione sul web facilitando il lavoro di ricerca: nati come evoluzione dei motori di ricerca, i portali hanno associato agli strumenti tipici di questi (search engine e categorizzazione delle informazioni) altri servizi, informativi e non, allo scopo di proporsi come accesso preferenziale e guida per la navigazione via Internet. Generalmente i portali sono costruiti e manutenuti con componenti software 15 di 113

CAPITOLO 2. ELEMENTI E FUNZIONAMENTO DI UN PORTALE dinamiche chiamate portlet. Una portlet un modulo web realizzato in tecnologia Java riusabile allinterno di un portale web. Attraverso le portlet possibile generare contenuti dinamici e, di conseguenza, gestirne la personalizzazione. Inoltre, tramite esse possibile integrare contenuti provenienti da diverse sorgenti. Il contenuto generato da una portlet denominato anche frammento. Questultimo del markup (ad esempio HTML, XHTML, WML) che aderisce a certe regole e che pu essere aggregato ad altri frammenti per costituire un documento completo. Il frammento di una stessa portlet pu variare da un utente allaltro a seconda della configurazione apportata ad essa. Diverse portlet, integrate insieme, concorrono a creare una singola pagina del portale.

Figura 2.1: Raffigurazione di una pagina formata da portlet. 16 di 113

2.2. ESEMPIO DI UNA SEQUENZA DI EVENTI Inoltre, una stessa portlet pu essere utilizzata in pi pagine. Visivamente, le portlet sono porzioni di pagina e funzionalmente sono dei canali informativi. Lapplicazione di questa modularit permette agli utenti di costruirsi un portale personalizzato, semplicemente scegliendo dove, come e in quale pagina disporre le portlet con diversi contenuti. Le portlet sono identificabili come un tipo speciale di Servlet, progettate per essere inserite facilmente in un portal server ed essere eseguite. Quindi, come si pu osservare, lutente finale costruisce una pagina per aggregazione dei singoli elementi, avendo come risultato finale una pagina web configurabile ed adattabile alle sue volont. Tecnicamente, la rappresentazione finale affidata per gran parte al portlet container che, come si vedr dettagliatamente in seguito, gestisce il loro ciclo di vita. Infatti, il suo compito di seguire le azioni dellutente (link, form, javascript, ecc.), eseguire la logica di business di tutte le portlet presenti nella pagina ed infine passare al portale i frammenti generati dalle stesse. In seguito il portale aggrega il risultato proveniente da ognuna di esse in un pannello tipo quello in figura 2.1. Per consentire la portabilit tra i vari portlet container commerciali, stata fatta richiesta al Java Community Process (JCP) di formalizzare uno standard apposito per le portlet, lo standard JSR-168 (Java Portlet Specification 1.0 [3]). Questultimo stato rilasciato nel 2003 e al gruppo di lavoro hanno partecipato diverse importanti aziende tra le quali Apache Software Foundation, IBM, Sun Microsystems, Oracle. La specifica ha definito un insieme di interfacce applicative (API) per linteroperabilit fra un portlet container e le portlet. In particolare, ha fissato i seguenti punti: il ruolo e le funzionalit dei portlet container; il contratto tra il container e le portlet; la gestione del ciclo di vita delle portlet; il packaging per la distribuzione delle portlet; linterazione con lo standard WSPR (Web Services for Remote Portlets) che definisce un protocollo standard per il dialogo tra il container e le portlet. Il portlet container, dunque, contiene le portlet e gestisce il loro ciclo di vita. Si occupa di immagazzinare le preferenze e le configurazioni di ogni portlet. Inoltre, riceve le request dal portale e le indirizza alle portlet che gestisce. Un portlet container non per responsabile dellaggregazione dei contenuti generati dalle diverse portlet. Questo , infatti, compito del portale. Portale e container possono essere integrati insieme come un componente singolo di una suite di applicazioni oppure come due parti separate di una portal application. 17 di 113

CAPITOLO 2. ELEMENTI E FUNZIONAMENTO DI UN PORTALE

2.2

Esempio di una sequenza di eventi

Qui di seguito si pu riportare una tipica sequenza di eventi, che inizia dal momento in cui un utente accede alla pagina del portale: un client (ad esempio un browser web), dopo essersi autenticato, esegue una richiesta HTTP al portale; la richiesta viene ricevuta dal portale; il portale determina se la richiesta contiene unazione mirata su una qualsiasi delle portlet associate alla pagina; se c unazione indirizzata ad una portlet, il portale richiede al portlet container di invocare la portlet per processare lazione; attraverso il container, il portale invoca le portlet per ottenere i frammenti generati da esse che possono essere inclusi nella pagina risultante; il portale aggrega gli output delle diverse portlet nella pagina e rimanda questultima al client.

2.3

Creazione di una pagina del portale

Il portlet container riceve i vari contenuti generati dalle diverse portlet. Poi, tipicamente, li passa al portale, il quale crea la pagina aggregando i vari frammenti delle portlet e la invia al dispositivo client (un browser) dove viene visualizzata. Il meccanismo appena descritto si pu riportare nella seguente figura.

Figura 2.2: Creazione di una pagina del portale. 18 di 113

2.5. CICLO DI VITA DI UNA PORTLET Gli utenti possono accedere ad un portale utilizzando un comune browser web. Al momento di ricevere la richiesta della pagina, il portale determina la lista di portlet di cui necessita per soddisfare la richiesta e, attraverso il portlet container, le invoca. In tal modo, il portale crea la pagina con i frammenti generati dalle portlet che viene ritornata al client dov presentata allutente.

2.4

Linterfaccia Portlet

Linterfaccia Portlet la principale astrazione delle Portlet API. Tutte le portlet implementano questa interfaccia o direttamente oppure, pi comunemente, estendendo una classe che la implementa. La specifica, infatti, include la classe GenericPortlet che implementa linterfaccia Portlet e fornisce delle funzionalit di base. Gli sviluppatori dovrebbero estendere, direttamente o indirettamente, tale classe per implementare le loro portlet.javax.portlet

Portlet + destroy() : void + init(config : javax.portlet.PortletConfig) : void + processAction(request : javax.portlet.ActionRequest, response : javax.portlet.ActionResponse) : void + render(request : javax.portlet.RenderRequest, response : javax.portlet.RenderResponse) : void

GenericPortlet

Figura 2.3: Package javax.portlet che contiene linterfaccia Portlet.

2.5

Ciclo di vita di una portlet

Una portlet gestita attraverso un ciclo di vita ben definito che determina come caricata, istanziata ed inizializzata, in che modo tratta le richieste che provengono dai client e come le soddisfa. Il ciclo di vita di una portlet per molti aspetti analogo al corrispettivo ciclo delle servlet. Le varie fasi sono individuate dai tre seguenti stati: 19 di 113

CAPITOLO 2. ELEMENTI E FUNZIONAMENTO DI UN PORTALE caricamento delle classi e inizializzazione; gestione della request; distruzione della portlet. Tutte le fasi sopracitate sono gestite attraverso quattro metodi esposti dallinterfaccia Portlet: init, che viene chiamato dal container quando la portlet viene inizializzata; destroy, metodo invocato dal container quando la portlet viene distrutta; processAction, chiamato dopo che lutente ha effettuato una richiesta e serve a processare i dati avuti in input; render, il quale va in esecuzione ogni volta che la portlet si visualizza nella pagina web. Il ciclo di vita di una portlet pu essere riassunto nel diagramma di stato sottostante.

SM1.1 Caricamento

SM1.2 Istanziazione

SM1.3 Inizializzazione

Gestione delle richieste

SM1.4 processAction

SM1.5 - render

End Of Service / s End Of Service ? / no

SM1.6 Distruzione

Figura 2.4: Diagramma di macchina a stati che specifica il ciclo di vita di una portlet. 20 di 113

2.5. CICLO DI VITA DI UNA PORTLET Di seguito si descriveranno dettagliatamente tutte le operazioni che avvengono nel ciclo di vita.

2.5.1

Caricamento e istanziazione

Il meccanismo di base del caricamento di una portlet non diverso da quello adottato da ogni altra applicazione Java EE. Il portlet container, che responsabile del caricamento (stato SM1.1 nel diagramma 2.4) e della conseguente istanziazione (stato SM1.2 nel diagramma 2.4) delle portlet, procede secondo le regole (e le priorit) dellapplication server sul caricamento delle classi e delle librerie presenti allinterno dellarchivio di Deploy dellapplicazione. Entrambe queste operazioni possono avvenire quando il container avvia lapplicazione portlet, oppure vengono ritardate fino a che esso determina che la portlet necessita di servire una richiesta arrivatale. Il portlet container deve caricare la classe della portlet usando lo stesso ClassLoader del servlet container utilizzato per la parte di applicazione web dedicata alla portlet, in modo che la classe principale e le classi di supporto possano condividere lo stesso spazio di indirizzamento. Dopo aver caricato le classi, il portlet container le istanzia per il loro uso.

2.5.2

Inizializzazione

Dopo che loggetto portlet istanziato, il portlet container deve inizializzarlo prima di invocarlo per gestire la richiesta del client. Linizializzazione (stato SM1.3 nel diagramma 2.4) avviene al momento dello startup dellapplicazione o del portal server (se specificato il parametro di autostart) o in alternativa al momento della prima invocazione da parte del client. Linizializzazione deve essere eseguita per fare in modo che le portlet possano inizializzare a loro volta delle risorse dispendiose (come, ad esempio, le connessioni al backend) e compiere tutta una serie di altre attivit. Il container inizializza loggetto portlet chiamando il metodo init che presenta come parametro di invocazione il contesto di configurazione, definito dallinterfaccia PortletConfig del package javax.portlet. Questultimo oggetto fornisce laccesso ai parametri di configurazione e consente alla portlet, inoltre, di accedere ad un oggetto di contesto che descrive il suo ambiente desecuzione. Analogamente al caso delle servlet, fino a che il metodo init non termina la sua esecuzione, la portlet non disponibile per lesecuzione. Per questo motivo bene non imporre lunghe procedure di inizializzazione, cos come sbagliato invocare nel metodo init metodi che necessitino della portlet in uno stato vivo e funzionante. Eccezioni durante linizializzazione Durante la fase di inizializzazione una portlet pu andare incontro a problemi di 21 di 113

CAPITOLO 2. ELEMENTI E FUNZIONAMENTO DI UN PORTALE varia natura che ne possono pregiudicare o meno il funzionamento successivo. Si possono infatti verificare problemi temporanei (che con una qualche operazione di recovery possono essere risolti agilmente) o incidenti definitivi (mancanza della connessione al database, un importante file di configurazione non viene trovato o un altro grave problema che pregiudica lesecuzione della portlet). Una portlet, dunque, pu notificare al portal server queste due situazioni lanciando le eccezioni di tipo PortletException o UnavailableException secondo lo schema seguente: throws new PortletException(Messaggio) : il problema provvisorio e il container pu tentare di riattivare la portlet in seguito; throws new UnavalaibleException(Messaggio) : il problema grave e non si deve riattivare la portlet; throws new UnavalaibleException(Messaggio, n) : il problema grave ma risolvibile: in tal caso si comunica al portlet container che pu essere tentata una successiva inizializzazione della portlet fra n secondi; throws new UnavalaibleException(Messaggio, 0) : in questo caso si ipotizza un problema non grave per il quale per non possibile determinare quando potr essere riattivata la portlet. Il container tenter nuovamente linizializzazione dopo una pausa arbitrariamente lunga. Il container, quindi, pu riprovare in qualsiasi momento ad istanziare ed inizializzare le portlet dopo un insuccesso, a meno che una UnavailableException indichi un tempo minimo di indisponibilit. Se ci accade, il portlet container deve aspettare un determinato tempo prima di creare ed inizializzare un nuovo oggetto portlet. Durante linizializzazione, inoltre, uneccezione di tipo RuntimeException trattata come una PortletException.

2.5.3

Portlet Window

La definizione della portlet pu includere un insieme di attributi (con i loro valori di default) che specificano delle preferenze e che sono utilizzati per creare i relativi oggetti. Le portlet, infatti, sono comunemente configurate per fornire delle viste o dei comportamenti personalizzati per utenti differenti. Tale configurazione rappresentata come un insieme persistente di coppie nome - valore che fanno riferimento alle preferenze della portlet. Il portlet container responsabile del recupero e della memorizzazione di questi attributi. Le preferenze sono destinate a salvare i dati di configurazione di base delle portlet e non loro scopo sostituire i comuni database. Le portlet hanno accesso ai relativi attributi delle preferenze attraverso linterfaccia PortletPreferences del package javax.portlet. Laccesso pu 22 di 113

2.5. CICLO DI VITA DI UNA PORTLET avvenire mentre stanno processando le richieste del client e, quindi, la modifica degli attributi (che non sono altro che array di stringhe) da parte di una portlet si pu verificare solamente durante uninvocazione del metodo processAction. A tempo desecuzione, quando vengono servite le richieste, una portlet associata ad un oggetto delle preferenze. In genere, una portlet personalizza il suo comportamento e il contenuto da essa prodotto basato proprio sugli attributi del relativo oggetto delle preferenze. Essa, quindi, pu leggere, modificare e aggiungere attributi, i quali possono anche assumere valori nulli. Di default, un oggetto delle preferenze costruito usando i valori iniziali delle preferenze, definiti nel Deployment descriptor della portlet. Limplementazione di un portale/portlet-container pu fornire, inoltre, degli strumenti per creare nuovi oggetti delle preferenze basati su altri gi esistenti. Quando una portlet posta in una pagina del portale, un oggetto di questo tipo viene associato ad essa. Linsieme di una portlet e del relativo oggetto delle preferenze costituisce la finestra della portlet (portlet window). Una pagina del portale pu contenere pi finestre che fanno riferimento alla stessa portlet e allo stesso oggetto delle preferenze.

2.5.4

Gestione delle richieste

Dopo che la portlet opportunamente inizializzata, il container pu invocarla per gestire le richieste (stati SM1.4 e SM1.5 nel diagramma 2.4) che provengono dal client. La richiesta eseguita dal client sul portale viene tradotta in una render request o action request a seconda della tipologia di invocazione. Per questo scopo, linterfaccia Portlet definisce i due metodi render (che, come detto, esegue la visualizzazione delle portlet) e processAction (che esegue una richiesta di elaborazione). In un caso o nellaltro il portale invoca il primo metodo o il secondo per rispondere alla richiesta, ma nel caso in cui sia attivo un meccanismo di cache, la ri-renderizzazione non viene forzata. Tipicamente le richieste del client sono innescate da URL creati dalle portlet (chiamati appunto portlet URL) che riferiscono le portlet stesse. Ad esempio, quando un utente agisce su un indirizzo relativo ad una portlet (cio cliccando un link o eseguendo il submit di un form) il risultato che ne consegue una nuova richiesta da parte del client al portale mirata a quella portlet. I portlet URL possono essere quindi di due tipi: action URL o render URL. Normalmente, una richiesta client innescata da un render URL si traduce come molte render request una per ogni portlet della pagina, mentre una richiesta provocata da unaction URL si realizza come unaction request e molte render request, una per portlet della pagina. Nel primo caso, il portale/container deve invocare il metodo render per tutte le portlet presenti nella pagina con la possibile eccezione delle portlet per cui i loro contenuti vengono trattenuti in cache. Non deve, invece, invocare il metodo processAction per alcuna delle portlet della pagina per quella richiesta. 23 di 113

CAPITOLO 2. ELEMENTI E FUNZIONAMENTO DI UN PORTALE In tal caso, infatti, si tratta semplicemente di caricare la pagina del portale visualizzando tutte le varie portlet della stessa, senza elaborare alcun dato ricevuto in input come nel caso dellaction request. Di seguito si riporta un diagramma di sequenza che illustra come viene gestita una richiesta innescata da un render URL.:Client :Portale :PortletContainer :PortletA :PortletB

1 : request()

2 : render()

3 : render() 4 : frammento

5 : frammento

6 : render() 7 : render() 8 : frammento 9 : frammento 10 : pagina del portale

Figura 2.5: Caricamento di una pagina del portale. Se, invece, la richiesta del client innescata da unaction URL, il portale / portlet-container deve prima avviare la richiesta invocando il metodo processAc tion della portlet in questione. In seguito, dopo aver atteso la terminazione della richiesta, deve innescare la render request chiamando il metodo render per tutte le portlet della pagina, eccetto possibilmente, anche in questo caso, per quelle il cui contenuto viene cachato. In questo modo quindi il container eseguir il refresh delloutput di tutte le portlet della pagina. Le render request possono essere eseguite sequenzialmente o in parallelo senza rispettare alcun ordine specifico. bene inoltre considerare che il portale deve garantire un efficiente livello di servizio a tutti i client per tutte le portlet basato su un meccanismo multithread la cui gestione viene eseguita in modo pi agile e snello proprio eliminando ogni vincolo di priorit e sincronia sullesecuzione di tali thread. Il container, infatti, gestisce le richieste concorrenti che arrivano alla portlet (la stessa portlet pu essere visualizzata in vari punti in pi pagine) da esecuzioni concorrenti di gestione richiesta su differenti thread. Action Request Tipicamente, in risposta ad unaction request, una portlet aggiorna il suo stato sulla base delle informazioni inviate tramite i parametri della richiesta. Il metodo processAction, infatti, riceve in ingresso due parametri di tipo 24 di 113

2.5. CICLO DI VITA DI UNA PORTLET:Client :Portale :PortletContainer :PortletA :PortletB

1 : request() 2 : processAction() 3 : processAction() 4 5

6 : render() 7 : render()

8 : frammento 9 : frammento

10 : render() 11 : render()

13 : frammento 14 : pagina del portale

12 : frammento

Figura 2.6: Process di unaction. ActionRequest e ActionResponse. Loggetto ActionRequest fornisce accesso a diverse informazioni: parametri della richiesta stessa; window state, che un indicatore della quantit di spazio della pagina che sar assegnata al contenuto generato dalla portlet (la specifica ha definito tre stati: NORMAL, MAXIMIZED e MINIMIZED) e pu essere usato da questultima per decidere quanta informazione dovrebbe renderizzare; portlet mode, che indica la funzione che la portlet sta eseguendo (la specifica ha fissato tre stati: VIEW per generare del markup che rispecchia lo stato corrente della portlet, EDIT, modalit che consente di modificare le impostazioni dellutente ed HELP che presenta informazioni di aiuto relative alla portlet); portal context, per ottenere informazioni sul portale; portlet session, che permette di identificare un utente su pi richieste e di memorizzare informazioni transitorie su di esso; dati delle preferenze della portlet. Durante una richiesta di questo tipo, la portlet pu cambiare la sua modalit di funzionamento (portlet mode) o il suo stato (window state). Tali operazioni 25 di 113

CAPITOLO 2. ELEMENTI E FUNZIONAMENTO DI UN PORTALE sono svolte utilizzando loggetto di tipo ActionResponse e diverranno effettive nella successiva fase di render. Render Request Comunemente, durante una render request, le portlet generano dei contenuti basati sul loro stato corrente. Il metodo render riceve in input due parametri di tipo RenderRequest e RenderResponse. Il primo parametro, come nel caso dellActionRequest, permette di accedere a diverse informazioni, ossia ai parametri della render request, al window state, al portlet mode, alla portlet session, alle preferenze della portlet e al portal context. Una portlet, inoltre, pu generare il suo contenuto usando loggetto di tipo RenderResponse (con un opportuno metodo getWriter() che ritorna un oggetto di tipo PrintWriter per inviare testo alla pagina del portale) oppure pu delegare questa operazione ad una servlet o ad una pagina JSP.

2.5.5

Distruzione della portlet

Il portlet container distrugge la porlet (stato SM1.6 nel diagramma 2.4) quando ritiene non pi necessario il suo utilizzo nel container. Questa decisione viene presa se non ci sono pi richieste in corso (e per un qualche motivo si deve fare shutdown dellapplicazione), quando tutti i thread di rendering o di action hanno terminato la loro esecuzione oppure quando il processo di inizializzazione si concluso. Da notare che il container non tenuto a mantenere indefinitamente in vita una portlet, ma per motivi vari pu procedere alla sua distruzione e successiva inizializzazione (in genere operazione effettuata se la carenza di risorse impone, ad esempio, di ottimizzare luso della memoria). In ogni caso la specifica garantisce che, prima della completa distruzione della portlet, venga invocato il metodo destroy(). Questultimo, infatti, permette ad essa di rilasciare qualsiasi risorsa che stava usando e salvare ogni stato persistente. Dopo la terminazione del metodo, il container deve rilasciare loggetto portlet in modo che possa essere raccolto dal garbage collector.

2.6

Modello dei dati della portlet

Lo standard specifica diversi meccanismi di cui la portlet pu usufruire per avere accesso ai dati persistenti e temporanei. Per gli stati persistenti ci sono i due seguenti modi: parametri di inizializzazione, definiti nel deployment descriptor della portlet, cio nel relativo file portlet.xml; preferenze della portlet, che possono essere di sola lettura oppure modificabili dallutente. 26 di 113

2.7. LIMITI DELLA SPECIFICA JSR-168 Il descrittore portlet.xml verr spiegato nel capitolo 7.3 dove si descriver come sono state sviluppate alcune portlet richieste dallazienda. Per avere accesso agli stati temporanei, invece, la portlet pu fare riferimento a: stato di navigazione, che consiste in portlet mode, window state e parametri di render e che definisce com presentata la vista corrente della portlet e come essa associata ad un particolare client; sessione: la portlet pu memorizzare le informazioni nella sessione o con uno scope globale (application scope), per lasciare che gli altri componenti di quellapplicazione web abbiano accesso ai dati, oppure con un portlet scope che privato per la portlet. Nel capitolo 6.2 si parler pi in dettaglio degli attributi di sessione e del loro funzionamento, in quanto sono stati usati per correggere un problema di cui era affetto il portale aziendale.

2.7

Limiti della specifica JSR-168

La specifica Java Portlet Specification 1.0 [3] presenta diverse limitazioni, le quali possono essere elencate di seguito: supporto parziale alla comunicazione inter-portlet, meccanismo standard per far interagire tra loro le portlet: supportato solamente allinterno della stessa portlet application usando gli attributi di sessione; la portlet ricevente vedr i messaggi solamente alla successiva richiesta di render; le portlet non possono aggiornare i loro stati durante una richiesta di render; da ci si comprende come la gestione degli eventi non sia in realt possibile. una portlet pu eseguire il render solo di frammenti HTML; non possibile ottenere una risorsa direttamente da una portlet, bisogna passare dal servlet container e ci richiede coordinamento tra portlet e servlet; lintegrazione con AJAX non supportata internamente, a meno che non sia offerta dal portlet container in modo non standard. Questi limiti hanno portato allintroduzione dello standard JSR-286 (Java Portlet Specification 2.0 [4]), rilasciato nel 2008, dopo che nel febbraio 2006 fu costituito il JSR 286 Expert Group al fine di arrivare alla specifica. Le novit introdotte riguardano principalmente i seguenti punti: 27 di 113

CAPITOLO 2. ELEMENTI E FUNZIONAMENTO DI UN PORTALE ogni portlet pu lanciare e ricevere determinati eventi; possibilit per le portlet di condividere parametri tra loro, attraverso i public render parameter; capacit di una portlet di restituire una risorsa; supporto migliore alla tecnologia AJAX. Il nuovo standard stato progettato per essere retrocompatibile con la prima specifica. Dunque, tutte le operazioni descritte in precedenza (ciclo di vita, caricamento pagina del portale, gestione delle richieste) sono valide, cos come mantiene la compatibilit con tutti i metodi delle vecchie API. Per via delle nuove funzionalit introdotte, oltre a nuovi metodi, sono state aggiunte diverse entry nel nuovo deployment descriptor.

28 di 113

Capitolo 3La piattaforma Liferay PortalIn questo capitolo ci si occuper di descrivere dettagliatamente la piattaforma Liferay Portal usata per la realizzazione dellintranet aziendale. In particolare, dopo aver illustrato quali sono le caratteristiche principali della piattaforma, ci si soffermer sullanalisi dellarchitettura del Framework che sta alla base. In seguito si presenteranno le strategie di sviluppo di un portale costruito con questa piattaforma.

3.1

Introduzione a Liferay Portal

Liferay Portal un portale web Open source basato sulla tecnologia Java che sfrutta al meglio le moderne tecnologie Web 2.0. Utilizzato da aziende in tutto il mondo, comprende una lunga lista di funzionalit che lo mettono a confronto diretto con molti portali commerciali, con il vantaggio di non avere oneri di licenza. Infatti, oltre ad una gestione ottimale delle portlet, il suo successo dovuto alla quantit (e qualit) dei servizi integrati, unottima flessibilit di utilizzo e una grande capacit di organizzare e supportare la collaborazione interna. Prima di parlare delle varie caratteristiche che presenta, si possono elencare alcune soluzioni che Liferay pu garantire: intranet (intesa anche come extranet) aziendale, per fare in modo di avere unorganizzazione delle informazioni funzionale e flessibile, consentendo una gestione totale dei ruoli e dei permessi di accesso per reparti/gruppi/singoli utenti; gestione contenuti e pubblicazione web, per amministrare un sito web con molte informazioni e con molte persone coinvolte nellorganizzazione e stesura dei contenuti; collaborazione, per stimolare il lavoro in team; 29 di 113

CAPITOLO 3. LA PIATTAFORMA LIFERAY PORTAL applicazione che pu servire da framework (ambiente) per la gestione e lintegrazione di nuovi contenuti ed applicazioni. Questo software un prodotto della Liferay Inc. ed stato concepito nel 2000. Esistono due versioni per questo progetto: Community Edition (CE), completamente gratuita ( distribuita sotto licenza GNU LGPL), destinata a sviluppatori, community e a coloro che vogliono valutare le potenzialit di questa applicazione; Enterprise Edition (EE), versione pi stabile della precedente e che, come dice la parola stessa, destinata ad usi professionali da parte delle imprese, e comprensibilmente a pagamento. In tal caso, viene trattata la versione 5.2.3 CE, utilizzata per il portale aziendale. Lapplicazione fornisce uninterfaccia web unificata per le varie informazioni e gli strumenti che provengono da diverse sorgenti. Allinterno del portale, come si visto, questa interfaccia composta da un certo numero di portlet. Dal momento che queste ultime sono sviluppate indipendentemente dal portale e che quindi sono scarsamente accoppiate con esso, si pu parlare di una piattaforma basata su unarchitettura SOA, della quale si parler pi dettagliatamente in seguito. Liferay presenta una vasta gamma di portlet liberamente disponibili per blog, forum, sondaggi, calendario, raccolta documenti, galleria immagini, feed RSS, wiki, contenuti web e cos via. Liferay presenta anche le soluzioni di CMS e Web Content Management (WCM). Liferay CMS dotato delle funzionalit di base di Enterprise Content Management System (ECMS), molto utili per la collaborazione in team. Le informazioni, infatti, possono essere specifiche per un piccolo gruppo allinterno di unazienda, ad esempio alcune saranno rilevanti a livello di team, mentre altre in tutta lorganizzazione. Il portale in questione supporta molto bene questo tipo di situazioni. Riassumendo, Liferay ha quindi tre principali funzionalit: portale; CMS e WCM: sistema di gestione dei contenuti aderente allo standard JSR-170 e gestione dei contenuti web; software sociali per la collaborazione tra utenti, come blog, forum, wiki, annunci, bacheca delle attivit, ecc.. In generale, dunque, un sito web costruito usando Liferay pu essere costituito dagli elementi sopra elencati dei quali, qui di seguito, si illustreranno le varie peculiarit e i vantaggi offerti. 30 di 113

3.2. PANORAMICA DELLE CARATTERISTICHE DEL PORTALE

3.2

Panoramica delle caratteristiche del portale

Dal momento che Liferay il leader nel campo dei portali aziendali open source, fornisce soluzioni sia per il settore privato che per quello pubblico. A tale scopo, presenta queste caratteristiche e funzionalit: gira su tutti i principali application server, come ad esempio Tomcat, Glassfish, JBoss, Geronimo, Jetty, JOnAS, Resin, Weblogic, WebSphere; supporta numerosi database, tra i quali si possono citare MySQL, Oracle, SQL Server, PostgresSQL, JDataStore, Sybase, SAP, Apache Derby, Firebird, Hypersonic; multipiattaforma, in quanto eseguibile su diverse famiglie di sistemi operativi quali Linux, Unix, Windows e Mac OS X ; utilizza lultima versione di Java J2EE e le moderne tecnologie Web 2.0; compatibile con le specifiche JSR-168 e JSR-286 per le portlet; interfaccia utente basata su AJAX; oltre 60 portlet pronte alluso: forte di unestesa community, Liferay fornisce il numero maggiore di portlet gi integrate di qualsiasi altro portale sul mercato; drag and drop dinamico: gli utenti possono spostare gli elementi nel portale semplicemente trascinando e rilasciando il mouse; tagging e ricerca di risorse: possibilit di etichettare i documenti, i contenuti web, i messaggi dei forum ed altri elementi in modo dinamico e condividendo questi tag con gli altri utenti del portale. Gli utenti possono quindi ricercare tramite le etichette assegnate alle informazioni o gruppi di informazioni comuni; pagine personali: tutti gli utenti abilitati possono avere uno spazio personale dove immettere proprie informazioni e decidere se renderle pubbliche o tenerle private. possibile personalizzare lo spazio messo a disposizione tramite il drag & drop delle portlet; supporto multilingua; sincronizzazione LDAP; supporto allautenticazione unica Single Sign On (SSO): il portale consente agli utenti di accedere ai contenuti e applicazioni da un unico punto di accesso. Liferay pu infatti aggregare diversi sistemi applicativi rendendoli disponibili accedendo una volta sola con il massimo della riservatezza; 31 di 113

CAPITOLO 3. LA PIATTAFORMA LIFERAY PORTAL sistema di autorizzazioni granulare basato sul ruolo di un utente: per garantire che le persone accedano con diritto alle sole informazioni/dati per le quali sono autorizzate, gli amministratori del portale possono assegnare ai singoli utenti o gruppi di utenti diversi ruoli per attribuire loro differenti livelli di accesso e differenti diritti di modifica; gestione centralizzata di tutti i contenuti, risorse, utenti, comunit, ruoli attraverso un pannello di controllo completamente personalizzabile con la possibilit di aggiungere o togliere alcune sue parti; facile configurazione: una veloce ed intuitiva interfaccia rende Liferay estremamente semplice da utilizzare da tutti i membri di unorganizzazione. Il tempo per modificare un layout di pagina, laggiunta di nuove applicazioni e contenuti, cambiando anche laspetto della grafica pu essere fatto in un paio di click, anche dallutente finale stesso; sistema di gestione dei contenuti: il CMS incluso allinterno di Liferay fornisce un insieme esteso di funzionalit fortemente integrate con le funzioni di collaborazione e fornisce un repository centralizzato per conservare e gestire contenuti da visualizzare sul web. Ciascuna community e ciascuna organization hanno a disposizione una propria separata document library e image gallery. Il CMS implementato tramite Liferay Journal, un contenuto intrinseco (built-in) del portale che abilita una serie di funzionalit di gestione contenuti; Web Publishing, sistema che pu essere usato per creare pagine web in modo veloce usando dei contenuti riusabili, dei modelli (template) per layout flessibili; Flexibile Template Mechanism (XSL/VM ): i modelli creati per i Journal articles (cos vengono chiamati i contenuti web) possono essere realizzati in XSL o Velocity (VM) offrendo cos agli sviluppatori la flessibilit di disegnare le pagine web; Document Library, che provvede un deposito centralizzato per i servizi della libreria, basato sulla specifica Java Content Repository (standard JSR-170 ) per trattare diversi tipi di documenti (PDF, DOC, ecc.) che possono essere salvati sotto un unico URL; Image Gallery, che fornisce un deposito centralizzato per le immagini; Portal Publishing & Staging: la funzione di publishing permette di modificare pagine web in tempo reale senza per pubblicare subito il cambiamento ma solo quando si decide di farlo. Lo staging, invece, consente di creare varie copie di modifica della stessa pagina e testarle senza toccare le pagine correnti sul portale. 32 di 113

3.3. FUNZIONI DI COLLABORAZIONE

3.3

Funzioni di collaborazione

Liferay, come detto precedentemente, offre inoltre un sistema potente ed integrato di funzioni di collaborazione. Queste ultime sono riassunte brevemente qui di seguito: wiki: Liferay implementa un sistema di wiki robusto ed efficace, comparabile a prodotti standalone. Ogni gruppo pu condividere una propria wiki con propri e differenziati insiemi di autorizzazioni. Ogni utente con i diritti necessari pu contribuire alla crescita del repository di conoscenza condiviso. I contenuti vengono inseriti semplicemente con un editor WYSIWYG, le pagine possono essere raggruppate in gerarchie e taggate con sistemi a vocabolario multiplo; bacheca elettronica: un sistema di bacheca elettronica (message boards) permette di condividere idee ed annunci allinterno di un gruppo (organizzazione o community). Liferay mette a disposizione dei report sullattivit svolta nella bacheca, riportando i post recenti, gli utenti attivi. Ogni thread visibile via feed RSS ed ogni post pu inviare una mail di avviso che permette di rispondere al post da client di posta. Come per tutte la altre portlet, anche quella della bacheca sottoposta al sistema finemente granulare di gestione degli accessi e autorizzazioni del portale che garantisce il controllo utilizzando i ruoli; blog: Liferay implementa un sistema di blog ricco di funzionalit, reso pi efficace dalla natura sociale del portale nel suo complesso. Tra le funzionalit pi importanti leditor WYSIWYG, social bookmarking, notifiche email per i contributi e commenti, sistemi di rating dei contributi, sottoscrizione via RSS, scheduling delle pubblicazioni; instant messaging: sono comprese delle funzioni di instant messaging che fruiscono naturalmente del sistema di relazioni del portale. Tramite la lista degli amici vengono automaticamente visualizzati i nomi degli amici collegati. Laccesso al servizio inserito in una barra in fondo alla videata e segue lutente lungo la navigazione allinterno del portale rimanendo sempre disponibile; calendari: possibile impostare ed utilizzare calendari di gruppo (basati sulle community). Gli eventi possono essere condivisi intragruppi, gli alert sugli eventi possono essere impostati per un avviso via email, instant messaging o SMS; avvisi: possibile inviare messaggi di tipo broadcast a gruppi di utenti. Ogni utente pu settare le modalit di ricezione degli avvisi tramite web alert via portale, SMS, email o altre modalit di delivery impostate dallamministratore; 33 di 113

CAPITOLO 3. LA PIATTAFORMA LIFERAY PORTAL sondaggi: sono disponibili delle portlet per limpostazione, la presentazione e la raccolta dati di sondaggi. Possono essere configurati e pubblicati pi sondaggi in contemporanea con visibilit differenziate rispetto ai gruppi; tracking delle attivit: la portlet Attivit Recenti tiene traccia delle attivit pi recenti effettuate sul portale (contributi o commenti su blog, bacheche, wiki e altri strumenti). Lapproccio e la presentazione sono simili a quelli di Facebook; RSS : Liferay consente di condividere, opzionalmente, tutte le tipologie di contenuto tramite feeding RSS.

3.4

Gestione degli utenti e gruppi

Liferay utilizza diversi concetti per organizzare un portale. Il modo pi semplice di pensare a ci considerare gli utenti e i diversi modi con cui essi possono essere raggruppati insieme. Le varie situazioni vengono cos presentate: un portale acceduto da utenti; gli utenti possono essere raccolti in gruppi di utenti; gli utenti possono appartenere ad organizzazioni; le organizzazioni possono essere raggruppate in gerarchie; utenti, gruppi e organizzazioni possono appartenere a comunit che hanno un interesse comune. Le relazioni che intercorrono tra le varie risorse citate sono riportate nella figura 3.1. Nella figura ogni freccia va interpretata con il significato di pu essere parte di. Questo vuol dire, ad esempio, che le organizzazioni possono essere parte di comunit, queste ultime possono essere parte di ruoli, gli utenti possono essere parte di qualsiasi cosa, e cos via. Anche se ci sembra molto complesso, fornisce un potente meccanismo per configurare le risorse del portale in un modo consistente e robusto. importante notare che il diagramma riporta solo gli utenti e i loro possibili raggruppamenti. I permessi non hanno influenza sui gruppi, ma possono essere assegnati solamente ai ruoli. Al portale possono avere accesso diverse categorie di utenti. La prima distinzione da fare tra utente autenticato e visitatore anonimo. Anche questi ultimi possono utilizzare le portlet, purch esse siano configurate opportunamente, dipende dallobiettivo del portale. Se si tratta di un portale aperto al 34 di 113

3.4. GESTIONE DEGLI UTENTI E GRUPPI

Pagine

Organizzazioni

Ruoli organizzazione

Ruoli

Utenti

Gruppi di utenti

Pagine

Comunit

Ruoli comunit

Figura 3.1: Organizzazione delle risorse umane e loro gruppi nel portale. pubblico, e che magari allutente autenticato riserva pi funzionalit personalizzate, saranno apportate opportune configurazioni alle portlet; se, invece, il portale totalmente privato, ad esempio unintranet, saranno fatte le diverse configurazioni del caso. In generale si pu parlare di ruoli allinterno di Liferay: avere un ruolo significa sostanzialmente possedere un insieme di permessi di esecuzione di alcune azioni. Nel sistema sono presenti dei ruoli predefiniti: amministratore, ospite, ecc.. Tuttavia possibile definire e personalizzare i ruoli, creando cos profili molto particolari, che possono ad esempio avere accesso solo su determinate portlet e/o che possono svolgere su di esse solamente alcune azioni.

3.4.1

Utenti

Gli utenti possono essere raggruppati in diverse maniere. Possono essere infatti membri di gerarchie di unorganizzazione oppure far parte di gruppi arbitrari (ad esempio il gruppo Bloggers che permetterebbe loro, ad esempio, di creare pagine di blog nei loro spazi personali). Possono anche essere raggruppati da comunit che condividono un interesse comune. Possono infine avere uno o pi ruoli che descrivono le loro funzioni nel sistema e tali ruoli possono essere nellambito dellorganizzazione, della comunit o dellintero portale. Ogni utente autenticato, inoltre, pu possedere un numero a piacere di pagine private, ovvero accessibili solo da lui, e di pagine pubbliche, cio accessibili a tutti gli utenti della comunit o organizzazione. 35 di 113

CAPITOLO 3. LA PIATTAFORMA LIFERAY PORTAL

3.4.2

Gruppi di utenti

I gruppi sono semplici raggruppamenti di utenti. Non vi un particolare modo di intendere il significato di gruppo. Infatti, i gruppi possono essere creati in base alla nazione di provenienza o in base alla professione ad esempio; la scelta del tutto arbitraria. Un gruppo pu essere parte di comunit o ruoli e ad esso non possono essere assegnati dei permessi. Anche se i gruppi non hanno delle pagine come nel caso degli altri raggruppamenti (comunit o organizzazioni), dispongono di template che possono essere usati per creare e modificare le pagine personali di un utente associato a quel gruppo.

3.4.3

Organizzazioni

Le organizzazioni sono insiemi gerarchici di utenti. Sono utili per poter suddividere gli utenti nello stesso modo in cui sono suddivisi allinterno delle imprese cui appartengono. In sostanza ci che si pu fare creare delle gerarchie aziendali. Ad esempio, se con Liferay si vuole gestire una grande azienda, pu essere utile definire un determinato utente attraverso la sua posizione nellorganigramma aziendale. Se, ad esempio, quellutente un responsabile commerciale che lavora sia per la sede di Padova che per quella di Bologna, potrebbe essere membro delle organizzazioni Vendite, Sede di Padova e Sede di Bologna. Le organizzazioni possono essere parte di comunit e, come queste ultime, dispongono di pagine personalizzabili al loro interno.

3.4.4

Comunit

Le comunit sono gruppi di utenti che condividono un particolare obiettivo/interesse comune. Esse, infatti, sono molto simili alle organizzazioni ad eccezione di non essere gerarchiche e sono pensate per essere dei luoghi a se stanti ai quali chiunque, da ogni organizzazione (o anche da nessuna), pu unirsi. Le comunit si possono poi utilizzare in ogni situazione in cui si ha la necessit di tralasciare la struttura organizzativa e raggruppare gli utenti in modo trasversale. Le comunit sono i luoghi di lavoro ideali dei team per collaborare su progetti comuni. Forniscono infatti unarea isolata dove un gruppo di persone possono inserire tutte le loro informazioni relative ad un particolare argomento. Molte aziende le usano proprio per tale scopo, in quanto questo si rivela essere un sistema di gran lunga migliore di condividere i dati rispetto alluso di mail e semplici cartelle condivise in rete. Come visto in precedenza, infatti, la document library consente agli utenti di accedere ai documenti presenti in essa, ed usufruire anche di un apposito sistema di versionamento. La portlet del calendario permette di tenere traccia di tutti gli appuntamenti e le riunioni del team di lavoro, mentre il forum un ottimo strumento per mantenere in un solo posto tutte le discussioni dei membri. La home page di default di Liferay una comunit chiamata Guest e su 36 di 113

3.5. SCOPE questa andrebbe inserito il sito web pubblico accessibile da tutti. Le comunit possono essere create e gestite in due modi. Il primo attraverso il pannello di controllo, proprio come ogni altra risorsa del portale. Laltro tramite la portlet Le mie comunit che pu essere aggiunta in ogni pagina. Tale portlet permette agli utenti di scorrere la lista delle comunit e per ognuna di esse scegliere se unirsi o meno. Ci permette allamministratore del portale di fornire questa funzionalit agli utenti senza dare accesso loro al pannello di controllo. In Liferay si individuano tre tipi di comunit: pubbliche; private; nascoste. Una comunit pubblica permette agli utenti del portale di unirsi od uscire da essa ogni qualvolta lo vogliono. Questo lo possono fare utilizzando il pannello di controllo o la portlet dedicata a tale scopo (che deve essere aggiunta ad una pagina a cui gli utenti hanno accesso). Una comunit privata, invece, necessita che gli utenti siano aggiunti ad essa dallamministratore della comunit. Gli utenti, anche in questo caso, possono usare il pannello di controllo o la portlet dedicata per richiedere ladesione. Infine, una comunit nascosta come una privata, con laggiunta del fatto che essa non visibile nella portlet delle comunit o come entry del pannello di controllo.

3.4.5

Ruoli

I ruoli sono raggruppamenti di utenti che condividono una funzione particolare allinterno del portale, secondo un determinato ambito. Quindi, avendo definito i possibili ruoli che gli utenti possono ricoprire, la loro suddivisione secondo questo parametro viene di conseguenza. I ruoli possono concedere dei permessi alle varie funzionalit presenti e in tal senso si pu pensare ad un ruolo come ad una descrizione di una funzione. Ad esempio, un ruolo con il nome Amministratore forum molto probabilmente avr i permessi per far funzionare opportunamente la portlet del forum. Gli utenti che si collocano in quel ruolo erediteranno tutte le varie autorizzazioni stabilite. I ruoli possono essere legati allintero portale, ad unorganizzazione o ad una comunit. Anche in questo caso il pannello di controllo fondamentale, in quanto consente di assegnare gli utenti a dei ruoli ed attribuire particolari permessi a questi ultimi. 37 di 113

CAPITOLO 3. LA PIATTAFORMA LIFERAY PORTAL

3.5

Scope

Nella versione 5.2 di Liferay stato introdotto il concetto di scope. In italiano questo termine pu essere tradotto come ambito o meglio ancora come raggio dazione. Pi in dettaglio, si pu dire che uno scope identifica un insieme di dati che isolato da un altro insieme di dati memorizzato nel database del portale. Ad esempio, se si aggiunge una portlet del forum in due comunit diverse, ognuna ha il proprio insieme di dati. Come citato in precedenza, un ruolo pu essere in ambito del portale, di unorganizzazione o di una comunit. Ci significa che ha effetto solo nellambito in cui risiede. Ritornando allesempio fatto nella sezione 3.4.5, si pu dire che un ruolo Amministratore forum con completo accesso alla relativa portlet presenta dei permessi differenti a seconda dello scope del ruolo. Infatti se un ruolo normale, i membri hanno il permesso di gestire i forum dellintero portale. Se, invece, un community role i membri hanno il permesso di gestire i forum solo allinterno delle comunit in cui sono membri del ruolo. Se, infine, un organization role i membri hanno lautorizzazione di amministrare il forum solamente nelle organizzazioni in cui sono membri del ruolo. Similmente a ci, anche alcune portlet presenti in Liferay possono ora avere degli scope che vanno oltre le specifiche comunit o organizzazioni su cui sono inserite. Infatti, possibile fare in modo che lo scope sia per pagina. Questo permette di aggiungere ad una comunit/organizzazione un numero qualsiasi di tali portlet e, fino a quando queste ultime verranno inserite in pagine diverse, avranno insiemi di dati differenti. Ci permette di avere pi di unistanza di una certa portlet in una comunit o organizzazione. Tutte le principali portlet out of the box (forum, blog, calendario, ecc.) di Liferay supportano il concetto di scope e questo offre molta pi flessibilit nel modo in cui si desidera impostare il portale. Tuttavia, per default, lo scope impostato che sia per comunit o organizzazione. Se lo scope di una determinata portlet per pagina, quindi, si possono inserire diverse istanze della stessa in una certa comunit/organizzazione, purch siano piazzate in pagine differenti.

3.6

Architettura e framework

Laspetto pi importante di ogni portale senza dubbio larchitettura sottostante. Quella di Liferay, oltre ad essere adatta per le normali applicazioni, supporta la massima disponibilit per sistemi di tipo mission-critical. Infatti, in grado di bilanciare una solida struttura che garantisce limplementazione dei principali portal standards con il valore e gli standard messi a disposizione dai maggiori open frameworks. La figura 3.2 mostra i diversi strati dellarchitettura e le funzionalit delle portlet. 38 di 113

3.6. ARCHITETTURA E FRAMEWORK

Portlets (JSR 168 / JSR 286) Portal-Kernel Portal-Impl

Web Services Portal-Service

XML, JSON, REST RMI, , SOAP etc. ,

Service Interface (Spring) CMS JSR 170 Events Message Bus Hibernate JDBC External Web Applications Servlet Container

Enterprise Service Bus (Mule / ServiceMix) Mail Server LDAP Server

Share Point

BPM

Bl XForms Reporting

JCR Repository

Database

Figura 3.2: Architettura di Liferay Portal.

3.6.1

Service Oriented Architecture

La piattaforma completamente basata sui principi di progettazione che fanno riferimento alla Service Oriented Architecture (SOA). Vi infatti la necessit di avere un modo standard per esporre un software su una rete attraverso uninterfaccia comprensibile da tutte quelle aziende che, volendo far interagire le proprie applicazioni con quelle di altre compagnie, riconoscono tale standard. Una SOA (Architettura Orientata ai Servizi) un modello architetturale per la creazione di sistemi residenti su una rete che focalizza lattenzione sul concetto di servizio. Un sistema costruito seguendo questa filosofia costituito da applicazioni, chiamate appunto servizi, ben definite ed indipendenti luna dallaltra, che risiedono su pi computer allinterno di una rete (ad esempio la rete interna di unazienda o una rete di connessione fra pi aziende che collaborano: intracompany e intercompany network). Ogni servizio mette a disposizione una certa funzionalit e pu utilizzare quelle che gli altri servizi hanno reso disponibili, realizzando, in tal modo, applicazioni di maggiore complessit. Larchitettura SOA, che si pu considerare quindi come una forma particolare di sistema distribuito, presenta alcune caratteristiche e propriet orientate al riutilizzo e allintegrazione in un ambiente eterogeneo che devono essere rispettate dai servizi. In particolare un servizio dovr: essere ricercabile in base alla sua interfaccia e recuperabile dinamicamente a tempo di esecuzione; essere ben definito, completo ed indipendente dal contesto o dallo stato di altri servizi; essere definito da uninterfaccia ed indipendente dallimplementazione; essere debolmente accoppiato con altri servizi; 39 di 113

CAPITOLO 3. LA PIATTAFORMA LIFERAY PORTAL essere reso disponibile sulla rete tramite la pubblicazione della sua interfaccia ed accessibile in modo trasparente rispetto alla sua allocazione; fornire uninterfaccia possibilmente a grana grossa, con poche funzionalit in modo tale da non dover avere un programma di controllo complesso; essere realizzato in modo tale da permetterne la composizione con altri.

In poche parole, si pu dire che le caratteristiche chiave di Liferay comprendono, tra gli altri aspetti, lutilizzo massiccio dei principi SOA, affidabili sotto il profilo della sicurezza ed integrati con SSO e LDAP. La piattaforma, inoltre, fornisce particolari strumenti e framework per estendere il concetto di SOA ad altre applicazioni enterprise. Larchitettura permette inoltre agli utenti di accedere al portale non solo con i dispositivi tradizionali e wireless, ma gli sviluppatori possono effettuare laccesso grazie a specifiche API per mezzo di protocolli quali REST, SOAP, XML-RPC ed altri.

3.6.2

Enterprise Service Bus

LEnterprise Service Bus (ESB) un gestore centrale delle connessioni che permette ad applicazioni e servizi di essere aggiunti rapidamente ad uninfrastruttura enterprise. Quando unapplicazione deve essere sostituita, essa pu essere facilmente disconnessa dal bus. In particolare, Liferay usa Mule o ServiceMix come ESB. Attraverso questo gestore il portale pu essere integrato con molteplici software, tra i quali SharePoint, applicazioni per il Business Process Management (BPM ) (che servono per ottimizzare e monitorare i processi aziendali), repository JCR (Content Repository API for Java) ed altri. Supporta lo standard JSR 170 per il CMS. Utilizza, inoltre, Hibernate e JDBC per la connessione con qualsiasi database. LESB supporta anche un sistema di eventi basato su messaggi asincroni. Liferay supporta inoltre dei web services per rendere pi facile la comunicazione tra diverse applicazioni in ambiente enterprise. Applicazioni Java, .NET e proprietarie possono funzionare facilmente assieme poich i servizi web usano gli standard XML. Liferay utilizza diversi sistemi di crittografia, tra i quali algoritmi avanzati come DES, MD5 e RSA. Proprio per questo, considerato uno dei portali pi sicuri del mercato. In breve, si pu dire che un portale basato su Liferay generalmente utilizza lESB per dotarsi di un layer di astrazione sopra limplementazione di un Enterprise Messaging System (EMS), che consente di inviare semanticamente dei precisi messaggi tra sistemi di computer. Ci permette di utilizzare il contenuto della comunicazione senza scrivere codice. 40 di 113

3.7. STRATEGIE DI SVILUPPO DEL PORTALE

3.6.3

Spring

Liferay usa il framework Spring per gli strati dei dati di business e dei servizi. Inoltre, lo utilizza anche per la gestione delle transazioni. Tale framework, infatti, ha come obiettivo principale quello di gestire la complessit nello sviluppo di applicazioni enterprise in ambiente Java. Unimportante sua caratteristica quella di non essere intrusivo, in quanto gli oggetti sviluppati non dipendono dalle classi del framework. Due sono gli aspetti principali di Spring i quali vengono spiegati qui di seguito. Il primo il pattern Inversion of Control (IoC) che serve a minimizzare le dipendenze fra gli oggetti rendendo unapplicazione pi robusta, facilitando anche il riutilizzo dei componenti e rendendo pi semplice lo sviluppo. Il concetto alla base dellIoC che le dipendenze degli oggetti devono essere risolte da una qualche infrastruttura esterna che ha la responsabilit di istanziare gli oggetti e di fornire loro le relative dipendenze. Quindi, il ciclo di vita degli oggetti gestito da unentit esterna (container) come anche la loro configurazione che usa file XML. Una delle tecniche con cui si pu attuare lIoC la Dependency Injection (DI), cio il container si fa carico di iniettare le dipendenze nellistanza di un oggetto automaticamente e a runtime. Per fare questo utilizza costruttori e metodi setter. Attraverso la DI, quindi, si riesce a separare il comportamento di una componente dalla risoluzione delle sue dipendenze, minimizzando, allo stesso tempo, il livello di accoppiamento. La seconda nozione quella dellAspect Oriented Programming (AOP), un paradigma di programmazione che mira a disaccoppiare tutte quelle caratteristiche di un sistema che sono logicamente indipendenti da esso stesso ma lo invadono in maniera capillare (ad esempio la security e gli aspetti transazionali). In Liferay, linterfaccia che espone i vari servizi della piattaforma basata appunto sul framework Spring. Basato su tale interfaccia Portal-Impl, una libreria di Liferay il cui utilizzo rivolto principalmente per usi interni alla piattaforma, come ad esempio per lambiente di estensione Ext del quale verr parlato in seguito. Altre librerie, come Portal-Kernel e Portal-Service, sono invece previste per usi esterni (e anche interni). Forniscono infatti delle API che possono venir sfruttate da plugin esterni, come avviene nellambiente Plugins SDK (descritto anche questo in seguito) per lo sviluppo di temi e portlet.

3.7

Strategie di sviluppo del portale

Un portale costruito con Liferay pu essere esteso secondo i seguenti tre livelli di sviluppo, illustrati anche in figura 3.3: ambiente Plugins SDK ; 41 di 113

CAPITOLO 3. LA PIATTAFORMA LIFERAY PORTAL ambiente Extension; codice sorgente di Liferay Portal.

Plugins SDK Environment Extension Environment Liferay Portal Source Code

Level l Level ll Level lll

Figura 3.3: Strategie di sviluppo di Liferay. Generalmente, ogni livello di estensibilit offre un diverso compromesso tra flessibilit e requisiti differenti per far migrare il sistema verso successive versioni. Si pu parlare subito del terzo livello di sviluppo con il quale si va a modificare direttamente il codice sorgente di Liferay. Questo approccio dovrebbe essere utilizzato solamente per sviluppi sponsorizzati, ovvero sviluppare specifiche funzionalit per determinati progetti e contribuire con esse ad estendere, integrare e correggere il codice sorgente. Gli ambienti Plugins SDK ed Extension vengono presentati nelle prossime due sezioni.

3.7.1

Ambiente Plugins SDK

Plugins SDK un semplice ambiente per lo sviluppo di plugin e, quindi, serve per realizzare portlet, temi, layout, hooks 1 come software indipendente dal portale. Tutte queste componenti sono hot-deployable. In particolare, le portlet create in Plugins SDK possono importare classi solamente dalle librerie Portal-Kernel e Portal-Service (e dagli altri file JAR presenti nella cartella /WEB-INF/lib della portlet), ma non da Portal-Impl. Ci forza le portlet ad affidarsi completamente alle API del portale e a non dipendere dalle classi implementative definite in Portal-Impl. Per gestire le propriet del portale, lingua e JSP relative a Portal-Impl si devono usare gli hook. Lambiente SDK consente quindi di creare plugin hot-deployable per il portale Liferay attraverso linvocazione di task di Ant (descritto brevemente in un paragrafo dedicato nella sezione 5.2.1) forniti insieme allSDK, che permettono di automatizzare attivit (come ad esempio la generazione automatica della struttura del progetto o il deploy a caldo sul server) senza dover riavviare lapplication server. Dunque, dapprima vengono sviluppati i plugin e poi vengono usati tali task per costituire dei file WAR che vengono direttamentehooks: un plugin out of the box di Liferay che permette, come dice il nome, di agganciarsi al codice di Liferay per modificare le funzionalit del core, come ad esempio il sistema di gestione di eventi, i model listeners, propriet del portale e relativi file JSP1

42 di 113

3.7. STRATEGIE DI SVILUPPO DEL PORTALE copiati in unapposita cartella di Auto Deploy. In seguito, il portale, assieme allapplication server, individua ogni archivio WAR presente nella directory di hot-deploy ed estrae automaticamente i file al loro interno nella cartella di deployment del server. Il funzionamento dellambiente Plugins SDK riportato nella seguente figura.Ant Deploy Hot Deploy

Plugins SDK

Auto Deploy Directory

Liferay Portal + Application Server

Figura 3.4: Funzionamento dellambiente Plugins SDK. Le portlet vanno a finire nella cartella /portlets, i temi in /themes, i template di layout nella cartella /layouttpl, le applicazioni web in /webs e gli hooks nella directory /hooks.

3.7.2

Ambiente Extension

Lambiente Extension (Ext) permette di personalizzare completamente Liferay Portal. Infatti, estende lambiente di sviluppo del portale, avendo la possibilit di agire sui file di configurazione del portale e sul codice Java e JSP relativo a Portal-Impl. quindi un wrapper per i sorgenti del core di Liferay (per questo motivo la struttura delle cartelle in Ext rispecchia la gerarchia delle directory dei sorgenti, cio ext-impl/, ext-service/ e ext-web/). Si possono configurare layout, temi, deployment, Hibernate, cache, impostazioni varie su utenti, gruppi, lingua, sessione, autenticazione, eventi e cos via, attraverso file di properties con desinenza ext. In particolare, le opzioni generali qui citate vengono settate tramite il file portal-ext.properties. Il file system-ext.properties, invece, modo conveniente per fornire ed estendere le Java System Properties usate dal portale. In Ext si possono creare anche delle classi personalizzate per estendere il portale, configurandole tramite il file portal.properties. In tutti questi casi, comunque, il codice sorgente di Liferay non viene modificato in alcun modo, in quanto tutte le personalizzazioni sono organizzate in un progetto separato con lobiettivo di agevolare lupgrade a nuove versioni di Liferay in cui inserire le personalizzazioni realizzate per le precedenti versioni. Come illustrato nella seguente figura, il funzionamento dellambiente di estensione pu essere riassunto in pochi punti: il custom code sovrascrive (override) il codice sorgente del portale nellambiente Ext; prima del processo di deploy il custom code viene fuso (merge) con il codice sorgente del portale sempre nellambiente Ext; il risultato 43 di 113

CAPITOLO 3. LA PIATTAFORMA LIFERAY PORTAL una versione custom del portale Liferay (Customized Liferay Portal) costruita in ambiente Ext; il portale Liferay cos personalizzato viene quindi deployato da Ext sullapplication server.

override Liferay Portal Source Code

merge Customized Liferay Portal

deploy

Custom Code

Application Server

Figura 3.5: Funzionamento dellambiente Extension. Per il codice sorgente custom, si pu usare anche il meccanismo Spring-based di Dependency Injection, configurato nel file ext-spring.xml. Il descrittore web.xml da invece la possibilit di estendere le definizioni delle servlet. Inoltre, il file struts-config.xml permette di aggiungere definizioni per le action delle portlet realizzate seguendo il framework Struts (che verr presentato nei capitoli dedicati rispettivamente alla correzione e allo sviluppo del portale). Come detto, in Ext si possono creare delle portlet che hanno accesso a Portal-Impl, realizzando semplici file JSP e il tutto, quindi, molto flessibile. Un aspetto per da tenere in considerazione il fatto che le portlet realizzate in Ext non sono hot-deployable e dunque lapproccio di sviluppo mediante lExtension environment pu essere usato solo per i sorgenti del portale e delle portlet interne al portale, ma non per le portlet out of the box, ovvero quelle distribuite al di fuori della web app del portale (ossia la ROOT ).

44 di 113

Capitolo 4Analisi dei requisitiIn questo capitolo si caler la piattaforma Liferay nel contesto aziendale, presentando innanzitutto il portale Euris Due.Zero. Seguir poi unanalisi dei problemi e delle mancanze di cui soffriva questultimo. Da questa disamina sono infatti emersi i vari requisiti previsti per lattivit di stage. Alcuni di questi, comunque, riguardanti in particolar modo le funzionalit da sviluppare erano gi stati prefissati al momento del colloquio iniziale con lazienda.

4.1

Euris Due.Zero

Nel 2010 lazienda ha lanciato Euris Due.Zero, una piattaforma di social networking che consente la comunicazione e la condivisione di conoscenza fra tutti i dipendenti di Gruppo Euris, spesso lontani fra loro. Tale portale agisce quindi da intranet (o meglio dire da extranet, in quanto accessibile anche a soggetti non operanti allinterno di una stessa rete locale, tramite interfaccia web) per lazienda, fornendo cos un luogo comune dove poter reperire ed inserire informazioni utili al fine aziendale. Inoltre, iniziata ormai da anni e prosegue tuttora una fase di espansione e riorganizzazione del gruppo e dunque lazienda ha sentito ancor pi lesigenza di dotarsi di una piattaforma di questo tipo, che potesse far collaborare al meglio le diverse figure professionali operanti al suo interno. Come illustrato in precedenza, Liferay mette a disposizione diversi strumenti per la collaborazione e varie modalit per lorganizzazione interna degli utenti. In particolare, lazienda ha optato per organizzare il personale secondo delle comunit. Un dipendente pu quindi far parte di una o pi comunit a seconda che svolga una determinata funzione o che operi in una certa sede. Gli amministratori hanno inizialmente dotato ogni comunit di sette pagine, una per la home della comunit, contenente le portlet generali di varie utilit, una per la portlet del calendario per la consultazione degli eventi aziendali, una per la portlet della document library, una quarta per il forum, unaltra per il 45 di 113

CAPITOLO 4. ANALISI DEI REQUISITI blog, una per la portlet della Wiki e unultima per visualizzare informazioni sui membri della comunit. Quando una certa comunit viene creata, viene apportata questa configurazione di default e ci stato reso possibile grazie allinserimento in portal.properties di impostazioni apposite. In seguito gli amministratori (anche quelli della comunit) possono aggiungere o togliere pagine e relativi contenuti a piacimento. Il portale presenta caratteristiche particolarmente spiccate per quanto riguarda la collaborazione aziendale, in quanto, gi al momento del suo concepimento, sono stati integrati diversi tool della suite Liferay Social Office. Questultima soluzione ha lo scopo di facilitare la comunicazione interna, costruire una coesione di gruppo ed incrementare la produttivit. La comunit di Liferay ha messo a disposizione sul web una versione bundle di Liferay Social Office, ovvero una versione precompilata adatta agli utenti non sviluppatori. Tuttavia, per ovvi motivi, tale scelta non stata presa in considerazione. Lapplicazione stata invece integrata in Liferay Portal, installando in ambiente Plugins SDK il relativo tema (so-theme) e la specifica portlet (so-portlet), entrambi presenti nel repository in rete, mediante opportuni comandi di build gestiti con Ant. Si pu dire quindi che Social Office una particolare istanza del portale che fornisce strumenti pi adatti al lavoro in team, offrendo, ad esempio, una document library con maggiori funzionalit e migliorie in diverse altre portlet volte ad incentivare attivit collaborative.

4.1.1

Problemi e mancanze

Essendo Liferay un progetto open source, soffre di alcuni bug, alcuni dei quali possono risultare molto fastidiosi per gli utilizzatori del portale. In particolare, nelle prime settimane di stage, dopo aver studiato dapprima il funzionamento generale del portale e poi la sua architettura interna, sono passato allindividuazione dei problemi di cui era affetta la piattaforma. Ho dunque cercato di scoprire quali erano le cause di tali problemi tracciando il comportamento dellapplicazione durante lesecuzione della stessa in particolari situazioni. Sono stati determinati i seguenti problemi principali: layout disordinato e confusionario in alcuni punti; mancato redirect ad una pagina richiesta dallutente dopo la sua autenticazione; alcune funzionalit implementate soltanto parzialmente; assenza di alcune portlet specifiche per la fruizione di contenuti e la cooperazione aziendale. 46 di 113

4.1. EURIS DUE.ZERO

4.1.2

Lista dei requisiti

Nellelenco qui sopra sono stati riportate le lacune che affliggevano maggiormente il portale aziendale. Da queste sono emersi i diversi requisiti richiesti dallazienda, estrapolati proprio grazie allanalisi fatta. Tuttavia, come detto, alcuni di questi erano gi stati fissati inizialmente. I requisiti, suddivisi per risoluzione o sviluppo di funzionalit, si possono elencare di seguito: risoluzione dei problemi e stabilizzazione dellapplicazione web: modifica del messaggio di benvenuto presente nella barra superiore di quasi tutti i temi installati; correzione reindirizzamento ad una pagina richiesta dallutente dopo la sua autenticazione al portale; filtraggio operazioni di modifica / modifica minore di una pagina della Wiki nella portlet delle attivit; modifica del formato di default delleditor per la creazione di una pagina Wiki. sviluppo di nuove funzionalit: implementazione di un sistema per la modifica dei documenti caricati nel portale; visualizzazione embedded di un documento presente allinterno della piattaforma; realizzazione di diverse portlet per dotare lambiente di ulteriori funzioni organizzative e collaborative, quali: (a) visualizzare informazioni pertinenti una certa comunit e/o lutente autenticato; (b) fornire ai membri dellazienda un accesso semplice ed immediato alle comunit di cui fanno parte e alle relative risorse, dopo il loro login al portale; (c) consentire a ciascun utente di segnalare le proprie aree di interesse e competenza e tenersi aggiornato su di esse attraverso il forum aziendale; (d) permettere a determinati utenti di inviare un feedback mensile al loro responsabile di progetto.

Durante il colloquio con il tutor aziendale erano stati concordati con precisione solamente alcuni requisiti relativi allimplementazione di nuove funzionalit. In particolare, lo sviluppo del sistema di modifica dei documenti e lintegrazione nel 47 di 113

CAPITOLO 4. ANALISI DEI REQUISITI portale dellapplicazione interna allazienda realizzata in Microsoft Silverlight per la compilazione dei rapportini. Questultimo requisito, per, non stato possibile soddisfarlo poich il team di lavoro responsabile