MokaByte Numero 30  - Maggio 1999 
Web dinamico
con JSP
di
GiovanniPuliti
 
II parte
In collaborazione con Computer Programming

Dopo l’introduzione fatta il mese scorso,  affrontiamo questa volta alcuni aspetti legati all’implementazione di JSP
Le Java Server Pages sono una tecnologia di recente introduzione di cui abbiamo avuto modo di parlare con un articolo introduttivo il mese scorso [JSP1]. 
Per chi non avesse letto la puntata precedente, ricordo che si tratta di un sistema di scripting simile alle ASP di Microsoft, in grado di unire HTML, servlet, Enterprise JavaBeans ed applicazioni lato server, per realizzare pagine web interattive a contenuto dinamico.
Dopo la parte dedicata al funzionamento ed alla sintassi delle JSP, questo mese, tra le altre cose, vedremo come realizzare una tipica applicazione che si trova molto frequentemente in rete: parleremo infatti di acquisti on-line per mezzo del cosiddetto "carrello della spesa", ovviamente virtuale. 
Affronteremo anche l’aspetto del software che attualmente è possibile utilizzare per mettere in piedi una struttura JSP: a tal proposito, subito dopo aver scritto l’articolo precedente, mi sono arrivate molte mail e news relativamente al rilascio di nuovi prodotti compatibili con la tecnologia JSP, dimostrazione che il settore è letteralmente in ebollizione, cosa che fa ben sperare per il futuro. 
I vari JRun di LiveSoftware [Jrun], JView di Apache Project [JView], JavaWebServer di Sun [JWS] sono solo alcuni esempi dei nuovi prodotti a disposizione dello sviluppatore; anche Lotus Domino [R5] pur non essendo un prodotto esclusivamente pensato per l’uso dei servlet, ne fornisce il supporto ed anzi sono in arrivo molte interessanti novità in tal senso con la prossima versione.
 
 
 

Il PageCompilerServlet 

Abbiamo detto che per poter essere utilizzate le JSP necessitano di un web server che le supporti, o (caso sempre più frequente) di un application server che ne estenda le funzionalità.
Chi però ha fatto un giro sul sito della Sun ed ha letto un po’ di documentazione relativa al Java Web Server, si sarà reso conto che in realtà ciò non è completamente vero.
Consultando infatti la documentazione relativa alla tecnica della compilazione di pagine HTML (una specie di Cascading Style Sheet fatto in Java), si comprende che il tutto poggia non su strani dispositivi o software, ma semplicemente su un piccolo servlet, il PageCompilerSerlvet, il quale svolge molti servizi, fra cui quello della compilazione di pagine HTML contenenti script Java.
In realtà si tratta dello stesso servlet che ad esempio il WebSphere Application server utilizza per gestire le JSP.
Effettuando due prove ci si può rendere conto che per far funzionare una pagina JSP in realtà è sufficiente un web server che supporti i servlet ed utilizzare il PageCompilerSerlvet ogni volta che venga effettuata una invocazione ad una pagina JSP.
Ad esempio una stringa del genere (da inserire nell’opportuno file di configurazione dei web server)
 
