In questo articolo analizziamo l’architettura interna di WCS. I diversi componenti (ContentServer, Xcelerate, Gator, Engage, WEM) rappresentano l’infrastruttura e gli elementi necessari per creare e gestire contenuti (asset) via via più complessi, e forniscono sofisticate funzioni di e-commerce e marketing che possono rappresentare strumenti molto efficaci, da usare in progetti anche molto complessi.

I componenti dell’architettura di WCS

Proseguiamo la nostra analisi di WebCenter Sites esaminando la sua architettura interna. Vedremo che in realtà WebCenter Sites è il core di una sistema aperto, con componenti ulteriori e una architettura più complessa che analizzeremo più in là. L’architettura è sintetizzata nella figura 1.

Figura 1 – L’architettura interna di WebCenter Sites.

Per chi non ha visto negli anni l’evoluzione del prodotto, non appare immediatamente chiaro che esso è effettivamente composto da alcuni strati differenti, e che ogni strato costruisce ed estende i precedenti. Questo fatto era maggiormente evidenziato un po’ di tempo fa, quando i vari componenti venivano installati separatamente, ma adesso fanno tutti parte del prodotto base, quindi serve qualche spiegazione. Inoltre esaminare i vari componenti è un ottimo modo di vedere quali funzionalità offre WCS.

Poiche’ i vari componenti non sono più prodotti separati, userò il loro nome interno per distinguerli. Questo perche’ gli sviluppatori sono ancora in grado di riconoscerli dai nomi interni che vedono nel prodotto quando si accede ai suoi internals per lo sviluppo.

ContentServer

Il primo strato è il vero ContentServer. Fino a poco tempo fa l’intero prodotto era chiamato Fatwire Content Server (mentre ora è WebCenter Sites), ma in realtà internamente ContentServer è solo uno strato, il primo. ContentServer è essenzialmente l’interprete di un linguaggio di programmazione basato su XML, simile almeno concettualmente a ColdFusion. Se ve lo ricordate, ColdFusion era un linguaggio di programmazione web con una sintassi che estendeva l’HTML, ed era piuttosto diffuso all’epoca dello sviluppo iniziale di ContentServer.

ContentServer è stato in seguito espanso aggiungendo al suo linguaggio interno, basato su XML (che è ancora utilizzabile e di fatto necessario per scrivere alcuni tipi di estensioni), un altro linguaggio di programmazione più standard basato su Java Server Pages. Sia l’interprete XML sia JSP condividono le librerie sottostanti (scritte in Java) cosicche’ tutto ciò che si può fare in XML si può fare anche in JSP.

ContentServer comunque è essenzialmente un ambiente di esecuzione, che fornisce alcune funzioni come sicurezza e caching, ma non ha il concetto di asset (contenuto). Inoltre ha una interfaccia utente molto limitata (quella esistente serve principalmente a creare utenti e configurare i permessi). Si può dunque considerare come un ambiente di esecuzione più potente delle semplici JSP, ma di per se’ non rappresenta un’applicazione di gestione contenuti.

Va comunque studiato abbastanza in dettaglio quando si sviluppa, perche’ è utilizzato dagli altri componenti del sistema, e la personalizzazione dei template di fatto è implementata direttamente usando il linguaggio di ContentServer.

Xcelerate

Siccome WCS è considerato, tra le altre cose, un CMS, normalmente l’utente utilizza una interfaccia utente per cambiare dei contenuti. Infatti, costruito sopra ContentServer, c’è la prima applicazione dello stack, che è Xcelerate. Xcelerate è provvista di una interfaccia utente Web. Il backoffice (o meglio, quella parte di backoffice normalmente conosciuta come Advanced Interface) è il componente Xcelerate.

Concettualmente questo componente è diverso da ContentServer, in quanto si tratta di una applicazione sviluppata con ContentServer. Cioè ContentServer è un “linguaggio di programmazione” e Xcelerate è “un programma” scritto con ContentServer. La sua funzione primaria è fornire una ricca interfaccia utente che serva per creare ed editare i contenuti.

Xcelerate implementa il più importante concetto di WCS: l’asset. Tutto in WCS è un asset, e per comporre un sito si usa una combinazione di asset di diverso tipo. Esistono vari asset predefiniti, come la Page e il Template, ma lo sviluppatore può definire nuovi tipi di asset.

In realtà Xcelerate implementa solo il concetto di Basic Asset, e consente di creare nuovi Basic Asset usando l’Asset Maker. Nel progetto originale, si tratta di una piattaforma orientata a costruire siti web anche complessi ma offre un modello di contenuti che si prevede piuttosto stabile (e quindi non è cambiato spesso).

Gator

Un’estensione di Xcelerate è invece Gator, che si integra perfettamente nel framework offerto da Xcelerate, e in più fornisce il concetto di Flex Asset. I Flex Asset erano originalmente progettati per implementare facilmente siti di e-commerce, anche se oggi si sfrutta la loro flessibilità in qualunque tipo di sito.

