Capitolo 8 L applicazione 8.1. Obiettivi e software utilizzati Uno degli obiettivi della tesi è la realizzazione di una applicazione WAP-SMS integrata con il Web, con in più una ben precisa caratteristica: la garanzia di una comunicazione sicura tra il client e il server. Come si è avuto più volte modo di vedere, i cinque elementi fondamentali del modello client/server di WAP, con in più l imperativo della sicurezza sono: il dispositivo mobile, oppure un emulatore che ne faccia le veci (quelli utilizzati per lo sviluppo ed i test sono il Nokia WAP SDK (Software Developement Kit) e l UP.Simulator di Phone.com), caratterizzato dalla possibilità di settare i collegamenti in modalità sicura; un WAP Gateway (è stato scelto WAPLite di Infinite Technologies); un certificato per tale WAP Gateway che ne autentifichi l identità (è stato scelto un certificato trial fornito da VeriSign); un Web server con la possibilità di settare una modalità di connessione sicura (è stato scelto OpenSA); un certificato per tale Web server, che ne autentifichi l identità (OpenSA includeva già un certificato fittizio). In relazione a quest ultimo punto, si è avuto modo di appurare che il certificato server non è strettamente necessario, vista la configurazione logistica dei dispositivi utilizzati. Infatti si è sfruttata l architettura di rete di una LAN aziendale (su sistema operativo Windows NT) alla quale appartengono entrambi i computer chiave coinvolti nell applicazione: essi vengono chiamati, nel seguito, con nomi fittizi: Pinco, su cui risiede il Web server; Panco, sul quale: l applicazione è stata sviluppata e testata; sono stati installati ed usati gli emulatori; è stato installato il WAP Gateway. In questo caso particolare non è necessario certificare sia il Gateway (su Panco) sia il Web server (su Pinco): se il WAP Gateway e il Web server appartengono entrambi alla stessa organizzazione (e per di più alla stessa LAN), sarebbe inutile certificali entrambi, perché sarebbe come certificare due volte l organizzazione stessa. Per questo motivo la certificazione vera e propria è stata fatta solo sul WAP Gateway (un certificato trial offre concettualmente le stesse garanzie di un certificato acquistato). 8.1.1. WAP Gateway: WAPLite Il WAP Gateway scelto è WAPLite, della Infinite Technologies [www.infinite.com]: in particolare ne è stata acquistata ed installata la versione 1.10. 1
WAPLite può essere utilizzato per il semplice sviluppo e testing delle applicazioni, ma anche per supportare l accesso concorrente di numerosi utenti attivi, grazie alla sua capacità di connettere telefoni mobili WAP ad applicazioni e contenuti basati su Internet o Intranet mantenendone separate le sessioni. WAPLite, infatti, include uno stack compatibile con quello descritto nelle specifiche WAP 1.1, supportando, quindi, obbligatoriamente entrambe le modalità di connessione (connectionless e connection oriented): sono inoltre supportati entrambi i metodi GET e POST per la connessione HTTP ad applicazioni basate su WML, su qualsiasi Web Server. Le applicazioni ed i contenuti WAP non sono ospitati direttamente sul Gateway WAPLite, ma su un Web Server standard, dove semplicemente il Web Server in questione è configurato per rispondere alle richieste che riceve con contenuti WML, invece che HTML (ad esempio inglobando questi ultimi all interno di una Servlet). WAPLite supporta telefoni compatibili con le specifiche WML 1.1, tra i quali, in particolare, si trovano i seguenti dispositivi ed emulatori: Nokia 7110 (dual-band GSM 900/1800); Motorola Timeport P7389 (tri-band GSM 900/1800/1900); Motorola L-Series+ (simile al P7389, ma dual-band GSM 900/1800); Ericsson MC218 PDA (Personal Digital Assistant); Ericsson R320s (dual-band GSM 900/1800); Siemens C35i (dual-band GSM 900/1800); Mitsubishi Trium WAP Phone (dual-band GSM 900/1800); Nokia WAP Toolkit v1.2 e v1.3 (SDK/Emulatore); Ericsson WapIDE (SDK/Emulatore); Ericsson R380 Emulatore (SDK/Emulatore); Phone.com v4.0 SDK (SDK/Emulatore); Emulatore AU Systems per Browser Psion (SDK/Emulatore); Browser AU Systems per Palm; WAPman della Edge Consultants (browser per Palm e Windows). Si hanno inoltre segnalazioni da utenti che affermano di aver potuto usare con successo versioni sperimentali di telefoni non ancora testate direttamente da Infinite Technologies: Nokia 7190 (GSM 1900 per il Nord America); Motorola TalkAbout (GSM, per l Europa). Si noti che l SDK (Software Developement Kit) di Phone.com (si tratta dell UP.Simulator, uno degli emulatori utilizzati) usa di default WTLS (Wireless Transport Layer Security) per comunicare con il WAP Gateway. Dal momento che si è usata la versione di WAPLite che include il supporto per WTLS (protocollo di sicurezza usato per fornire connessioni sicure tra dispositivi mobili e il WAP Gateway), essa supporta anche l uso di SSL per la connessione ai Web server che contengono contenuti WML. Per garantire una sicurezza end-to-end ad una applicazione che risiede su un Web Server, il WAP Gateway deve usare il protocollo SSL o TLS per connettersi al Web server, tramite https. Vengono ora descritti i dettagli della configurazione per l uso di WAPLite. WAPLite può supportare i dispositivi WAP che usano un protocollo connectionless come protocollo portante, incluse le connessioni CSD e il GPRS (General Packet Radio Service, il futuro servizio a pacchetti delle reti GSM), quando questo diventerà accessibile: infatti, molti utenti WAPLite hanno comunicato di essere in fase di beta testing di telefoni compatibili con GPRS e di non aver incontrato problemi con WAPLite. La connessione e poi il dialogo con il WAP Gateway comprende i seguenti passi: per connettersi al Gateway WAPLite si devono configurare i servizi WAP sul proprio telefono, impostando una chiamata CSD (chiamata dati) ad un server RAS (Remote Access Server) per il dial- up: in questo modo il telefono eseguirà una connessione PPP (Point-to- 2
Point Protocol) al server RAS. PPP è il protocollo standard usato per le connessioni Internet dial-up, per cui la propria connessione PPP potrebbe essere un dial-in ad un ISP (Internet Service Provider) preesistente, oppure una connessione ad un server Windows NT o Unix. Per configurare queste proprietà è necessario inserire il numero di telefono, uno username e una password. Tramite la connessione RAS il telefono invierà e riceverà pacchetti sul protocollo connectionless per interfacciarsi con il Gateway WAPLite. È necessario configurare l indirizzo IP del Gateway sul telefono ed, in alcuni dispositivi, anche un numero di porta: il numero di porta segue le seguenti regole, dettate direttamente dalle specifiche WAP: Porta 9200: collegamento connectionless non sicuro; questa porta può essere aperta attraverso i firewall (il Nokia 7110 usa la porta 9200 quando è configurato con Connection-type = temporary ). Porta 9201: collegamento connection oriented non sicuro (il Nokia 7110 usa la porta 9201 quando è configurato con Connection-type = continuous ); Porta 9202: collegamento connectionless sicuro (modalità WTLS di WAPLite); Porta 9203: collegamento connection oriented sicuro (modalità WTLS di WAPLite). Il Gateway WAPLite invia una richiesta HTTP per caricare contenuti WML da altri Web server: le richieste provenienti dal telefono sono trasformate in richieste HTTP, mentre i risultati sono codificati (se WML) o compilati (se WMLScript) e ritrasmessi al telefono mobile. Le applicazioni, naturalmente, elaborano su Web server standard, invece che direttamente sul Gateway WAP. L applicazione dal lato server deve ritornare, in risposta a queste richieste HTTP, contenuti WML o WMLScript che WAPLite, poi, invia ai dispositivi mobili (si noti bene che WAPLite non traduce contenuti da HTML a WML): nel caso il Web server invii contenuto WML, deve essere specificato nella Servlet un tipo di contenuto MIME per la risposta chiamato text/vnd.wap.wml, mentre, nel caso di contenuto WMLScript, deve essere specificato nella Servlet un tipo di contenuto MIME chiamato text/vnd.wap.wmlscript. Nella maggior parte dei casi questo richiede una configurazione del Web Server per associare ogni tipo MIME all estensione di file.wml e.wmls. Alcuni dispositivi permettono anche di configurare un URL per la propria home page (pagina iniziale). Questo URL deve avere un formato Web standard, che punti ad una pagina con contenuto WML, come ad esempio http://www.waplite.com/index.wml. 8.1.2. Certificato trial Attraverso il link http://www.verisign.com/wireless/content/index.html si è scaricato il Free Trial WAP Server Certificate della VeriSign, una versione di valutazione (della durata di trenta giorni di effettivo utilizzo) di un certificato per il WAP Gateway, in vista di un eventuale acquisto del certificato vero e proprio, al prezzo di 795 dollari e della durata di un anno. Il Trial WAP CPS stabilisce determinati termini e condizioni in base ai quali VeriSign emette e gestisce i certificati trial ed in base ai quali il certificato trial deve essere usato. Un certificato trial abilita il sottoscrittore a simulare un Gateway WAP sicuro, permettendo, ad esempio, ad un dispositivo di autenticarsi e stabilire un canale sicuro con tale Gateway WAP: VeriSign rende disponibile al download il Trial Certificate sul proprio sito Web per propositi di testing, autorizzati solo in accordo alla relativa CPS. I punti base per l utilizzo del certificato trial sono i seguenti: l utilizzo deve essere limitato alla sola attività di testing e non deve comprendere transazioni commerciali, né autenticazione dell identità del sottoscrittore, né l assicurazione della confidenzialità di una qualsiasi informazione: infatti non si può pretendere tutto ciò da un certificato trial. I sottoscrittori e gli utenti concordano sul fatto che VeriSign non fornisce servizi di sospensione o revoca per i certificati Trial. 3
VeriSign si prende il diritto di pubblicare qualsiasi Certificato Trial o qualsiasi porzione del suo contenuto. VeriSign nega ogni garanzia, eccetto che per i servizi esplicitamente citati, escludendo senza limitazioni ogni garanzia di utilizzo commerciale. Questo certificato non garantisce che il suo proprietario, persona o organizzazione, sia chi dichiara di essere. VeriSign non assicura l accuratezza, l autenticità, l integrità o l affidabilità delle informazioni contenute nel certificato trial, né i risultati dei metodi crittografici implementati. Preso atto delle condizioni legali di utilizzo, si è richiesto, previa compilazione del relativo form di dati, il certificato a VeriSign, ricevendolo dopo poche ore via e-mail sottoforma di allegato; tale allegato è stato semplicemente posizionato nella directory di WAPLite: questa operazione è stata sufficiente per installare il certificato. 8.1.3. Web server OpenSA Si è scelto di installare su Pinco (con sistema operativo Windows NT) il Web server Apache, essendo Apache il software più diffuso e utilizzato in questo settore. Un requisito fondamentale, però, era rappresentato dall obiettivo sicurezza: l installazione doveva garantire la possibilità di abilitare connessioni sicure con il Web server, ovvero accessi tramite protocollo https (http secure). Consultando le specifiche per l installazione di Apache ci si è trovati di fronte a due soluzioni possibili: mod_ssl [www.modssl.org] OpenSA [www.opensa.org] Il modulo mod_ssl permette di realizzare la sicurezza nelle connessioni Internet tramite un robusto algoritmo di crittografia, applicandolo al Web Server Apache (v1.3) attraverso i protocolli di Secure Socket Layer (SSL v2/v3) e di Transport Layer Security (TLS v1), grazie all aiuto dell eccellente libreria di implementazione di SSL/TLS OpenSSL di Eric A. Young e Tim Hudson. Figura 8.1: architettura di Apache con moduli per la sicurezza Il pacchetto mod_ssl è stato creato nell Aprile 1998 ed è stato originariamente derivato dal pacchetto Apache-SSL sviluppato da Ben Laurie. Possiede una licenza nello stile BSD che è equivalente alla licenza usata dall Apache Group [www.apache.org] per lo stesso Web Server Apache. Questo significa, in breve, che ognuno è libero di usarlo per scopi sia commerciali sia non commerciali, a patto di rispettare le regole di copyright degli autori (che sono quelle dell Open Source) e di dare agli autori il giusto riconoscimento. Il pacchetto mod_ssl consiste del modulo SSL (mod_ssl ❶in Figura 8.1) e in un insieme di patch per Apache aggiunti come Extended API (EAPI ❷ sempre in Figura 8.1), che rappresentano prerequisiti essenziali per usare mod_ssl. 4
Il grosso problema, qui, è rappresentato del fatto che, all atto pratico, l installazione di mod_ssl non è possibile che su piattaforma Unix. Infatti, nella guida all installazione, si trovano i seguenti warning: Il supporto a WIN32 per Apache è ancora in fase beta. Il supporto a WIN32 per mod_ssl è ancora in fase alfa! Non c è alcun supporto ufficiale per mod_ssl su piattaforma WIN32, perché l autore di mod_ssl utilizza esclusivamente piattaforme Unix; perciò quando si utilizzerà Apache + mod_ssl su WIN32 lo si farà a proprio rischio e pericolo. Come alternativa si può attingere ai file binari precompilati del progetto OpenSA, che si possono trovare al link: http://www.opensa.org./ A questo punto, lavorando su un sistema Windows NT, la scelta è stata obbligata. 8.1.3.1. OpenSA OpenSA è un pacchetto software che, quando installato su un sistema Windows, lo trasforma in un Web Server facile da usare; si tratta di software free (si può leggere qualcosa di più sulla filosofia del software free ed Open Source al link http://www.opensource.org/) ed è liberamente disponibile per chiunque voglia scaricarlo ed usarlo. Il sito Web www.opensa.org contiene tutto quello di cui si può aver bisogno, ad esempio informazioni su come i componenti di OpenSA lavorano insieme, su come modificarli, su dove trovarli ed altro ancora. Il Web Server OpenSA consiste in una installazione di Apache modificata, insieme ad un certo numero di moduli aggiuntivi: ciò che è stato fatto dagli sviluppatori è stata una semplificazione della distribuzione standard di Apache tramite l impacchettamento di tutti i moduli più piccoli in un unica grande distribuzione. Quindi è stata automatizzata la procedura di installazione e sono state aggiunte altre caratteristiche interessanti. Punti fondamentali di OpenSA: Software Open Source (licenza nello stile di BSD); Utilizzabile per fini commerciali e non commerciali; Disponibile per piattaforma Win32 (Windows 95/98/NT/2000); Completo supporto Visual Studio Makefile (tool per compilazione e link di programmi in Visual C++, Visual J++, Visual Basic) per tutti i pacchetti inclusi; Completo supporto per utenti e sviluppatori; Versione corrente di Apache; Supporto per PHP4 (linguaggio di programmazione ad oggetti); Supporto per ASP; Supporto per ColdFusion; Robusta crittografia a 128-bit (SSLv2, SSLv3 e TLSv1); Sistema di installazione Professional InstallShield. Il sistema di installazione si presenta agli utenti sottoforma di installazione semplificata, configurando automaticamente il server ed i moduli: si ottiene una configurazione veloce, semplice e ottimale direttamente durante la prima installazione. Anche con gli aggiornamenti successivi il sistema si integra con ciò che è già presente. Per gli amministratori di sistema, l aggiornamento del software server è uno dei punti più importanti, insieme alla scelta dello stesso: grazie ad OpenSA si ha la garanzia di un Web Server che include la versione più nuova del Web Server Apache e le estensioni più importanti, come PHP e mod_ssl/openssl. 5
8.1.4. Installazione di OpenSA, JVM, JRE, JSDK, Jserv1.1 L installazione di OpenSA è estremamente semplice, come affermato nelle specifiche, ed è stata effettuata su sistema Windows NT 4.0, disponendo, ovviamente, dei diritti di amministratore della macchina: si tratta di installare il file autoestraente (self extracting), scaricabile da www.opensa.org, chiamato opensa_0.20bin (esiste anche l analogo opensa_0.20src, con i sorgenti). Se durante l installazione viene richiesto il FQND (Fully Qualified Domain System), questo deve essere un nome DNS valido (nel nostro caso il nome di rete della macchina server Pinco), oppure un indirizzo IP: queste informazioni sono memorizzate nel file httpd.conf, come Server Name. È poi importante avere il file mime.types nella directory /conf, che contiene tutte le impostazioni MIME. MIME (Multipurpose Internet Mail Extension) è uno standard per l invio di dati multimediali e compositi attraverso la posta elettronica. I dati possono essere binari o utilizzare diversi gruppi di caratteri ASCII e non ASCII. Nonostante MIME fosse stato in origine concepito solo per la posta elettronica, col tempo è in realtà divenuto una tecnica ampiamente utilizzata per descrivere i contenuti di un file, così che il software del client possa capire la differenza tra i diversi tipi di dati. Per esempio, un browser Web utilizza MIME per stabilire se un file è un'immagine GIF o un file PostScript stampabile. MIME include circa cento tipi predefiniti di contenuti, i quali sono classificati in due livelli: un tipo e un sottotipo. Il tipo indica in modo molto generico quale tipo di dati è contenuto, ad esempio un immagine, un testo, un file audio. Il sottotipo identifica specificatamente il tipo di dati: immagine GIF, immagine JPEG, immagine TIFF. Per esempio, il tipo di contenuto di HTML è text/html: il tipo è text, il sottotipo è HTML. Il tipo di contenuto per una immagine GIF è image/gif: il tipo è image, il sottotipo è gif. È interessante elencare qui i tipi e i sottotipi fondamentali per WAP: Codice WML: text/vnd.wap.wml. Codice WMLScript: text/vnd.wap.wmlscript. Codice WML compilato: application/vnd.wap.wmlc. Codice WMLScript compilato: application/vnd.wap.wmlscriptc. Immagini WAP (formato WBMP): image/vnd.wap.wbmp. Nella maggior parte dei sistemi, un semplice file di testo mime.types conserva un mapping tra i tipi MIME e l applicazione usata per elaborare quel tipo di dati. Apache può essere avviato in tre modi distinti: come servizio (per cui comparirà in Servizi del Pannello di Controllo): apache i (installazione) net start apache per avviare net stop apache per fermare apache u (disinstallazione) come applicazione (come se fosse un normale programma) start apache (avvio) apache k shutdown (stop) in modalità SSL apache i apache D SSL apache k shutdown apache u Naturalmente è necessario cercare, tra i file appena installati, tutti i file con contenuti eseguibili (.exe,.bat,.com) ed inserirne il percorso nel path (Pannello di Controllo > Sistema > Ambiente). Una volta installato, si può verificare il funzionamento di Apache da un qualsiasi browser, collegandosi a http://host:port, dove host e port sono quelle settate nel file httpd.conf (nel nostro 6
caso http://pinco:82).la JVM (Java Virtual Machine) e il JRE (Java Runtime Environment) si ottengono dall installazione del jdk1.2.2 (Java Developement Kit), mentre l ambiente per le Servlet vere e proprie è il JSDK2.0 (Java Servlet Developement Kit), insieme al modulo Apache Jserv 1.1, installato in seguito, per l esecuzione delle Servlet con il Web Server Apache. Apache Jserv è un motore per le Servlet compatibile con le specifiche Java Servlet API 2.0, che può eseguire qualsiasi Servlet Java compatibile con la versione 2.0. Per ottenere questa completa astrazione dagli ambienti nativi, Apache Jserv è stato progettato come una applicazione server che risponde alle richieste fatte tramite un preciso protocollo (Apache Jserv Protocol); quindi alcuni moduli inclusi permettono al Web Server di tradurre le richieste delle Servlet e di inviarle al motore che le gestisce. In questo momento, la distribuzione dell Apache Jserv contiene solamente il modulo mod_jserv. Il passo successivo di configurazione del Web Server contempla la definizione delle Servlet zones, aree di esecuzione separate per le Servlet, una per ogni applicazione e ognuna con classloader proprio. Vengono qui esposti, in proposito, alcuni concetti base: una Servlet è semplicemente una classe Java che implementa il package javax.servlet.servlet; un Servlet repository è una collezione di Servlet (può essere una directory o un archivio di classi, cioè un file zip o jar), mentre dal punto di vista del Web Server è semplicemente una directory); una Servlet zone è una collezione di repository, mentre dal punto di vista del motore delle Servlet è l equivalente dell host virtuale di un Web Server, nel senso che tutti i repository contenuti nella Servlet zone condividono un comune contesto logico. Questo fornisce il potere di isolare le Servlet l una dall altra sia logicamente (in quanto appartenenti a differenti host) e, in futuro, in relazione alla sicurezza, mappando ogni Servlet zone in un differente sandbox (Java impedisce a determinate applicazioni di leggere e scrivere al di fuori di un area loro dedicata chiamata sandbox: questo meccanismo di sicurezza è utilizzato, ad esempio, per limitare l accesso al sistema da parte delle Applet). Al suo avvio, Apache Jserv farà il setup di ogni Servlet zone usando gli appositi file di configurazione. Per questa ragione, bisogna assicurarsi che l Apache Jserv abbia i privilegi di accesso almeno in lettura ai file di configurazione delle zone e i loro repository. Una volta che si siano configurate le zone di Apache Jserv, è necessario montarle, aggiungendo semplicemente una riga di specifiche al file di configurazione. Questa operazione viene fatta per separare dal punto di vista logico le zone, montandole in corrispondenza di un particolare URL del Web Server, esattamente come si farebbe per un disco in un sistema Unix. È da notare come la possibilità di montare Servlet zone sia locali sia remote sia la vera potenzialità di Apache Jserv e la maggiore differenza rispetto ad altri motori. Di fatto, il modulo del Web Server si comporta come un AJP Browser (Active Java Pages Browser), piuttosto che come un collante tra un processo nativo ed un processo Java. Questo permette di creare un ambiente di rete completo e fornisce al Web Server il potere di concentrare sul proprio spazio URL tutte le sue risorse di rete, incapsulandole nell Apache Jserv. 8.1.5. Finalmente la sicurezza A questo punto tutto dovrebbe essere pronto per impostare la sicurezza end-to-end, cioè tra il dispositivo wireless (inizialmente è stato usato un emulatore) e il Web server (Apache), passando attraverso il WAP Gateway (WAPLite): WTLS: si utilizza l emulatore Phone.com (come si è visto più sopra, WTLS è già attivato), oppure l emulatore Nokia, attivando la sicurezza; nelle impostazioni è necessario specificare 7
l indirizzo IP della macchina che ha attivato WAPLite (nel nostro caso l indirizzo IP di Panco); SSL: si imposta Apache in modalità SSL digitando da prompt del DOS apache D SSL ; WAPLite: si imposta WAPLite in modalità WTLS, impostando la Home Page: https://pinco/mor/testuspss.wml (questo nome dato al file di codice WML significa test username password ). I codici di prova utilizzati sono i due seguenti file: TestUsPss.wml <?xml version= 1.0?> <wml> <card id= a newcontext= true title= Accesso > <p> Inserire username e password:<br/> Username:<input name= u title= Username: type= text maxlength= 8 emptyok= false /> Password:<input name= p title= Password: type= password maxlength= 8 emptyok= false /> Riimmettere password:<input name= p2 title= Riimmettere password: type= password maxlength= 8 emptyok= false /> <anchor> Prosegui <go href= https://pinco/mr/control?u=$(u)&p=$(p)&p2=$(p2) /> </anchor> </p> </card> </wml> Questo primo codice wml visualizza un richiesta di immissione di username e password, con conferma, immagazzinando i valori immessi da telefono nelle variabili u, p e p2. A questo punto viene chiamato il codice della Servlet di verifica tramite https, cioè tramite connessione sicura al Web Server Apache. Quello che avviene è: l emulatore si collega alla home page https://pinco/mor/testuspss.wml in modalità sicura (mor è un alias, cioè un collegamento ad una particolare directory che contiene il codice wml) attraverso il Gateway specificato con indirizzo IP nelle sue impostazioni; il Gateway passa la richiesta contenuta nel codice WML al Web server Apache in modalità sicura (https://pinco/mr/control?u=$(u)&p=$(p)&p2=$(p2): mr è un alias che porta nella sottodirectory che contiene i file compilati, cioè in formato bytecode, identificabili come.class); Apache trasforma l alias in un vero path, trova il file, che è una Servlet, lo esegue grazie al modulo Jserv; il compito della Servlet è scrivere codice WML in risposta alla richiesta ricevuta e scrivere il suo resoconto sullo username e la password ricevuti su un file di log locale, appendendo in fondo (per la scrittura su file, che è locale, non si ha bisogno di ripassare attraverso il Gateway); Control.java import javax.servlet.http.*; import javax.servlet.*; import java.io.*; 8
public class Control extends HttpServlet { public void doget(httpservletrequest req, HttpServletResponse res) throws ServletException { PrintWriter out = null; res.setcontenttype( text/vnd.wap.wml ); try { out = res.getwriter(); String u = req.getparameter( u ); String p = req.getparameter( p ); String p2 = req.getparameter( p2 ); final String U = morena ; final String P = ciao ; FileWriter miofile = new FileWriter (,true); PrintWriter tofile = new PrintWriter(mioFile); tofile.println( Username = + u); tofile.println( Password = + p); tofile.println( Ancora Password = + p2); tofile.flush(); // se le due password non coincidono if (p.compareto(p2)!= 0) { // risposta in codice wml out.println( <?xml version=\ 1.0\?> + <wml> + <card id=\ b\ title=\ ErroreCoinc\ > + <p>le due password non coincidono. + <do type=\ prev\ label=\ IndietroDo\ > + <prev/> + </do> + </p> + </card> + </wml> ); } else { // se username e password sono corretti if (u.compareto(u) == 0 && p.compareto(p) == 0) { out.println( <?xml version=\ 1.0\?> + <wml> + <card id=\ d\ title=\ Giusto\ > + <p>username e password corretti. + <do type=\ accept\ label=\ IndietroAccept\ > + <prev/> + </do> + </p> + </card> + </wml> ); 9
} } } else { // se username o password sono scorretti } out.close(); out.println( <?xml version=\ 1.0\?> + <wml> + <card id=\ c\ title=\ ErroreUsPss\ > + <p>username e password scorretti. + <anchor>indietroanchor + <prev/> + </anchor> + </p> + miofile.close(); catch(ioexception e) { } </card> + </wml> ); e.printstacktrace(); out.println( <?xml version=\ 1.0\?> + <wml> + <card> + <p>errore strano. + e.tostring() + </p> ); out.println( </card> + </wml> ); out.close(); } } Il precedente è il codice della Servlet, che controlla il valore di username e password: se questi due valori corrispondono rispettivamente a morena e ciao e la password e la sua conferma coincidono viene visualizzato sullo schermo del cellulare o dell emulatore il messaggio Username e password corretti (si noti quanto sia poco duttile il linguaggio Java per la formattazione del testo, quando è necessario scrivere sulla Response il codice WML da inviare al cellulare). Le Servlet sono programmi Java che rendono estensibili i server: nella misura in cui un utente può caricare degli Applet in un browser Web, può anche caricare delle Servlet su un server in esecuzione, per estenderne le capacità. Come gli Applet, i bytecode (file.class) delle Servlet possono essere letti dal sistema di file locale o dalla rete. Una Servlet può ritornare dati al client, sottoforma di una nuova pagina Web o di dati all interno di una pagina Web (scrivendo codice HTML, mentre nel nostro caso si tratta di codice WML, interpretato dal microbrowser dell emulatore o del telefono). Le Servlet in sé non hanno una interfaccia grafica o un flusso di output al quale possano inviare i risultati, perciò si affidano al client per fornire questi servizi, sfruttando essenzialmente HTML o 10
WML. Le Servlet forniscono ad un server Web anche un altro modo di generare dati dinamici: normalmente, un server riceve un URL che richiede una certa pagina, associa questo URL ad un file, legge il file dal disco locale ed invia i dati al client. In questa situazione, i dati sono statici, cioè non cambiano se l amministratore del server non cambia i file. Una Servlet, invece, può generare nuovi dati per ogni richiesta, perché è un programma: per questo motivo può rilasciare informazioni che cambiano, come un ora del giorno o la quotazione di un titolo in Borsa. Anche i programmi CGI possono generare dati in modo dinamico da inviare ad un client: CGI è utilizzato da molto tempo, è ben compreso ed è facile scrivere una pagina Web che lo richiami, così come è facile scrivere un programma che rimandi dati al browser. Inoltre tutti i server Web comprendono il CGI, mentre i server che gestiscono le Servlet non sono diffusissimi. CGI viene utilizzato per creare pagine Web in modo dinamico: il browser chiama un programma sul server che crea una nuova pagina. Questa pagina Web può basarsi unicamente sui dati del server o può elaborare i risultati di un modulo client. È possibile scrivere programmi CGI in quasi tutti i linguaggi, incluso Java, sebbene la programmazione CGI più diffusa venga effettuata in Perl e C. Le Servlet, però, sono interessanti proprio perché sono ben più di programmi CGI scritti in Java e perché possono fare molte cose che i programmi CGI non possono fare: Una Servlet può continuare ad essere eseguita in background, dopo che ha finito di elaborare una richiesta, così da essere sempre pronta ad elaborare una richiesta successiva, senza dover ricorrere ad ulteriori riavvii (su un server attivo, l onere di avviare programmi CGI è significativo). Inoltre una Servlet può usare dei thread per elaborare richieste simultanee in modo efficiente e può persino passare dati attraverso connessioni multiple: per esempio una Servlet può agire come un server per giochi a più giocatori, stando in ascolto di input da più client e poi trasmettendo quei dati ai client connessi, oppure può permettere la collaborazione tra le persone, nelle conferenze on-line. Una Servlet può comunicare in modo interattivo con un Applet su un client. Un programma CGI, invece, riceve una richiesta da un client e poi invia la risposta; a quel punto la connessione viene chiusa, dopodiché il client non può inviare un altra richiesta al programma CGI in risposta ai dati ricevuti. Al contrario, una coppia Applet/Servlet può proseguire una conversazione, facendo molti trasferimenti di dati tra il client e il server e può persino implementare un nuovo protocollo, se necessario. Tutto questo è ovviamente molto più efficiente rispetto al dover fare delle chiamate multiple allo stesso programma CGI, e molto più facile da codificare. Le Servlet possono essere originate sul client. Come gli Applet, le Servlet vengono eseguite in un ambiente sicuro (il sandbox di cui si parlava prima), quindi i server non devono preoccuparsi di eventuali Servlet pericolose. Per esempio un client può caricare una Servlet personalizzata che cerca un sito Web per ottenere delle informazioni; con l accesso locale ai file su ogni possibile sorgente di informazione trovata, la ricerca può avvenire in maniera molto più veloce di quanto non farebbe se il client dovesse scaricare ogni file sul sito Web. Una Servlet può essere caricata su server differenti, eseguendo la stessa azione alternativamente su ciascun server. Fino ad ora, tutte le tecnologie relative ai componenti eseguibili scaricabili dalla rete hanno condiviso diverse importanti limitazioni. Per prima cosa, gli host devono fidarsi di tali componenti, mentre grazie alle caratteristiche di sicurezza di Java, un server Web può eseguire una Servlet senza preoccuparsi che il sistema possa andare in crash o possa essere violata la sicurezza. In secondo luogo, tali componenti attivi possono essere eseguiti solo su certe piattaforme, mentre, per contro, la portabilità di Java permette di eseguire le Servlet su qualunque sistema. Le possibilità degli componenti attivi (programmi scaricabili da Internet ed eseguibili localmente sul client) sono quasi illimitate: si pensi ai componenti attivi di shopping, che cercano i prezzi migliori, a quelli che setacciano continuamente la rete alla ricerca di informazioni, a quelli di gestione del sistema che aggiornano i siti mirror con copie dei file modificati, a quelli che fanno il backup di dati di un host centrale, ed altro ancora. Le Servlet non sono ancora a questi 11
livelli, perché devono essere invocate in modo esplicito, ma questo potrebbe cambiare in futuro, grazie alle loro potenzialità, che le rendono molto appetibili per gli sviluppatori. Una Servlet può processare dati inviati con metodo POST su una connessione HTTPS usando un form HTML, che può includere ordini di acquisto o numeri di carte di credito. Una Servlet simile può far parte di un sistema di gestione e processing di ordini, basato su un database di prodotti ed inventari, ed eventualmente anche di un sistema di pagamenti online. Le Servlet sono sviluppate con le Java Servlet API, una estensione standard di Java. Anche se quest ultima non fa parte della struttura base di Java ( core ), che invece deve sempre essere presente, essa viene resadisponibile come un package da aggiungere alla configurazione normale. Sostanzialmente una Servlet è una classe definita dal programmatore, progettata per implementare l interfaccia javax.servlet.servlet, ed il modo più facile per farlo è di estendere una delle due seguenti classi: javax.servlet.genericservlet javax.servlet.http.httpservlet HttpServlet va utilizzato per le classi che vengono eseguite da un server HTTP ed hanno accesso alle classiche intestazioni MIME di una richiesta HTTP. Le Servlet HTTP hanno alcuni oggetti addizionali che forniscono funzionalità di tracciamento delle sessioni: lo sviluppatore di Servlet può usare queste API per mantenere lo stato tra la Servlet ed il client, che persiste attraverso connessioni multiple durante un certo periodo di tempo. Invece GenericServlet va utilizzato per le Servlet che non necessitano delle speciali caratteristiche fornite da un server HTTP e possono essere eseguite da qualsiasi server compatibile con le Servlet. Un server comunica con le Servlet invocando i metodi dell interfaccia javax.servlet.servlet, ovvero: init(): per inizializzare una Servlet; service(): per chiedere alla Servlet di elaborare una richiesta, passata al metodo come un oggetto che implementa l interfaccia ServletRequest; destroy(): per scaricare una Servlet. L astrazione centrale nelle Servlet API è, dunque, l interfaccia Servlet. Tutte le Servlet implementano questa interfaccia, sia direttamente oppure, più comunemente, ereditando da una classe che la implementi, come HttpServlet. L interfaccia Servlet fornisce metodi che gestiscono le Servlet e le loro comunicazioni con i client. Quando una Servlet accetta una chiamata da un client, riceve due oggetti: ServletRequest: classe che incapsula la comunicazione dal client alla Servlet; ServletResponse: classe che incapsula la comunicazione dalla Servlet al client. L interfaccia ServletRequest permette alla Servlet di accedere ad informazioni come i nomi dei parametri inviati dal client, il protocollo usato e i nomi degli host remoti che fanno le richieste e del server che le riceve. Fornisce anche alla Servlet accesso all input stream, ServletInputStream, attraverso il quale riceve dati dai client che stanno usando metodi come HTTP POST o PUT. Le sottoclassi di ServletRequest permettono alla Servlet di trovare dati più specifici per il protocollo. Per esempio, HttpServletRequest contiene metodi per accedere ad informazioni specifiche dell header HTTP. L interfaccia ServletResponse fornisce alla Servlet metodi per rispondere al client: questi permettono alla Servlet di impostare la lunghezza del contenuto ed i tipi MIME della risposta e fornisce un output stream, ServletOutputStream ed una classe Writer attraverso la quale la Servlet può inviare la risposta. Le sottoclassi di ServletResponse forniscono funzionalità più specifiche per il protocollo. Anche HttpServletResponse contiene metodi che permettono di manipolare informazioni specifiche dell header HTTP. Quando un server riceve la richiesta di una Servlet da un client la sequenza degli eventi è: Il server carica il bytecode per la Servlet richiesta. 12
Il server istanzia l oggetto della Servlet. Il server chiama il metodo init() della Servlet. Il server costruisce un oggetto request che implementa l interfaccia ServletRequest dai dati forniti nella richiesta del client. Il server costruisce un oggetto response che implementa l interfaccia ServletResponse. Il server richiama il metodo service(request, response) della Servlet. Il metodo di servizio elabora la richiesta chiamando i metodi nell argomento response per rimandare le informazioni al client. Nel momento in cui ci fossero più richieste del client, si torna al quarto punto. Quando il server non ha più bisogno della Servlet, ne richiama il metodo destroy(). Le Servlet API, che vengono usate per scrivere le Servlet, non fanno nessuna assunzione su come una Servlet viene caricata, sull ambiente del server nel quale la Servlet viene eseguita o sul protocollo usato per trasmettere dati da/all utente. Gli sviluppatori che stanno scrivendo Servlet HTTP (che specializzano la classe HttpServlet) possono ridefinire (override) i metodi designati per gestire le interazioni HTTP. I metodi in questione sono: doget, per gestire richieste GET, GET condizionali e HEAD; dopost, per gestire richieste POST; doput, per gestire richieste PUT; dodelete, per gestire richieste DELETE. Di default, questi metodi ritornano un errore BAD_REQUEST (400). 8.2. L applicazione realizzata 8.2.1. Specifica dei requisiti Si ipotizza che una banca, per venire maggiormente incontro ai bisogni dei clienti e per rimanere al passo con le nuove tecnologie, richieda la realizzazione di un software che possa permettere ai correntisti di consultare agevolmente i dati personali riguardanti il saldo e i relativi movimenti. In particolare, la consultazione deve avvenire attraverso la tecnologia dei telefoni cellulari, rispettando i requisiti di sicurezza più all avanguardia: questo requisito è molto importante, dovendo l applicazione trattare dati delicati come numeri di conto corrente, password, ammontare di saldi, ecc. La tecnologia wireless è stata preferita a quella wired, poiché l applicazione deve essere di tipo push/pull, nel senso che non deve semplicemente limitarsi a rispondere alle richieste di un cliente, ma deve di propria iniziativa avvertirlo nel caso si verifichino particolari eventi, come un addebito o un accredito su un conto corrente. L accesso ad Internet non avrebbe permesso di avvertire il cliente in tempo reale, sia perché il cliente, presumibilmente, non passa 24 ore al giorno davanti al computer, sia perché, anche in questo caso, avrebbe dovuto egli stesso, periodicamente, controllare l arrivo di eventuali messaggi. Invece è molto più facile che il cliente mantenga il proprio cellulare acceso per buona parte della giornata e che questo dispositivo possa avvertirlo in corrispondenza di un evento. Addentrandosi nel problema, si possono elencare brevemente le caratteristiche del rapporto che il cliente ha con la banca: un cliente della banca può avere aperto in essa uno o più conti correnti, ognuno dei quali è caratterizzato da un identificatore alfanumerico univoco; in corrispondenza di un conto corrente possono essere effettuati, nel corso del tempo, diversi movimenti, cioè addebiti e accrediti; ognuno di questi movimenti deve essere tempestivamente comunicato al cliente; 13
la banca fornisce al cliente uno username e una password univoci, che potranno essere da lui utilizzati per connettersi tramite cellulare all applicazione; il saldo deve essere espresso in due valute: Lire ed Euro. la lista dei movimenti deve comprendere, oltre, ovviamente, all ammontare, la causale e la data in cui l addebito o l accredito ha avuto luogo; il cliente può attivare o disabilitare l aggiornamento automatico dei movimenti selettivamente, per ogni conto corrente. Di seguito vengono presentate le fasi fondamentali del processo seguito durante lo sviluppo dell applicazione. 8.2.2. Analisi dei requisiti chiede lista movimenti su conto corrente chiede saldo del conto corrente Utente si aspetta aggiornamenti su movimenti attiva/disattiva il servizio push Figura 8.2: Use Cases diagram. Il linguaggio di modellazione utilizzato per l analisi e la progettazione del software è UML (Unified Modeling Language), di cui si può trovare una breve descrizione nell Appendice E. Si sono utilizzati essenzialmente tre dei nove diagrammi, ovverosia lo Use Cases diagram, il Class diagram e l Object Sequence diagram o, più semplicemente, Sequence diagram. Una tecnica molto comoda per raggiungere una buona rappresentazione dei requisiti raccolti è ::Utente username password identificativo setusername setpassword verificaup sceglinumerocc setidentificativo setpush aggiornautente 1 1..* ::ContoCorrente numerocc saldo getsaldo setnumerocc getlistamovimenti 1 * ::Movimento data causale importo setdata setcausale setimporto Figura 8.3: Class diagram quella dell uso degli Use Cases, istantanee dei diversi aspetti del sistema e, come dice il nome (casi d uso), rappresentazione dei possibili utilizzi del software. La somma di tutti gli Use Cases forma 14
l immagine esterna del sistema e una loro collezione aiuta a capire cosa vogliono gli utenti, rappresentando un buon veicolo per la pianificazione di un progetto. L Actor in Figura 8.2 rappresenta il ruolo dell utente/cliente proprietario del dispositivo mobile, che interagisce con il software in quattro modi diversi: per informarsi sul saldo e sui movimenti effettuati sul proprio conto, per abilitare o disabilitare il servizio di aggiornamento in tempo reale di addebiti o accrediti e per essere aggiornato su tali movimenti. Anche se gli Use Cases dovrebbero rappresentare azioni svolte dall utente SUL sistema, si è comunque pensato di rappresentare nello stesso modo un ruolo PASSIVO dell utente, che subisce dal sistema l azione di essere aggiornato. In Figura 8.3, invece, si trova il Class diagram: una delle classi presenti è Utente, con gli attributi username e password, che gli permettono di accedere all intero sistema, e l attributo identificativo, lasciato per ora un po sul vago, visto che la fase è ancora quella dell analisi. I metodi elencati sono stati ottenuti dall Object Sequence diagram di Figura 8.4. e 8.5. :Utente :ContoCorrente L'utente si connette al servizio e fornisce username e password che vengono verificati L'utente sceglie il numero di conto corrente desiderato Se l'utente vuole determinare il saldo determina il saldo del conto corrente Fine determinazione saldo Se l'utente vuole determinare la lista movimenti determina lista movimenti Fine determinazione movimenti setusername setpassword getsaldo getlistamovimenti verificaup setnumerocc Figura 8.4: Object Sequence con le classi Utente e ContoCorrente. In Figura 8.4 viene mostrato l Object Sequence che rappresenta l azione di autenticazione dell utente, che si connette al servizio e fornisce il proprio username e la propria password: queste due azioni corrispondono ai metodi setusername e setpassword della classe Utente: una volta che il sistema ha questi due dati, può procedere con il metodo verificaup, per verificare la validità dei dati inseriti. Una volta autenticato, l utente può richiedere l ammontare del saldo (getsaldo) e la lista dei movimenti (getlistamovimenti). A questo punto, proprio sulla lista dei movimenti da presentare all utente, bisogna fare una precisazione: è necessario limitare il numero dei movimenti da :ContoCorrente :Movimento :Utente Segnalazione su un numero di conto corrente di un movimento di importo X in data Y con causale Z per avvertire l'utente devo memorizzarne l'identificativo l'utente viene avvertito setnumerocc setimporto setdata setcausale setidentificativo aggiornautente Figura 8.5: segnalazione del verificarsi di un movimento. visualizzare, altrimenti si rischierebbe di subissare l utente di troppi dati. La lista dei movimenti deve limitarsi agli ultimi X movimenti (dove X deve essere un parametro definibile a piacere). 15
:Utente L'utente si connette con username e password verifica di username e password notifica che vuole attivare/disattivare il servizio push setusername setpassword setpush verificaup Figura 8.6: cambiamento del settaggio della variabile Push. In Figura 8.5 viene introdotta in un Object Sequence diagram anche la classe Movimento, che ha attributi data, causale e importo : questo Sequence diagram esprime le azioni intraprese dal sistema quando si verifica un cambiamento (movimento) su un conto corrente. Prima di tutto viene memorizzato il numero del conto corrente (setnumerocc), poi l importo, la data e la causale (setimporto, setdata, setcausale), l identificativo dell utente (che a questo punto potrebbe essere un numero telefonico) tramite il quale poterlo aggiornare (aggiornautente). La Figura 8.6 è abbastanza simile alla 8.4, perché visualizza le operazioni effettuate dall utente per modificare le impostazioni della variabile Push: come per visualizzare saldo e movimenti, l utente deve prima autenticarsi e poi può accedere alle informazioni ed, in questo caso, aggiornarle. 8.2.3. Progetto A livello di progetto si può adottare un punto di vista meno astratto, concentrandosi sulle problematiche dell applicazione più da vicino. A questo punto è possibile considerare il tipo di dispositivo destinazione, nella fattispecie un dispositivo WAP: non si può certo pretendere di avere le stesse possibilità garantite da un computer connesso alla rete, anzi ci si scontra con tutta una serie di difficoltà, legate alla povertà del mezzo. Il display è piccolo e può contenere poche righe e poche colonne, inoltre l applicazione deve essere estremamente chiara e comprensibile da chiunque: non ci si può concedere il lusso della prolissità, né ci si può perdere in lungaggini. È necessario colpire immediatamente nel segno, anche per evitare di annoiare l utente che, probabilmente, dovrà utilizzare questo servizio molte volte. Quanto più l interfaccia è immediata e diretta e migliore sarà l impatto sul cliente. Per questi motivi si è scelto di organizzare la MMI (Man Machine Interface) in un numero di livelli ridotto: gli innestamenti tra le finestre non possono superare le tre schermate. 16
Questo concetto può essere meglio spiegato con l aiuto della Figura 8.7, che illustra l organizzazione globale dell interfaccia utente di questa particolare applicazione. 1 -Login- --------------- Username: [ ] Password: [ ] Entra 2 3 4 -Saldo- ---------------.: Eu.: Movimenti? ListaCC? Push? ON/OFF -SceltaCC- --------------- Quale conto? 1234/56 2345/67 3456/78 4567/89 -Errore- --------------- Nessun conto. Riprova 5 -Movimenti- --------------- ±. il per Avanti Indietro Saldo 6 -Movimenti- --------------- Nessun movimento disponibile. Saldo Figura 8.7: organizzazione dell interfaccia utente. Come si vede, i livelli sono esattamente tre: uno di login (di cui non si può fare a meno, anche se questo livello non produce alcuna informazione, dal punto do vista dell utente), uno per la visualizzazione del saldo, della lista eventuale dei conti correnti, dell errore; infine il terzo livello riguarda i movimenti veri e propri, sia che ci siano, sia che non ci siano. La fase di progettazione si è dovuta occupare dei dettagli implementativi, ma è stata anche estremamente interessante, nonostante le sue oggettive difficoltà. Il Class diagram si è arricchito di nome cognome username password id_utente ::Utente prefisso numero setpref setnum setusername setpassword verificaup sceglinumerocc setpush aggiornautente 1 ::SMSPoster prefisso numero url msg hidden setprefisso setnumero send setproxy setmsg sethidden ::Pager dimensione numerodecktotale numerodeckcorrente trovadeckprec preparadeck trovadecksucc 1..* push numerocc saldo getpush ::CC setpush setsaldo getnumerocc getsaldo setnumerocc getlistamovimenti 1 * data causale ::Movimento importo setdata setcausale setimporto 17 ::Listener inviadeckmov-5- inviasaldo-2- inviapushsms-6- invialogin-1- inviaerrore-4- inviasceltacc-3- Figura 8.8: Class diagram scaturito dalla fase progettuale.
tre nuove classi, Listener, Pager e SMSPoster, come si può vedere in Figura 8.8. Oltre ad un arricchimento informativo delle classi originarie, le tre nuove classi derivano da problematiche implementative: -PushSMS- --------------- Aggiornamento in tempo reale: ON OFF -Movimenti- --------------- Nessun movimento disponibile. Saldo Figura 8.9: sostituzione tra finestre. la classe Listener (ascoltatore) è quella che rimane in ascolto delle chiamate dei clienti e che ne smista le richieste alle altre classi; è anche la responsabile dell interfaccia con l utente, anche se i metodi numerati (quelli che contengono nella parte finale del loro nome un numero), che corrispondono all invio di ognuna delle schermate viste in Figura 8.9, non sono esattamente quelli implementati nell applicazione finale. In particolare il metodo inviapushsms-6- non è stato realizzato, perché la Figura 8.9 è in realtà un ottimizzazione di una precedente idea, dopo la sostituzione tra finestre visualizzata in Figura 8.9: in essa esisteva una finestra appositamente dedicata al settaggio della variabile Push, che è poi stata sostituita dalla finestra riguardante l errore per mancanza di movimenti. Questa sostituzione è stata effettuata per rendere l applicazione quanto più sintetica possibile, visto che, comunque l utente, nella schermata 2 del saldo, vede l informazione sullo stato del servizio di aggiornamento automatico o push (ON oppure OFF). Ogni volta che l utente selezionerà il link Push?, la variabile push assumerà il valore contrario rispetto a quello attuale. L utente potrà verificare l avvenuto aggiornamento immediatamente, dalla schermata del saldo. La classe Pager (paginatore) si occupa di organizzare in porzioni di dati trasportabili On- The-Air (deck) le informazioni sui movimenti; questi contengono la data, l importo e la causale e sono più di uno; non deve capitare che in un deck sia visualizzata una data e l importo, mentre la causale viene relegata nel deck successivo: queste tre informazioni non devono essere spezzettate. La classe Pager si occupa proprio di questo, rispettando, comunque, il limite dei 1400 byte alla volta per deck (in realtà si è approssimato per difetto, imponendo un limite ai dati sui movimenti di 900 byte, per sicurezza: comunque questo attributo è settabile a piacere). Infatti, le specifiche WAP definiscono un limite di default sulla dimensione di un SDA (Service Data Unit) all interno del Wireless Session Protocol (WSP) di 1400 byte. Questo può limitare la dimensione del deck WML che può essere trasmesso dal WAP Gateway al telefono, a meno che il telefono non negozi un limite maggiore. Se la risposta eccede il limite (quello negoziato o quello di default, se il telefono non realizza la negoziazione), di default il Gateway ritornerà un messaggio di errore al dispositivo. Questo messaggio di errore viene inteso come un aiuto agli sviluppatori e agli utenti, anche se i telefoni più diffusi non faranno altro che avere un crash, o riporteranno un errore per sopraggiunto timeout, aspettando la risposta. La classe SMSPoster contiene al suo interno le informazioni per raggiungere un particolare URL, sede del centro SMS che si occupa dello smistamento dei messaggi: le altre informazioni di cui tale centro ha, naturalmente, bisogno sono il prefisso e il numero del cellulare dell utente e il messaggio (msg) di aggiornamento sul conto corrente. L attributo hidden (nascosto) rappresenta una serie di codici identificativi, per avere il permesso di sfruttare il servizio fornito dal server attraverso il quale si accede al centro SMS. 18
In Figura 8.10 sono state anche inserite le cosiddette user class, che rappresentano ognuna una schermata di quelle viste in Figura 8.7. Da ognuna di esse partono uno o più eventi, che rappresentano l azione dell utente che seleziona uno dei link disponibili su ognuna delle schermate: in corrispondenza della 1 (Login) è possibile scatenare l evento Entra ; in corrispondenza della 2 (Saldo) si possono scatenare gli eventi Movimenti e Push ; in corrispondenza della 3 (SceltaCC) si può scatenare l evento nnnn/nn ; in corrispondenza della 4 (Errore) si può scatenare l evento Riprova ; in corrispondenza della 5 (Movimenti) si possono scatenare gli eventi Avanti, Indietro e Saldo ; in corrispondenza della 6 (PushSMS, prima che venisse cambiata) si potevano scatenare gli eventi ON e OFF. Sul DB dovranno essere create ed aggiornate le seguenti tabelle: UTENTE USERNAM E PASSWOR D ID_UTENT E PREFISSO NUMERO NOME COGNOM E CC ID_UTENT E NUM_CC SALDO PUSH MOVIMENTO ID_MOVIMEN TO NUM_CC IMPORTO DATA CAUSALE UTENTE avrà come Primary Key USERNAME e come Alternate Key ID_UTENTE. CC avrà come Primary Key NUM_CC e come Foreign Key da UTENTE ID_UTENTE. MOVIMENTO avrà come Primary Key ID_MOVIMENTO e come Foreign Key da CC NUM_CC. Tutto questo viene realizzato con il seguente codice SQL: CREATE TABLE UTENTE (USERNAME VARCHAR2(8) NOT NULL, PASSWORD VARCHAR2(8) NOT NULL, ID_UTENTE INTEGER NOT NULL, PREFISSO VARCHAR2(4) NOT NULL, NUMERO VARCHAR2(7) NOT NULL, NOME VARCHAR2(20), COGNOME VARCHAR2(20)); ALTER TABLE UTENTE ADD (PRIMARY KEY (ID_UTENTE)); CREATE TABLE CC (ID_UTENTE INTEGER NOT NULL, NUM_CC VARCHAR2(15) NOT NULL, SALDO VARCHAR2(15) DEFAULT '0', PUSH VARCHAR2(4) DEFAULT 'OFF'); 19
ALTER TABLE CC ADD (PRIMARY KEY (NUM_CC)); ALTER TABLE CC ADD (FOREIGN KEY (ID_UTENTE) REFERENCES UTENTE); CREATE TABLE MOVIMENTO (ID_MOVIMENTO INTEGER NOT NULL, NUM_CC VARCHAR2(15) NOT NULL, IMPORTO VARCHAR2(15) DEFAULT '0', DATA VARCHAR2(10) NOT NULL, CAUSALE VARCHAR2(30) DEFAULT 'IGNOTA'); ALTER TABLE MOVIMENTO ADD (PRIMARY KEY (ID_MOVIMENTO)); ALTER TABLE MOVIMENTO ADD (FOREIGN KEY (NUM_CC) REFERENCES CC); Per le prime prove, inoltre, si era popolato il DB utilizzando le seguenti stringhe SQL (si noti la scomodità di questo approccio, che ha portato a decidere di realizzare una interfaccia Web che permettesse di aggiornare il DB automaticamente). INSERT INTO UTENTE (USERNAME, PASSWORD, ID_UTENTE, PREFISSO, NUMERO, NOME, COGNOME) VALUES ('morena','ciao','1','0337','563943','morena','bonezzi'); SELECT * FROM UTENTE; INSERT INTO CC (ID_UTENTE, NUM_CC, SALDO, PUSH) VALUES ('1','1234/56','100000000','OFF'); SELECT * FROM CC; INSERT INTO CC (ID_UTENTE, NUM_CC, SALDO, PUSH) VALUES ('1','333','50000','OFF'); SELECT * FROM CC; INSERT INTO MOVIMENTO (ID_MOVIMENTO, NUM_CC, IMPORTO, DATA, CAUSALE) VALUES ('4','1234/56','-20000','25/02/2001','pizzata con amici'); SELECT * FROM MOVIMENTO; INSERT INTO MOVIMENTO (ID_MOVIMENTO, NUM_CC, IMPORTO, DATA, CAUSALE) VALUES ('5','1234/56','-50000','27/02/2001','acquisto CD'); SELECT * FROM MOVIMENTO; INSERT INTO MOVIMENTO (ID_MOVIMENTO, NUM_CC, IMPORTO, DATA, CAUSALE) VALUES ('6','1234/56','-900000','29/02/2001','viaggio'); SELECT * FROM MOVIMENTO; 20