*.jsp PageCompilerServlet
permette di dire al web server che ogni pagina di tipo JSP non deve essere inviata direttamente al browser, ma deve essere processata dal PageCompilerServlet (questo è il motivo per cui se si apre direttamente una pagina JSP con il browser non succede niente).
Effettivamente tale situazione è piuttosto ovvia, anche pensando a come sono strutturati tali oggetti: il PageCompilerServlet infatti esegue un parsing del codice HTML della pagina JSP, e provvede a compilare tutto il codice Java che vi è inserito, oppure a mandare in esecuzione i vari bean o servlet referenziati.
Ovviamente l’utilizzo di un application server ottimizza l’utilizzo di tale servlet, ed offre ulteriori funzionalità, come la capacità di controllare la presenza di modifiche nel codice e di ricompilare solo quando necessario. 
Anche se questa scoperta potrà deludere l’utente che sperava in una nuova rivoluzione tecnologica, si deve tenere conto che, rispetto all’utilizzo di una applicazione monolitica, tale soluzione permette una maggiore flessibilità: dato che infatti tutto il lavoro relativo alle JSP viene svolto da un piccolo componente, il servlet appunto, si possono eseguire modifiche o upgrade del sistema semplicemente sostituendo pochi file .class. 
È possibile quindi, nel caso si abbiano sufficienti conoscenze, implementare una propria versione di JSP, in modo da aggiungere particolari funzionalità o personalizzare il comportamento del web server.
Questa in fondo è stata fin dall’inizio la filosofia dei servlet, anche se nessuno ha mai detto apertamente che poteva essere utilizzata per realizzare qualcosa di veramente nuovo, come invece le JSP si propongono di essere.
Possibili architetture
Vediamo adesso quali sono le possibili soluzioni che si possono adottare per la creazione di un sito web basato su JSP. 
Partendo dai vari web server più diffusi ed utilizzati, tralasciamo per un momento le considerazioni relative al PageCompilerServlet, e concentriamo l’attenzione sulle soluzioni "chiavi in mano": 
  • Apache: è praticamente il web server più diffuso, sia per la sua politica free che si è sposata perfettamente con quella di Linux, sia per le sue doti effettive. Per default non supporta i servlet, né JSP, lacuna in parte colmabile ricompilando il prodotto con l’aggiunta dell’apposito plug-in; tale sistema però al momento non aggiunge il supporto per JSP. Di recente, il gruppo Java Apache Project ha presentato JView, una specie di application server, il quale oltre ad aggiungere il supporto per servlet e JSP, introduce alcune interessanti novità, prima fra tutte quella delle "zone" di esecuzione (vedi Riquadro 3). In alternativa si può utilizzare JRun, un application server prodotto da LiveSoftware, in grado di offrire supporto servlet e di recente anche JSP (nella versione PRO). JRun è disponibile sia per Linux che per Windows NT, per cui la maggior parte delle casistiche può essere coperta, anche se spesso i vari web sono basati su sistemi operativi più solidi come Solaris.
  • Lotus Domino GoWeb è invece la soluzione offerta da IBM, e rappresenta un ottimo prodotto che può essere esteso grazie a WebSphere di IBM. Questi due prodotti volutamente pensati per essere utilizzati in coppia, offrono interessanti ed utili funzionalità, anche grazie all’abbinamento di WebSphere Studio, un ambiente di sviluppo che promette bene per il futuro. Grosso punto a favore di questa famiglia di prodotti, oltre ad avere alle spalle una casa come IBM, è la disponibilità per le maggiori piattaforme: Aix, Solaris, NT e prossimamente anche Linux, garantiscono una copertura totale veramente invidiabile. L’application server WebSphere ha il grosso vantaggio di poter essere utilizzato anche con altri server http, come Netscape FastTrack, Microsoft IIS, o altri.
  • Java Web Server: il prodotto della Sun, uscito inizialmente col nome di Jeewes era un esercizio di stile al quale fu affidato il compito di mostrare le potenzialità di Java. Adesso, con la versione 1.1 inizia ad entrare nell’era della maturità e viene proposto come valida alternativa dalla casa a prodotti più stagionati. Offre interessanti funzionalità, prima fra tutte le possibilità di essere totalmente gestito via web per mezzo di una applet. Essendo direttamente prodotto dalla Sun, rappresenta lo standard per la compatibilità della piattaforma servlet e JSP. 
  • Internet Information Server è la proposta di Microsoft in tale settore, e come molti sanno non supporta i servlet e JSP (principalmente per motivi di politica aziendale). Può però essere esteso grazie all’utilizzo di application server come JRun o WebSphere.
  • Nestscape FastTrack, almeno nell’ultima versione che ho avuto modo di provare, non permetteva l’uso di servlet e JSP, ma anche in questo caso lo si può estendere con WebSphere, e nel prossimo futuro anche con JRun.
Fra i vari application server, oltre a quelli già citati qui sopra, è da menzionare anche ServletExec 2.0 di New Atlanta Communications [SExec] disponibile praticamente per ogni sistema operativo (Win NT Srv e Wks, Win 95/98, SPARC Solaris, HP-UX, Linux, MacOs) e funzionante con i relativi web server: non in tutti i casi offre però il supporto per JSP. 
Nel Riquadro 2 sono riportati alcuni prodotti meno noti che offrono il supporto per servlet ed in alcuni casi anche JSP. 
 
 
 

Carrello della spesa

Quello del mantenimento dello stato è uno degli aspetti che ogni programmatore web ha dovuto prima o poi risolvere: si tratta di dover mantenere traccia delle varie operazioni effettuate dall’utente al passare da una pagina HTML ad un’altra, cioè al susseguirsi delle varie invocazioni CGI.
Anche i servlet lavorano in parte con la modalità CGI, ma offrono qualche vantaggio in più, grazie al dualismo offerto dai metodi init() e service(), e grazie anche alla presenza di una JVM alle spalle; per mantenere lo stato anche con i servlet però è necessario un po’ di lavoro aggiuntivo. 
Vediamo invece, per mezzo delle JSP, come possiamo risolvere questo problema in maniera più elegante: prendiamo in considerazione un caso tipico, quello del carrello della spesa utilizzato su molti siti web che offrono servizi di acquisti on-line.
In questo caso l’utente può navigare fra le varie pagine del sito e memorizzare passo per passo tutta la merce comprata in un contenitore (il carrello appunto) che verrà utilizzato sia per visualizzare la spesa che per effettuare il conto finale.
Il grosso vantaggio, come abbiamo avuto modo di vedere il mese scorso, è che in questo caso la presenza di soggetti differenti (HTML, EJB, servlet) permette di diversificare i vari compiti, semplificando la loro realizzazione. 
In questo caso possiamo memorizzare tutti i dati nel bean accedendovi con lo script JSP, evitando di dover adempiere a questo compito con i servlet ed HTML.
L’esempio che prendiamo in esame è costituito dai seguenti file: 
  • un file HTML che visualizza una lista di prodotti in vendita da aggiungere o togliere dal carrello;
  • un JavaBeans che implementa di fatto il carrello vero e proprio;
  • un file JSP che serve per visualizzare il contenuto del carrello dopo che un oggetto è stato aggiunto o tolto.
