30 ebook a un prezzo mai visto!

Risparmia sui tuoi libri preferiti, mentre supporti la community Python Italia

➡️ Scopri gli ebook bundle
Home
Deploy di Web Applications

06 Giugno 2002

Deploy di Web Applications

di

Lo standard WAR per effettuare il deploy di un'intera applicazione web copiando un solo file.

Abbiamo recentemente descritto le Web Applications secondo lo schema proposto da Sun Microsystem, che propone un modello descrittivo dell’alberatura del progetto in modo da separare e descrivere meglio tutta l’applicazione.
Questo approccio ha, come sappiamo, gli indubbi vantaggi della standardizzazione. Da una parte consente a chi produce i tool di sviluppo e gli application server di rendersi compatibili (e magari certificati da Sun) con le nuove specifiche, dall’altra permette a chi sviluppa applicazioni Web di sapere che la struttura dell’applicazione deve essere fatta in un certo modo e che un qualunque application server, se certificato, tratterà l’applicazione allo stesso modo, garantendo quindi la portabilità assoluta.

Il nodo centrale della standardizzazione, come sappiamo, è dato da una definizione precisa dell’alberatura dell’applicazione.
Vediamo un esempio di come può essere strutturata questa alberatura.

Come sappiamo la root della Web Application sarà “MyApp”, che dovrà contenere le pagine HTML o JSP. In questo caso le pagine JSP sono anche nella cartella JSP, in “css” ci sono i fogli di stile, in “js” i file contenenti codice Javascript e dentro “WEB-INF” c’è l’alberatura che conosciamo.
In particolare a partire dalla cartella “classes” vengono espansi i package Java dell’applicazione, in “conf” ci sono i file deputati alla configurazione applicativa, in “lib” tutte le librerie esterne sotto forma di JAR o ZIP, in “tld” eventuali tag libraries, in “log” i log dell’applicazione.

Supponiamo di aver creato la nostra applicazione utilizzando questo schema, ad un certo punto sarà necessario effettuare il deploy su una macchina differente da quella di sviluppo.
La macchine di sviluppo, soprattutto se si utilizzano ambienti di sviluppo molto sofisticati, sono configurate diversamente da quelle di test, pertanto il passaggio da un ambiente all’altro potrebbe non essere indolore.

Deploy – modo tradizionale

Per eseguire il deploy di questa Web Application in modo tradizionale, se si utilizza Tomcat come application server, è necessario copiare l’alberatura così com’è sul file system della macchina server ed editare il file

TOMCAT_HOMEconfserver.xml

/

aggiungendovi la sezione relativa al nuovo context da creare per poter utilizzare la nuova Web Application attraverso HTTP.

La sezione che ci serve è di questo genere:


docBase=”c:myapp”
crossContext=”true”
debug=”0″
reloadable=”true”
trusted=”false” >

/

Sarà nostra cura inoltre modificare il CLASSPATH di sistema in modo da includere tutte le librerie esterne che debbano essere utilizzate dalle componenti della nostra applicazione.

Questo metodo funziona indipendentemente da come sia organizzata la Web Applicaton. Al termine potremo raggiungere la nostra applicazione attraverso l’url:

http://localhost:8080/myapp/

/

Cosa accade però in fase di manutenzione? In altre parole, cosa succede quando dobbiamo riportare in ambiente di test delle modifiche che coinvolgono alcune parti della Web Application?
Ci sono solitamente due alternative:

  • si sovrascrive l’intera alberatura con la versione aggiornata
  • si sovrascrivono selettivamente soltanto i file modificati

In ogni caso gli interventi da effettuare manualmente sono molti e la procedura non troppo semplice, soprattutto se siamo di fronte ad applicazioni con un certo grado di complessità.

Deploy – il file WAR

La specifica proposta da Sun non si limita a descrivere l’alberatura per la costruzione dell’applicazione, ma ci consente anche di avere un buon sistema per effettuare il deploy dell’applicazione utilizzando un singolo file, il file WAR.
Un file WAR, come sappiamo, viene generato attraverso il tool jar.exe contenuto nel JDK ed è pertanto un semplice file JAR rinominato.
Il fatto che sia un WAR e non un JAR, indipendentemente dal contenuto, gli permette di essere automaticamente riconosciuto come una vera e propria Web Application completa e dotata di vita propria, in questo modo l’application server sarà in grado di autoconfigurarsi sapendo che il WAR contiene esattamente quel tipo di struttura.

Per effettuare il deploy su Tomcat di un file WAR è sufficiente crearlo, dopo essersi posizionati all’interno della cartella “myapp”, attraverso il comando:

jar cvf myapp.war.

/

Dopo aver ottenuto il file myapp.war l’operazione di deploy si limita allo spostamento del file WAR all’interno della cartella webapps di Tomcat.
Subito dopo il restart dell’application server potremo vedere la nostra applicazione utilizzando il solito url:

http://localhost:8080/myapp/

/

Quando l’application server parte, si scompatta automaticamente il file WAR e si crea il context per poter raggiungere l’applicazione via http.

Utilizzando questo metodo di deploy la manutenzione si riduce ai tre passi seguenti:

  • creazione del nuovo file WAR
  • copia del nuovo WAR sulla macchina di test
  • eliminazione della vecchia alberatura estratta dal WAR precedente

Conclusioni

I vantaggi della seconda soluzione sono evidenti, è possibile effettuare un deploy su qualsiasi application server compatibile con le specifiche di Sun semplicemente copiando il file nella posizione giusta ed effettuando il restart.
Utilizzando il metodo tradizionale, invece, dovremmo verificare caso per caso qual è la procedura di creazione del context e specificando manualmente il CLASSPATH.

Credo che, a meno di condizioni particolari, la scelta del WAR sia la più interessante. Il vero problema è la migrazione di applicazioni scritte utilizzando strutture differenti. Spesso questa non è un’operazione banale, ma questa è un’altra storia.

L'autore

  • Massimo Canducci
    Massimo Canducci vanta oltre 25 anni di esperienza nel campo dell'innovazione e della digital transformation ed è Chief Innovation Officer per Engineering Ingegneria Informatica. È docente alla Singularity University, l'Università di Torino e l'Università di Pavia, e insegna in master MBA.

Iscriviti alla newsletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Immagine decorativa form newsletter
Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.