Introduzione Alle Applicazioni Web 1 2

Introduzione alle Applicazioni Web
A cura di: Andrea Viarengo

Data: 12/03/08
Revisione: 1.2
Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 1/43

Indice generale
1 INTRODUZIONE.........................................................................................................................................................3
2 IL PROTOCOLLO TCP/IP..........................................................................................................................................4
3 IL PROTOCOLLO HTTP............................................................................................................................................6
4 IL LINGUAGGIO HTML............................................................................................................................................8
5 I FOGLI DI STILE CSS.............................................................................................................................................10
6 IL SERVER HTTP......................................................................................................................................................12
7 IL BROWSER..............................................................................................................................................................13
8 L'INTERFACCIA CGI...............................................................................................................................................14
9 JAVASCRIPT...............................................................................................................................................................16
10 COOKIE.....................................................................................................................................................................19
11 SERVER STATICI E APPLICATION SERVER...................................................................................................20
12 GLI APPLICATION SERVER................................................................................................................................21
13 CENNI SULLA PROGRAMMAZIONE A OGGETTI.........................................................................................22
13.1 CLASSI ..................................................................................................................................................................22
13.2 OGGETTI.................................................................................................................................................................22
13.3 INCAPSULAMENTO.....................................................................................................................................................22
13.4 EREDITARIETÀ..........................................................................................................................................................22
13.5 POLIMORFISMO.........................................................................................................................................................23
14 IL LINGUAGGIO JAVA...........................................................................................................................................24
15 APPLET JAVA ..........................................................................................................................................................27
16 I SERVLET JAVA......................................................................................................................................................28
17 LE JAVA SERVER PAGES......................................................................................................................................29
18 GESTIONE DELLE SESSIONI..............................................................................................................................31
18.1 IL PROBLEMA...........................................................................................................................................................31
18.2 LE SOLUZIONI POSSIBILI.............................................................................................................................................31
18.3 SESSION MANAGEMENT..............................................................................................................................................33
19 IBM WEBSPHERE...................................................................................................................................................34
19.1 L'AMBIENTE DI SVILUPPO RATIONAL............................................................................................................................34
19.2 STRUTTURA DELL'APPLICAZIONE E DEPLOYMENT DESCRIPTOR...........................................................................................36
19.3 IL DEPLOYMENT DESCRIPTOR.......................................................................................................................................36
20 ESECUZIONE SUL SERVER DI TEST.................................................................................................................38
21 IL SERVER WEBSPHERE UFFICIALE...............................................................................................................41
21.1 AVVIO....................................................................................................................................................................41
21.2 STOP......................................................................................................................................................................41
21.3 CONTROLLARE I LOG.................................................................................................................................................41
21.4 FILE DELL'APPLICAZIONE INSTALLATA...........................................................................................................................41
22 IL DEPLOYMENT SUL SERVER UFFICIALE...................................................................................................42

1 Introduzione
Il presente documento è una “collezione” organizzata, riveduta e corretta di materiale di vario
genere recuperato in Internet, da utilizzare per un corso aziendale introduttivo (2-3 giorni) sugli
“Application Server”, in particolare rivolto alla tecnologia Java J2EE, e i relativi AS Tomcat e IBM
Websphere.

2 Il protocollo TCP/IP
• È uno dei protocolli di rete più diffusi al mondo; sul TCP/IP si basa la comunicazione fra i
nodi della rete Internet.
• Ad ogni nodo della Rete è assegnato un indirizzo IP univoco di 32 bit che permette di
identificare 2^32 nodi differenti corrispondenti a circa 4 miliardi di host, per semplicità,
normalmente si usa la notazione decimale puntata composta da quattro numeri compresi tra
0 e 254 (es.: 151.100.50.2).
• Mediante opportuni meccanismi (DNS) è possibile convertire gli IP address numerici in
indirizzi mnemonici (es.: 141.108.3.218 = www.google.it ).
• Sopra al protocollo TCP/IP possono viaggiare informazioni codificate secondo altri
protocolli di comunicazione (Telnet, FTP, HTTP, SMTP), tutti questi protocolli si basano
fondamentalmente sul protocollo telnet che permette di trasferire uno standard input ad un
computer remoto e ricevere come risultato uno standard output. Telnet è anche il nome del
programma client che permette di accedere in interattivo a dei servizi remoti.
• Un host remoto può fornire contemporaneamente diversi servizi, tutti accessibili tramite il
protocollo telnet, ma su porte (socket) diverse, ad esempio:
1. TELNET porta 23 (login remoto)
2. FTP porta 21 (gestione dischi remoti)
3. HTTP porta 80 (web)
4. SMTP porta 25 (Simple Mail Transfer Protocol)
La comunicazione in internet è diversa da quella telefonica (detta anche “commutata”, poiché

collega in modo “fisico” 2 punti della rete tramite appunto dei commutatori che instradano la
comunicazione), poiché gli host sono raggruppati in sottoreti, con una tipologia detta “a bus”
Quando un host inizia una comunicazione, spezzerà il file da trasmettere in pacchetti, e ad ogni
pacchetto farà precedente una intestazione contenente l'indirizzo del mittente e l'indirizzo del
destinatario, quindi invierà i pacchetti sul bus.
Tutti gli host della sottorete, saranno in ascolto e riceveranno tutti i pacchetti trasmetti,
controlleranno l'indirizzo del destinatario e se corrisponde al proprio, preleveranno il pacchetto,
viceversa lo scarteranno.
Questo sistema crea però dei problemi di sicurezza, perchè ciascun host nella sottorete può
“ascoltare” (con opportuni software) tutte le comunicazioni degli altri.

Con i protocolli TELNET, FTP, ma anche con l'HTTP, username e password viaggiano “in chiaro”,
percui e facile da un qualsiasi host della sottorete, “sniffare” queste informazioni.
Per questo motivo ultimamente si preferisce utilizzare altri protocolli più sicuri al posto di TELNET
e FTP, come SSH e SFTP che utilizzano Secure Sockets Layer (SSL) per criptare le informazioni
che transitano sulla rete, evitando così l'intercettazione da parte di altri host.
Per quanto riguarda il web, è stato introdotto il protocollo HTTPS che utilizza anch'esso un
meccanismo di crittografia di tipo Secure Sockets Layer (SSL) o Transport Layer Security (TLS)
La porta di default per un accesso di tipo https:// è la porta 443 (mentre per il protocollo http:// si
utilizza di default la porta 80).
Per impostare un web server in modo che accetti connessioni di tipo https, l'amministratore deve
creare un certificato digitale ovvero un documento elettronico che associa l'identità di una persona
ad una chiave pubblica.

