Sei sulla pagina 1di 51

MASTER DI II LIVELLO:

"METODOLOGIE E TECNOLOGIE PER LO SVILUPPO DI INFRASTRUTTURE


DIGITALI (GARR-X Progress - Infrastruttura Digitale per promuovere Ricerca, Istruzione
e Competitività nel Sud)"

Modulo: "Tecnologie di Calcolo Distribuito"


Tesi conclusiva

" Definizione di linee guida per l'utilizzo e la gestione del sistema distribuito
collaborativo del Progetto S.F.I.N.G.E."

Relatore: A cura

Prof. Marcello Castellano Dott. Ing. Giovanni Zazzera

1
Un sentito ringraziamento va al Prof. Marcello Castellano e al suo team di esperti che mi
hanno permesso di scrivere il seguente lavoro, sostenendomi quotidianamente nell’
apprendere nuove conoscenze professionali e umane che entreranno a far parte del mio
bagaglio culturale…

2
Introduzione  .................................................................................................................................  4  
CAPITOLO  1  ...................................................................................................................................  4  
E-­‐LEARNING  STORIA  E  DEFINIZIONE  .............................................................................................  5  
1.1  COS’E’  L’E-­‐LEARNING  ....................................................................................................................  8  
1.2  Migliorare  la  qualità  in  e-­‐Learning  per  il  supporto  IT  basata  sulla  conoscenza  ....  12  
Capitolo  2  ....................................................................................................................................  14  
Elementi  e  funzionamento  di  un  portale  ....................................................................................  14  
2.1  Definizioni  generali  ....................................................................................................................  14  
2.2  Esempio  di  una  sequenza  di  eventi  .......................................................................................  16  
2.3  Limiti  della  specifica  JSR-­‐168  ..................................................................................................  17  
Capitolo  3  ....................................................................................................................................  19  
3.1  Introduzione  a  Liferay  Portal  ..................................................................................................  19  
3.2  Panoramica  delle  caratteristiche  del  portale  ....................................................................  21  
3.3  Funzioni  di  collaborazione  .......................................................................................................  23  
3.4  Gestione  degli  utenti  e  gruppi  .................................................................................................  24  
3.4.1  Utenti  ..........................................................................................................................................................  26  
3.4.2  Gruppi  di  utenti  ......................................................................................................................................  26  
3.4.3  Organizzazioni  ........................................................................................................................................  26  
3.4.4  Comunità  ...................................................................................................................................................  27  
3.4.5  Ruoli  ............................................................................................................................................................  28  
3.5  Scope  ................................................................................................................................................  28  
3.6  Architettura  e  framework  ........................................................................................................  29  
3.6.1  Service  Oriented  Architecture  .........................................................................................................  30  
3.6.2  Enterprise  Service  Bus  ........................................................................................................................  31  
3.6.3  Spring  .........................................................................................................................................................  32  
3.7  Strategie  di  sviluppo  del  portale  ............................................................................................  33  
3.7.1  Ambiente  Plugins  SDK  .........................................................................................................................  34  
3.7.2  Ambiente  Extension  .............................................................................................................................  35  
CAPITOLO  4  ................................................................................................................................  37  
S.F.I.N.G.E.  ..............................................................................................................................................  37  
CONCLUSIONE  ............................................................................................................................  49  
BIBLIOGRAFIA  E  SITOGRAFIA  DI  RIFERIMENTO  ...........................................................  50  

3
Introduzione    
Il lavoro svolto all’ interno del Laboratorio di Sistemi Distribuiti, Dipartimento di
Ingegneria Elettrica e dell’Informazione del Politecnico di Bari, ha prodotto, nelle seguenti
pagine, un’ attenta e approfondita analisi dell’ e-learning concentrandosi in un’ ampio
resoconto storico del concetto di apprendimento a distanza, passando per un riscontro
tecnico degli strumenti utilizzati per implementare un, sempre più incalzante, tipo di
apprendimento che si può definire “at any time anywhere you want”. Infatti si cerca di far
comprendere l’ elevata importanza di piattaforme e-learning che consentono a chiunque di
implementare la propria formazione ovunque si voglia e con l’ ausilio di qualsiasi tipo di
dispositivo elettronico pc, tablet e smartphone capace di garantire una connessione e la
portabilità della propria formazione è assicurata. Successivamente si è passati a parlare di
concetti più tecnici soffermando l’ attenzione su quelli che sono gli strumenti che
permettono lo sviluppo del servizio, ossia le portlet e i portali che danno la possibilità di
sviluppare il servizio di e-learning infine ci si è soffermati sul lavoro svolto all’ interno del
progetto S.F.I.N.G.E.

Regione Puglia Repubblica Italiana Unione Europea

Solution Framework for Interoperable Network in Grid E-learning


“Intervento cofinanziato dall’U.E.
FESR P.O. Regione Puglia 2007-2013 – Asse I – Linea 1.2 – Azione 1.2.4
Bando Aiuti a Sostegno dei Partenariati Regionali per l’Innovazione – Investiamo nel
vostro futuro” che ha sviluppato un portale di e-learnig utilizzando un portare liferay.
Infine il lavoro si conclude con prospettive possibili per una maggiore divulgazione dell’ e-
learning.

4
CAPITOLO  1  
E-­‐LEARNING  STORIA  E  DEFINIZIONE  

Nella società della conoscenza e dell’informazione un ruolo importante


assume l’e-learning. L’e-learning, letteralmente “apprendimento elettronico”, si propone come
un insieme di metodologie e strategie didattiche finalizzate alla creazione di un nuovo ambiente
di apprendimento in grado di sfruttare le potenzialità del web e della multimedialità. Non esiste
una definizione standard di e-learning, quella maggiormente condivisa è stata elaborata da
Anee, Associazione dei Servizi e Contenuti Multimediali (Liscia, 2004, p.12). L’ e-learning è
una metodologia di insegnamento e apprendimento che coinvolge sia il prodotto sia il processo
formativo. Per prodotto formativo si intende ogni tipologia di materiale o contenuto messo a
disposizione in formato digitale attraverso supporti informatici o di rete. Per processo
formativo si intende invece la gestione dell'intero iter didattico che coinvolge gli aspetti di
erogazione, fruizione, interazione, valutazione. In questa dimensione il vero valore aggiunto
dell'e-learning emerge nei servizi di assistenza e tutorship, nelle modalità di interazione
sincrona e asincrona, di condivisione e collaborazione a livello di community. Peculiarità dell'e-
learning è l'alta flessibilità garantita al discente dalla reperibilità sempre e ovunque dei contenuti
formativi, che gli permette l'autogestione e l'autodeterminazione del proprio apprendimento;
resta tuttavia di primaria importanza la scansione del processo formativo, secondo un'agenda
che responsabilizzi formando e formatore al fine del raggiungimento degli obiettivi didattici
prefissati. Come si può dedurre da questa definizione, con l’e-learning cambia il modo di
pensare e progettare i contenuti formativi, cambia il modo di organizzarli ed archiviarli, le
modalità di fruizione e di scelta da parte dell’utente e i sistemi di erogazione dei contenuti e di
gestione del processo (Eletti, 2002, p.65). Fondamentale è la concezione di un sistema di
apprendimento basato su contenuti pensati per il web e svincolati dal tempo e dallo spazio
della formazione tradizionale. Centrale, in questo senso, diventa il ruolo dell’utente, che in
maniera autonoma sceglie come e quando approcciarsi alla materia, contando su un
apprendimento attivo e collaborativo. Caratteristiche fondamentali dell’e-learning, quindi, sono
(Ganino, 2009, p.60-61):

