In questa serie di articoli ci occuperemo di WebCenter Sites ossia il prodotto che evolve a partire da Fatwire dopo l’acquisizione di quest’ultimo da parte di Oracle. Semplicemente, si potrebbe dire che si tratta di un sistema di gestione dei contenuti piuttosto evoluto. Ma definirlo solo un CMS enterprise sarebbe riduttivo: Oracle WebCenter Sites è molto di più e si presenta come un vero sistema di Web Experience Management.

Introduzione

Nel luglio di quest’anno è stata annunciata l’acquisizione di Fatwire Software da parte di Oracle. Non è passato molto tempo che è stata annunciata anche la nuova strategia Oracle per quanto riguarda il web: la linea di prodotti WebCenter, che include anche i prodotti acquisiti con l’incorporazione di Fatwire.

Poiche’ Oracle è oggi la “casa madre” di Java, e Java è a sua volta il linguaggio più usato per sviluppare applicazioni web, quello che propone Oracle in ambito web è sicuramente interessante per tutti gli sviluppatori Java e quindi anche per lettori di MokaByte. Poiche’ lavoro con i prodotti Fatwire oramai da molti anni, ho deciso di scrivere questa serie di articoli per illustrare come fare “Web Experience Management” con WebCenter Sites, che è il nuovo nome di marca Oracle dei prodotti Fatwire. Ma prima di andare in dettaglio vediamo la linea WebCenter.

La linea Oracle WebCenter

La linea WebCenter è rappresentata nella figura 1. La linea comprende ora WebCenter Sites, che è l’oggetto dei nostri articoli, WebCenter Portal, WebCenter Content e WebCenter Connect. Dalle comunicazioni ufficiali, WebCenter Portal e WebCenter Content sono i prodotti già esistenti nella linea, e sono posizionati per la intranet. Ad essi si è appena aggiunto WebCenter Sites, che è proprio la linea dei prodotti ex Fatwire, mentre WebCenter Connect sarà nuovo prodotto.

Figura 1 – La suite WebCenter e le sue componenti.

Questo articolo è un’introduzione a WebCenter Sites per architetti e sviluppatori Java. Poiche’ il prodotto non è ancora disponibile per il download sul sito di Oracle, abbiamo scritto la nostra introduzione basandoci sull’ultima release di Fatwire Content Server (la 7.6). Ovviamente ci aspettiamo che il prodotto rilasciato sarà sostanzialmente un rebranding, e riteniamo che manterrà le caratteristiche del prodotto, aggiungendone eventualmente di nuove.

Mi riservo comunque, non appena il prodotto sarà rilasciato da Oracle, di aggiornare i lettori e notificare di qualunque cambiamento possa esserci tra il “vecchio” Fatwire Content Server 7.6 e il nuovo WebCenter Sites, o WCS come lo chiamerò in seguito. Fatta questa premessa, possiamo cominciare.

Che cosa è WebCenter Sites

WCS è nato come Content Management System; per certi versi è analogo a molti altri prodotti sul mercato, una larga parte dei quali sono anche open source. WCS, però, presenta comunque una serie di caratteristiche che lo rendono un prodotto di punta adatto per lo sviluppo di siti particolarmente complessi, performanti, e gestiti da redazioni piuttosto che da singoli webmaster. WCS ha effettivamente le caratteristiche di un sistema di Web Experience Management in senso proprio. Vedremo infatti che l’intero sistema sembra ideato per rendere il marketing parte integrante della definizione di un sito web aziendale.

Immagino già la domanda del lettore: quali caratteristiche peculiari ha WCS? Che cosa rende un CMS come questo più adatto alle imprese rispetto ad altri? Continuate a leggere: il resto dell’articolo presenta alcune caratteristiche di WCS che lo rendono (a mio avviso, ma non solo mio) adatto a chi ha esigenze complesse.

Ricchezza del Content Model

Personalmente, la caratteristica che apprezzo di più di WCS è il suo ricco Content Model. Utilizzando WCS si riesce a definire molto in dettaglio i contenuti e le sue relazioni, e creare un ambiente molto personalizzato. Molti CMS non hanno un vero e proprio concetto di Content Model. O meglio, hanno solo un content model predefinito. Tipicamente, potete creare degli articoli, organizzarli in una gerachia e visualizzarli. Personalizzare il content model molto spesso richiede di modificare il codice del CMS stesso.

Con WCS invece il content model è completamente configurabile. Non solo potete definire i modelli di contenuto che volete, ma dovete farlo. La modifica del content model comunque non è fatta da codice ma interamente da interfaccia utente, e fa parte del processo di “configurazione” del sito stesso.

