L’ultimo articolo della serie su WebCenter Sites prende in esame una serie di altri prodotti che potrebbero essere definiti genericamente CMS/portal descrivendone brevemente le caratteristiche e l’ambito d’uso preferibile. Come vedremo, anche se auno sguardo veloce tutto sembra uguale, in realtà le differenze ci sono, e sono significative.

Concludiamo questa serie di articoli comparando WCS con una serie di altri prodotti tutti ben noti presenti sul mercato. I sistemi comparati in questo articolo sono per lo più sistemi open source, sono facilmente disponibili e sono anche abbastanza diffusi, con qualche punta di grande notorietà.

La comparazione sarà in ogni caso solamente di tipo tecnico e illustrativo. Se dovessimo fare una comparazione punto per punto, e da un punto di vista commerciale, dovremmo paragonare WebCenter Sites a tutti altri sistemi di pari grado e di tipologia identica. Per citare alcuni nomi, probabilmente sconosciuti ai più, parliamo di Intervowen, OpenText o Vignette. Questo perche’ non entra in gioco solamente l’aspetto tecnico, ma anche la disponibilità di un numero di installazioni di classe enterprise per grandi clienti. In tal senso, non si può dire “cosa è meglio” in assoluto, perche‘ in certi casi può bastare il prodotto semplice e con pochi fronzoli, mentre per certe aziende di classe enterprise diventa necessario un prodotto altamente configurabile e strutturato come il nostro WebCenter Sites.

WCS e OpenCMS

Il sistema probabilmente più simile a WCS è OpenCMS. È realizzato anche esso in Java, offre capacità di content modeling ed editing simili; permette di personalizzare il modello dei contenuti e definire form per l’editing; permette inoltre di personalizzare il rendering del sito definendo dei template.

Rispetto a WCS, le capacità di content modeling sono più limitate e più difficili da usare: sono basate sulla definizione di schemi in XML che permettono di specificare il formato dei contenuti. Anche la definizione di form per l’editing è strettamente legata a questi schemi XML. Va notato, quindi, che queste funzionalità richiedono la scrittura di codice in OpenCMS.

Da parte sua, WCS ha capacità di content modeling molto più flessibili e accessibili a livello di interfaccia di editing dei contenuti, come abbiamo visto negli articoli precedenti di questa serie. Questo significa, in termini di workflow di produzione editoriale, che la redazione può tranquillamente essere coinvolta nella definizione del modello dei contenuti, anche se poi deve essere scritto comunque del codice per il rendering (ma si tratta comunque di un lavoro specialistico molto limitato, che non taglia fuori necessariamente il lavoro di chi produce ed edita contenuti).

Le capacità di pubblicazione di OpenCMS si limitano a un meccanismo a due livelli: si costruisce il sito in modalità di modifiche, e poi si effettua il commit delle modifiche rendendole visibili. Il tutto avviene su un singolo server. WCS definisce i contenuti in un server di staging e poi le pubblica su un server di delivery separato.

La versione open source di OpenCMS è a singolo server ma possono essere acquistate separamente funzionalità per il clustering (scalabilità verticale). WCS supporta clustering ma anche scalabilità orizzontale tramite l’uso di Satellite Server.

WCS e Drupal

Anche Drupal è abbastanza simile concettualmente a WCS, ma le differenze sono più marcate. Innanzitutto gli approcci sono ortogonali: WCS è una soluzione proprietaria, tutto-in-uno, sviluppata in un linguaggio enterprise come Java ed eseguito su robusti application server come WebLogic o WebSphere. Drupal è una soluzione open source, estremamente modulare, sviluppata in un linguaggio di scripting come PHP e ha una forte vocazione comunitaria.

In generale, quello che in WCS è parte del pacchetto base, in Drupal è un plugin. Per esempio, WCS ha di base complesse funzionalità di personalizzazione del contenuto, mentre Drupal ha nel core delle funzionalità minime. La personalizzazione dei contenuti viene aggiunta installando dei plugin.

WCS ha funzionalità di scalabilità incluse (per esempio il caching o il già citato Satellite Server) mentre Drupal le ottiene installando plugin, configurando memcached o sfruttando prodotti esterni come varnish.

In definitiva mentre WCS si propone come una soluzione completa pronta all’uso, Drupal si presenta più come un kit per costruire la propria soluzione, anche perche‘ sono disponibili moltissimi componenti di diverso tipo che possono essere aggiunti: va da se‘ che alcuni di questi componenti sono ben stabili e testati, mentre moltri altri non danno queste garanzie.

Una clamorosa differenza con WCS per esempio, però, è che Drupal non separa l’ambiente di gestione dall’ambiente di pubblicazione: ogni modifica che viene fatta è immediatamente visibile. In realtà Drupal non separa nemmeno tra inferfaccia editoriale e sito: sono la stessa cosa. Il sito una volta che, si sia effettuato il login, diventa immediatamente editabile e le modifiche fatte sono visibili al mondo immediatamente.

Ovviamente in un ambiente enterprise dove l’immagine è importante e il messaggio web deve venire in qualche modo “validato” da personale preposto al marketing e alla comunicazione, questo può essere un grosso limite. Viceversa un sito collaborativo in cui gli utenti possono aggiungere i propri contenuti liberamente, vede in Drupal un eccellente strumento. WCS, in ogni caso, supporta queste funzioni collaborative tramite Community Server, che è un prodotto separato seppur integrato.

WCS e WordPress

Lo stesso discorso vale praticamente identico per WCS e WordPress, con la differenza che WordPress è una piattaforma meno modulare di Drupal. Nato come piattaforma per blog, WordPress ha via via acquisito estensioni tali da poterlo definire comunque un Content Management System. Ma per quanto la definizione di CMS possa essere applicata, WordPress in tal senso rimane comunque abbastanza legato a un approccio, se vogliamo, “casalingo”.