5
1. utilizzo di una connessione ad internet e di un dispositivo tecnologico
(computer, tablet, smartphone);
2. indipendenza da vincoli di presenza fisica e orari specifici (anywhere, anytime);
3. monitoraggio continuo del livello di apprendimento, tramite valutazione e
autovalutazione;
4. valorizzazione della multimedialità;
5. interattività con i materiali didattici, i docenti, i tutor, e con gli altri studenti;
6. valorizzazione della dimensione sociale e collaborativa dell’apprendimento.

L’evoluzione dell’e-learning nella storia della didattica vede tre principali generazioni di FAD
(formazione a distanza). La prima, denominata per corrispondenza, risale alla metà
dell’Ottocento, ed era basata sul supporto del servizio postale e sullo sviluppo delle reti dei
trasporti; consisteva essenzialmente nell’utilizzo di materiale didattico cartaceo corredato di
istruzioni per lo studio autonomo e di test di verifica da rispedire al mittente. Si ha traccia di un
primo corso a distanza realizzato a Londra nel 1840 (Eletti, 2002, p.18) e, successivamente, in
altre località dell’Inghilterra e in Svezia. I corsi proposti erano prevalentemente di tipo tecnico-
commerciale, erogati da privati ed indirizzati a coloro che potevano permettersi un’istruzione al
di fuori del contesto scolastico. Le potenzialità di questa modalità didattica vengono rafforzate
dall’introduzione della radio nella prima metà del Novecento, che sancisce il passaggio dalla
modalità one-to-one alla one-to-many. I primi corsi universitari via radio vengono organizzati
negli Stati Uniti dal 1921; in Europa è la BBC inglese ad introdurli, a partire dal 1927 (Ganino,
2009, p. 59).
La seconda generazione si sviluppa negli anni sessanta, con
l’introduzione della televisione. Subito le sue potenzialità educative risultano evidenti: in
particolare l’impatto e la fascinazione molto forte delle immagini, il raggiungimento delle fasce
sociali a basso reddito, la facile comprensione anche da parte di un pubblico analfabeta.
L’impatto sulla società di massa viene poi amplificato con la diffusione dello standard VHS,
che ha aumentato l’uso domestico di materiale educativo in modalità asincrona.
La terza generazione, relativa all’attuale fase di FAD, è invece legata

6
alla diffusione del digitale a partire dagli anni ottanta. L’introduzione del computer sancisce una
svolta epocale nel paradigma didattico-educativo, attraverso il rafforzamento del ruolo
dell’utente grazie ai principi di interattività, multimedialità e crossmedialità. Due sono le fasi
principali che la caratterizzano:
- fase off-line, basata sull'uso di strumenti che non si avvalgono
del supporto delle reti (floppy disk, videodischi, cd-rom);
- fase on-line, caratterizzata dalla diffusione dell'uso di Internet.
Con l'avvento della formazione on-line, l'apprendimento diventa un
processo sociale dinamico che prevede il ruolo attivo dell’utente che entra a far parte di una
comunità in cui regna una condivisione di tipo orizzontale della conoscenza. Tutto ciò favorito
dal passaggio dal Web 1.0 al Web 2.0 e la nascita di strumenti che facilitano le attività autoriali,
di condivisione, collaborazione, partecipazione. La rete utilizzata non più soltanto come
strumento per accedere alle informazioni ma contraddistinta da caratteristiche social (wiki, blog,
youtube, social software ecc.) favorisce il consolidamento del concetto di e-learning e la sua
applicazione in contesti diversi: formazione universitaria, aziendale, formazione continua.
Questo tipo di formazione risponde alle esigenze della società contemporanea di tenere
continuamente aggiornati i saperi e le competenze dei propri membri, per non trovarsi in
condizioni di inferiorità sullo scenario dell’economia globalizzata. Come esempio
dell’importanza di questo tipo di formazione, si può dire che nel bilancio USA il totale della
spesa destinata alla formazione universitaria è uguale al totale della spesa investita nella
formazione continua dei cittadini [Banzato, 2003]. In Europa, ed in Italia, si riscontra un certo
ritardo nell’adeguamento dell’offerta formativa alle esigenze della formazione continua e
dell’Information Communication Technology (ICT). Tra le cause, si può annoverare una
percezione diffusa dell’e-learning come un semplice trasferimento in rete del modello di
lezione in presenza [Calvani, 2005]. In realtà la formazione on-line assume varie sfaccettature, e
accanto a modalità erogative dei corsi, che si basano sul modello tradizionale di didattica
incentrato sullo studio individuale e sui test di valutazione, si assiste all’affermazione di modelli
innovativi, nei quali la conoscenza individuale viene considerata come il risultato di una
costruzione collaborativa, frutto delle interazioni sociali instaurate fra i partecipanti al processo
formativo.

7
1.1  COS’E’  L’E-­‐LEARNING  

L’e-learning, come già detto in precedenza, non è limitato alla


formazione scolastica, essendo rivolto anche a utenti adulti, studenti universitari, insegnanti,
ecc. ed anche nella formazione aziendale, specialmente per le organizzazioni con una pluralità
di sedi. Tutti i sistemi di e-learning devono prevedere alcuni elementi essenziali, che sono:

- l’utilizzo della connessione in rete per la fruizione dei materiali didattici e lo