Per chi vuole cominciare subito ci sono ovviamente dei siti base in dotazione che definiscono un loro modello di contenuti pronto e modificabile, ma è sicuramente importante analizzare bene i propri obiettivi di marketing, per poter stabilire al meglio il proprio modello di contenuti. Effettuare questa operazione all’inizio renderà la costruzione del sito piuttosto agevole.

Prima di andare avanti diciamo subito che il termine utilizzato per tipo di contentuto in WCS è Asset. Andando sul tecnico, in realtà ci sono due tipi di modelli di contenuto disponibili: i Basic Asset e i Flex Asset. Inoltre sono Asset anche le configurazioni di sistema, e ci sono un certo numero di asset predefiniti. In un certo senso in WCS qualunque cosa è un Asset, e l’intero sistema è configurabile creando o modificando asset.

Figura 2 – Gli Asset disponibili in WebCenter Sites.

Per avere una prima iniziale idea di cosa sia disponibile in WCS si può osservare la figura 2. Possiamo notare l’AssetMaker, usato per creare e configurare gli Asset di tipo basic; il Flex Family Maker che permette di configurare i Flex Asset (o meglio, le famiglie di Flex Asset, lo vedremo dopo). La voce espansa Asset Types, invece, mostra alcuni degli asset già definiti. Alcuni sono asset standard di sistema, come Attribute Editor o CSElement; altri come Content Attribute, Content Definition sono parte di una Flex Family e sono definite dall’utente. Tra i vari asset inoltre è possibile definire delle relazioni, che sono di diverso tipo. In ogni caso, il punto cruciale è l’alta configurabilità del content model.

In un certo senso, WCS è una specie di “database” orientato alla gestione di contenuto. Se devo fornire una sensazione per far capire a cosa assomigli WCS, direi che è simile (attenzione, in senso molto lato), a un sistema di gestione database come Access. Considerando Access, sono definite generiche tabelle di database, usate come base per costruire moduli e report (il tutto con una interfaccia GUI). WCS ha una interfaccia interamente web; consente di definire form usate per editare i contenuti; su questi contenuti, invece di produrre dei report, vengono definiti dei rendering per la visualizzazione del sito, creando dei template.

La ricchezza del Content Model è tutt’altro che inutile. In un sito di discreta complessità non avete semplicemente a che fare con testi organizzati gerarchicamente. Avete invece dei contenuti specifici, come news, blog post, opinion, testi di marketing, comunicati stampa, documentazione tecnica, brochure e molto altro. Quando i contenuti diventano tanti, la loro organizzazione appropriata diventa essenziale. E in questo WCS aiuta molto.

Inoltre WCS consente di raccogliere informazioni su cosa sta facendo l’utente e di “reagire” di conseguenza. È una delle sue caratteristiche fondamentali.

Flessibilità del Content Model

La possibilità di modellare in maniera molto sofisticata i contenuti è sicuramente uno dei più importanti aspetti di un Enterprise Content Management. Ma WCS ha un’altra possibilità: la possibilità di cambiare dinamicamente il Content Model. Per questo motivo esistono due tipi di asset, quelli Basic e quelli Flex. Mentre gli asset Basic vanno definiti in XML, e sono in un certo senso rigidi (un po’ come le tabelle di database) gli asset Flex possono essere cambiati molto facilmente dalla stessa interfaccia amministrativa.

Figura 3 – La configurazione di un asset di tipo Flex.

Per illustrare il concetto, osservare la figura 3 che mostra come configurare un asset Flex (in questo esempio rappresenta un prodotto). Come si vede, il prodotto prevede uno SKU (identificativo unico), una descrizione e un paio di immagini. La form per l’editing del contenuto è mostrata in figura 4.

Ora se a un certo punto si decide che ogni prodotto debba avere anche il logo del produttore , tutto quello che si deve fare è semplicemente aggiungere l’attributo adatto, come mostrato in figura 5.

Figura 5 – L’aggiunta dinamica di un attributo: si è selezionato l’attributo per il logo del produttore.

A questo punto, cambia di conseguenza, e in automatico, anche la form di gestione dei contenuti inerenti un prodotto, come si vede in figura 6.

Figura 6 – Una volta aggiunto dinamicamente un attributo, nella form di gestione dei contenuti appare il campo per quel contenuto: lo spazio per l’immagine del logo del produttore.

I template non vengono influenzati dall’avere un attributo in più, anche se ovviamente il sito non visualizzerà il nuovo attributo. I membri della redazione, però, possono iniziare immediatamente a usare la nuova informazione, aggiungendo il logo del produttore ad ogni prodotto.