Osservando tutti i sorgenti si può facilmente intuirne il funzionamento: si osservi come il bean (il carrello della spesa) non serva altro che ad effettuare una raccolta di item che possono essere aggiunti o tolti, grazie ai metodi addItem() e removeItem().
Interessante come la chiamata http venga passata direttamente al bean e per mezzo della istruzione 
 
SETFROMREQUEST beanproperty="*"


tutti i parametri contenuti vengano direttamente passati al bean. Il bean gestisce questo caso grazie alla presenza del metodo
public void processRequest(HttpServletRequest request)
come se si trattasse di un servlet: questa situazione può apparire piuttosto bizzarra, e confondere non poco le idee. 
In realtà si può immaginare che sia l’application server ad effettuare una specie di merge fra un template-servlet ed il bean in questione. Per il resto, il corpo del metodo  rocessRequest non fa altro che aggiungere i vari item (oggetti comprati) alla lista interna. Si noti che se il valore del parametro submit è nullo, allora si presume che l’utente abbia semplicemente premuto il tasto invio, e non l’apposito bottone del form HTML.
 

// il valore null per submit, implica che l’utente ha premuto 
// il tasto enter invece che cliccare sul pulsante "aggiungi" o "togli"
if (submit == null) 
addItem(item);


Come si può notare quindi, con poche righe si affrontano i punti più delicati ed importanti della tecnologia JSP.
WebSphere
Il problema maggiore delle Java Server Pages è che attualmente esistono ben pochi strumenti di sviluppo che permettano di creare soluzioni complete con poco lavoro. Quello che è offerto in ambito Microsoft con ASP, Visual Basic e Visual Interdev, qui è ancora lungi dall’essere disponibile.
Un buon strumento di sviluppo, per poter essere realmente funzionale, deve permettere la produzione sia di script (HTML e JSP), ma anche di codice Java (beans, servlet applicazioni generiche), e soprattutto deve permettere a tutte queste parti, di interagire fra loro in modo corretto. 
Quest’ultimo è attualmente il punto critico dei vari tool che ho avuto modo di provare, specialmente per quanto riguarda la creazione dei riferimenti ai vari path. 
Fra tutte le possibilità, benché sia ancora da migliorare molto, WebSphere Studio, offre alcune utili funzionalità 

  • Consente di creare un progetto partendo da zero, permettendo la produzione del codice HTML, JavaBeans, Serlvet e impostando automaticamente i vari link incrociati.
  • Permette la creazione di Data-Beans, componenti in grado di interfacciarsi con i più diffusi e potenti database-engine disponibili sul mercato: la gestione dei dati ad alto livello è resa possibile per mezzo di istruzioni SQL. 
  • Consente la compilazione dei sorgenti Java (servlet e beans) e la loro installazione remota. In particolare questa feauture permette la manutenzione remota di siti purché anche sul lato server sia installato WebSphere Application Server della stessa versione.
Attualmente il tallone di Achille di questo prodotto è rappresentato da una non ancora perfetta correttezza di funzionamento, che porta a volte a dover verificare e modificare manualmente il codice prodotto, operazione non certo gradita.
 
 
 

Meglio di ASP