3 Il protocollo HTTP
• HTTP = HyperText Transfer Protocol.
• Consente l'accesso a documenti ipertestuali in cui vengono realizzati dei link tra file di vario
genere (non solo testuali) fisicamente residenti anche su host differenti.
• È gestito da un software (server HTTP o demone HTTPD) residente sugli host che
intendono essere fornitori di informazioni. Chi vuole accedere alle informazioni fornite dal
server HTTP deve utilizzare un software client (browser) in grado di interpretare le
informazioni inviate dal server.
• HTTP è un protocollo "stateless": cioè senza memoria, ad ogni richiesta si effettua una
connessione al server che viene chiusa al termine del trasferimento dell'oggetto richiesto
(pagina HTML, immagine, ecc.).
• HTTP identifica le risorse in rete mediante URL (Universal Resource Locator):
Il servizio http è una sessione telnet sulla porta 80 esattamente come il servizio FTP è una sessione
telnet sulla porta 21.
Tramite il telnet posso inviare del testo al server che verrà interpretato secondo il protocollo http e
verrà fornita una risposta sullo standard output.
Il caso più semplice è il metodo GET che permette di recuperare una pagina web o un file dal
server, dopo metodo (che nel caso del http può essere uno tra GET, POST, HEAD, PUT, DELETE,
TRACE, OPTIONS) possono poi essere aggiunte delle informazioni opzionali.
la richiesta deve poi terminare con una riga vuota, cioè con due "a capo" consecutivi.
A questo punto il server risponderà con una riga di stato, una intestazione (header http) costituita da
una o più righe, e dopo una riga vuota che ne identifica l’inizio vero e proprio del corpo del
messaggio, il file richiesto.

Esempio di sessione http
$ telnet www.miosito.it 80
Connected to www.miosito.it port 80
GET /index.html HTTP/1.1

Connection: Keep-Alive
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: it
HTTP/1.0 200 OK
Date: Mon, 28 Jun 2004 10:47:31 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4
X-Powered-By: PHP/4.3.4
Vary: Accept-Encoding,Cookie
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: it
Content-Type: text/html; charset=utf-8
<html>
<head><title>Welcome to Mio sito</title></head>
<body>
<h1>Mio sito, web server del progetto </h1>
...
$ _
Nella risposta è molto importante la presenza della riga di stato e della direttiva Content-Type che
identifica il MIME type del file che segue, in pratica fa la veci dell'estensione usata sul filesystem,
questo permette al browser di interpretare in modo corretto il file e attivarsi di conseguenza, ad
esempio una pagina HTML deve essere preceduta dalla direttiva Content-Type: text/html; che
istruirà il browser a interpretare il testo seguente come codice HTML.
Altri MIME type molto utilizzati sono:
 text/html pagina html

 text/plain testo semplice
 application/octet-stream programma/file da scaricare
 application/zip file zip
 image/bmp immagine Bitmap
 image/jpg immagine Jpeg
 image/gif immagine gif

4 Il linguaggio HTML
• HTML = HyperText Markup Language
• È un semplice "linguaggio" di marcatura del testo, ereditato da SGML (Standard
Generalized Markup Language).
• Consente di esprimere dei collegamenti ad altri oggetti (pagine HTML, immagini, ecc.)
mediante URL.
• Consiste in un insieme di tag che consentono di caratterizzare porzioni di testo; è compito
del client (browser) l'interpretazione dei tag.
Esempio:
Il seguente codice HTML:
Verrà interpretato dal browser in questo modo:

5 I fogli di stile CSS
L'introduzione dei fogli di stile si è resa necessaria per separare i contenuti dalla formattazione e
permettere una programmazione più chiara e facile da utilizzare, sia per gli autori delle pagine
HTML che per gli utenti.
Il codice CSS permette di deswcrivere soltanto lo stile da applicare ai tag HTML, quindi colore,
spessore, carattere, dimensioni dei margini, etc.
L'inserimento di codice CSS nelle pagine web può essere effettuato in due modi:
• Inserendo nel tag <head> della pagina un collegamento ad un foglio di stile esterno, cioè
un file contrassegnato dall'estensione .css come negli esempi seguenti:
<html>
<head>
<title>Esempio</title>
<link rel="stylesheet" type="text/css" href="foglio_di_stile.css">
</head>
• Inserendo, sempre all'interno dell'<head> tra gli specifici tag <style> e </style> le
dichiarazioni css.
•
<html>
<head>
<title>Esempio</title>
<style type="text/css">
codice css
</style>
</head>
Le regole CSS sono strutturate secondo il seguente schema (gli spazi sono tutti facoltativi):
selettore {
proprietà1 : valore1;
proprietà2 : valore2, valore3;
}
E' anche possibile inserire le regole direttamente nei tag HTML usando l'attributo style:
<B style='font-size:12px; color:red;'>

Esempi di codice CSS:
h1 {font-weight: normal; font-size: 35px}
In questo caso la regola viene applicata a tutti gli oggetti <h1>
table.tab1 {
background-color: #a0a0a0;
color: black;
border-width: 1px 1px 1px 1px;
border-style: solid;
border-color: black;
padding-left: 10px;
padding-right: 10px;
padding-top: 10px;
padding-bottom: 5px;
font-size: 14px;
}
In questo secondo caso viene definita una classe tab1 applicabile solo agli oggetti table con la
sintassi HTML:
<table class='tab1'>

6 Il server HTTP
• È un programma che "gira" su un server in attesa di una richiesta di connessione sul suo
socket (la porta assegnatagli, tipicamente la 80).
• Svolge tre compiti fondamentali:
1. invia al client le risorse disponibili localmente, richieste mediante l'indicazione di
una URL;
2. richiama eventuali procedure esterne con cui comunica mediante l'interfaccia CGI
(Common Gateway Interface) per lo scambio di parametri e per ottenere in risposta
informazioni in formato HTML;
3. effettua, ove esplicitamente richiesto dalla sua configurazione, l'autenticazione degli
utenti mediante username e password.
• Il server HTTP svolge quindi un ruolo di interfaccia tra il client remoto che effettua delle
richieste sul socket ed il sistema che lo ospita, il suo filesystem ed altri programmi che
girano sulla macchina server.
I server http (chiamati anche server Web) più noti sono:
• Apache di Apache Software Foundation

• Microsoft Information Services IIS
• IBM Lotus Domino

7 Il browser
• Il browser è l'applicazione client di questo sistema ad architettura "client/server".
• Gira sulla macchina dell'utente remoto, legge ed interpreta l'output in formato HTML.
• Visualizza o gestisce le informazioni codificate in formati a lui noti (es.: immagini GIF o
JPEG, filmati QuickTime, scene VRML) e rimanda ad altri programmi esterni presenti sulla
macchina client per la gestione di formati non conosciuti (es.: documenti Word, documenti
Postscript, ecc.).
• Le procedure CGI non vengono eseguite sulla macchina client.
• I programmi in linguaggio Java vengono invece scaricati sul client, compilati in tempo reale
ed eseguiti su di esso.
• Il browser consente di impaginare l'output indipendentemente dalla piattaforma che lo ospita
(X11, Macintosh, Windows, ecc.).
I Browser più utilizzati sono:
• Mozilla Firefox (l’erede di Netscape)

• Microsoft Internet Explorer
• Opera
• Apple Safari

