Una nuova serie di articoli dedicati alla nota API JSR 168, tramite la quale è possibile realizzare portal web applications in Java. Dai concetti basilari alla integrazione con le specifiche dei web services tramite WSRP.

Introduzione

In questa miniserie di articoli parleremo della portlet API, strumento tramite il quale è possibile realizzare portali in Java. Parallelamente a una dettagliata rassegna delle tecniche di composizione e configurazione delle portlet per costruire un portale Java-based, si cercherà  di mostrare come questi strumenti si inseriscono in uno scenario più ampio di Enterprise Portal Integration, ovvero quegli ambiti in cui la realizzazione di un portale Java rappresenta lo strato più esterno (il presentation layer) di una architettura enterprise di ultimo tipo.
A fronte di una popolazione Internet di portali basati principalmente su PHP (che innegabilmente a parità  di risultato finale, richiede tempi e complessità  di realizzazione minori), cercheremo di capire quali possano essere i vantaggi derivanti dall‘uso di portali basati su Java.
Non avremo certo la pretesa di dare una risposta univoca e definitiva ai molti punti che metteremo sul piatto: per giungere a una valutazione obiettiva è necessario prendere in considerazione aspetti molteplici spesso legati anche alla realtà  nella quale il portale viene inserito.
Gli articoli partiranno con una serie di informazioni sui concetti basilari delle portlet, per passare ad analizzare nel dettaglio la programmazione delle portlet negli articoli successivi. Parleremo anche delle differenze fra le varie versioni della Portlet API, così come vedremo cosa è necessario fare per creare e impacchettare una portlet application all‘interno di un container.
Infine, per quanto possibile, vedremo all‘atto pratico come funzionano i più famosi portal server open source disponibili sul mercato, mostrandone caratteristiche di funzionamento.
Portal server, portal container, portlet
Si inizia da alcune semplici definizioni in modo da chiarire fin da subito il ruolo dei vari soggetti coinvolti.
Partiamo dal concetto di portlet: una portlet è una classe Java che rappresenta il mattone elementare di un portale. Le portlet sono elementi molto simili alle servlet con le quali condividono il modello di funzionamento di base: a fronte di una request arrivata da parte del client (il browser HTTP) le portlet eseguono alcune operazioni di base volte a modificare il loro stato, interagire con gli strati applicativi sottostanti e fornire una risposta coerente con la configurazione complessiva del portale.
Le portlet sviluppate dal programmatore quindi derivano da classi base che forniscono il comportamento di massima, e seguono un ciclo di vita analogo a quello delle servlet (vedremo nel dettaglio più avanti come scrivere il codice Java che porta a una portlet).
La differenza principale che sussiste fra una servlet e una portlet è legata al contesto di esecuzione: le servlet lavorano secondo un modello uno a uno con il client (una request viene gestita da una sola servlet), e quindi rappresentano l‘unico punto di ingresso allo strato server da parte del client. Per le portlet, a fronte di una richiesta, si possono eseguire contemporaneamente più portlet ed avere una sola pagina di risposta.
Le servlet possono essere sviluppate senza tener particolarmente conto di cosa accade nel resto della pagina che viene inviata in risposta alla request: tale pagina può essere prodotta da una sola servlet, oppure più servlet possono essere responsabili della preparazione di varie parti della pagina finale, ma in definitiva è come se ognuna lavorasse per conto proprio.
Questo modello, pur essendo relativamente semplice e rudimentale, ha un innegabile svantaggio: se si devono comporre contenuti diversi, si richiede una molteplice esecuzione di thread indipendenti anche se l‘output finale è sempre unico (la pagina appunto).
Ad esempio nella home page di un ipotetico portale web, la servlet che calcola un calendario, quella delle rolling-news, e la cms-servlet dovranno essere eseguite in parallelo per comporre la pagina complessiva.
Questo porta a un maggior carico di lavoro per il server, con un degrado delle prestazioni: probabilmente, se cambia una news, il calendario degli eventi o il contenuto di un box di testo non devono essere aggiornati (quindi non si rende necessario un nuovo accesso al DB per caricare i dati del calendar o del box di testo). In teoria la pagina potrebbe essere aggiornata solamente con la esecuzione della servlet delle news, mentre il resto della pagina potrebbe essere riprodotta con dati mantenuti in cache o con HTML “pre-prodotto”.
L‘obiettivo delle portlet quindi è proprio quello di risolvere questo aspetto: dare la possibilità  di creare un ecosistema di componenti web i quali possano cooperare nella realizzazione di contenuti web in maniera ottimizzata.
Le varie portlet devono essere inserite all‘interno di portlet applications, che sono applicazioni standard Java EE basate sulla specifica JSR 168 (vedi oltre) e che utilizzano un file di configurazione portlet.xml per specificare il contenuto della applicazione e il particolare funzionamento delle singole portlet.
Le varie portlet application sono poi deployate all‘interno di un contesto di esecuzione che è rappresentato dal portal container: questo oggetto, sulla base delle configurazioni delle applicazioni, esegue le operazioni di orchestrazione e di coordinamento della applicazione.
Il portal (o portal server) invece esegue il lavoro finale di aggregazione delle portlet applications e delle singole portlet.
In particolare il portal server esegue il dispatch delle request a tutte le portlet contenute in una singola pagina e quindi svolge il lavoro di orchestrazione e coordinamento delle request e delle response.