sviluppo di attività formative basate su una tecnologia specifica, detta
"piattaforma tecnologica" (Learning Management System, LMS);
- l’impiego del personal computer (eventualmente integrato da altre interfacce e
dispositivi) come strumento principale per la partecipazione al percorso di
apprendimento;
- un alto grado di indipendenza del percorso didattico da vincoli di presenza
fisica o di orario specifico;
- il monitoraggio continuo del livello di apprendimento, sia attraverso il
tracciamento del percorso che attraverso frequenti momenti di valutazione e
autovalutazione;
- la valorizzazione di:
- multimedialità (effettiva integrazione tra diversi media per favorire una migliore
comprensione dei contenuti);
- interattività con i materiali (per favorire percorsi di studio personalizzati e di
ottimizzare l'apprendimento);
- interazione umana (con i docenti/tutor e con gli altri studenti - per favorire,
tramite le tecnologie di comunicazione in rete, la creazione di contesti collettivi
di apprendimento).
L'e-learning sfrutta le potenzialità rese disponibili da Internet per
fornire formazione sincrona e/o asincrona agli utenti, che possono accedere ai contenuti dei
corsi in qualsiasi momento e in ogni luogo in cui esista una connessione online. Questa
caratteristica, unita alla tipologia di progettazione dei materiali didattici, portano a definire

8
alcune forme di e-learning come "soluzioni di insegnamento centrato sullo studente".

I Learning Object
Come si avrà avuto modo di capire, l'e-learning è un processo di
formazione continua che implica l'utilizzo delle tecnologie di rete per progettare, distribuire,
scegliere, gestire e ampliare l'apprendimento. In quest'ottica gli elementi principali nella
progettazione di contenuti erogabili via rete, i quali rendono la Formazione a distanza
(abbreviata in FAD) non più assimilabile ai monolitici corsi tradizionali da distribuire
indistintamente a tutti gli studenti, sono tre:
- l'interattività, vale a dire la necessità di coinvolgere il discente, generalmente
avvalendosi del learning by doing;
- la dinamicità, ovvero il bisogno da parte del discente di acquisire nuove
competenze mirate just in time;
- la modularità, ossia la possibilità di organizzare i contenuti di un corso secondo
gli obiettivi formativi e le necessità dell'utenza.
Spendiamo altre due parole su questo terzo e ultimo elemento. Ogni
blocco formativo (detto nel linguaggio tecnico learning object) può essere sfilato e da un corso
e assemblato con altri blocchi formativi per formare un corso nuovo: per tanto il learning
object può esser definito come un qualsiasi oggetto che entra a far parte del processo di
formazione e che può essere (ri)utilizzato in tempi e luoghi diversi. La grandezza di un learning
object varia a secondo la metodologia adottata dal progettista. Ma quali sono le caratteristiche
necessarie ai learning objects per poter essere riutilizzati?
I. Sono facilmente reperibili e trasportabili;
II. possibilità di gestire gli archivi dei contenuti;
III. assegnare ai singoli learning objects dei set di metadata.
Oggigiorno esistono solo due certificazioni di trasparenza e
riutilizzabilità dell'e-learning: l'AICC (acronimo di Aviation Industry CBT Committee) e la
SCORM (Sharable Courseware Objects Reference Model). Esistono poi altri gruppi impegnati
nella definizione di una specifica internazionale dei lerning object, definita e condivisa,
menzioniamo ARIADNE (Allience of Remote Instructional Authoring and Distribution
Network for Europe) e PROMETEUS (PROmoting Multimedia access to Education and

9
Training in EUropean Society). Da segnalare l'utilizzo del linguaggio XML (Extensible Markup
Language) che consente infatti una migliore atomizzazione dei contenuti e una più efficace
esportabilità sui diversi supporti (p.e. palmeri, periferiche indossabili ecc.).

Le figure professionali coinvolte nell’ e-learning


Varie sono le figure professionali che orbitano attorno il mondo dell'e-
learning. Quelle che illustreremo a breve spesso in Italia sono riunite in una sola persona fisica.
Ma prima di far ciò è bene elencare le strutture che intervengono in modo rivelante nello
svolgimento del processo, suddividendole in:
- cliente, ovvero chi commissiona gli interventi formativi;
- learning company, l'azienda che risolve con diverse soluzioni i bisogni
del cliente;
- content provider, la struttura che fornisce i contenuti oggetto del
percorso di apprendimento;
- multimedia agency, l'azienda che collabora con la learning company alla
progettazione del corso multimediale e ne realizza concretamente la
grafica e il software;
- tester, le aziende che collaborano con le learning company alla verifica
tecnica dei prodotti finiti.

I contenuti dell'e-learning
I contenuti dei corsi didattici possono essere progettati in diversi
formati: pagine HTML, animazioni 2D o 3D, contributi audio, contributi video, simulazioni,
esercitazioni interattive, test,… In qualsiasi caso, si tratta di contenuti realizzati in modalità
multimediale e possono essere costruiti ad hoc (attraverso software di authoring) o essere stati
modificati da materiale già esistente in formato elettronico come ad esempio gli eBook (anche
in modo molto semplice, salvando - ad esempio - una presentazione in formato HTML).
Gli esperti di e-learning sostengono che i materiali didattici
dovrebbero essere costruiti ad hoc in modo da garantire le quattro principali caratteristiche

10
della formazione online:
- modularità
il materiale didattico deve essere composto da moduli didattici,
chiamati anche Learning object (LO) in modo che l'utente possa
dedicare alla formazione brevi lassi di tempo (indicativamente
15/20 minuti di tempo), personalizzando così tempi e modalità di
approccio ai contenuti.
- interattività
l'utente deve interagire con il materiale didattico, che deve
rispondere efficacemente alle necessità motivazionali
dell'interazione uomo-macchina
- esaustività
ogni LO deve rispondere a un obiettivo formativo e portare l'utente
al completamento di tale obiettivo.
- interoperabilità
i materiali didattici devono essere predisposti per poter essere
distribuiti su qualsiasi piattaforma tecnologica e per garantire la
tracciabilità dell'azione formativa. A tal fine sono stati individuati
quindi degli standard (AICC, SCORM, IMS,…) che devono essere
implementati per garantire la comunicazione fra diversi sistemi e
fare in modo che un Learning Object concepito su una piattaforma
possa essere integrato in un'altra. Attualmente lo standard più
diffuso è SCORM.
L'evoluzione tecnologica ha portato alla realizzazione di sistemi
Learning Content Management System (LCMS) che si occupano della gestione dei contenuti
sia nella fase di creazione che nella fase di erogazione. Tali strumenti, associati al LMS,
completano una piattaforma di e-learning.
Da un punto di vista tecnico, i Learning Object sono oggetti descritti
tramite specifiche XML e/o, appunto, dialetti specializzati di XML come EML ed altri, che
vengono interpretati dal browser nella sua interazione con il LCMS server per costruire
l'oggetto documentale, multimediale, il test con le sue caratteristiche e, in SCORM e successivi,

11
anche la corretta sequenza di contenuti del percorso formativo. Un oggetto di apprendimento
(LO) può contenere inoltre specifiche del livello di ingresso, dei prerequisiti, del contesto di
applicazione.

1.2  Migliorare  la  qualità  in  e-­‐Learning  per  il  supporto  IT  basata  sulla  conoscenza  

I progressi della tecnologia nel fornirniscono un aiuto


efficaceper il processo decisionale e di problem solving in molti aspetti della vita. Tra le
tecnologie disponibili, Information Technology (IT) è una delle tecnologie leader che utilizza
efficacemente le scarse risorse per incontrare il divario tra le soluzioni fornite da metodologie e
le esigenze della società esistenti. Questo documento identifica i parametri qualitativi e di
supporto IT per i parametri. Questi parametri sono utilizzati per valutare l'efficacia che può
essere valorizzato mediante dato supporto IT per ottenere vantaggi massimi di metodologia e-
learning. Sulla base di un risultato di un'indagine fatta per i parametri selezionati, una nuova
conoscenza e-Learning prototipo è implementata.