Un tipico problema dei siti di e-commerce infatti è che il modello di contenuti può essere molto complesso, cambiato frequentemente (al limite quotidianamente), per cui i Basic Asset non sono sufficientemente flessibili per questo uso.

I FlexAsset soddisfano questo requisito offrendo la capacità di cambiare facilmente il modello dei contenuti, senza perdere i dati esistenti. Inoltre l’aggiornamento del sito, inclusi cambiamenti di struttura, è facile come pubblicare il contenuto.

La pubblicazione infatti viene normalmente usata in Xcelerate solo per aggiornare i contenuti; ma se si vuole aggiornarnare il modello dei contenuti bisogna operare delle modifiche a un Basic Asset e occorrono degli aggiornamenti manuali alla struttura del database.

Usando invece Gator, anche il modello di contenuti è parte del sito, e può essere pubblicato consentendo un aggiornamento rapido e indolore dello stesso (non è necessario mettere in calendario degli spegnimenti del sito, per esempio, per mettere mano al database).

Notare che Gator fornisce anche altre funzioni come un carrello della spesa e una interfaccia a sistemi di e-commerce di backend per processare gli ordini.

Engage

Mentre Gator fornisce funzionalità che consentono di costruire siti di e-commerce, Engage (un componente la cui installazione è opzionale) consente di implementare facilmente funzioni utili per chi si occupa di marketing. A grandi linee, fornisce funzioni di profilazione e segmentazione dei visitatori. In base ai segmenti il sistema è in grado di generare raccomandazioni e promozioni.

Andando in maggior dettaglio, sono disponibili Vistor Attributes e History Attributes. I primi memorizzano informazioni specifiche del singolo utente, come nome, età, fascia di reddito e via dicendo. I secondi invece permettono di creare uno storico di cosa ha fatto l’utente, come gli oggetti acquistati o le aree che ha visitato. Usando le informazioni di profilo raccolte, è possibile poi costruire dei segmenti. Un segmento è mostrato nella figura 2.

Figura 2 – Un esempio di segmento in Engage.

Si tratta a tutti gli effetti di regole, combinazioni in and/or, di condizioni costruite intorno al profilo dell’utente. La cosa interessante è che queste regole possono essere costruite direttamente della redazione e non richiedono il coinvolgimento dello sviluppatore (mentre la definizione e la raccolta di informazioni sul visitatore invece richiedono l’intervento dello sviluppatore).

Utilizzando i segmenti si possono poi costruire Recommendations, un tipo di asset “intelligente” che ricava i contenuti da presentare dai segmenti. L’assegnamento di un visitatore a un segmento è svolto automaticamente dal sistema. Quindi, per fare un esempio abbastanza banale, in una zona del sito come la home page, è possibile offrire prodotti di interesse a un pubblico femminile se il visitatore è una donna, viceversa offrire prodotti tipicamente maschili se il visitatore è un uomo.

Segmentazione e profilazione sono “armi” di enorme potere se messe in mano a marketer esperti ed Engage fornisce loro gli strumenti necessari per fare il loro mestiere facilmente.

WEM

Concludo l’analisi dell’architettura interna di WCS parlando dell’API WEM che è stata introdotta recentemente. In realtà WEM fa parte di una strategia sia tecnica che commerciale mirata a estendere le funzionalità web “1.0” di WCS verso il web sociale, o Web 2.0. Tecnicamente parlando si tratta di permettere al CMS di gestire contenuti provenienti dall’utente o da altri siti.

Dal punto di vista tecnico, WEM è una API Restful che permette di leggere asset in formato XML o JSON, ed eventualmente anche di creare nuovi contenuti. WEM apre il core del CMS ad altre applicazioni.

Questa funzionalità è già sfruttata da alcuni componenti addizionali, che sono sempre parte di WCS, ma sono tecnicamente applicazioni separate, ovvero Community Server e Gadget Server. È possibile utilizzare anche l’API WEM direttamente: alcuni siti, infatti, tipicamente quelli con front-end non realizzati in Java, utilizzano WCS come content repository ma accedono ai contenuti via WEM per presentarli.

Infine, la API WEM viene utilizzata anche per inserire i contributi dell’utente dentro il sistema, e per questo motivo il controllo di sicurezza WEM è piuttosto articolato. WEM prevede un modello di sicurezza esteso, con un sistema di Single Sign On per applicazioni multiple basato sul prodotto open source CAS, e una interfaccia utente amministrativa con il concetto di gruppo distribuito, usato per distribuire permessi a livello di risorsa REST tra le varie applicazioni.

Conclusioni

In questa rapida panoramica abbiamo dato uno sguardo all’architettura interna di WCS e ai suoi componenti fondamentali. Conoscere tali componenti, il loro ruolo e il modo in cui sono collegati tra loro ci consente di apprezzare la complessità e la flessibilità di WebCenter Sites e ci mette nelle migliori condizioni per poterlo utilizzare al meglio per la realizzazione di siti anche in progetti complessi.