Introduzione
Obiettivo del presente articolo è evidenziare quanto critica sia per le aziende, specie di medio-grandi dimensioni, la decisione relativa all'Application Server (AS d'ora in avanti) da utilizzare per lo sviluppo e messa in esercizio di sistemi basati sull'architettura J2EE. Si tratta di una decisione troppo spesso data per scontata o sottovalutata che invece presenta notevoli ripercussioni sulle politiche aziendali. In Internet è possibile reperire diversi articoli che affrontano il problema della scelta degli AS; quasi tutti però si limitano ad esaminare l'argomento dal punto di vista delle caratteristiche tecniche offerte (gestione delle transazioni, scalabilità, sicurezza, ecc.). Con il presente articolo, intendiamo invece affrontare la problematica spostando l'attenzione su considerazioni a maggiore carattere manageriale. Con questo non si vuole assolutamente contestare l'importanza delle caratteristiche tecniche, però si è anche convinti che attualmente considerazioni di diversa natura siano prioritarie. Tale convinzione è rafforzata da diverse osservazioni. In primo luogo la tecnologia degli AS sta raggiungendo grado di maturità sempre più elevato che finisce per sminuire il dislivello dei servizi base offerti dai vari AS; quindi spesso non è molto saggio basare la scelta su caratteristiche tecniche ben supportate dalla quasi totalità degli AS disponibili. Altra importante osservazione è che, da una scrupolosa analisi, è possibile evidenziare come la selezione dell'AS preveda tutta una serie di ripercussioni sulla politica di medio/lungo termine delle imprese (gestione personale, relazioni con i vendor, manutenzione dei sistemi, ecc) alle quali è opportuno conferire la giusta considerazione.
Nel presente articolo è particolarmente enfatizzato il punto di vista di organizzazioni medio/grandi, in cui l'infrastruttura informatica costituisce una risorsa imprescindibile. Un esempio? Le banche londinesi in cui i progetti hanno un budget tipo di milioni di sterline al mese (!), i progetti si protaggono per qualche anno e il personale impiegato si aggira sulle centinaia di unità.