QUALITA’ IN E-LEARNING
Al fine di aumentare l'efficacia nel processo di apprendimento, diversi
approcci sono stati sviluppati oltre l’ istruzione tradizionale. Efficacia del sistema di istruzione
dipende dal grado di qualità che esibisce. Il potere di imparare attraverso Information
Technology (IT), in una certa misura garantisce l'apprendimento di alta qualità, fornendo le
informazioni necessarie, passo assistenza saggio, e consiglia per il processo decisionale in modo
costo-efficacia. La tecnologia e-Learning è un'infrastruttura che privilegia la distribuzione
online di informazioni e, quindi, accelera l'apprendimento. Le principali figure di un sistema di
e-learning sono: esperti della materia, sviluppatori multimediali, istruttori, editori, progettisti, e
tecnici (Kanedran, Johnny & Durga 2004). I vantaggi, come la disponibilità di informazioni di
alta qualità sulle punte delle dita, consulenza tempestiva, e la rappresentazione efficace di
informazioni possono essere raggiunti con la tecnica e-Learning. Obiettivi primari della
struttura tecnica di e-Learning sono i seguenti (Unwin 2003):

- garantire che l'accesso alle informazioni di alta qualità è integrato nella

12
disposizione del corso;

- equipaggiare e-Learners con le competenze di informazione per sfruttare tali


informazioni;

- fornire adeguata assistenza alle e-Learners in informazioni-ricerca;

- affrontare le relative comunicazioni e le questioni che costano.

Sono stati sviluppati diversi sistemi di e-Learning e modelli finora per


incassare quanto sopra detto vantaggi. Zahm (2000) ha descritto computer-based training
multimediale (CBT) su CD-ROM o come download Web. Urdan & Weggen (2000) hanno
condiviso che l'e-Learning copre una vasta gamma di applicazioni e processi, tra cui computer-
based learning, l'apprendimento basato sul web, classi virtuali, e collaborazioni digitali via
internet, intranet ed extranet. Schreiber & Berge (1998) e Gotschall (2000) hanno proposto che
l'apprendimento on-line è basato su atechnology-learning per rendere le informazioni
attualmente disponibili per l'accesso diretto. Nella sua opera, Hall (2000) ha proposto
formazione a distanza come corso interattivo progettato utilizzando il concetto di e-Learning
per insegnare efficacemente competenze tecniche. Tuttavia, la qualità può essere ulteriormente
migliorata con l'adozione di approccio basato sulla conoscenza per l'e-Learning. Software
computer-aided tradizionale è in genere un sistema vero e proprio sulla base di una banca dati
che fornisca solo presentazione statica delle informazioni. Tali sistemi non hanno l'attenzione
personale e gli studenti non vengono motivati, in quanto vi è la mancanza di una guida. Il
software dovrebbe essere facile da usare (principalmente in lingua madre), in grado di
presentare le informazioni in modo dinamico e multimediale, e in grado di spiegare il proprio
processo decisionale. In breve, la strategia ha bisogno di soddisfare i diversi gruppi di utenti in
modi diversi, identificando l'interesse dell'utente e il livello.

13
Capitolo  2  

Elementi  e  funzionamento  di  un  portale  

In questo capitolo ci si occuperà di fornire alcune nozioni fondamentali necessarie ad


introdurre la piattaforma Liferay Portal.

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 s’intende 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 dinamiche chiamate portlet. Una portlet è un
modulo web realizzato in tecnologia Java riusabile all’interno 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.

14
Il contenuto generato da una portlet è denominato anche frammento. Quest’ultimo è 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 all’altro a seconda della configurazione apportata ad essa.
Diverse portlet, integrate insieme, concorrono a creare una singola pagina del portale. Inoltre,
una stessa portlet può essere utilizzata in più pagine.

Figura 2.1: Raffigurazione di una pagina formata da portlet.

Visivamente, le portlet sono porzioni di pagina e funzionalmente sono dei canali


informativi. L’applicazione 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,
l’utente finale costruisce una pagina per aggregazione dei singoli elementi, avendo come

15
risultato finale una pagina web configurabile ed adattabile alle sue volontà.
Tecnicamente, la rappresentazione finale è affidata per gran parte al portlet container che
gestisce il loro ciclo di vita. Infatti, il suo compito è di seguire le azioni dell’utente (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]).
Quest’ultimo è 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 l’interoperabilità
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;
! l’interazione 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 dell’aggregazione 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.

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

16
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 un’azione mirata su un qualsiasi delle portlet
associate alla pagina;
- se c’è un’azione indirizzata ad una portlet, il portale richiede al portlet container di
invocare la portlet per processare l’azione;
- 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 quest’ultima al
client.

2.3  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 all’interno 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;
- l’integrazione con AJAX non è supportata internamente, a meno che non sia
offerta dal portlet container in modo non standard.
Questi limiti hanno portato all’introduzione 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

17
di arrivare alla specifica. Le novità introdotte riguardano principalmente i seguenti punti:
- 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.

18
Capitolo  3  

La piattaforma Liferay Portal


In questo capitolo ci si occuperà di descrivere dettagliatamente la piattaforma Liferay
Portal usata per la realizzazione del progetto S.F.I.N.G.E.. In particolare, dopo aver illustrato
quali sono le caratteristiche principali della piattaforma, ci si soffermerà sull’analisi
dell’architettura 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, un’ottima 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
un’organizzazione 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 nell’organizzazione e stesura
dei contenuti;
- collaborazione, per stimolare il lavoro in team;
- applicazione che può servire da framework (ambiente) per la gestione e
l’integrazione di nuovi contenuti ed applicazioni.
Questo software è un prodotto della Liferay Inc. ed stato concepito nel 2000.

19
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.
L’applicazione fornisce un’interfaccia web unificata per le varie informazioni e gli
strumenti che provengono da diverse sorgenti. All’interno 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 un’architettura SOA.
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 all’interno di un’azienda, ad esempio alcune saranno rilevanti
a livello di team, mentre altre in tutta l’organizzazione. 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.

20
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 l’ultima 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 all’uso: forte di un’estesa 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 all’autenticazione 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

21
accedendo una volta sola con il massimo della riservatezza;
- 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 un’organizzazione. Il
tempo per modificare un layout di pagina, l’aggiunta di nuove applicazioni e
contenuti, cambiando anche l’aspetto della grafica può essere fatto in un paio di
click, anche dall’utente finale stesso;
- sistema di gestione dei contenuti: il CMS incluso all’interno 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;

22
- 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.

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 all’interno di un gruppo (organizzazione o
community). Liferay mette a disposizione dei report sull’attività 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 l’editor 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