Quando mi trovo ad illustrare le caratteristiche di nuovi oggetti Java come i servlet, mi viene chiesto quanto sia conveniente adottare tale soluzione a scapito di altre più diffuse o più semplici ed immediate da realizzare. Ad esempio nel caso dei servlet mi si chiede quale sia la maggior differenza rispetto alle ASP e cosa convenga utilizzare. Per rispondere a tali quesiti occorre fare un po’ di chiarezza.
Per prima cosa le ASP non si possono mettere a confronto con i servlet: mentre infatti la prima è essenzialmente una tecnica di scripting, i secondi sono veri e propri programmi Java che si interfacciano con il resto del sistema. Adesso che Sun ha rilasciato le JSP, possiamo dire che esiste un corrispettivo in ambito Java delle ASP. In entrambi i casi (JSP ed ASP) si utilizza infatti un linguaggio di script per "incollare" componenti compilati (OCX in un caso, Enterprise JavaBeans e servlet nell’altro).
Ma quali sono i pro ed i contro di entrambe le alternative? Le ASP e tutto ciò che vi è collegato, hanno il grosso vantaggio della piattaforma di sviluppo, ormai consolidata e di facile utilizzo grazie a prodotti ormai maturi. In tal senso nel caso di JSP, ancora molto deve essere fatto. 
Le ASP però non sono portabili, e limitano alla piattaforma Windows (NT) che, seppur con innegabili vantaggi, ha anche mostrato le sue limitazioni per lo sviluppo di sistemi Internet robusti.
JSP, servlet EJB e tutta la piattaforma Java invece sono del tutto svincolati dalla particolare scelta del sistema operativo ed hardware. 
A tal proposito si potrebbe pensare che la portabilità possa essere una caratteristica più importante per lo sviluppo di soluzioni lato client e non server; sempre più spesso però entro in contatto con realtà, in cui la scelta di Java sul lato server è stata fatta non tanto per permettere la portabilità immediata del sistema (come ad esempio avviene con le applet), ma piuttosto per non pregiudicare in futuro un passaggio a sistemi differenti, rendendo in tal modo il software un po’ più longevo. In tal senso le innate doti di scalabilità di Java, sono un punto a favore invidiabile.
Infine si tenga presente che per poter scrivere OCX o simili, si deve avere una certa conoscenza della tecnologia DCOM e della piattaforma sottostante, cosa che invece non è affatto necessaria con Java grazie al processo di astrazione che offre.
Mi sentirei di consigliare le Java Server Pages in tutti quei casi in cui si voglia implementare una struttura solida, sicura e portabile che si debba interfacciare con del software già esistente e funzionante (non solo Java ma anche legacy grazie a CORBA).
 
 
 

Conclusioni

Al termine di questa lunga trattazione in due puntate sulle Java Server Pages, cosa possiamo concludere? Vediamo di fare una sintesi dei punti fondamentali: 
  • le Java Server Pages sono l’ultimo ritrovato nell’ottica Java per la realizzazione di siti a contenuto dinamico. Il loro principale vantaggio è la possibilità di separare la sezione di gestione delle operazioni e di produzione dei contenuti, da quella di visualizzazione vera e propria. I vantaggi di questo disaccoppiamento, si ripercuotono anche sulla modalità di produzione e manutenzione del sito, permettendo a team di lavoro differenti di lavorare in maniera indipendente ma parallela.
  • JSP necessitano di web server appositamente progettati o comunque estesi, grazie ai cosiddetti application server.
  • Moltissima offerta di prodotti: in questo momento stiamo assistendo ad una vera e propria esplosione dei prodotti disponibili sul mercato, e di fatto le possibilità offerte stanno diventando sempre più articolate. 
  • Carenza in fase di sviluppo: ancora non si dispone di prodotti sufficientemente potenti per lo sviluppo, e molto lavoro deve essere fatto a mano.
  • Si possono considerare una valida alternativa alle ASP: anche se le prime vantano per il momento una maggiore esperienza e maturità alle spalle, le JSP invece, benché ancora non pienamente affidabili, hanno dalla loro l’utilizzo di Java, e quindi portabilità, sicurezza e tutto quello che ne consegue. 
In due parole quindi cosa possiamo dire di JSP? Sicuramente che è ancora presto - almeno nel momento in cui è stato redatto questo articolo - per poterle considerare una soluzione realmente utilizzabile in ambiti mission critical; è altresì vero che probabilmente in un prossimo futuro, quando la versione 1.0 verrà rilasciata, e contemporaneamente i vari application server e tool di sviluppo saranno più affidabili, questi oggetti potranno colmare una delle ultime lacune di Java, quella della mancanza di un sistema facile e flessibile per la presentazione dei contenuti.
 
 
 

Bibliografia

[JSP1] "Web a contenuto dinamico con Java Server Pages - I parte" di Giovanni Puliti, Computer Programming XXX marzo 1999;
[JSPSun] JSP Public Review 0.92 - Documentazione ufficiale della Sun presso http://java.sun.com/products/jsp;
[JRun] JRun e JRun Pro sono disponibili sul sito LiveSoftware (www.livesoftware.com);
[JView] Informazioni sul progetto Java di Apache presso http://java.apache.org;
[JWS] http://www.sun.com;
[R5] www.lotus.com;
[SExec] ServletExec 2.0 di New Atlanta Communications http://www.newatlanta.com/;
[JSPML] Mailing list dedicata alle JSP JSP-INTEREST@JAVA.SUN.COM, per iscrizioni mandare un messaggio listserv@java.sun.com con "help" nel body del messaggio.

  
 
MokaByte rivista web su Java

MokaByte ricerca nuovi collaboratori
Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@mokabyte.it