Sarà inoltre sufficiente aggiungere poche righe di codice al template per visualizzare anche il nuovo attributo. La modifica del template normalmente non è invasiva, è un semplice ritocco che può essere effettuato in pochi minuti. Certamente la flessibilità dei Flex Asset per un sito in continua evoluzione è una caratteristica preziosa.

Workflow evoluto

In un sistema enterprise di gestione dei contenuti, bisogna prevedere che I contenuti siano inseriti da molti redattori differenti. Non si può inoltre dare per scontato che tutti i redattori abbiano lo stesso livello di responsabilità nel decidere cosa pubblicare nel sito e in quale parte del sito.

Come abbiamo ricordato, altri CMS si limitano a consentire di editare un contenuto e poi pubblicarlo. Ovviamente quando in una redazione ci sono decine di persone che possono aggiungere e modificare contenuti, con il sito che cresce di centinaia di articoli al mese, non si può pensare che ogni redattore sia abilitato a far comparire il suo articolo in home page, ne’ che conosca bene le regole di organizzazione del sito e lo sappia collocare “nel posto giusto”. Senza contare il problema, non banale, che un articolo scritto da un tecnico, magari geniale, potrebbe contenere testo che è incomprensibile al grande pubblico. Per questo motivo un CMS enteprise richiede funzionalità di flusso di lavoro. Un esempio di workflow (probabilmente un classico, e adottato molto di frequente) è quello mostrato in figura 7.

Figura 7 – Un classico esempio di workflow di redazione.

Un autore scrive un articolo, e quando è completo, lo manda al revisore, il quale lo verifica. Se l’articolo è conforme alle regole redazionali, il revisore lo approva e lo manda al webmaster; se non lo è, lo respinge e lo rimanda all’autore per le opportune modifiche. Il webmaster si occupa di ricevere gli articoli e di “impaginarli” (ossia metterli in una posizione appropriata nella gerarchia del sito). Una volta impaginato che l’articolo sia stato impaginato, è possibile metterlo in coda per la pubblicazione. Parleremo della pubblicazione nel prossimo paragrafo. Per il momento ci limitiamo ai workflow, e suggeriamo di dare uno sguardo alla figura 8.

Figura 8 – La possibilità di creare e modificare i vari passi di un workflow.

La figura 8 in questione mostra un workflow equivalente a quello illustrato nella figura 7, configurato in WCS (anche se la terminologia è leggermente differente). È facile intuire quanto sia semplice creare, e modificare, i workflow, visto che non è necessario scrivere codice ma semplicemente applicare delle configurazioni usando l’interfaccia utente.

Una volta creato un workflow, questo può essere associato (automaticamente o manualmente) a un articolo. Vediamo un esempio di workflow. Quando si crea un aricolo, viene iniziato un workflow; il primo passo è scegliere i soggetti coinvolti (anche se è possibile farli scegliere al sistema). In figura 9 viene appunto mostrato questo primo passo.

Figura 9 – La scelta dei soggetti coinvolti nel workflow.

Questo è il primo passo. Conclusa la redazione di un articolo, si seleziona la voce “Completa il mio assegnamento” e l’articolo comincia a viaggiare nel workflow, come si vede in figura 10.

Figura 10 – L’articolo e il suo stato all’interno del workflow stabilito.

L’articolo adesso verrà trasmesso ai vari redattori nel workflow, i quali vedranno comparire l’articolo nella propria lista di cose da fare. Normalmente un articolo viene trasmesso fino a raggiungere l’addetto alla pubblicazione. A questo punto per capire la pubblicazione, dobbiamo ampliare un discorso e introdurre altre funzioni “enterprise” di WCS.

Pubblicazione

Un sistema di gestione dei contenuti che si rispetti deve consentire una qualche separazione tra il server utilizzato per la redazione dei contenuti e il sistema utilizzato per il delivery degli stessi. Le ragioni di tale separazione sono molteplici:

• consentire di verificare i contenuti, evitando che vadano “live” contenuti incorretti, anche solo per colpa di una errata configurazione dei sistemi di sicurezza del sistema;
• garantire la performance nel delivery e la flessibilità per la redazione.

Normalmente un sistema di redazione di contenuti deve avvantaggiare l’aggiornamento rapido. Un redattore deve poter immediatamente vedere il risultato delle sue modifiche per rendersi conto di cosa sta producendo. Per questo motivo normalmente un sistema di redazione di contenuti viene configurato disabilitando le varie cache.