23
amici vengono automaticamente visualizzati i nomi degli amici collegati.
L’accesso al servizio è inserito in una barra in fondo alla videata e segue l’utente
lungo la navigazione all’interno 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 dall’amministratore;
- sondaggi: sono disponibili delle portlet per l’impostazione, 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). L’approccio 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’’.

24
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 dall’obiettivo del portale. Se si
tratta di un portale aperto al

Figura 3.1: Organizzazione delle risorse umane e loro gruppi nel portale.

pubblico, e che magari all’utente autenticato riserva più funzionalità personalizzate, saranno
apportate opportune configurazioni alle portlet; se, invece, il portale è totalmente privato, ad
esempio un’intranet, saranno fatte le diverse configurazioni del caso.
In generale si può parlare di ruoli all’interno 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.

25
3.4.1  Utenti  
Gli utenti possono essere raggruppati in diverse maniere. Possono essere infatti
membri di gerarchie di un’organizzazione 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 nell’ambito dell’organizzazione, della comunità o dell’intero 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.

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 all’interno 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 nell’organigramma aziendale. Se, ad esempio, quell’utente è 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.

26
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 un’area 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 all’uso 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 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. L’altro è 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 all’amministratore 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).

27
Una comunità privata, invece, necessita che gli utenti siano aggiunti ad essa
dall’amministratore della comunità. Gli utenti, anche in questo caso, possono usare il pannello
di controllo o la portlet dedicata per richiedere l’adesione.
Infine, una comunità nascosta è come una privata, con l’aggiunta 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
all’interno 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 all’intero portale,
ad un’organizzazione 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.

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 d’azione’’. 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
un’organizzazione o di una comunità. Ciò significa che ha effetto solo nell’ambito in cui risiede.
Ritornando all’esempio 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 dell’intero portale.

28
Se, invece, è un community role i membri hanno il permesso di gestire i forum solo
all’interno delle comunità in cui sono membri del ruolo. Se, infine, è un organization role i
membri hanno l’autorizzazione 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 un’istanza 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  


L’aspetto più importante di ogni portale è senza dubbio l’architettura 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 l’implementazione 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 dell’architettura e le funzionalità delle portlet.

29
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 un’interfaccia 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 l’attenzione sul concetto di servizio. Un
sistema costruito seguendo questa filosofia è costituito da applicazioni, chiamate appunto
servizi, ben definite ed indipendenti l’una dall’altra, che risiedono su più computer all’interno di
una rete (ad esempio la rete interna di un’azienda 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à.
L’architettura SOA, che si può considerare quindi come una forma particolare di
sistema distribuito, presenta alcune caratteristiche e proprietà orientate al riutilizzo e
all’integrazione 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

30
servizi;
- essere definito da un’interfaccia ed indipendente dall’implementazione; essere
debolmente accoppiato con altri servizi;
- essere reso disponibile sulla rete tramite la pubblicazione della sua interfaccia ed
accessibile in modo trasparente rispetto alla sua allocazione;
- fornire un’interfaccia 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, l’utilizzo 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. L’architettura permette inoltre
agli utenti di accedere al portale non solo con i dispositivi tradizionali e wireless, ma gli
sviluppatori possono effettuare l’accesso grazie a specifiche API per mezzo di protocolli quali
REST, SOAP, XML-RPC ed altri.

3.6.2  Enterprise  Service  Bus  


L’Enterprise Service Bus (ESB) è un gestore centrale delle connessioni che permette ad
applicazioni e servizi di essere aggiunti rapidamente ad un’infrastruttura enterprise. Quando
un’applicazione 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.
L’ESB 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.

31
In breve, si può dire che un portale basato su Liferay generalmente utilizza l’ESB per
dotarsi di un layer di astrazione sopra l’implementazione 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.

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. Un’importante 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 un’applicazione più robusta, facilitando anche il riutilizzo dei componenti e
rendendo più semplice lo sviluppo. Il concetto alla base dell’IoC è 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 un’entità esterna (container) come anche la loro configurazione che usa file XML.
Una delle tecniche con cui si può attuare l’IoC è la Dependency Injection (DI), cioè il
container si fa carico di ‘‘iniettare’’ le dipendenze nell’istanza 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 dell’Aspect 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, l’interfaccia 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 l’ambiente di
estensione Ext. Altre librerie, come Portal-Kernel e Portal-Service, sono invece previste per usi

32
esterni (e anche interni). Forniscono infatti delle API che possono venir sfruttate da plugin
esterni, come avviene nell’ambiente 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;


- ambiente Extension;
- codice sorgente di Liferay Portal.

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.

33
3.7.1  Ambiente  Plugins  SDK  

Plugins SDK è un semplice ambiente per lo sviluppo di plugin e, quindi, serve per
realizzare portlet, temi, layout, hooks1 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.
L’ambiente SDK consente quindi di creare plugin hot-deployable per il portale Liferay
attraverso l’invocazione di task di Ant forniti insieme all’SDK, 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 l’application server. Dunque, dapprima
vengono sviluppati i plugin e poi vengono usati tali task per costituire dei file WAR che
vengono direttamente copiati in un’apposita cartella di Auto Deploy. In seguito, il portale,
assieme all’application 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 dell’ambiente Plugins SDK è riportato nella seguente figura.

Figura 3.4: Funzionamento dell’ambiente 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.

34
3.7.2  Ambiente  Extension  
L’ambiente Extension (Ext) permette di personalizzare completamente Liferay Portal.
Infatti, estende l’ambiente 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
l’obiettivo di agevolare l’upgrade a nuove versioni di Liferay in cui inserire le personalizzazioni
realizzate per le precedenti versioni.
Come illustrato nella seguente figura, il funzionamento dell’ambiente di estensione
può essere riassunto in pochi punti:
il custom code sovrascrive (‘‘override’’) il codice sorgente del portale nell’ambiente Ext;
prima del processo di deploy il custom code viene fuso (‘‘merge’’) con il codice sorgente
del portale sempre nell’ambiente Ext; il risultato è una versione custom del portale Liferay
(‘‘Customized Liferay Portal’’) costruita in ambiente Ext;
il portale Liferay così personalizzato viene quindi ‘‘deployato’’ da Ext sull’application
server.

35
Figura 3.5: Funzionamento dell’ambiente 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 l’approccio di sviluppo mediante l’Extension 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).

36
CAPITOLO  4  