8 L'interfaccia CGI
Ogni volta che un client richiede al web-server un URL corrispondente ad un documento in puro
HTML gli viene restituito un documento statico (come un file di testo); se l'URL corrisponde invece
ad un programma CGI, il server lo esegue in tempo reale, generando dinamicamente informazioni.
Un programma (o uno script) CGI può essere scritto in qualsiasi linguaggio di programmazione (C,
C++, Perl, PHP, Visual Basic, Java, ecc.), la scelta si basa sul sistema su cui girerà; il Perl, il PHP ,
Java e l'ASP sono comunque i linguaggi più comunemente utilizzati.
CGI = Common Gateway Interface
È il canale di comunicazione tra il server HTTP (le pagine HTML) e le procedure software che
girano sul sistema (procedure e script CGI).
Consente di passare dei parametri ad un programma esterno attraverso una form o una semplice
URL. Consente anche di catturare l'output della procedura (tipicamente in formato HTML) e di
inviarlo al client dell'utente remoto.
I metodi per il passaggio dei parametri alla procedura esterna sono due:
GET: tramite variabile di ambiente (QUERY_STRING);
POST: tramite lo standard input.
Il metodo utilizzato viene comunicato alla procedura CGI mediante la variabile di ambiente
REQUEST_METHOD.
Uno script CGI può essere richiamato mediante una form HTML:
che verrà visualizzato dal browser nel seguente modo:

Oppure mediante una URL diretta (il passaggio dei parametri avviene implicitamente con il metodo
GET):
<A HREF="/cgi-bin/search.cgi?nome=Marco&eta=28">Richiesta</A>
La stessa richiesta può essere fatta anche direttamente dalla barra degli indirizzi del browser,
utilizzando la seguente sintassi:
http://miosito/cgi-bin/search.cgi?nome=Marco&eta=28
In questo caso, search.cgi non corrisponderà ad una pagina HTML statica memorizzata sul server,
bensì ad un qualche applicativo che verrà eseguito sul server, gli verranno passati i parametri
nome=Marco ed eta=28 e in funzione di questi genererà sul suo standard output del codice HTML
che verrà poi interpretato dal browser.

9 Javascript
Il codice HTML non è un linguaggio di programmazione, bensì un linguaggio descrittivo, in pratica
“descrive” come deve essere “disegnata” un a pagina Web.
In seguito alla definizione del HTML, si è visto che sarebbe stato utile disporre della possibilità di
eseguire dei semplici programmi (script) da parte del browser per migliorare l'interattività delle
pagine web, come ad esempio:
controllare i valori nei campi di ingresso prima di inviare i dati al server
● preimpostare i valori dei form
● moficare al volo il contenuto dei menù a tendina
● visualizzare pulsanti e link che si evidenziano quando il mouse gli passa sopra
● visualizzare news scorrevoli
● creare calendari per selezionare una data
Per questi motivi è stata aggiunta la possibilità di includere nelle pagine HTML delle sezioni
contenenti del codice che permette di interagire con gli oggetti grafici (e solo con quelli)
visualizzati dal browser.
Il codice JavaScript, integrato in un browser Web, si collega tramite classi di oggetti chiamate DOM
(Document Object Model) che permettono di accedere a tutti gli elementi grafici rappresentati in
una pagina web. Sfortunatamente, i DOM dei vari browser non sono standardizzati: browser diversi
espongono diversi oggetti o metodi allo script, ed è quindi spesso necessario scrivere differenti
versioni di una funzione JavaScript per ciascuno dei browser.
uno script può essere inserito in due modi all'interno di pagina HTML:
● Usando un file contenente uno script esterno (con estensione .js)
● Includendo direttamente il codice javascript nel codice HTML all'interno dei tag
<script></script>
Esempio di inclusione javascript con un file esterno
<SCRIPT Language=Javascript src="nomefile.js"></SCRIPT>
Esempio di sezione javascript in un file HTML
<script type="text/javascript">
alert("Messaggio");
</script>

L'esecuzione del codice javascript può essere scatenata da una serie di eventi, gli eventi vengono
inseriti come attributi dei tag HTML, in questo modo:
<img src=/images/button.gif onMouseOver=changeButtonImage(this) >
Dove onMouseOver è l'evento che scatena l'esecuzione dalla funzione javascript

changeButtonImage()
I principali eventi utilizzabili sono:
onLoad: attivato al caricamento di oggetti, per lo più finestre e immagini;

onClick: attivato quando si clicca su un oggetto;
onDblClick: attivato con un doppio click;
onMouseDown: attivato quando si schiaccia il tasto sinistro del mouse;
onMouseUp: attivato quando si alza il tasto sinistro del mouse precedentemente
schiacciato;
onContextMenu: attivato quando si clicca il tasto destro del mouse aprendo il ContextMenu.
OnMouseOver: attivato quando il mouse si muove su un oggetto;
onMouseOut: attivato quando il mouse si sposta da un oggetto;
onMove: attivato quando un oggetto muove una finestra o un frame;
onDrag: attivato quando il mouse trascina un oggetto o una selezione di testo nella
finestra dello stesso browser o anche di un altro o anche sul Desktop;
onKeyPress: attivato quando un utente preme e rilascia un tasto o anche quando lo tiene
premuto;
onKeyDown: attivato quando viene premuto il tasto;
onKeyUp: attivato quando un tasto, che era stato premuto, viene rilasciato;
onHelp: attivato quando un utente preme il tasto F1;
onChange: attivato quando il contenuto di un campo di un form o modulo è modificato o
non è più selezionato.

Esempio di funzione di validazione dei form
<html>
<body>
<form name="myForm" method="POST" action="/bin/send.cgi">

<input type="text" value="Enter email address" name="userEmail"
onChange=validateInput(this.value) />
<input type="submit" name="Invia">
</form>
<script type="text/javascript">
this.myForm.userEmail.focus();
this.myForm.userEmail.select();
function validateInput()
{
userInput = new String();
userInput = this.myForm.userEmail.value;
if (userInput.match("@"))
alert("Thanks for your interest.");
else
alert("Please check your email details are correct before submitting");
}
</script>
</body>
</html>
Il Javascript ha in comune con Java solo la sintassi.

Il codice è interpretato ed eseguito dal Browser, da notare che è possibile utilizzare anche altri
linguaggi diversi da Javascript, come VBScript di Microsoft e TCL.

10 Cookie
I cookie (letteralmente biscottini) sono piccoli file di testo che i siti web utilizzano per
immagazzinare alcune informazioni nel computer dell'utente.
I cookie sono inviati dal sito web e memorizzati sul computer. Sono quindi re-inviati
(nell'intestazione del protocollo http) al sito web al momento delle visite successive.
Le informazioni all'interno dei cookie sono spesso codificate e non comprensibili.
le applicazioni più comuni vanno dalla memorizzazione di informazioni sulle abilitazioni dell'utente
alla tracciatura dei movimenti dell'utente stesso all'interno dei siti web che visita.
Tali applicazioni hanno spesso sollevato dubbi da parte dei difensori della privacy dei navigatori,
infatti un cookie potrebbe aiutarci nella navigazione oppure spiarci. In questo secondo caso
rientrano molte catene di pubblicitari (che vendono pubblicità a molti siti differenti) i quali usano
un cookie accluso all'immagine pubblicitaria per correlare le visite di uno stesso utente a più siti
diversi, costruendo quindi una specie di profilo dei siti più graditi.
Ad esempio il motore di ricerca più famoso del mondo, Google, spedisce un cookie che
immagazzina dati riguardanti le ricerche, le parole chiave delle ricerche e le abitudini dell'utente.
Più in dettaglio i diversi utilizzi dei cookie sono dunque:

● Per riempire il carrello della spesa virtuale in siti commerciali (i cookie ci permettono di
mettere o togliere gli articoli dal carello in qualsiasi momento).
● Per permettere ad un utente il login in un sito web.
● Per personalizzare la pagina web sulla base delle preferenze dell'utente (per esempio il
motore di ricerca Google permette all'utente di decidere quanti risultati della ricerca voglia
visualizzare per pagina).
● Per tracciare i percorsi dell'utente (tipicamente usato dalle compagnie pubblicitarie per
ottenere informazioni sul navigatore, i suoi gusti le sue preferenze. Questi dati vengono usati
per tracciare un profilo del visitatore in modo da presentare solo i banners pubblicitari che
gli potrebbero interessare).
● Per la gestione di un sito: i cookie servono a chi si occupa dell'aggiornamento di un sito per
capire in che modo avviene la visita degli utenti, quale percorso compiono all'interno del
sito. Se il percorso porta a dei vicoli ciechi il gestore se ne può accorgere e può migliorare la
navigazione del sito.

