Liferay Portal è sviluppato
utilizzando una strategia SOA aperta, che lo ha reso la scelta di
riferimento per aziende di tutto il mondo e di tutte le dimensioni
nella realizzazione di progetti di Enterprise Integration, e non solo
di Web Content Management.
Alcuni mesi fa ho partecipato ad un
paio di progetti – per entrambi si trattava di commercio
elettronico e la piattaforma era costituita sostanzialmente da tre
elementi: Liferay Portal installato su JBoss Application Server, il
prodotto Hybris per la parte di eCommerce e JBoss ESB per le
comunicazioni tra l'ambiente Liferay e Hybris (gli ultimi due non
rilevanti per quanto concerne queste note).
Scrivo queste note, indirizzate a chi
si accinge ad impiegare costosi e complessi J2EE Application Servers,
che però non sono richiesti per il deploy di Liferay Portal.
Nei due progetti che ho citato, il
deploy di Liferay Portal è stato eseguito impiegando, quale
application server, il prodotto JBoss Enterprise Application Platform
5.1. In particolare, nell'ambiente di produzione, erano presenti otto
istanze del suddetto application server: sei per la piattaforma
utilizzata dal primo store e due per la piattaforma utilizzata
dall'altro store.
Analizzando però il codice
dell'applicazione sviluppata sotto forma di portlets installate su
Liferay, e consultando sia i progettisti che i programmatori del
sistema, risultò che non fossero stati utilizzati componenti EJB.
Al tempo stesso, è da considerare che
Liferay Portal non ha bisogno necessariamente di uno stack
application server/J6EE per poter
funzionare, ed offre comunque tutte le sue funzionalità attraverso
il deploy su un servlet container, come ad esempio Tomcat.
L'indipendenza di Liferay Portal dall'uso di un application server
vale anche per l'accesso al database – per questo punto
particolare, rimando ad un prossimo articolo dal titolo “Liferay -
Metodo di accesso al database”.
Non c'era motivo quindi per utilizzare
JBoss Enterprise Application Platform per il deploy di Liferay
Portal, introducendo di fatto una notevole complessità e pesantezza
dell'ambiente di produzione, senza apparentemente alcun vantaggio.
Sostanzialmente, gli otto application server jBoss AS, per di più
con licenza Enterprise onerosa, nel caso esaminato non forniscono
alcuna funzione necessaria a Liferay Portal per i quali sono stati
impiegati.
E' questo un caso eclattante di quante
risorse, non solo economiche, potevano essere risparmiate in un caso
così tipico di allestimento di una piattaforma di eCommerce basata
su Liferay Portal.
A supporto di quanto sopra, e per chi
fosse interessato ad approfondire l'argomento, cito un interessante
articolo di Mike Gualtieri del 15 luglio 2011 dal titolo “Stop
Wasting Money On WebLogic, WebSphere, And JBoss Application Servers”.
Di seguito l'introduzione:
“Use Apache Tomcat. It is free. I
don’t understand why firms spend millions of dollars on Java
application servers like Oracle Weblogic or IBM WebSphere Application
Server. I get why firms spend money on Red Hat JBoss -- they want to
spend less on application servers. But, why spend anything at all?
Apache Tomcat will satisfy the deployment requirements of most Java
web applications.”
L'intero articolo, del quale consiglio
vivamente la lettura, può essere letto su questo blog:
L'autore è Mike Gualtieri, Principal
Analyst per Forrester Research, Inc.
Ciao, sono capitato per caso sul tuo articolo, ed essendo parte integrante del team con cui hai lavorato mi fa piacere scrivere un paio di considerazioni circa quello che hai scritto.
RispondiElimina1 Jboss e' un progetto open source ed e' possibile utilizzarlo gratuitamente (FREE AS A BEER) senza alcun vincolo di funzionalita'. Questo significa che funzionalita' quali clustering , high availability o fail over sono disponibili anche sulle versioni GA free, basta solo configurarle.
2 Jboss prevede una fase di slimming dell'installazione in modo da avere attivi solo i servizi necessari al deployment dell'applicazione in oggetto (tra l'altro questa e' una buona pratica di security legata all'hardening di un sistema) https://community.jboss.org/wiki/JBoss5xTuningSlimming
Questo significa che non sono presenti serivizi al netto del webcontainer e del servizio di clustering della sessione. Per tanto le istanze usano solo le risorse necessarie ;-) (non so se sai che tra l'altro jboss usa tomcat come web container)
3 Non ha davvero senso comparare licensing tanto diversi (ibm, oracle , jboss) , jboss arriva a costare 10K (nella versione migliore) per server , cosa ben diversa per i prodotti closed come websphere o bea o altro.
4 Nei progetti ecommerce se il sito e' offline e' bloccata la vendita. Considerando questo la scelta di impiegare la versione EAP (supportata da RedHat next business day) e' legata alla volonta' da parte del cliente di avere il supporto ufficiale dal vendor, altrimenti una versione GA portrebbe essere utilizzata senza problemi.
5 Tomcat e' open source e gratuito all'"utente finale", ma ci sono aziende che hanno sponsorizzato e finanziato gli sviluppi e la maintenance. Quasi nessun progetto opensource potrebbe permettersi di sopravvivere senza nessuno che ne finanzia il lavoro. Se tutti prendessero e basta dall'opensource non ci sarebbe opensource
6 Se state seguendo un progetto cosi' attento ai budget, non e' un problema , utilizzate tranquillamente le versioni GA di jboss e liferay senza dover pagare un euro ed avrete clustering e session failover (feature di livello enterprise ) senza aggravio di costi. Naturalmente il supporto sara' comunity based. Naturalmente spendere 40K per nodo di liferay e non avere il suporto per il webcontainer mi sembra una scelta al quanto rischiosa. Tanto vale usare solo licenze GA, ma e' solo una questione di budget.
7 Liferay non fa supporto(inteso come bugfix) su tomcat, il supporto di tomcat e' acquistabile da aziende terze come SpringSource ad esempio.
Grazie
Alessandro Palumbo
Ciao Alessandro, grazie per avere commentato il mio articolo …
EliminaPer me e' stato un'onore perché, anche se per poco tempo, ho avuto modo di apprezzare in te un vero professionista dotato di una profonda conoscenza del settore di cui, anche grazie a questo articolo, ci troviamo a parlare.
Più di quanto sopra però, vorrei sottolineare una tua qualità che poche volte nella mia vita professionale mi è capitato di incontrare: la tua estrema disponibilità a divulgare (e spesso ad insegnare) quanto sai nei confronti delle persone con le quali lavori, e questo ti fa molto onore al di là delle tue capacità professionali.
Ora, a proposito del mio articolo iniziale e dei tuoi recenti commenti …
In sintesi, dal punto di vista funzionale di Liferay, nel tuo commento non ho trovato un motivo prettamente tecnico che mi abbia convinto che sia meglio utilizzare un Application Server (ad esempio jBoss AS) piuttosto che un Servlet Container (ad esempio Apache Tomcat).
E' certo che, come appunto scrivi, “nei progetti ecommerce se il sito e' offline e' bloccata la vendita”. Pensando alla complessità delle componenti, sarai daccordo con me nell'affermare che Liferay Portal, e tutte le personalizzazioni dell'applicazione in esame, e' certamente più soggetto a malfunzionamenti rispetto all'Application Server / Servlet Container su cui si appoggia.
Se quindi fossimo in presenza di scelte sul budget, meglio sarebbe indirizzare risorse economiche verso il vendor dello strato applicativo (Liferay Portal e applicazioni personalizzate) piuttosto che verso l'Application Server / Servlet Container che, una volta ben configurato, ha decisamente meno probabilità di non funzionare.
Se però, infine, volessimo comunque l'assistenza del vendor dell'Application Server / Servlet Container, non dovremmo dimenticare dell'esistenza del prodotto “Liferay Portal Tcat Edition”, che è una combinazione di Liferay Portal e Tcat Server, quest'ultimo fornito da MuleSoft.
Tcat Server fornisce una soluzione “enterprise” per sviluppare, eseguire il deploy, gestire, integrare ed eseguire il debug di web applications in Apache Tomcat. Comprende una o più istanze di Apache Tomcat e una consolle amministrativa.
Potremmo quindi comunque utilizzare un “semplice” Servlet Container, con tutte i vantaggi relatvi alla semplicità di deploy e di gestione, minore necessità di risorse hardware e altri ben conosciute semplificazioni, rispetto a ciò che richiede un Application Server, avendo comunque l'assistenza del vendor se richiesta. In questo caso però, di gran lunga meno costosa rispetto ad un Application server.
In conclusione … ricordi quando Netscape vendeva il proprio Web server a $50.000 per istanza ? Oggi nessuno comprerebbe più un Web server. La mia convinzione oggi, è che la necessità di Application servers sia ormai alla fine dei suoi tempi.