S.F.I.N.G.E.  
In generale, il Mercato della formazione scaturisce dalla risposta imprenditoriale alla
crescente domanda (proveniente da Aziende o comunque Organizzazioni) di allineamento
delle competenze delle risorse umane alla revisione dei processi di produzione che ha spinto
allo studio del prototipo infrastrutturale realizzato con cui sono state definite le specifiche della
piattaforma software per l’e-learning e delle funzionalità applicati e del sistema.
L'applicazione prototipale è stata progettata e descritta a livello concettuale e logico,
mettendo in evidenza livelli di design tra loro ortogonali: design della struttura informativa,
design dell’interfaccia, design della struttura di aggregazione e presentazione delle informazioni,
design delle operazioni che possono essere compiute sui dati.
Qualità e Rapidità di risposta rimangono i temi su cui lavorare per essere Competitivi.
La Flessibilità nei Processi di Produzione sostiene il requisito di competitività. Un Sistema
Produttivo Distribuito è uno scenario flessibile.
In questo quadro generale il progetto ha come fine ultimo quello di creare un portale
capace di interfacciarsi con i dipendenti di un’ azienda rendendo loro un servizio di formazione
capace di fornire mobilità e qualità dei corsi che i dipendenti sono tenuti a sostenere per la
formazione continua.
Il prodotto del progetto SFINGE è rappresentato dai seguenti elementi:
" piattaforma SOFTWARE per la progettazione, realizzazione, produzione ed
erogazione di corsi e-learning;
" linee guida per la conversione di attività di formazione tradizionale in attività di
formazione a distanza;
" middleware per griglie computazionali in grado di supportare l'interoperabilità
fra i partner;
" hardware per l'implementazione del prototipo.
L'obiettivo finale ha come oggetto una proposta di innovazione riguardante l'azienda
proponente in termini di trasferimento tecnologico da processo\prodotto di formazione
tradizionale a processo\prodotto di formazione in modalità e-learning.

37
Per far ciò si sono individuate varie piattaforme e tra queste ci si è soffermati su quali
offrissero una facile gestione dei contenuti e che fossero di semplice utilizzo da parte
dell’utente e che potessero essere interfacciabili con una griglia computazionale.
Nella prima fase dello studio si è cercato di capire quale fosse la soluzione migliore per
creare diversi profili utenti che accederebbero alla piattaforma ad ognuno dei quali associare
dei permessi specifici nell’utilizzo della stessa.
Le piattaforme analizzate sono state Moodle, WordPress, Elgg e Liferay, che è stata
scelta rispetto alle altre in quanto offre un buon livello di libertà e personalizzazione all’interno
del portale, inoltre ha un elevato grado di interfacciabilità con i sistemi di grid computing.
Si è scelta la formattazione del portale tramite delle portlet che nella schermata iniziale
sono presenti in un numero pari a 3, inoltre S.F.I.N.G.E., come si è accennato in precedenza,
adotta la tecnologia della grid information poiché fondamentale per l’ inserimento sul portale
di nozioni da parte di chiunque aumentando così qualità e quantità del servizio, in quanto si
verifica un aumento della capacità di storage e computing.

Figura 4.1: homepage del portale con 3 portlet


Una volta dentro, il portale consente una serie operazioni in base alla tipologia di ruolo
assegnato, infatti si possono distinguere vari “attori” all’ interno dello stesso con i rispettivi
permessi con i quali possono usare il portale. Il direttore di progetto, il project manager,
l’instructional designer, gli esperti di contenuto possono collaborare al fine di garantire che il
Project Plan sia pedagogicamente valido. Questa fase fondamentale vede la stretta
collaborazione tra diverse figure professionali ognuna con competenze diverse, che si
appiattiscono in un’unica persona, soprattutto in piccole e medie realtà imprenditoriali.
In questa fase le figure professionali interessate sono:
" PM = Project Manager

38
" ID = Instructional Designer
" SME= Subject Matter Expert (o Esperto di contenuti)
" EP = Esperto di Piattaforme (Sviluppatore e Amministratore della
piattaforma/Responsabile LMS)
" EV = Esperto di Valutazione
In questa fase il PM definisce e perfeziona gli obiettivi generali, dettagliandoli e pianificando lo
svolgimento delle azioni necessarie per il raggiungimento degli obiettivi stabiliti, descrivendo in
dettaglio “quello che deve essere fatto”, i deliverables (azioni sottoposte e approvate dal team
di project management) e il lavoro necessario per la realizzazione:
• viene generata la WBS (Work Breakdown Structure), cioè la segmentazione gerarchica
strutturata del lavoro da svolgere in singole azioni (pacchetti di lavoro, “Work
Package”) per migliorare la gestione e il controllo del progetto
• viene costruita la schedulazione dei tempi, a partire dalle attività previste, dalle stime di
durata, dai mezzi disponibili, dal budget
Il Project Management Plan è il documento che descrive in che modo il processo è eseguito,
monitorato e controllato.
Esso deve anche contenere:
• il Quality Plan (Piano di Gestione della Qualità) che identifica gli standard di qualità per
il progetto e le modalità di attuazione delle politiche di gestione della Qualità
• il Registro dei Rischi, che contiene l’elenco dei rischi identificati, delle potenziali
risposte, le principali cause di rischio
• il Piano di Comunicazione, che definisce le esigenze informative e di comunicazione
degli stakeholders.
Una volta loggati come admin all’ interno del portale non ci sono limiti di operazioni nello
stesso, potendo sceglie la sezione relativa all’ amministrazione web con cui si può operare e
gestire i template, i content dove si procede con l’ analisi (project character), planning (più
detagliato del project plan), implementazione (creazione del corso tutti i learning object),
erogazione (piattaforma collegata con moodle o altre piattaforme).

Nello specifico una volta dentro loggati come admin si possono avere, come detto in
precedenza, tutti i permessi che nel nostro caso cominciano con l’ aggiunta di uno o più

39
progetti. Lo stesso può dirsi per il PM che a differenza dell’ admin nel portale può gestire
solo un progetto ovviamente previa autorizzazione.

Figura 4.2: set up CONTENT nuovo progetto

Figura 4.3: set up APPLICATIONS nuovo progetto

40
Figura 4.4: set up PAGE nuovo progetto
Queste sono strutture per settare gli elementi, i template usati sono dei linguaggi xml che
servono a creare i template che effettivamente il documento/progetto segue e che
vengono fatti secondo le disposizioni date dall’ azienda che ha collaborato al progetto. Per
seguire un corretto flusso di lavoro si fa ricorso al workflow Kaleo 6.2 e vi si accede
tramite la sequenza:
my account > my workflow Tasks > action

Figura 4.5: gestione del workflow


Il workflow permette di creare un documento, questo viene assegnato dall’ amministratore
di sistema ad un altro utente per la correzione, quindi approvato o rigettato. Per come è

41
strutturato liferay per poter assegnare un workflow ad un’ organizzazione, nel nostro caso a
Genesis, il documento deve essere creato sul portale dell’ organizzazione a quel punto il
workflow potrà essere assegnato solo agli utenti iscritti a quella data organizzazione ed è
importante perché così possiamo tenere varie organizzazioni e vari gruppi separati, senza
che tutti vedano le notifiche di tutti.
Nello specifico si è optato per Kaleo 6.2 che ha le seguenti caratteristiche:
La creazione di nuove definizioni del flusso di lavoro