11 Server Statici e Application Server
Quando si accede ad un sito internet o intranet è impossibile distinguere delle pagine generate da
un server "statico" da quelle generate da una Web application.
La differenza sta nell'origine di quelle pagine. Nel primo caso le pagine sono file statici (file
.html) che vengono semplicemente prelevati dal server e visualizzati nel browser. Nel caso di Web
application, invece, le pagine vengono costruite dinamicamente al tempo della chiamata da un
programma che gira sul server e che può essere scritto in qualsiasi linguaggio.
Ma perché realizzare un'applicazione Web e non un semplice sito statico?
Perché le Web application permettono di fare molto di più. Come farebbe un sito statico a prendere
le vostre username e password, controllare che siano corrette, recuperare da un database i vostri
messaggi e visualizzarli a video dividendoli 10 per pagina? Come farebbe un sito statico a
permettervi di rilanciare sull'asta dell'ultimo cd del vostro cantante preferito fino alla cifra massima
da voi impostata?
Una Web application lo può fare e ci può aiutare a risolvere problemi anche molto più complessi.
Essa è composta in genere da una serie di algoritmi che vengono eseguiti sul server e che generano
l'output desiderato.

12 Gli Application Server
Le 2 famiglie più diffuse che si contendono la supremazia del Web sono Java e DotNet.
Le due tecnologie hanno parecchio in comune, questo anche perché il Framework .NET ed i relativi
linguaggi di programmazione sono stati sviluppati molto dopo la nascita di Java
Scegliere una piattaforma infatti non significa solo scegliere un linguaggio di programmazione, ma
anche tutto ciò che lo circonda. Chi usa la tecnologia Microsoft .NET e C#, ad esempio, avrà a che
fare con il Framework .NET, con il Web server IIS e con tutte le estensioni (o filtri) ISAPI che gli
permettono di svolgere le funzioni di application server. In questo caso, sarà configurato il filtro
ISAPI per le applicazioni scritte nei linguaggi per DotNet.
Chi invece predilige J2EE ha una gamma più larga di scelte. Infatti esistono versioni della JVM sia
per Windows sia per Linux ed anche il principe degli AS, Jakarta Tomcat, è disponibile per
entrambi i sitstemi operativi. Inoltre possiamo scegliere di usare Tomcat in coppia con IIS o Apache
su sistemi Microsoft o su Apache per sistemi Linux.
Questo application server open source è usato per quasi il 70% dei server della rete mondiale ed è la
soluzione ottimale per chi sceglie di utilizzare Java e JSP per realizzare il codice delle pagine Web e
della logica.
Il punto forte della coppia Apache-Tomcat sta nel fatto che, essendo open source, vantano sul
supporto delle migliaia di comunità di sviluppatori online sparsi nei cinque continenti.
Websphere di IBM si basa su Apache Geronimo che è un Application Server Opensource sviluppato
dalla Apache Software Foundation basato sulle specifiche J2EE 5.0.

13 Cenni sulla programmazione a oggetti
La programmazione orientata agli oggetti (OOP, Object Oriented Programming) è un paradigma
di programmazione, che prevede di raggruppare in un'unica entità (la classe) sia le strutture dati che
le procedure che operano su di esse, creando per l'appunto un "oggetto" software dotato di proprietà
(dati) e metodi (procedure) che operano sui dati dell'oggetto stesso.
13.1 Classi
Le classi sono uno strumento per costruire strutture dati che contengano non solo dati ma anche il
codice per gestirli.
Come tutti i costrutti che permettono di definire le strutture dati, una classe definisce un nuovo tipo
di dato.
I membri di una classe sono:
● attributi (dati, esattamente come i membri di un record)
● metodi (procedure che operano su un oggetto)
13.2 Oggetti
Un oggetto è una istanza di una classe. Un oggetto occupa memoria, la sua classe definisce come
sono organizzati i dati in questa memoria.
Ogni oggetto possiede tutti gli attributi definiti nella classe, ed essi hanno un valore, che può mutare
durante l'esecuzione del programma come quello di qualsiasi variabile.
Sintatticamente, i metodi di una classe vengono invocati "su" un particolare oggetto, e ricevono
come parametro implicito l'oggetto su cui sono stati invocati. Questo parametro normalmente può
essere referenziato esplicitamente; per esempio, a tale scopo in C++, in Java, e in C# si usa la parola
chiave this
Gli oggetti effettivamente creati sono membri dell'insieme definito dalla loro classe.
Molti linguaggi forniscono un supporto per l'inizializzazione automatica di un oggetto, con uno o
più speciali metodi detti costruttori. Analogamente, la fine della vita di un oggetto può essere
gestita con un metodo detto distruttore.
13.3 Incapsulamento
L'incapsulamento è la proprietà per cui un oggetto contiene ("incapsula") al suo interno gli attributi
(dati) e i metodi (procedure) che accedono ai dati stessi. Lo scopo principale dell'incapsulamento è
appunto dare accesso ai dati incapsulati solo attraverso i metodi definiti, nell'interfaccia, come
accessibili dall'esterno. Gestito in maniera intelligente, l'incapsulamento permette di vedere
l'oggetto come una black-box, cioè una scatola nera di cui, attraverso l'Interfaccia sappiamo cosa fa
e come interagisce con l'esterno ma non come lo fa (o per lo meno non ci interessa).
13.4 Ereditarietà
L'OOP prevede un meccanismo molto importante, l'ereditarietà, che permette di derivare nuove
classi a partire da classi già definite. L'ereditarietà permette di aggiungere membri ad una classe, e
di modificare il comportamento dei metodi, in modo da adattarli alla nuova struttura della classe.
Da una stessa classe è possibile costruire diverse classi derivate. Da una classe derivata è possibile
derivarne un'altra con lo stesso meccanismo.