Selezionare l'AS il prima possibile
I sistemi informatici moderni tendono a diventare sempre più estesi e costosi. Prima di avviarne la progettazione ed il conseguente sviluppo è necessario stabilire alcuni punti fermi di notevole importanza su cui basare l'intero sviluppo. Per esempio è necessario stabilire il processo da utilizzare, la tecnologia e l'architettura da adottare, la piattaforma su cui mettere in produzione il sistema, i prodotti da utilizzare, e così via. Supponendo di aver concluso di utilizzare l'architettura J2EE (a nostro parere è la migliore attualmente disponibile sul mercato), una decisione molto importante è relativa a quale Application Server (AS) utilizzare per sviluppare e mettere in produzione il sistema finale.
(inizio nota) In aziende o sistemi di medio/piccole dimensioni, è possibile ipotizzare di sviluppare sistemi J2EE utilizzando un particolare AS per poi metterlo in esercizio su uno diverso, oppure svilupparlo e verificarlo su diversi AS. Sebbene ciò possa portare diversi benefici, come per esempio una maggiore speranza di completa portabilità, non è infrequente il caso in cui si tratta di una strategia semplicemente non fattibile. Ciò per motivi essenzialmente legati all'aumento dei tempi di sviluppo e test, alla difficoltà di mantenere in esercizio diversi ambienti e configurazioni, etc. Spesso poi non è possibile o conveniente rifiutare a priori i servizi aggiuntivi forniti da particolari AS. I progetti reali insegnano che un giusto grado di pragmatismo è fondamentale. Si tenga in mente che non è infrequente il caso in cui i sistemi siano sviluppati per funzionare nei tempi e costi previsti, e non per essere esempi di "pure J2EE". Ovviamente ciò non significa neanche che non bisogna disegnare pensando alla portabilità o che ciò sia impossibile. (Fine nota)
In teoria i sistemi sviluppati in architettura J2EE dovrebbero essere portabili e pertanto dovrebbero poter funzionare su qualsiasi AS compatibile con la versione delle specifiche J2EE globali (EJB, Sevlet, etc.) prese di riferimento. Ciò potrebbe portare a pensare (erroneamente) che la selezione dell'AS non dovrebbe essere poi così cruciale. Nella pratica ahimè, la situazione è ben diversa. Per svariati motivi, come per esempio l'utilizzo di caratteristiche peculiari di un determinato AS, e non ultimo la non sempre chiara conoscenza delle specifiche ufficiali J2EE da parte di alcuni tecnici (non vi è mai capitato di osservare tecnici intenti a generare thread all'interno dei container?), fanno sì che la tanto agognata portabilità non sia poi così scontata. Questi problemi, più altre considerazioni commerciali/strategiche, determinano la necessità di selezionare l'AS già durante le prime fasi del processo di sviluppo del software. Tale "rapida" selezione è utile non solo per incorporare nel processo stesso adeguamenti richiesti dall'AS (ebbene sì, alcuni strumenti influenzano il processo: basti pensare alle attività di gestione dello stesso AS o a eventuali servizi aggiuntivi offerti dallo specifico AS come per esempio servizi di integrazione), ma anche per stabilire un migliore rapporto con il vendor, nel caso in cui si decida di non ricorrere ad un prodotto open source. Inoltre, attendere troppo per prendere tale decisione rappresenta uno spreco di tempo ed una mancata occasione per gli sviluppatori di aumentare la propria conoscenza del prodotto. Si tratta di investigazioni particolarmente importanti, specie considerando che molti progetti, come quelli particolarmente critici/rischiosi, sono preceduti dalla realizzazione di sistemi pilota (i cosiddetti "proof of concepts"), atti a provare la fattibilità tecnico-architetturale del progetto stesso. Altro argomento non trascurabile è relativo al fatto che le licenze di utilizzo degli AS, tipicamente, includono pacchetti di ore di supporto e/o consulenza. Queste, spesso, si rivelano particolarmente utili proprio nelle fasi iniziali, quando è necessario impostare l'ambiente, approfondire la conoscenza delle problematiche del deployment, eventuale clustering, prendere decisioni cruciali (utilizzare o meno gli entity beans o integrare un O/R tier, ricorrere o meno a session stateful beans, ecc.)..

L'AS è uno strumento strategico per l'azienda
La selezione dell'AS da utilizzare costituisce una decisione strategica per l'azienda. Acquisire skill specifico, formare il personale, non solo per lo sviluppo e messa in esericizio, ma anche per la successiva manutenzione, richiede molto tempo e denaro. È abbastanza logico che, una volta selezionato un determinato AS, questo tenda a divenire una sorta di standard interno dell'organizzazione (almeno per gli ambienti di produzione). Ben poche aziende gradirebbero dover mantenere operativi diversi AS, disporre di molto hardware ridondante non motivato, dover ogni volta formare il proprio personale per utilizzare nuove tecnologie o peggio ancora, dover disporre di personale con mansioni simili, esuberante, specializzato per i diversi AS. Ciò è particolarmente vero per sistemi di grandi dimensioni, dove anche una minima variazione della configurazione richiede l'esecuzioni di una serie lunghissima di test, spesso non tutti automatizzati. (Nota) Da notare che, sebbene test dello strato di service business siano facilmente automatizzabili (tipicamente sono un'estensione dei test di sistema), lo stesso non si può dire per test che riguardano la GUI. Sul mercato sono disponibili diversi tool per supportare tali attività, i quali però ahimè sono fortemente legati alla struttura dell'interfaccia utente (ogni minima variazione ne prevede l'aggiornamento) e richiedono moltissimo tempo per essere sviluppati e verificati a loro volta. (Fine nota)
Altra considerazione è relativa al fatto che tecnici preparati tendono a non reinventare la ruota ad ogni progetto, e quindi, prima e durante la costruzione dei vari sistemi, preferiscono, saggiamente, investire del tempo disegnando ed implementando framework riutilizzabili, strumenti di supporto allo sviluppo e test, che spesso, inevitabilmente, risultano fortemente legati alle caratteristiche dello specifico AS.
Per finire, lo sviluppo di qualsivoglia sistema richiede di investire un considevervole lasso di tempo per mantenere i vari script e per aggirare gli inevitabili bug dei singoli AS, tale da rendere semplicemente non proponibile l'idea di dover moltiplicare questi tempi per diversi AS... E poi si trova sempre la libreria X o il driver Y che non funziona bene con la versione Z1 dell'AS S3.

AS predefinito
Nei casi in cui ci si dovesse trovare in un'azienda in cui esistano già sistemi funzionanti su un determinato AS, oppure questo sia già stato stabilito da policy interne all'azienda stessa o da particolari accordi commerciali, è opportuno attenersi a tali direttive evitando quanto più possibile di introdurne uno diverso. Ciò è vero a meno che l'AS di riferimento evidenzi problemi così gravi da giustificare i rischi ed i costi della relativa sostituzione. È appena il caso di sottolineare che la decisione di sostituire un AS richiede notevoli investimenti e presenta rischi spesso elevati: è necessario eseguire un nuovo processo di tuning e test di tutte le applicazioni esistenti, con eventuali necessità di eseguire opportuni processi di manutenzione.
A tal proposito, ho avuto modo di assistere ad una decisione abbastanza autolesionista. Dopo aver sviluppato e messo in esercizio un sistema di medio/grandi dimensioni basato su uno specifico AS, il management decise di cambiare fornitore. Si trattava di una decisione basata esclusivamente su considerazioni economiche (leggasi migliore offerta ricevuta da un altro fornitore). Purtoppo i semplicistici conti sulla carta, non riflettevano la situazione reale. Se da un lato era vero che il costo di esercizio del nuovo AS permetteva di risparmiare moltissimo, dall'altro, ahimé, tale scelta implicava elevatissimi costi che finivano per annullare il risparmio per almeno una decina di anni. Cambiare l'AS significò: nuova iterazione del processo di sviluppo del sistema resasi necessaria per adattare il codice al nuovo AS, nuovo processo di test, ennesimi studi di tuning, clustering, formazione dell'intero personale, specie quello demandato al supporto, revisioni di tutti i tool e gli script, ecc.

Politica di adeguamento alle nuove specifiche
Ormai dovrebbe essere sufficiente chiaro quanto importante e critico sia selezionare un AS di riferimento. Gli effetti di tale scelta tendono a ripercuotersi nel tempo: i futuri sistemi, gioco forza, continueranno a utilizzare lo stesso AS.
Una prima necessità è quindi conoscere sia la versione delle specifiche ufficiali (Java, J2EE, Servlet, etc.) a cui i vari AS sono allineati, sia condividere la politica adottata dal fornitore rispetto alle evoluzioni delle specifiche stesse. Esistono alcuni vendor che adottano strategie particolarmente sollecite, impegnandosi a fornire nuove versioni del proprio AS ad ogni aggiornamento delle specifiche ufficiali (questa per esempio è la strategia utilizzata da Bea con WebLogic), mentre altri preferiscono utilizzare un atteggiamento più protettivo, attendendo che le specifiche acquisiscano un certo grado di stabilità prima di incorporarle (questa è la strategia di IBM per quanto attiene a WebSphere). Quale strategia è migliore? Ebbene, la risposta dipende dai propri requisiti, dalla dimensione dell'azienda, dalla relativa natura, ecc. Per esempio, è abbastanza naturale attendersi che aziende votate al "cutting-edge" tendano a preferire strategie più aggressive, mentre altre, magari gravate dall'onere di dover supportare diversi sistemi funzionanti, dovrebbero naturalmente preferire strategie più conservative. Il problema di fondo è che tutti i prodotti e tecnologie prima di acquisire una certa stabilità necessitano di una certa tranisizione, più o meno estesa, che può gravare sulla manutenzione/realizzazione dei sistemi e, logicamente, tutte le aziende desiderano limitare i costi dovuti a periodi di minore stabilità dei prodotti adottati. Chiaramente nulla vieta di continuare ad adottare una specifica versione di un prodotto anche in occasione del rilascio di una nuova versione. Questa strategia potrebbe però presentare degli svantaggi legati alla correzione di difetti presentati da una versione non più supportata di uno specifico AS.

L'importanza del fattore budget
Nei casi in cui sia necessario dover operare una scelta è molto opportuno, come da buona tradizione ingengeristica, stabilire i requisiti. Attualmente sul mercato sono disponibili svariati application server. Si può scegliere diversi gratuiti o quasi, quali per esempio Jboss, altri a costi molto accessibili come l'AS della Oracle, ad altri ancora a costi piuttosto elevati, quali Bea WebLogic, IBM Websphere, e così via. Molte organizzazioni concentrano la decisione su quale adottare, basandosi esclusivamente sul fattore economico. Chiaramente si tratta di un elemento molto importante, ma limitare la selezione al solo costo delle licenze sarebbe piuttosto semplicistico. Non è infrequente il caso in cui si tratti di un costo trascurabile rispetto ad altri elementi quali, per esempio, il costo di messa in esercizio, l'acquisto delle attrezzature hardware, lo stesso sviluppo, ecc. Inoltre, è opportuno tenere presente che molti fornitori non si limitano a vendere le licenze d'uso dell'AS, bensì offrono una serie di servizi (training, supporto, consulenze specifiche, ecc.) che, a lungo termine, possono risultare strategici.
Il fattore budget può anche prevedere risvolti paradossali. In una grande azienda londinese, fui coinvolto nelle discussioni volte a stabilire quale AS utilizzare. Dopo una lunga serie di dibattiti, nel meeting finale, sperimentai una situazione abbastanza bizzarra. Un collega influente continuava a "battersi a spada tratta" per l'adozione dell'AS più costoso... Spazientiti dall'atteggiamento si decise di investigare le motivazione di tale forte propensione per uno specifico AS. Dopo alcune argomentazioni piuttosto discutibili, quella finale fu: "Se costa molto più degli altri, evidentemente, significa che vale molto di più degli altri". Forse anche in questa frase c'é un fondo di verità.
A parte strani comportamenti, chiaramente il budget a disposizione è un importante criterio di selezione, ma non va limitato al solo fattore licenza, bensì va analizzato nel complesso dei servizi offerti.

Supporto
Una volta selezionato un AS, questo tenderà ad essere riutilizzato per lo sviluppo dei sistemi futuri: volenti o nolenti, si finisce per instaurare uno stretto legame con il vendor. Una situazione diversa si genera in tutti quei casi si decida di ricorrere a sistemi Open Source (OS d'ora in avanti). Quantunque alcuni manager e tecnici, non sempre preparati, nutrano ingiustificate reticenze a soluzioni di questo tipo, la verità dei fatti ha mostrato che si tratta invece di sistemi affidabili con elevato grado di supporto. Attualmente sono disponibili tantissimi sistemi open source il cui successo non ha bisogno di commenti (Red Hat, Tomcat, Jboss, Ant, Log4j, Struts, etc.). Una considerazione interessante è che sviluppatori di sistemi OS sono "nascosti" in tutti gli angoli della terra e pertanto tendono ad essere disponibili per il supporto a qualsiasi orario e in qualsiasi giorno dell'anno. Questi tecnici (salvo rarissime eccezioni) sono molto orgogliosi del prodotto e del loro codice e quindi sono sempre più che solerti nel risolvere i vari problemi. Inoltre i prodotti OS, tipicamente, dispongono di molti gruppi di mailing list gratuite in cui potersi iscrivere per discutere eventuali problemi e per studiare sulla base dei problemi incontrati da altri tecnici. Infine, nella nefasta situazione in cui un problema non sia già stato risolto e che nessuno lo voglia o sia in grado di affrontarlo, è sempre possibile rimboccarsi le maniche e, a colpi di debugger, tentare si risolverlo autonomamente (ricordandosi poi di rendere la correzione disponibile alla comunità).
Chiaramente ogni medaglia ha il lato negativo. Per quanto concerne il supporto esistono diversi svantaggi legati ai sistemi OS. Il primo è quello che pesa di più ad alcuni manager: qualora sia presente un serio problema o qualora si seguano consigli azzardati forniti da un zelante programmatore non preparatissimo, che invece di risolvere il problema ne generi un aggravio, non è possibile scaricare la responsabilità su nessun'altra organizzazione. Le tanto amate frasi: "è colpa dell'AS perché non fornisce il servizio X come dovrebbe", oppure: "è colpa del consulente Z che non ha fornito chiare direttive", non sono ahimè utilizzabili (o magari lo sono, però manca comunque il capro espiatorio). L'esperienza però insegna che la stessa situazione può occorrere anche con prodotti proprietari.
Durante lo sviluppo di un sistema molto complesso ci imbattemmo in un strano e alquanto antipatico problema. In particolare, in singolari circostanze il sistema diventava inutilizzabile poiché il database, inaspettatamente, transitava in uno stato di locking. Sottoponendo l'inconveniente sia al fornitore dell'AS, sia a quello del database, assistemmo ad un antipatico gioco dello scaricabarile tra i due fornitori con imbarazzanti ripercussioni sui tempi ed i costi dell'intero progetto. Questo increscioso "ping-pong" si protrasse piuttosto a lungo. Il fornitore dall'AS puntava il dito sui driver del database. Il fornitore di quest'ultimo, a sua volta, spostava tutta la colpa sull'AS. Il problema era piuttosto noioso perché cambiare temporaneamente AS e/o database non era assolutamente immediato per via delle dimensioni del sistema stesso. Alla fine, esasperati dalla situazione, decidemmo di realizzare, con non poca fatica, un componente riproducente il problema e di effettuarne il deployment su un altro AS. Risultato: il problema si riproponeva, era effettivamente colpa di un bug nel driver del database. Considerazioni: il tanto osannato supporto dei vendor fu piuttosto carente. Chiaramente si tratta di uno scenario isolato e si è sicuri che il supporto dei vendor sia invece risultato strategico in molti altri progetti.
Un altro aspetto che tende a scoraggiare taluni manager, specie se appartenenti a grandi organizzazioni, nella selezione di prodotti OS è legato alla relativa intrinseca democraticità: la priorità assegnata ai problemi sottomessi agli sviluppatori di OS, tipicamente, non è in funzione della dimensione dell'azienda che lo sottopone. Questa politica, molto utile per le aziende medio/piccole, è meno apprezzata da quelle di maggiori dimensioni abituate ad un trattamento VIP da parte di vendor proprietari.
Sempre in merito al fattore supporto, è opportuno considerare anche la speranza di vita del fornitore. Sebbene questo problema non si ponga per i principali vendor, e meno che mai per i prodotti OS di successo, gli ultimi tempi hanno fornito importanti insegnamenti. In particolare, molte software house sono state costrette a chiudere i battenti, altre a riconsiderare i propri budget e altre ancora sono state assorbite da aziende più grandi. Molto spesso questi avvenimenti hanno generato l'abbandono del supporto di alcuni prodotti offerti, ritenuti non più strategici o profittevoli (Un esempio? HP). Pertanto, qualora si decida di selezionare un AS fornito da un vendor, specie di medie/piccole dimensioni, è necessario considerare quali problemi potrebbero occorrere qualora l'AS non sia più supportato. Questa considerazione dovrebbe far propendere per non disegnare applicazioni eccessivamente basate sulle peculiari capacità dei singoli AS. A questo punto ci si potrebbe interrogare sul perché ricorrere a fornitori di medio-piccole dimensioni? Semplice, perché queste aziende tendono a: offrire servizi di maggiori qualità, risultare più dinamiche e presentare un'elevata sollecitudine nell'assecondare i desideri e i bisogni dei propri clienti, offrire proposte economicamente più vantaggiose.

Affidabilità dell'AS
Un fattore di importanza fondamentale nella selezione dell'AS è relativo all'affidabilità dello stesso. Bug o malfunzionamenti degli AS possono generare seri problemi non sempre aggirabili. Non è infrequente che anche la stessa individuazione di malfunzionamenti tenda a consumare un elevato lasso di tempo. Per questo motivo è opportuno assicurarsi che l'AS presenti un elevato grado di affidabilità e che eventuali problemi tendano ad essere risolti rapidamente. Ora come fare ad informarsi circa l'affidabilità dell'AS? Chiaramente interrogare l'oste circa la qualità del proprio vino potrebbe non essere la strategia più scaltra. Il metro migliore è chiaramente l'esperienza diretta ed il parere di personale veramente qualificato (anche se spesso non tutti i consulenti sono indenni da, usando un eufemismo, sollecitazioni commerciali). Altre indicazioni possono provenire dalla consultazione dei newsgroup e mailing list: tutti gli AS ne dispongono diverse. Nel caso in cui si incappi in newsgroup e mailing list con poca attività è possibile trarre due deduzioni: le particolari fonti scelte non sono attendibili; oppure tutti gli utilizzatori dell'AS si sono dedicati al harakiri per via della relativa scarsa qualità. L'esperienza insegna ad abbandonare a priori l'illusione che esista un AS perfetto. Nel caso generale, queste fonti offrono una serie di importanti vantaggi: sono quasi sempre accessibili gratuitamente, forniscono una buona idea dell'AS dalla prospettiva degli utilizzatori, e, cosa importante, rarissimamente sono moderati dal personale appartenente al vendor. Dalla lettura delle varie richieste è possibile risalire a molte utili informazioni; è possibile: intuire quale sia il livello di affidabilità, o se si preferisce, la tendenza ai malfunzionamenti dell'AS; comprendere se gli utenti discutono circa problemi rarissimi e di effimera importanza o di cose più fondamentali (il che dovrebbe incutere un certo terrore); crearsi un'idea circa il tempo medio di risposta ai vari interrogativi e di risoluzione dei guasti; capire il livello qualitativo del supporto fornito; etc.

Reperimento del personale
L'esperienza insegna che reperire personale veramente esperto dell'architettura J2EE non è poi così facile. Eppure dalla lettura dei vari CV sembrerebbe di trovarsi in un ambiente di persone super-esperte, navigati disegnatori ed implementatori di architetture J2EE, conoscitori di ogni API Java, pattern di disegno, etc... In ogni modo, nelle sporadiche situazioni in cui si è interessati a sviluppare sistemi che dovranno veramente funzionare, è inoltre utile individuare personale esperto anche dello specifico AS adottato. Pertanto, selezionare un AS non molto conosciuto potrebbe complicare il problema del reperimento del personale, nonché aumentare i costi, specie se questo avviene in corso d'opera (come da prassi). Tipicamente selezionare AS popolari offre un'elevata sicurezza sia sulla possibilità di reperire tecnici preparati e pronti da impiegare e sia sul contenimento delle relative tariffe. Gli stessi tecnici tendono a gradire poco partecipazioni in progetti in cui siano presenti "buzzword" non facilmente spendibili nel proprio CV. Questo è spesso anche colpa di alcune agenzie di reclutamento, o body rental, le quali, invece di selezionare personale in funzione delle capacità di disegno e di implementazione, si limitano a ricercare nei CV dei candidati la presenza di parole chiavi come JBoss, WebLogic, WebSphere, etc.

Caratteristiche peculiari dell'AS
Ritornando alla considerazione con cui si è aperto l'articolo, ossia che ormai tutti i maggiori AS realizzano i servizi standard (affidabilità, scalabitilità, realizzazione delle specifiche J2EE, ecc.) con livelli qualitativi abbastanza elevati, si può comprendere come funzionalità aggiuntive possano generare la famosa differenza. Il personale tecnico è pagato per sviluppare sistemi qualitativamente avanzati e funzionanti nei tempi e costi previsti. Sistemi pure J2EE sono molto affascinanti, ma spesso costituiscono un bene di lusso che poche organizzazioni posso permettersi: rifiutare a priori ogni caratteristica peculiare di un AS è semplicemente pericoloso. Ciò però non deve neppure portare a negare la portabilità o a disegnare sistemi fortemente legati a singoli vendor. Ogniqualvolta venga individuata una soluzione portabile e funzionante, questa deve avere l'assoluta precedenza; nei casi in cui invece si debba ricorrere a soluzioni peculiari di un AS, è importante utilizzare le direttive del buon disegno: isolare le parti di sistema fortemente legate ai vendor, generare livelli di astrazione nei confronti dei dettagli, ecc.
In ogni modo le caratteristiche peculiari dei vari AS, spesso, permettono di risolvere alla fonte moltissimi problemi. Per esempio, nelle architetture moderne è sempre più frequente la presenza di sistemi di messaggistica (Message Oriented Middleware), ove la presenza di una buona implementazione dell'architettura JMS è, indubbiamente un ottimo valore aggiunto. Per esempio, dovento operare con MQSeries, ovviamente WebSphere presenta alcune caratteristiche peculiari di integrazione che lo rendono quasi imbattibile. Un'altra tecnologia sulla quale si sta investendo molto sono i famosi web-services. Sebbene questi stiano divenendo parte delle specifiche ufficiali, esistono già diversi AS che integrano egregiamente soluzioni fornite da terze parti. Infine, come non parlare degli entity bean. Non è un mistero che il loro utilizzo, specie se accoppiato con database relazionali, non sempre riesce a raggiungere performance paragonabili a quelle presentate da opportuni strati di integrazione con la base dati. Pertanto, AS offerti con buone integrazioni di prodotti di questo tipo presentano indubbiamente grossi vantaggi. Per esempio Oracle offre gratuitamente Top-Link con i proprio sever.

Alcune particolari considerazioni tecniche
Sviluppare sistemi basati sull'architettura J2EE semplifica drasticamente o rimuove del tutto molti problemi tecnici: il container offre tutta una serie di servizi pronti ad essere utilizzati (gestione del ciclo di vita dei componenti, resourse pooling, multi-threading, transazionalità, etc.) permettendo agli sviluppatori di concentrarsi sulla business logic, trascurando molti dettagli implementativi. A fronte di questo vantaggio, però, esistono una serie di nuovi problemi. Sviluppare, effettuare il deployment e verificare sistemi J2EE è più complesso e richiede molto più tempo. Un fattore che, specie in passato, giocava un importante ruolo nella scelta degli AS era legato alla facilità di sviluppare e di effettuare il deployment dei vari EJBs. Si trattava di un processo abbastanza gravoso che richiedeva la necessità di scrivere diversi script proprietari. Attualmente sono disponibili molti tool che permettono di effettuare automaticamente il deployment e poi, la quasi totalità degli AS supporta il cosiddetto hot-deployment: è possibile eseguire il deployment di una nuova versione dei componenti senza dover eseguire lo shutdown dell'AS. Si tratta di un servizio particolarmente apprezzato durante la costruzione del sistema, mentre è praticamente trascurabile quando il sistema è in esercizio. (Nota) Le organizzazioni che sfruttano sistemi informatici per erogare servizi funzionanti su base 24x7, dispongono di configurazioni ridondanti. Ciò è utile per questioni legate al load balancing, per assicurare il funzionamento del sistema in caso di guasto di un server e di aggiornamenti. In questo ultimo caso, le nuove versioni vengono installate su un server opportunamente posto in off-line, dopodiché, tipicamente, si esegue un set minimo di test (tipicamente detti Sanity Check) per verificare che non siano occorsi problemi durante il deployment, quindi si riporta il server on-line, disabilitando gli altri. (Fine nota)
Altro elemento che in passato risultava molto importante era relativo alla qualità della documentazione. Inizialmente non tutti gli AS fornivano un adeguato livello di documentazione. In quei casi era curioso assistere alla frustrazione di alcuni tecnici che, a loro volta, molto spesso erano stati fonte di frustrazione per persone che ne dovevano utilizzare il relativo codice non adeguatamente documentato. Attualmente la documentazione ufficiale, almeno quella degli AS più blasonati, è supportata dalla pubblicazione di svariati articoli e libri provenienti anche da fonti indipendenti. Questi libri spesso affrontano in dettaglio argomenti che possono avere il loro peso, come il tuning, l'accrescimento delle performance, ecc. La disponibilità di questa documentazione, chiaramente, finisce per favorire, ancora una volta, gli AS più popolari.

Il supporto da parte della SUN...
Un fattore molto importante (come accennato anche in precedenza) nella selezione di un AS è relativo al livello di adeguamento alle specifiche ufficiale e le performance fornite. Per quanto riguarda il primo punto, la Sun microsystem, proprietaria delle specifiche J2EE, ha l'onere (ben remunerato) di fornire opportuni strumenti atti a misurare l'aderenza degli AS alle specifiche ufficiali. In particolare, la Sun fornisce il famoso Compatibility Test Suite (CTS). Si tratta di test esaustivi che, a detta della Sun, si occupano di verificare tutte le classi e tutti i metodi delle API J2EE e relativi servizi annessi. La lista degli AS che superano i test sono pubblicati presso l'indirizzo ([2]).
Il CTS è indubbiamente un valido strumento, però non è esente da limitazioni. Sottomettere un AS ai test presenta costi abbastanza sostenuti e non tutti i vendor possono o vogliono invertire in tale direzione. Per esempio per molti AS open source (come JBoss, sebbene sembrerebbe che questo problema sia, finalmente, in corso di soluzione, cfr: [5]) si tratta di un investimento proibitivo, altre aziende invece, molto semplicemente, non ritengono si tratti di un buon investimento (per esempio Orion). Inoltre, sebbene questi test si occupino di verificare la corrispondenza alle specifiche ufficiali, non prendono in considerazione altri aspetti ugualmente importanti, come tuning, scalabilità, facilità d'uso, costo della manutenzione, ecc. Inoltre, non sono verificate neanche eventuali caratteristiche aggiuntive fornite dagli specifici AS. Per esempio IBM WebSphere presenta tutta una serie di utilità che agevolano moltissimo l'integrazione con gli altri sistemi forniti dall'IBM, mentre Oracle dispone di TopLink come tier di integrazione con la base di dati qualora si decida (spesso saggiamente) di non utilizzare gli entity bean. Per tutti questi motivi, è importante considerare gli AS dotati di certificazione Sun, tenendo però a mente tutte le limitazioni esposte.
Per quanto concerne invece le performance e la scalabilità, la Sun ha sviluppato un EJB benchmark, ECPerf (cfr.: [3]), atto proprio a verificare performance e scalabilità degli application server. I risultati sono pubblicati sul sito theServerSide (cfr.: [4]). ECPerf dovrebbe simulare i problemi particolarmente ricorrenti nei progetti reali e quindi verificare le performance dell'application server. La scelta operata è quella di adottare un database relazionale e gli entity bean la cui transazionalità è gestita dal container (CMP). Si tratta anche in questo caso di risultati da considerare con le dovute cautele. Già l'architettura selezionata potrebbe creare diversi argomenti di discussione (la maggioranza dei sistemi J2EE in cui abbiamo lavorato o visionato, saggiamente, non impiegavano entity bean... Non è un caso che la stessa Sun abbia prodotto le direttive JDO), inoltre, il particolare database utilizzato con l'AS è un fattore decisamente non trascurabile, così come non è trascurabile la configurazione hardware presa per riferimento. Pertanto, come nel caso del CTS, è importante considerare cautamente i risultati prodotti dall'esecuzione del benchmark.

Conclusioni
Con il presente articolo abbiamo affrontato il problema della selezione dell'AS. In particolare l'intento è stato spostare l'attenzione da considerazioni prettamente tecniche ad altre di portata strategico-manageriale. In internet è possibile trovare molti articoli che illustrano le diverse caratteristiche tecniche e i requisiti che un AS deve soddisfare, ma ben pochi affrontano il tema del fattore strategico di tale decisione e dell'impatto sulle politiche tecnologiche aziendali (gestione personale, rapporti con i vendor, pianificazioni di progetti futuri, ecc).
Il tema è stato affrontato conferendo particolare importanza allla prospettiva delle medio/grani imprese e sistemi. In questi casi, una volta selezionato un AS, gioco forza, questo tende a divenire lo standard aziendale. Chiaramente questo problema è meno sentito dalle software house, le quali, per loro natura, dovrebbero rimanere il più possibile indipendenti dai vari vendor. Nel contesto preso in considerazione, variazioni di fornitori tendono a generare notevoli rischi, la cui gestione può prevedere un elevato impatto economico (basti pensare al costo di dover ritrasportare tutte le applicazioni su un diverso AS).
Considerati gli effetti della scelta dell'AS, è molto importante effettuarla il prima possibile. Ciò permette di: adeguare lo sviluppo del sistema alle peculiarità dello specifico AS, instaurare un migliore rapporto con il vendor, aumentare il livello di conoscenza e lo skill richiesto dallo stesso, ecc.
Oggigiorno il mercato fornisce moltissime alternative di AS e le ripercussioni della scelta sono molto importanti. Pertanto, prima di prendere una scelta è consigliabile condurre studi approfonditi considerando tutti i diversi fattori e non limitandosi a selezionare quello meno costoso o quello più blasonato.

Bibliografia
[1] Rod Johnson- "J2EE Design and Development", Wrox, 2003

Riferimenti
[2] Compatibility Test Suite - http://java.sun.com/j2ee/compatibility.html
[3] ECPerf - http://java.sun.com/j2ee/ecperf
[4] http://www.theserverside.com/ecperf/
[5] http://www.zdnet.com.au/newstech/os/story/0,2000048630,20273052,00.htm

Luca Vetti Tagliati opera nell'area della City di Londra, attualmente operativo presso la Deutsche Bank UK. Si occupa di ricerca di processi di sviluppo del software presso la Birkbeck University of London. Negli ultimi anni ha applicato la progettazione/programmazione Component Based in settori che variano dal mondo delle smart card a quello del trading bancario, prevalentemente in ambienti Java e J2EE. Ha lavorato presso HSBC Investiment Bank PLC UK con funzioni di chief designer, team leader e membro del gruppo PEG (Processing Engineering Group) istituito per stabilire un processo di sviluppo standard da applicarsi per lo sviluppo di sistemi software. Ha collaborato attivamente con persone del calibro di John Daniels (coautore del libro "UML components") e Frank Armour (coautore del libro "Advanced Use Case Modeling"). È rintracciabile presso l'indirizzo LucaVT@tiscali.co.uk.