Un flusso di lavoro Kaleo, chiamato una definizione di processo, è definita in un file XML
e viene eseguito dagli utenti del portale. È possibile creare tante definizioni del flusso di
lavoro diversi, se necessario per gestire il lavoro fatto sul vostro portale. I flussi di lavoro
possono definire nuovi ruoli utente per gestire il processo di approvazione o utilizzare ruoli
che già esistono nel portale. Il file XML ha diverse parti che definiscono il flusso di lavoro.
Per avere un'idea di come funziona, esamineremo il singolo file-validatore-definition.xml
predefinita che è incluso nel plugin Liferay Kaleo.

Le parti principali della definizione del flusso di lavoro sono il bene o l'azione di workflow-
enabled che sta correndo attraverso il flusso di lavoro, i nodi del flusso di lavoro, e le
transizioni tra i nodi. Le attività sono ogni tipo di attività registrato in Liferay: contenuti
web, articoli wiki, discussioni message board, blog le voci, e anche i commenti, sono
workflow-enabled. Azioni workflow-enabled nel portale includono Pagina Revisione e
aggiunta utente o la modifica. Gli sviluppatori possono inoltre creare i propri beni da
utilizzare con i flussi di lavoro (vedi Liferay in azione o Guida Liferay Developer per
ulteriori informazioni). I nodi rappresentano le fasi del flusso di lavoro e ci sono diversi tipi.
Transizioni si verificano tra i nodi e dovrebbe indicare il nodo successivo. Pensate al flusso
di lavoro come una macchina a stati costituita da nodi. Un nodo può essere uno stato, un
compito, una condizione, una forchetta, un join o un timer. Transizioni sono utilizzati per
passare da un nodo all'altro. Ogni tipo di nodo ha proprietà diverse. Ad esempio, afferma
di eseguire azioni in modo automatico e non richiedono l'input dell'utente. Compiti blocco
finché l'ingresso utente completa una transizione a un altro stato. Il passaggio poi sposta il
flusso di lavoro per il prossimo compito o lo stato. Questo ciclo continua fino al

42
raggiungimento dello stato finale approvato. Ad esempio, è possibile creare un flusso di
lavoro che passa attraverso due approvazioni. Avvio il flusso di lavoro mette in stato In
Review e poi passa a un compito che richiede l'input dell'utente. Gli utenti approvano o
respingono l'attività come parte del compito. Quando il primo utente approva l'attività del
flusso di lavoro, una condizione verifica se ci sono due approvazioni. Poiché vi è un solo,
la transizione workflow torna al compito. Quando il secondo utente approva il bene, la
condizione trova ci sono due approvazioni e innesca una transizione diversa allo stato
Approvato. Impariamo su componenti del flusso di lavoro del validatore unico e guardare
in dettaglio come si sarebbe creato un flusso di lavoro utilizzando un unico responsabile
dell'approvazione.

Avvio di una definizione del flusso di lavoro

Di seguito è riportato un diagramma di una definizione unica del flusso di lavoro


dell'approvazione. Ha solo due compiti (UPDATE e Review) e due stati (stato iniziale e
approvati).

Figura 11.1: Il flusso di lavoro responsabile dell'approvazione singolo difetto. Frecce rappresentano
transizioni e scatole rappresentano gli stati e le attività.

In primo luogo è necessario definire lo schema. Per Liferay flussi di lavoro utilizzando
Kaleo, Liferay-worklow-definizione-6_2_0.xsd dovrebbe essere lo schema. Ecco come si
definisce nel file XML di vostra definizione del flusso di lavoro:

43
Quindi, si definisce un nome e una descrizione per il flusso di lavoro. Questa viene
visualizzata nel pannello di controllo quando gli utenti scelgono e configurare i flussi di
lavoro.

Dopo di che, è possibile definire lo stato iniziale.

Creazione di uno stato iniziale

In questo caso, lo stato è semplicemente che l'attività è stata creata. Uniti possono
contenere azioni e transizioni. Le azioni possono contenere script. È possibile specificare la
lingua dello script con il <script language> tag. Gli script possono essere scritti in Groovy,
JavaScript, Ruby o Python. Per uno Stato, l'azione viene attivata automaticamente e quindi
esegue una transizione. Transitions si trasferiscono in un nuovo stato o attività.

Dallo stato iniziale, la transizione a una nuova attività, in cui l'ulteriore elaborazione è
bloccato in modo che il bene può essere riesaminato.

44
Il passo successivo è quello di creare un'attività.

Creazione di attività

Il compito ha più parti ed è la parte più complessa della definizione. Le attività sono legate
a ruoli per scegliere chi deve completare il compito. I ruoli vengono informati che ci sono
nuovi contenuti in bisogno di revisione. Se si definisce un ruolo che non esiste, viene
creato automaticamente. Il primo compito di cui la definizione del flusso di lavoro single-
validatore-definition.xml è il UPDATEtask. Anche se appare per prima nel file, in realtà
non è la prima attività nel flusso di lavoro. L'attività di aggiornamento è il compito che è
assegnato dal flusso di lavoro, se l'attività è respinta da un responsabile. E 'nominata per
prima perché è il compito di default: quando questa attività viene attivato, il processo di
workflow viene azzerato di nuovo all'inizio. In questo compito, l'attività è assegnato di
nuovo al creatore di contenuti, che riceve una notifica via email ed è necessario per
ripresentare l'attività. Una volta che il compito è ripresentato, risale alla fase di revisione. È
anche possibile vedere il compito è assegnato a <utente />. Questo tag assegna sempre il
compito indietro per l'utente che ha creato il bene.