Per quello che avremo modo di vedere, lo sviluppo di una portlet è molto simile a quello di una servlet, mentre sarà  necessaria una maggiore specializzazione e conoscenza durante la fase di configurazione del portale.

Enterprise Integration Portal

Prima di passare alla programmazione tramite portlet, è forse utile fare una breve panoramica sul concetto di Enterprise Portal Integration. Partiamo da una definizione che spesso viene utilizzata come citazione nei vari corsi sulle portlet:

“Enterprise Information Portals are applications that enable companies to unlock internally and externally stored information, and provide users a single gateway to personalized information [â?¦] they are an amalgamation of software applications that consolidate, manage, analyze and distribute information across and outside of an enterprise (including Business Intelligence, Content Management, Data Warehouse & Mart and Data Management applications.)”
Tratto da “Enterprise Information Portals”, Shilakes andTylman 1998.

Prendendo in esame il passo fondamentale di questa citazione “they are an amalgamation of software applications”, si ha immediatamente una risposta del perché sia importante poter disporre di una API Java per la realizzazione di portali, a fronte della diffusione di tecnologie di scripting più semplici come il PHP.
La Portlet API assume rilevanza quando è necessario creare un portale che non sia un semplice aggregatore di contenuti ma invece consenta di centralizzare l‘accesso alle varie risorse (enterprise) che ci sono in azienda. L‘utilizzo di una tecnologia enterprise (come è la piattaforma Java EE) sullo strato di front end è di primaria importanza per rispondere a tutte le esigenze tipiche di una grande azienda: ad esempio è omnipresente l‘esigenza di poter disporre di un meccanismo di Single Sign On (SSO) che a partire dal portale permetta di propagare le informazioni di autenticazione da e verso sistemi Java EE, applicazioni legacy, sistemi Host.
Altro esempio significativo è dato dalla specifica Web Services for Remote Portlets (WSRP), tramite la quale è possibile integrare portlet (quindi lo strato di presentazione) con i web services per poter ricavare contenuti da sistemi remoti.
Per concludere il concetto di EIP (che avremo modo di riprendere nei prossimi articoli dove si parlerà  degli aspetti implementativi) è utile fare una breve sintesi di quelle che sono le caratteristiche che deve avere un sistema EIP:

• Centralizzazione: un portale fornisce un unico punto di accesso verso le informazioni, le applicazioni e i dati aziendali.
• Collaborazione: il portale consente di condividere e interrogare le informazioni aziendali a prescindere dal luogo geografico.
• Personalizzazione: deve poter consentire la caratterizzazione delle funzionalità  in relazione al conteso operativo di ogni utente.
• Verticalizzazione: ogni EIP è fortemente personalizzato per rispondere a specifiche esigenze aziendali.

Da un punto di vista delle funzionalità  invece un portale deve permettere:

• Gestione dei contenuti: categorizzazione, indicizzazione e ricerca delle informazioni; gestione del ciclo di vita dei documenti (creazione, publishing); workflow per autorizzazione e approvazione dei documenti tecnologie Push/Pull per il delivery delle informazioni.
• Aggregazione: aggregazione di funzionalità  di sistemi eterogenei in componenti di Business (portlet); aggregazione dei dati forniti dai sistemi di Data Warehouse e Data Mart (Business Intelligence).
• Sicurezza: Single Sign On; sicurezza delle informazioni in relazione al ruolo/gruppo dell‘utente.

Specifiche coinvolte

Passando ad analizzare aspetti certamente più pratici, le portlet sono state presentate ufficialmente nel 2003 quando Sun ha rilasciato la versione finale della “JSR 168 – The Portlet Specification” (anche se il percorso è stato non immediato e per certi versi complesso).
Il gruppo di lavoro ha visto coinvolti i principali attori del panorama IT mondiale, come Apache, BEA, Broadvision, IBM, Oracle, SAP, SUN, Sybase, TIBCO e altri ancora.
Le specifiche JSR 168, pur lasciando ancora alcuni aspetti irrisolti, definiscono la maggior parte dei punti cardine dei componenti portlet; ricordiamo i più significativi:

• il ruolo e le funzionalità  del Portlet Container
• il contratto tra il Container e le Portlet
• la gestione del ciclo di vita delle Portlet
• la gestione delle informazioni transienti e persistenti delle Portlet
• le relazioni tra Portlet, Servlet e JSP
• la gestione della sicurezza
• il packaging per la distribuzione delle Portlet
• l‘interazione con Web Services for Remote Portlets (WSRP) di OASIS