Lo sviluppo con WordPress più o meno è il seguente: si prende il pacchetto e lo si estende, in varie maniere. Si può codificare “a mano” quello che si vuole, si possono installare plugin e patch, o si può modificare direttamente direttamente il codice. WordPress è sicuramente un ottimo modo per andare online velocemente, ma probabilmente non adatto a siti di grandi dimensioni, strutturati in maniera complessa, e accuratamente controllati.

WCS e Alfresco

Compariamo adesso WCS con Alfresco. L’attitudine nativa di Alfresco è abbastanza diversa da WCS. Nasce infatti come Document Management System. Di fatto è piuttosto buono per gestire grandi basi di dati contenenti documenti di diversa tipologia, ma non è propriamente un sistema di gestione dei contenuti orientato alla pubblicazione sul web.

La sua interfaccia è flessibile per quando riguarda la memorizzazione, la categorizzazione e l’indicizzazione dei documenti. Recentemente ha acquisito anche il componente Share che semplifica anche la collaborazione.

I documenti comunque vengono generalmente memorizzati nel document repository così come sono, e il problema principale è renderli accessibili in molti modi diversi. Specificamente, Alfresco esporta i suoi contenuti organizzati gerarchicamente in HTTP, FTP, SMB, DAV , IMAP e altri protocolli e formati. Si tratta di funzionalità non offerte da WCS, il quale demanda a Documentum o SharePoint queste funzioni.

Per quanto riguarda la gestione dei contenuti web, ossia il principale ambito in cui WCS e Alfresco si possono confrontare, va rimarcato che Alfresco ha delle estensioni che lo rendono anche in grado di generare siti web, ma queste estensioni, comparate a WCS, appaiono rudimentali. Innanzitutto è possibile definire contenuti e form utilizzando schemi XML. Le possibilità di personalizzazione delle form sono abbastanza ristrette, mentre quelle di WCS sono molto più flessibili. Alfresco supporta anche il rendering di contenuti applicando a ogni singolo contenuto un rendering “in place”. Il che significa sostanzialmente che si crea un contenuto con una form, si salva e questo viene trasformato in HTML applicando un template (che può essere XSLT o FreeMarker). Questa soluzione “furba” mostra i suoi limiti quando il contenuto deve essere distribuito in diversi componenti che devono essere assemblati.

Mentre WCS brilla in queste trasformazioni del content model in complessi siti, Alfresco funziona bene con siti semplici, con pochi tipi di contenuti e con poche relazioni tra di loro. C’e’ da dire, comunque, che Alfresco supporta anche la pubblicazione e il preview dei contenuti, sia pure con qualche limitazione tecnica.

WCS e Liferay

Completiamo la carrellata comparando WCS con Liferay. Qui la comparazione si fa difficile. Liferay è fondamentalmente un Portal Server, che è una cosa abbastanza diversa da un CMS. Un Portal Server è fondamentalmente un prodotto che è il grado di creare pagine web con componenti personalizzati dall’utente. Per fare un esempio corrente, si può pensare a iGoogle: l’utente si registra e può comporre le sue pagine aggiungendo widget alla pagina. Liferay nasce esattamente con questo scopo: la sua attitudine è creare pagine web personalizzabili composte di componenti Java chiamati Portlet.

In pratica, complice la confusione del termine “portale”, Liferay è stato continuamente esteso fino a diventare capace di offrire funzionalità simili a quelle di un CMS. Infatti mentre un portale sarebbe solamente un punto di accesso, nella pratica un portale è diventato sinonimo di sito web ricco di funzionalità, e molti utenti confondono un portal server con un CMS.

Quindi se in linea di massima sia WCS che LifeRay sono in grado di creare siti web, la somiglianza si ferma qui. In WCS si compongono content model complessi, progettati per una redazione, e si implementa un rendering per gli stessi. In Liferay si può configurare una gerarchia di pagine, e inserire in queste pagine dei contenuti usando specifiche (e di solito limitate) portlet per la gestione dei contenuti.

Per far capire le differenze basta citare il fatto che WCS ha una versione (chiamata Spark) che può essere eseguita in un portal server (ma non in Liferay, almeno al momento), in cui le sue funzionalità di gestione di contenuti possono essere utilizzate come portlet ospitate in un Portal Server.

Di fatto, se si usa Liferay, si può comporre un sito con una gerarchia di pagine e con una navigazione, e riempirle di componenti come wiki, blog, gallerie di immagini, forum e così via (tutti component disponibili come portlet), ma ci si deve attenere alle limitazioni nella struttura di Liferay. Con WCS, invece, si definisce un modello di contenuti ricco adatto a una redazione, e si può creare un effettivo sistema editoriale enterprise per la gestione dei contenuti.

Conclusioni

Questa rapida panoramica che conclude la serie su WCS non ha lo scopo di “fare la classifica” del migliore o, peggio, di mettere in cattiva luce un qualche prodotto. Quel che ci interessava era presentare i punti di somiglianza, ma anche le notevoli differenze di filosofia di base, che esistono tra prodotti diversi tra loro, ma spesso ed erroneamente considerati sostanzialmente uguali. In questo modo speriamo di aver illustrato brevemente certi punti salienti che possono servire al lettore per fare delle scelte informate, in base alle sue esigenze e al tipo di attività che viene svolta: in genere non serve un cannone per scacciare una mosca… WCS, da parte sua, resta un prodotto di punta di classe enterprise che dà il meglio di se‘ quando applicato a realtà in cui il processo di ideazione, strutturazione, produzione, revisione e aggiornamento dei contenuti da pubblicare sul web ricopra un ruolo importante e debba essere gestito in maniera flessibile e potente.