45
Il compito recensione rappresenta il primo compito nel flusso di lavoro. Questo è dove gli
utenti del portale con il ruolo proprio rivedono il contenuto e decidono di rifiutarlo
(spostarlo indietro all'inizio) o accettarlo (passaggio alla fase successiva). Una volta che la
transizione è stata fatta a questo compito, viene inviata una notifica a coloro che sono
assegnati al compito. È possibile modificare il nome o il contenuto della notifica nel file
XML. Una volta che il recensore ha completato la loro revisione ed esce il compito di
workflow, un'altra e-mail viene inviata al mittente originario indicando che la revisione è
stata completata.

È inoltre necessario assegnare il compito di un ruolo o ruoli specifici. Questo ruolo non
deve essere il ruolo che la notifica. Ad esempio, si potrebbe desiderare di notificare tutti i

46
creatori di contenuti ogni volta che un nuovo elemento è presentato. Indipendentemente
da chi si sta notificando, e sicuramente desidera inviare una notifica a chi è competente per
l'approvazione dei contenuti.
Per poter parlare del Control Panel bisogna dare una definizione di quello che è per noi la
Virtual Organization in quanto tramite questo comando si gestiscono Users, Siti, Apps e
configurazioni del workflow.
V.O.: unione di uomini, macchine, know how gestite dal portale usati per migliorare il processo di
produzione di corsi di e-learning
A tal proposito è molto importante la Sfinge grid information perché saranno visibili le
info della griglia computazionale.
Selezionando dal Control Panel gli Users si possono gestire utenti e organizzazioni e
spostando il cursore su Actions si possono dare vari tipi di permessi ai vari attori presenti
nell’ elenco, inoltre selezionando Organization si può notare che c’è Genesis.org , che
rappresenta l’ azienda che collabora e che si occupa di produzione di e-learning.

Figura 4.6: gestione Users


Succesivamente si possono gestire i Roles ossia le varie figure presenti nel layout della
gestione del processo di e-learning a cui si possono attribuire vari tipi di permessi,
selezionando sempre, action.

47
Figura 4.7: vari roles (ruoli) presenti nel portale
L’ attenzione è rivolta tutta su Project Manager che nel nostro caso è la figura più
importante in quanto gestisce tutto nel nostro portale perché ha i seguenti ruoli:
" da compiti e altri ruoli agli utenti;
" edita quello che c’è in griglia (griglia dei ruoli);
" definisce i permessi che fanno interagire con il portale;
" assegna i membri;
" vede utenti che appartengono a una categoria;
" può cancellare tutto.

Figura 4.8: schermata rolus in cui è presente P.M.

48
CONCLUSIONE  

IT è uno degli strumenti efficaci per accelerare il processo di apprendimento in modo


altamente personalizzato. Le indagini condotte qui indicano che la tecnologia di base e le
infrastrutture per fornire funzionalità efficace sono fondamentali per la corretta attuazione del
modello adottato di e-Learning. Varie istituzioni mantengono una serie di risorse di
formazione al fine di garantire un livello base di competenza. Il risultato delle indagini
evidenzia la necessità di un approccio basato sulla conoscenza per ottenere dei vantaggi, come
il recupero efficace e la presentazione, gli utenti hanno bisogno di identificazione, la
valutazione delle risposte degli utenti, e la spiegazione e giustificazione dei sistemi proprie
decisioni per raggiungere un'elevata qualità. Le istituzioni devono essere consapevoli dell’
evoluzione di livelli di abilità tecniche e adattare le loro risorse di conseguenza per gestire il
cambio necessità di formazione tecnica e pedagogica avanzate per garantire il corretto utilizzo
di tecniche e-Learning. In aggiunta a questo, le istituzioni che offrono la tecnologia devono
bilanciare costantemente la crescita del numero di corsi e-learning con le mutevoli dinamiche
della struttura di supporto.
Inoltre, lo sviluppo di e-Learning è essere orientata a soddisfare le esigenze e la
situazione dello studente. La qualità e l'orientamento verso i bisogni degli studenti sono fattori
critici per determinare l'efficacia del sistema. Implementazione IT di successo dovrebbe
affrontare (i) l'assistenza tecnica generale; (ii) informazioni ampliato l'accessibilità mediante
risorse; e (iii) Sistema meccanismo di utilizzare il supporto tecnico e altre risorse. I fattori di
qualità denotate in questo documento sono anche utili a fornire misure di qualità per i sistemi
di e-Learning. Questo aiuta anche a determinare l'impatto di un determinato parametro di
qualità per i sistemi di e-Learning e quindi fornisce le linee guida per lo sviluppo di successo.

49
BIBLIOGRAFIA  E  SITOGRAFIA  DI  RIFERIMENTO  
Banzato M., Apprendere in rete. Modelli e strumenti per l’e-learning, Utet, 2006
Eletti V. (a cura di), Che cos’è l’e-learning, Carocci, 2002
Ganino G., Immagini per la didattica. Metodologie e Tecnologie dell’audiovisivo
digitale, Anicia, 2009
Liscia R. (a cura di), E-learning. Stato dell’arte e prospettive di sviluppo, Apogeo, 2004
Alsultanny, Y. (2006), “e-Learning system overview based on semantic web”, The
Electronic Journal of e-Learning, vol.4, no.2, pp.111-118.
Ambjörn, N., Mikael, N., Matthias, P. & Fredrik, P. (2005), “Contributions to a public
e-learning platform: infrastructure; architecture; frameworks; tools”, International Journal of
Learning Technology, vol. 1, no.3, pp.352-381.
Dolog, P., Henze, N., Nejdl, W. & Sintek, M. (2004), “Personalisation in distributed
eLearning environments”, Proceedings of WWW2004 - The Thirteenth International World Wide Web
Conference, New York, USA.
Ehlers, U. (2004), “Quality in e-learning from a learner's perspective”, European Journal
of Open Distance and E-Learning. May. Retrieved on 2 May 2007 from
http://www.eurodl.org/materials/contrib/2004/Online_Master_COPs.html
Gotschall, M. (2000), “E-learning strategies for executive education and corporate
training”, Fortune, vol. 141, no.10, pp.S5-S59.
Hall, B. (2000), “How to embark on your e-Learning adventure: Making sense of the
environment”, e-Learning, January-March.
Kanendran, T.A., Johnny, S. & Durga, B.V. (2004), “Technical report: Issues and
strategies of e-Learning”, Sunway College Journal, vol.1, pp.99-107.
Moreale, E. & Vargas, M. (2004), “Semantic services in e-Learning: an argumentation
case study”, Educational Technology & Society, vol.7, no.4, pp.112-128.
Noy, N. & Klein, M. (2004), “Ontology Evolution: Not the same as schema evolution”,
Knowledge and Information Systems, vol.6, no.4, pp.428-440.

50
Shreiber, D.A. & Berge, Z.L. (1998), “Distance training: How innovative organisations
are using technology to maximise learning and business objectives”, Jossey-Bass, San Francisco,
CA.
Stojanovic, L. (2004), “Methods and tools for ontology evolution”, PhD thesis,
Universitat Karlsruhe.
Tony, G., Anne, J.G., & Mary, S.W. (2005), “Introduction to metadata: Pathways to
digital information”, Online Edition, Version 2.1, Retrieved 9 September 2007 from
http://www.getty.edu/research/institute/standards/intrometadata/
Unwin, D. (2003), “Information support for e-Learning: principles and practice”, UK
eUniversities Worldwide Summer.
Urdan, T.A. & Weggen, C.C. (2000), “Corporate e-Learning: Exploring a new frontier”,
WR Hambrecht + Co. Retrieved 3 August 2001 from
http://www.wrhambrecht.com/research/coverage/elearning/ir/ir_explore.html
Zahm, S. (2000), “No question about it - e-Learning is here to stay: A quick history of
the e-Learning evolution”, e-Learning, vol.1, no.1, pp.44-47.
http://www.liferay.com/it/documentation/liferay-portal/6.2/user-guide/-
/ai/creating-new-workflow-definitions-liferay-portal-6-2-user-guide-11-en

" Definizione di linee guida per l'utilizzo e la gestione del sistema distribuito
collaborativo del Progetto S.F.I.N.G.E."

51

Potrebbero piacerti anche