Sintatticamente, una classe può essere definita come derivata da un'altra classe esistente. In molti
linguaggi la classe derivata, o sottoclasse, eredita tutti i metodi e gli attributi della classe
"genitrice", e può aggiungere membri alla classe, sia attributi che metodi, e/o ridefinire il codice di
alcuni metodi.
L'ereditarietà può essere usata come meccanismo per gestire l'evoluzione ed il riuso del software: il
codice disponibile definisce delle classi, se sono necessarie modifiche, vengono definite delle
sottoclassi che adattano la classe esistente alle nuove esigenze.
13.5 Polimorfismo
La possibilità che le classi derivate implementino in modo differente i metodi e le proprietà dei
propri antenati rende possibile che gli oggetti appartenenti a delle sottoclassi di una stessa classe
rispondano diversamente alle stesse istruzioni. Ad esempio in una gerarchia in cui le classi Cane e
Gatto discendono dalla SuperClasse Animale potremmo avere il metodo mangia() che restituisce la
stringa "osso" se eseguito sulla classe Cane e "pesce" se eseguito sulla classe Gatto. I metodi che
vengono ridefiniti in una sottoclasse sono detti "polimorfi", in quanto lo stesso metodo si comporta
diversamente a seconda del tipo di oggetto su cui è invocato.
Normalmente nei linguaggi che supportano i tipi non è possibile assegnare ad una variabile di un
tipo una di un'altro tipo, la OOP, grazie al polimorfismo, fa un deroga a questa regola, poiché ad una
variabile di un certa classe posso anche assegnare tutte le variabili delle classi derivate.
Forma a,b,c;
Quadrato q1; //Quadrato deriva Forma
QuadratoOmbreggiato q2; //QuadratoOmbreggiato deriva da Quadrato
Cerchio c1; //Cerchio deriva da Forma
.......
a=q1;
b=q2;
q1=q2;
c=c1;
........
a.draw();
/* questa istruzione potrebbe potenzialmente disegnare
* un quadrato, un cerchio, o un quadrato ombreggiato,
* dipende dalla “storia” che ha avuto la variabile 'a'

14 Il linguaggio Java
Le principali caratteristiche del linguaggio Java sono:
Sintassi: è simile a quella del C e del C++, e questo non può far altro che facilitare la migrazione
dei programmatori da due tra i più importanti ed utilizzati linguaggi esistenti.
Gratuito: per scrivere applicazioni commerciali non bisogna pagare licenze a nessuno. Sun ha
sviluppato questo prodotto e lo ha migliorato usufruendo anche dell’aiuto della comunità "open-
source".
Robustezza: essa è derivante soprattutto da una gestione delle eccezioni chiara e funzionale, e ad
un meccanismo automatico della gestione della memoria (Garbage Collection) che esonera il
programmatore dall’obbligo di dover deallocare memoria quando ce n’è bisogno. Inoltre il
compilatore Java, è molto "severo". Il programmatore è infatti costretto a risolvere tutte le situazioni
"poco chiare", garantendo al programma maggiori chance di corretto funzionamento.
Libreria e standardizzazione: Java possiede una enorme libreria di classi standard che forniscono
al programmatore la possibilità di operare su funzioni comuni di sistema come la gestione delle
finestre, dei collegamenti in rete e dell’input/output.
Indipendenza dall’architettura: grazie al concetto di macchina virtuale ogni applicazione, una
volta compilata, potrà essere eseguita su di una qualsiasi piattaforma (per esempio un PC con
sistema operativo Windows o una workstation Unix). Questa è sicuramente la caratteristica più
importante di Java.
Java Virtual Machine: Ciò che rende possibile di fatto l’indipendenza dalla piattaforma è la Java
Virtual Machine, un software che svolge un ruolo da interprete (ma non solo) per le applicazioni
Java.
Compilando un programma Java non si ottiene un file eseguibile (ovvero la traduzione in
linguaggio macchina del file sorgente “.java”), ma un file che contiene la traduzione del nostro
listato in un linguaggio molto vicino al linguaggio macchina detto "byte code"; questi file hanno
normalmente estensione “.class”.
Una volta ottenuto questo file dobbiamo interpretarlo. A questo punto la J.V.M. interpreterà il byte
code ed il nostro programma andrà finalmente in esecuzione.
In realtà, nelle ultime versioni della JVM viene effettuata una compilazione Bytecode-linguaggio
Macchina “Just-in-Time” per migliorare le prestazioni a discapito di una maggiore lentezza
nell'avvio dell'applicazione.
Si parla di "macchina virtuale" perché in pratica questo software è stato implementato per simulare
un hardware completo e non solo una CPU. Si potrebbe affermare che il linguaggio macchina sta ad
un computer come il byte code sta ad una Java Virtual Machine.
Multithreaded: Oltre che permettere l’indipendenza dalla piattaforma, la J.V.M. permette a Java di
essere un linguaggio multithreaded (caratteristica di solito dei sistemi operativi), ovvero capace di
mandare in esecuzione più processi in maniera parallella.
Orientato agli oggetti: Java ci fornisce infatti degli strumenti che praticamente ci "obbligano" a
programmare ad oggetti.

Sicurezza: ovviamente, avendo la possibilità di scrivere applicazioni interattive in rete, Java
possiede anche delle caratteristiche di sicurezza molto efficienti.
Nella Figura è illustrato il flusso dei dati e i controlli del sistema Java, controlli fatti attraverso il
compilatore Java, il caricatore di bytecode, il verificatore di bytecode e quindi l’interprete Java.
Java è un linguaggio orientato agli oggetti, ciascun oggetto è dichiarato con la parola chiave class,
un file .java può contenere solo una classe e il file deve avere lo steso nome della classe.
La classe è poi divisa in attributi (necessari a memorizzare i dati del oggetto) e metodi, che sono le
funzioni che permettono di operare sugli attributi.
Gli attributi di norma sono dichiarati privati e i metodi pubblici, definendo l'interfaccia che
permette di operare sull'oggetto.
Le classi sono poi raccolte in package, per utilizzare un particolare package bisogna importarlo con
l'istruzione import.
Java è fornita da un'ampia libreria di package, i principali sono:

 java.io definisce classi per le operazioni di imput output, acceso al filesystem,...
 java.util classi di utilità generale
 java.lang classi relative al linguaggio
 java.text classi per la conversione di testo
 java.math classi per le operazioni matematiche
 java.net classi per l'accesso in rete
Esempio di classi java

import ...
public abstract class Forma {

private int x;
private int y;
private int w;
private int h;
public Forma() { //Questo è il metodo Costruttore

x=0; y=0; w=0; h=0;}
public setBound(x,y,w,h) {
this.x=x; this.y=y; this.w=w; this.h=h; }
public abstract draw(); //metodo da implementare

}
public class Rettangolo extends Forma {

public Rettangolo() {
super(); }
public draw() {
//disegna un quadrato
}
}
Per usare la classe Rettangolo:
Rettangolo rettangolo1=new Rettangolo();

Rettangolo rettangolo2=new Rettangolo();
rettangolo1.setBound(10,10,100,150);
rettangolo1.setBound(60,80,200,100);
rettangolo1.draw();
rettangolo2.draw();

15 Applet Java
Gli applet Java sono programmi scritti in linguaggio Java che possono essere eseguiti da un Web
browser. Gli applet appaiono visivamente collocati all'interno di pagine Web (devono avere un'area
rettangolare ben definita), e sono solitamente usati per creare pagine dotate di funzioni interattive
non realizzabili con altre tecnologie per il Web.
I Java applets vengono eseguiti dai web browser utilizzanti la Java virtual machine (JVM), o in
alternativa possono essere eseguiti utilizzando il Sun AppletViewer, un programma nato per testare
gli applet.
Gli Applet sono utilizzati per fornire contenuti interattivi alla pagine web che il linguaggio HTML
non è in grado di fornire, in modo un po' più sofisticato di quanto si possa fare utilizzando solo
Javascript..
La maggioranza dei Web Browser utilizzano una sandbox per eseguire gli Applet in modo da
impedire a questi di accedere alle informazioni salvate in locale sul computer. Il codice degli Applet
viene scaricato dal web server nel web browser. Quest'ultimo riceve insieme all'Applet anche la
pagina html che lo contiene.
In alternativa l'Applet può provvedere ad aprire una finestra personale senza doversi appoggiare a
codice html per mostrare l'interfaccia grafica. Gli Applet che vengono mostrati nelle pagine web
vengono identificati dal tag html applet. Questo specifica la posizione del sorgente dell'Applet da
scaricare. Dato che il bytecode Java è indipendente dalla piattaforma gli Applet Java possono essere
eseguiti dai browser delle principali piattaforme senza problemi.
Codice java dell'applet
import java.applet.*;
import java.awt.*;
public class FirstApplet extends Applet{

public void paint(Graphics g){
g.drawString("Welcome in Java Applet.",40,20);
}
}
Pagina HTML che contiene l'applet
<HTML>
<HEAD>
</HEAD>
<BODY>
<APPLET
ALIGN="CENTER"
CODE="FirstApplet.class"
WIDTH="800"
HEIGHT="500">
</APPLET>
</BODY>
</HTML>

16 I Servlet java
Un servlet non è altro che un'applicazione Java in esecuzione su una JVM (Java Virtual Machine)
residente su un server. Questa applicazione tipicamente esegue una serie di operazioni che
producono in output un codice HTML che verrà poi inviato direttamente al client per venire
interpretato da un qualsiasi Browser che non necessita di funzionalità aggiuntive.
A differenza di uno script CGI i servlet vengono caricati solo una volta, al momento della prima
richiesta, e rimangono residenti in memoria pronti per servire le richieste fino a quando non
vengono chiusi, con ovvi vantaggi in fatto di prestazioni (risultano infatti un po' più lenti in
caricamento, ma una volta "aperti" le successive richieste vengono evase molto velocemente).
Di seguito un esempio di Servlet che implementa il metodo doGet che risponde ad una richiesta di
un browser (http://mioserver/MioServlet) scrivendo “Ciao Mondo” nella finestra del browser.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class MioServlet extends HttpServlet{
public void doGet(HttpServletRequest request,HttpServletResponse response)

throws IOException,ServletException {
PrintWriter out = response.getWriter();

out.println("Ciao Mondo");
}
}

17 Le Java Server Pages
La tecnologia Java Server Pages è una soluzione multipiattaforma per realizzare pagine HTML
dinamiche, dal lato server.
Le pagine JSP sono un'evoluzione dei già collaudati servlet Java, create per separare i contenuti
dalla loro presentazione: una pagina JSP si presenta, infatti, come un normale documento in
linguaggio HTML, frammentato da sezioni di codice Java. Si potranno quindi modificare le parti
sviluppate in Java lasciando inalterata la struttura HTML o viceversa.
Una Java Server Page possono essere invocate (richiamate) utilizzando due diversi metodi: la
richiesta può venire effettuata direttamente ad una pagina JSP, che grazie alle risorse messe a
disposizione sul lato server, è in grado di elaborare i dati di ingresso per ottenere e restituire l'output
voluto, oppure la richiesta può essere fatta in un primo tempo ad un servlet che, dopo l'elaborazione
dei dati, incapsula adeguatamente i risultati e richiama la pagina JSP. Sarà poi quest'ultima che, in
grado di prelevare i dati immagazzinati, produrrà l'output voluto.
Un primo esempio di Java Server Page potrebbe essere rappresentato dalla semplice stampa a
video di un messaggio ("PRIMA PROVA JSP"), implementato in questo modo:


<HTML>
<BODY>
<% out.println("PRIMA PROVA DI JSP"); %>
<% String testo=”<h1>Titolo</h1>” %>
<%=testo %>
</BODY>
</HTML>
Come si può notare le sezioni racchiuse tra i tag <% e %> sono quelle che contengono le istruzioni
in linguaggio Java (gli stessi tag sono utilizzati anche nelle pagine ASP). Da notare che i file per
essere riconosciuti dal browser come pagine JSP devono essere salvati con estensione .jsp.
La sezione <%= %> invece valuta un espressione e il risultato viene sostituito a tutta l’espressione
<%= %>
La prima volta che si effettua la richiesta di visualizzazione del file, quest'ultimo viene compilato,
creando un oggetto servlet, che sarà archiviato in memoria (per servire le richieste successive); solo
dopo questi passaggi l'output viene mandato al browser, che potrà interpretarlo come fosse una
semplice pagina HTML.

Ad ogni richiesta successiva alla prima il server controlla se sulla pagina .jsp è stata effettuata
qualche modifica, in caso negativo richiama il servlet già compilato, altrimenti si occupa di eseguire
nuovamente la compilazione e memorizzare il nuovo servlet.

18 Gestione delle Sessioni
Come è già stato detto in precedenza, Il protocollo HTTP è “senza memoria” (stateless)
Ogni richiesta è indipendente dalle altre, e non può “ricordare” il percorso precedente di un utente.
Le variabili di input di ogni pagina possono dipendere solamente dai FORM nella pagina
precedente.
Gli utenti, invece, vorrebbero avere l’impressione di una navigazione continua, in cui una scelta
compiuta in una pagina venga “ricordata” in tutte le pagine successive.
È necessario costruire una astrazione di una sessione di navigazione.
Sessione = sequenza di pagine, visitata sullo stesso sito dallo stesso utente con lo stesso browser
nella stessa seduta di navigazione, che presentino una consequenzialità logica.
18.1 Il problema
L’utente inserisce i propri username e password sulla prima pagina che visita
La pagina successiva sarà necessariamente una pagina dinamica che “valida” il login
Tutte le pagine successive dovranno conoscere il nome dell’utente e generare le pagine successive
di conseguenza, mostrando solo i dati a cui l'utente può accedere.
18.2 Le soluzioni possibili

● Variabili nascoste nei FORM
● URL rewriting
● Cookie
● Session management
18.2.1 Variabili nascoste nei FORM

In ogni FORM, è possibile aggiungere delle variabili nascoste
<input type="hidden" name="user" value="andrea">
Non visibile dall’utente, non modificabile dall’utente (a meno di visualizzare il codice HTML della
pagina)
Occorre ripetere tutte le variabili comuni a più pagine come parametri nascosti in tutti i form
Occorre fare sì che tutti i passaggi di pagina siano sotto forma di invio di form (quindi non sono
permessi semplici link <a href="...">)

18.2.2 URL rewriting
Si può modificare il testo dei link tra le pagine per passare continuamente, in modalità GET, le
variabili desiderate <a href="posta.php?user=xyz>
Occorre modificare tutti i link con la strategia sopra detta.
Ovviamente in questo caso, nascono dei problemi di sicurezza, poiché, utilizzando un url come
quello descritto sopra, “invoglierebbe” l'utente a modificare l'indirizzo in
http://www.miosito.it/posta.php?user=abc
diventando “magicamente” l'utente “abc” e by-passando ogni fase di autenticazione.

Volendo usare questa tecnica è opportuno non utilizzare nomi utenti in chiaro (e neanche nomi
variabili tipo user, username, utente etc.),anzi la cosa migliore da fare è quella di utilizzare una
variabile di sessione con un numero di sessione (che cambia per ogni login) a cui il server
internamente associa la variabile user il cui contenuto è memorizzato sul server e accessibile solo ad
esso (vedi più avanti, session managment) .
18.2.3 Cookie
Nella risposta http il server aggiunge un comando di intestazione “set cookie”
Il browser si impegna a restituire al server il cookie ad ogni nuova richiesta http che farà
Esempio: Nome: “user”, valore: “andrea”, scadenza: “1400”, dominio: “miosito.it”
In pratica quando la pagina di login valida la password, può settare un cookie sul browser
La pagine successive possono leggere il cookie, che il server riceverà nuovamente dal browser
Tra le alternative viste, questa è la più conveniente è poiché:

● È sufficiente fare una sola setcookie all’inizio
● È possibile settare più cookie relative a diverse variabili
● Non occorre modificare né i link esistenti né i form esistenti
Svantaggi:
● Non è possibile memorizzare informazioni voluminose
● Non è “educato” memorizzare molti cookie diversi
● Non è consigliabile fidarsi dei dati memorizzati sul browser dell’utente
● È possibile che il browser rifiuti di restituire i cookie memorizzati

18.3 Session management
Invece che recuperare tutte le variabili di stato con i metodi descritti prima, è più opportuna usare
una sola variabile di sessione memorizzando un “numero magico”, diverso per ogni nuova sessione
nome="session" value="123456"
Il server memorizza, da qualche parte, tutte le variabili di sessione associate al numero magico.
Session=123456 ⇒ "user" = "andrea"

Session=123456 ⇒ "color" = "blue"
Session=123456 ⇒ "language" = "IT"
Session=123456 ⇒ "profile" = "admin"
queste informazioni possono essere memorizzato nella memoria del web server, oppure in un file
privato del server, oppure in una tabella di database (Session, Name, Value).

19 IBM Websphere
IBM Websphere è un Application Server molto potente sviluppato da IBM, basato sulla tecnologia
J2EE. Ne esiste anche una versione gratuita denominata WASCE (WebSphere Application Server
Comunity Edition)
● http://www.ibm.com/websphere/wasce/
● http://www-306.ibm.com/software/webservers/appserv/community/
19.1 L'ambiente di sviluppo Rational

Rational è l'ambiente di sviluppo per Websphere rilasciato da IBM; ne esiste anche una versione
open-source liberamente scaricabile denominata Eclipse. Lanciamo il file "rational.exe" e dopo la
visualizzazione dello Splash Screen dell'applicazione, apparirà la seguente finestra di dialogo:
Figura 1. Selezionare un workspace
All'interno del campo di testo contrassegnato dalla etichetta Workspace andrà specificata la
directory (comprensiva del path) che Rational utilizzerà per salvare i propri progetti.
È possibile accettare quella fornita per default oppure modificarla a proprio piacimento.
Attraverso la check box in basso alla finestra di dialogo sarà, quindi, possibile scegliere se utilizzare
la medesima directory per tutti i progetti evitando di sceglierla di volta in volta.
Una volta ultimata la selezione del workspace, verrà visualizzata una schermata di benvenuto.

Figura 2. Schermata di benvenuto
Da questa schermata, selezionando l'icona contrassegnata dalla descrizione "Workbench", sarà

possibile accedere all'ambiente di sviluppo vero e proprio:
Menu delle
Prospettive
Navigator Java Editor

View
Console dei
Messaggi
Figura 3. L'ambiente di sviluppo
L’interfaccia grafica di rational è organizzata a prospettive. Le prospettive non sono altro che dei
raggruppamenti di funzionalità dell’IDE, fatti in base ad una specifica operazione di sviluppo. La
Java perspective ad esempio riunisce strumenti di stesura e organizzazione del codice mentre la
Debug perspective fornisce strumenti in fase di debug.
La prospettiva che interesserà a noi è quella denominata J2EE.

Ogni prospettiva è costituita da più viste.
Le viste sono “riquadri” organizzati in schede che offrono supporto per organizzare e stendere il
codice. Ci sono tre gruppi schede che possono ospitare le viste:
● Navigatori (tra i file o tra i metodi Java)

● Editor (Java/Html/text)
● Browser
● Console dei messaggi
Le varie viste possono essere spostate da un gruppo all’altro mediante semplice trascinamento della
scheda sul nuovo gruppo.
Le viste sono molto numerose. Per aggiungerne di nuove occorre accedere al menù
“Finestra->Mostra Viste”.
19.2 Struttura dell'applicazione e deployment descriptor

Tutti i file necessari sono inseriti in una cartella che segue la struttura standard dettata dalla
specifica J2EE.
Ogni applicazione web J2EE al di sotto della cartella in cui viene installata (Progetti Web Dinamici)
rispetta la seguente struttura:
• MyApp: Una cartella che costituisce la root dell'applicazione. Al di sotto della cartella root
viene inserite le seguenti voci:
• Descrittore di distribuzione
• Java resources
• Web Content
• Tutto il contenuto statico dell'applicazione (pagine HTML, javascript, css, etc) organizzato
come si vuole, e tutte le pagine JSP anch'esse in cartelle strutturate a piacere,
vengonoincluse nella cartella WebContent che a sua volta contiene le cartelle:
• WEB-INF contenente le classi compilate (sotto la cartella classes) e i jar delle

eventuali librerie (cartella lib)
• META-INF contenente il file manifest.nf
solitamente da non modificare e gestite dal rational
• Il contenuto dinamico (sorgenti java, nel nostro caso) viene incluso nella cartella Java
Source inclusa nella cartella Java Resources, suddivise per java package.
19.3 Il deployment descriptor

Oltre alla struttura standard appena descritta esiste anche un file che l'applicazione web deve
prevedere obbligatoriamente in base alla specifica, il deployment descriptor o descrittore di
distribuzione..

Il deployment descriptor è un file XML denominato web.xml che contiene tutte le definizioni
necessarie al container per poter avviare ed eseguire correttamente l'applicazione.
Il web.xml segue le regole dettate dal suo XML Schema e contiene numerose informazioni, alcune
obbligatorie alcune opzionali, sui vari elementi che costituiscono l'applicazione.
C'è da osservare che sebbene sia opportuno conoscere la struttura di un web.xml Rational consente
di costruirlo in maniera automatica senza la necessità di una digitazione manuale.
Per accedere al Depoloyment Descriptor, basta cliccare due volte sulla voce
Progetti Web Dinamici

PortaleDBT
Descrittore di distribuzione
sulla sinistra (nell'esploratore di progetti) e visionare il file "web.xml" che Rational ha generato in
automatico per noi.
Sarà poi possibile, qualora ce ne sia la necessità, modificare il contenuto del file stesso avvalendosi
della struttura ad albero che Eclipse fornisce per leggere il contenuto dei nodi XML.

20 Esecuzione sul server di test
Per testare la nostra applicazione, abbiamo 2 possibilità:
● Esportare l'applicazione come file WAR o EAR (meglio) e fare il deployment su un server
Websphere, dalla pagina della console amministrativa.
● Eseguire la nostra applicazione sul server di test interno al Rational (che deve essere
installato come modulo a parte assieme all'Agent)
Per l'esecuzione sul server di test, andiamo nella vista inferiore dove appaiono i messaggi e
selezioniamo la linguetta “Server”.
Se non fosse visibile è possibile richiamarla dal menù Finestra->Mostra Vista->Server
Se non fosse presente nessun server è possibile cliccare all'interno della “vista” e selezionare
“nuovo...” per visualizzare il wizard di creazione dei server.

Ricordarsi di aggiungere il progetto al server, selezionandolo dai progetti disponibili e cliccando su
“Aggiungi...”
MyApp
Una volta completato il Wizard di creazione dei nuovi server, cliccare con il tasto di destra sul
server creato per visualizzare il menù contestuale e selezionare “Apri” per visualizzare le proprietà
del server:
E' importante selezionare “Abilita console di gestione” dalla linguetta “Configurazione”

e “Abilita protezione” dalla linguetta “Sicurezza” inserendo anche utenza e password per accedere
alla console amministrativa.
Per avviare il server è sufficiente premere sul tasto “Avvia il server”.
Avvia il Pubblicazion
Server e
Console degli errori
Cliccando sulla linguetta “Console” è possibile accedere ai messaggi di errore o di informazione

del server.
Il server sarà ora accessibile da un browser agli indirizzi:
http://localhost:9080/MyApp per l'applicativo

http://localhost:9090/Admin per la console amministrativa

21 Il Server Websphere ufficiale
Alcune operazioni che possono risultare utili sul server WebSphere ufficiale:
21.1 Avvio
/usr/WebSphere/AppServer/bin/startServer.sh server1
21.2 Stop
/usr/WebSphere/AppServer/bin/stopServer.sh server1 -username <user> -password <pwd>
21.3 Controllare i log

I log di Websphere si trovano nella directory:
/usr/WebSphere/AppServer/logs/server1/
Puo essere interessante visionare (con un editor tipo vi) i file:
● SystemOut
● SystemErr
21.4 File dell'applicazione installata

Si trovano sotto la cartella:
/usr/WebSphere/installedApps/<hostname>
Suddivisi in sottocartelle con estensione ear, al cui interno troviamo una ulteriore cartella con
estensione war:
Ad esempio:
.../DefaultApplication.ear/DefaultApplication.war/WEB-INF/classes

22 Il Deployment sul server ufficiale
Una volta testata l'applicazione sul server di test, bisogna fare il “deployment” cioè l'installazione
sul server ufficiale.
Per prima cosa bisogna esportare l'applicativo dall'ambiente di sviluppo; per fare ciò bisogna andare
nella finestra “Esplora progetti” e selezionare “Applicazioni Enterprise”, quindi selezionare
“MyApp” – Questa cartella è generata automaticamente dal Rational ed è sempre abbinata ad un
progetto “Web Dinamico”.
A questo punto, con il tasto di destra selezionare Esporta->File Ear come mostrato in figura:
Nella fase di esportazione è possibile anche includere tutti i sorgenti, spuntando la casella:
“Esporta file di origine” nella finestra di esportazione, realizzando così anche una forma di backup
dei sorgenti.
Una volta creato il pacchetto EAR, bisogna importarlo nel Websphere Ufficiale, accedendo alla
console amministrativa con l'indirizzo:
http://serverUfficiale:9090/Admin
Nel pannello di destra selezionare Applicazioni->Applicazioni Enterprise

Come indicato in figura:

MyApp
Quindi occorre:
● stoppare la versione dell'applicativo vecchia in esecuzione sul server

● disinstallare la versione vecchia
● installare la nuova versione (indicando il pacchetto EAR) e mantenendo i default in tutti i
pannelli di installazione
● avviare la nuova versione
● salvare la “Master Configuration” quando richiesto.
Agendo sui pulsanti “Arresta” “Disinstalla” “Installa” “Avvia” mostrati nella figura,
ricordandosi di spuntare sempre l'applicativo su cui si vuole operare.
A questo punto l'applicativo dovrebbe essere disponibile all'indirizzo:
http://ServerUfficiale:9080/MyApp
pronto per il test di funzionamento.

Introduzione Alle Applicazioni Web 1 2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Introduzione Alle Applicazioni Web 1 2

Transféré par

Droits d'auteur :

Formats disponibles

Introduzione alle Applicazioni Web

A cura di: Andrea Viarengo

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 1/43

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 2/43

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 3/43

La comunicazione in internet è diversa da quella telefonica (detta anche “commutata”, poiché

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 4/43

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 5/43

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 6/43

GET /index.html HTTP/1.1

Altri MIME type molto utilizzati sono:

 text/html pagina html

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 7/43

Il seguente codice HTML:

Verrà interpretato dal browser in questo modo:

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 8/43

<B style='font-size:12px; color:red;'>

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 10/43

h1 {font-weight: normal; font-size: 35px}

In questo caso la regola viene applicata a tutti gli oggetti <h1>

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 11/43

I server http (chiamati anche server Web) più noti sono:

• Apache di Apache Software Foundation

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 12/43

I Browser più utilizzati sono:

• Mozilla Firefox (l’erede di Netscape)

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 13/43

CGI = Common Gateway Interface

che verrà visualizzato dal browser nel seguente modo:

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 14/43

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 15/43

<SCRIPT Language=Javascript src="nomefile.js"></SCRIPT>

Esempio di sezione javascript in un file HTML

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 16/43

<img src=/images/button.gif onMouseOver=changeButtonImage(this) >

Dove onMouseOver è l'evento che scatena l'esecuzione dalla funzione javascript

onLoad: attivato al caricamento di oggetti, per lo più finestre e immagini;

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 17/43

<form name="myForm" method="POST" action="/bin/send.cgi">

Il Javascript ha in comune con Java solo la sintassi.

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 18/43

Più in dettaglio i diversi utilizzi dei cookie sono dunque:

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 19/43

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 20/43

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 21/43

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 22/43

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 23/43

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 24/43

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 25/43

Esempio di classi java

public abstract class Forma {

public Forma() { //Questo è il metodo Costruttore

public abstract draw(); //metodo da implementare

public class Rettangolo extends Forma {

Per usare la classe Rettangolo:

Rettangolo rettangolo1=new Rettangolo();

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 26/43

Codice java dell'applet

public class FirstApplet extends Applet{

Pagina HTML che contiene l'applet

Andrea Viarengo - Introduzione alle Applicazioni Web Pagina 27/43

public class MioServlet extends HttpServlet{

public void doGet(HttpServletRequest request,HttpServletResponse response)