Un sistema di delivery invece deve privilegiare la velocità nell’erogazione dei contenuti. Un sistema live di un grande sito normalmente serve decine, se non centinaia, di richieste al secondo, e quindi è necessario utilizzare una cache.

Abbiamo quindi visto che i sistemi di redazione e di delivery sono piuttosto diversi come configurazione. Un sistema di redazione è normalmente accessibile solo in Intranet, ha configurato un ricco workflow, ci sono numerosi utenti che possono accedervi per creare e modificare i contenuti, ma normalmente gira senza cache, e ha un cluster limitato in quando gli utenti redattori sono pochi rispetto agli utenti lettori.

WCS consente la redazione dei contenuti in un sistema di redazione e poi, utilizzando un meccanismo di pubblicazione, di pubblicare i suddetti contenuti nel sistema di delivery. Sono quindi di solito presenti almeno due diversi sistemi (figura 11).

Figura 11 – Un sistema di gestione dei contenuti enterprise presenta in genere una separazione tra il server di redazione dei contenuti e il sistema usato per la pubblicazione.

Un aspetto molto importante del meccanismo di pubblicazione è che consente di pubblicare ogni aspetto del sito, non solamente i contenuti ma anche il content model e i template. È così possibile aggiornare il sito, creando nuovi contenuti, modificando i template, e mandare il tutto in pubblicazione in un’unica sessione.

Vantaggi del sistema di pubblicazione

Soprattutto, con queste modalità di funzionamento, di solito non è più necessario pianificare dei momenti di “down del sistema” quando si aggiornano i template. Il tutto è compreso nella fase di pubblicazione. Notare anche che la pubblicazione è incrementale, e pubblica solamente gli asset che sono stati modificati, quindi è piuttosto efficiente.

Inoltre, e questo è un altro aspetto interessante, la cache del sistema di Delivery (che abbiamo accennato) e che può essere molto ampia come dimensione, viene invalidata selettivamente in modo da rigenerare solo gli elementi della cache che risultano dipendenti dagli asset modificati. Ovviamente se si modifica il layout principale del sito ci si può aspettare che si debba ricostruire l’intera cache, ma in casi normali solo una piccolissima parte della cache viene invalidata e ricostruita.

Notare infine come la pubblicazione (che è sostanzialmente un meccanismo di replicazione incrementale) non deve essere necessariamente limitata a due livelli: anzi, solitamente è strutturata in più livelli. Consideriamo nella figura 12 un caso in cui è presente un sistema di sviluppo, una redazione, un sistema di QA e infine un sistema di Delivery.

Figura 12 – Il delivery non è necessariamente limitato a due livelli, ma può essere strutturato in maniera più complessa.

Generalmente il sistema di sviluppo è piuttosto instabile. In sviluppo, il sistema è frequentemente oggetto di esprimenti, e può contenere codice non necessariamente completo e ben testato. Dal sistema di sviluppo si pubblica nel sistema di redazione, dove i redattori possono inserire i contenuti (renderizzati utilizzando il codice proveniente dal sistema di sviluppo). In ogni caso, template e contenuti non vengono pubblicati direttamente nel sistema di delivery ma vanno prima in un sistema intermedio Quality Assurance (QA), e in tal modo il sito risultante viene verificato prima di essere inviato al sistema di delivery.

Satellite Server

Consideriamo un’ultima caratteristica importante di WebCenter Sites: i Satellite Server. Normalmente un singolo server è in grado di sostenere traffico fino a un certo numero di utenti al secondo. Se si supera tale limite, occorre introdurre altri server o, come si dice in gergo, “scalare il sito”.

WCS prevede una funzionalità di scalabilità nella forma dei Satellite Server. Si tratta di cache in grado di essere messe di fronte alla istanza principale, e che ne alleggeriscono il carico in quanto ne sostengono loro stesse una gran parte. Il modo con cui i Satellite Server sono utilizzati è illustrato nella figura 13.

Figura 13 – I Satellite Server di WCS.

Normalmente si ha una sede principale dove il sito viene erogato. Allo scopo di alleggerire il carico però si possono installare una serie di Satellite Server, normalmente collocati in varie aree del mondo. Le ragioni di questa distribuzione geografica sono:

• distribuzione del carico normalmente in base alla zona geografica di provenienza;
• riduzione del tempo di latenza nell’erogazione del sito.

Conclusioni

Abbiamo completato una prima introduzione a volo d’uccello su WCS, ma c’è molto altro da dire. Sperando di aver stuzzicato il vostro interesse vi rimandiamo alla prossima puntata in cui esploreremo in maggior dettaglio la definizione del Content Model.