Al momento il gruppo di lavoro sta mettendo a punto la nuova versione della API, la 2.0 che annovera fra le principali novità :

• Gestione degli eventi: le portlet potranno ricevere e inviare eventi durante un cambiamento di stato o come risposta di un evento ricevuto. Questo passaggio è particolarmente importante e va a colmare una lacuna molto sentita dalla comunità  dei programmatori. Quando vedremo gli aspetti legati alla inter-portlet-communication, il lettore comprenderà  immediatamente l‘importanza di una gestione basata sugli eventi.
• Condivisione degli attributi di sessione con applicativi al di fuori della Web application corrente. Anche qui vale la considerazione fatta al punto precedente. Poter propagare informazioni fra più portlet è un fattore essenziale per la EIP.
• Portlet filter: meccanismo simile a quello delle servlet per la trasformazione delle informazioni durante le fasi di req/res.
• Allineamento a J2EE 1.4 e WSRP 2.0

Anche se non di stretta pertinenza con le portlet, da un paio di anni Sun ha presentato una API che potremmo definire un parente più o meno stretto della JSR 168: la “JSR 170 – Content Repository API” infatti è pensata per colmare una importante lacuna della piattaforma JavaEE in ambito Content Management Systems (CMS).
La API non ha di fatto nessuna interdipendenza con la portlet API, ma spesso viene vista come uno strumento da usare in parallelo durante lo sviluppo o la personalizzazione di portali. Personalmente credo che in questo periodo si faccia una gran confusione fra il concetto di CMS e quello di portale. Quanto spesso si trova nella documentazione dei vari produttori non fa altro che alimentare tale fumosa separazione: sembra quasi che, tramite una qualche CMS-Portlet, un portale possa diventare in tutto e per tutto un CMS (senza chiedersi cosa faccia e cosa sia la CMS-Portlet).
In questo articolo e nei successivi non ci soffermeremo su questo tema, anche se è bene notare che la specifica vive ancora un periodo piuttosto transitorio, sebbene sia stata rilasciata nel Giugno 2005: i vari CMS che implementano tale API (o dicono di implementarla) sono ancora pochissimi e raramente implementano in tutto e per tutto le indicazioni ufficiali.
Le specifiche JSR 170 definiscono una modalità  univoca per accedere ai contenuti dei Repository CMS e sono divise in livelli a seconda del grado di funzionalità  offerto: al livello 1 (Read Only API) si possono leggere le informazioni, interrogare il repository, eseguire l‘export dei dati in XML. Al livello 2 (Writing API) si può eseguire la scrittura delle informazioni dei metadati, l‘import dei dati in XML. Opzionalmente il sistema può fornire il supporto per le transazioni, la gestione delle concorrenza (lock), la ricerca avanzata e il versioning dei dati.
Da Settembre 2005, è attivo un gruppo di lavoro per la definizione delle specifiche JSR 283, l‘evoluzione di JSR 170. Pare che 168 e 170 avranno molte parti in comune e anzi si parla di una fusione.

Web Services for Remote Portlets (WSRP)

Accenniamo solo brevemente (avremo modo di parlarne in seguito) a una tecnologia che rappresenta una specie di plugin del core API, il WSRP: si tratta di uno standard definito dal gruppo OASIS per l‘accesso e la visualizzazione di Portlet remote basato su tecnologia Web Services. È organizzato in versioni: la WSRP v1 definisce le basi per la pubblicazione e il consumo di portlet remote, mentre la WSRP v2 estende il modello aggiungendo la gestione degli eventi e della inter-comunicazione (stato e dati di sessione).

Come si diceva all‘inizio del paragrafo, la WSRP è di fatto complementare a JSR 168 che definisce le specifiche relative alla costruzione di una Portlet (API) e i contratti con il container; la WSRP definisce invece il protocollo per accedere a portlet remote e visualizzare localmente il contenuto. Appare piuttosto evidente l‘importanza di questo genere di soluzioni quando si voglia dar vita alla cosiddetta integrazione basata sul portale (EIP) in un momento storico in cui fare integrazione significa sempre più spesso integrare contenitori (di funzioni e di contenuti) diversi tramite i web services. Avremo modo di rivedere in un prossimo articolo i concetti base di WSRP.

Conclusioni

In questo primo articolo abbiamo fatto una breve e superficiale introduzione alle portlet API e ai componenti di base di questi oggetti. Nei prossimi articoli si inizierà  a parlare di programmazione con esempi di codice e di configurazione. Parleremo prossimamente anche di come mettere in funzione una portlet all‘interno di uno dei più comuni portal server disponibili in ambito open source.

Riferimenti

[JSR168] Java Portlet Specification
http://jcp.org/en/jsr/detail?id=168

[SPEC] Introducing Java Portlet Specifications: JSR 168 and JSR 286
http://developers.sun.com/portalserver/reference/techart/jsr168/