Servizi a
valore aggiunto
per Terminali WAP compatibili
Progetto di : Reti di Calcolatori
Professore : Antonio Corradi
Realizzato da : Antonio Tozzi
Matricola : 2148/52361
E-mail : tozzi_antonio@hotmail.com
Indice
1. Introduzione
2. Scopo
3. Requisiti
7. Prestazioni dell’architettura
1. Introduzione
Le informazioni reperibili attraverso Internet sono ormai incommensurabili ed accessibili con linee sempre più veloci e meno costose. Il passo successivo, è quello di creare un meccanismo che permetta di rendere raggiungibile, da terminali wireless come telefonini cellulari e Personal Digital Assistant (PDA), la grandissima quantità di informazioni di Internet e l’insieme di servizi ad essa correlati.
Studi portati avanti dai più importanti produttori di telefonia cellulare mondiale, Ericsson, Nokia e Motorola (che coprono il 75% del mercato mondiale) prevedono che la richiesta di servizi messi a disposizione dalle capacità multimediali dei telefonini, tra le quali l’accesso alle informazioni wireless da Internet/intranet e la possibilità di scambio di e-mail, seguirà l’andamento del grafico riportato nella figura 1.
Il mercato attuale propone due grandi linee guida: la telefonia cellulare ed Internet, ed ormai la convergenza è una realtà. Nel giugno del 1997, Nokia, Motorola, Ericsson e Unwired Planet si sono unite nel Wap forum (http://www.wapforum.com) con l’intento di creare uno standard utilizzabile da tutti, il cui obiettivo principale è la standardizzazione del modo con cui i dispositivi wireless come cellulari e PDA, utilizzano Internet. Il protocollo WAP (Wireless Application Protocol), rende possibile reperire direttamente dal proprio terminale qualsiasi informazione da Internet. Questo nuovo protocollo permette a tutti i telefonini compatibili WAP non solo di navigare in Internet, ma di ottenere ogni sorta di servizio e di informazione direttamente sul display del proprio telefono. Allo stesso modo di Internet, chiunque potrà fornire un servizio e tutti potranno riceverlo sul proprio terminale.
Il protocollo WAP, nasce con precise caratteristiche:
Il protocollo WAP va inteso come un protocollo di trasmissione a tutti gli effetti, che non viene però utilizzato per trasmettere dell’HTML, ma per trasmettere "pagine" WML (Wireless Markup Language), il linguaggio sviluppato ad hoc per la telefonia cellulare. Il WML è un linguaggio interpretato, ottimizzato per la trasmissione via WAP ed è strutturato per essere visualizzato sui piccoli display dei telefonini cellulari. Sul protocollo WAP, insieme al WML si può anche trasmettere codice WML Script, che è un linguaggio di scripting contenente alcune istruzioni particolari per la gestione di funzioni client side. Il commercio mobile o la possibilità di effettuare transazioni diventano in questo modo possibili.
Il modello di implementazione di applicazioni WAP è un modello Client/Server a tre stadi, come mostrato nella figura 2:
Sul Client (Terminale WAP), girano applicazioni WML e WML Script, una richiesta quando viene inoltrata utilizza il protocollo di trasporto WTP per giungere al WAP Gateway. Il WAP Gateway, sul quale gira un WML e WML Script decoder/encoder, riceve la richiesta e la trasmette al WEB Server utilizzando il protocollo HTTP. Il WEB Server riceve la richiesta, la elabora, e genera una risposta che viene ritrasmessa al WAP Gateway, che la codifica per essere ritrasmessa al Client (Terminale WAP) per essere visualizzata.
Figura 2
Un fattore importante da sottolineare è che la comunicazione tra Client (Terminale WAP) e WAP Gateway (e viceversa) avviene come comunicazione codificata, quindi compito del WAP Gateway è anche quello di decodificare e codificare le varie chiamate.
Questo settore è in continua evoluzione e si prevede in futuro anche l’inserimento della JVM (Java Virtual Machine) all’interno dei dispositivi wireless per sfruttare appieno le potenzialità del linguaggio Java.
2. Scopo
Lo scopo del progetto è quello di acquisire conoscenza sul nuovo standard di comunicazione WAP (Wireless Application Protocol), per terminali wireless ed in particolare vedere come questo si colloca ed interagisce con il tradizionale standard di comunicazione TCP/IP di Internet.
I possibili scenari che si possono presentare ad un potenziale utente WAP sono:
Un qualsiasi utente, configurando opportunamente il proprio terminale può eseguire una normale chiamata dati al proprio ISP, via Internet raggiungere il gateway pubblico (via WDP), il gateway rimette i dati sulla rete in formato HTTP, permettendo di giungere ai comuni server web, appositamente preparati a gestire contenuti WML.
Vantaggi
Svantaggi
Essendo gestiti direttamente dall’operatore, lo standard di qualità è garantito dalla competitività dell’operatore stesso e dalla concorrenza con gli altri operatori.
Vantaggi
Svantaggi
In un panorama aziendale, dove l’utilizzo dei servizi WAP è prevalentemente orientato al contatto ed alla collaborazione tra le varie componenti dell’azienda è senz’altro più produttiva la scelta di un gateway privato, collegato alla intranet aziendale.
Vantaggi
Svantaggi
L’obiettivo del progetto allora è quello di realizzare un servizio a valore aggiunto per utenti WAP ed in particolare una transazione da effettuarsi su dei Server connessi alla rete (Internet/intranet) utilizzando un terminale WAP compatibile. La transazione potrebbe essere ad es. il pagamento del taxi o la prenotazione di un film presso una sala cinematografica; nel nostro caso la transazione consiste semplicemente in una richiesta di una operazione di incremento/decremento di un contatore posto su un Server remoto.
3. Requisiti
Le parti che si mettono in gioco nel progetto sono molteplici, ed in particolare un Client (Terminale WAP) che effettua la richiesta di esecuzione della transazione, un WAP Gateway (Server WAP) che ha lo scopo di ricevere la richiesta dal Client e di smistarla opportunamente su dei Server, dei Server (Server Primario e Secondario ) che si coordinano per la corretta esecuzione della transazione. La transazione deve essere un servizio reliable, cioè deve essere garantito il corretto esito della risposta fornita al Terminale WAP e di conseguenza all’utente. Per realizzare ciò bisogna avere una comunicazione affidabile tra le varie parti dell’architettura, sia sulla rete wireless sia sulla rete Internet/intranet. L’architettura per ovviare a problemi di guasto (quindi con relativo ripristino della consistenza dei dati) e di bilanciamento del carico prevede una replicazione per quanto riguarda i Server, quindi di conseguenza la transazione (operazione) deve essere eseguita in maniera atomica su entrambe i Server, che devono controllarsi e coordinarsi tra di loro. L’architettura è fortemente centralizzata dalla presenza del Server WAP che ha la funzione di gateway tra la rete wireless e la rete Internet/intranet e ha il compito di smistare le richieste che arrivano dai Terminali WAP, in modo da tenere bilanciato il carico in ingresso ai due Server. Per ovviare ai problemi che una struttura fortemente centralizzata può comportare, si può, o replicare anche il Server WAP (con relativo protocollo di controllo e coordinamento), oppure, fare in modo che sia un componente con un grado di affidabilità maggiore rispetto ai due Server.
La realizzazione deve essere in grado di :
I problemi che possono verificarsi durante la transazione sono:
4. Architettura e coordinamento
Terminale WAP
Il Terminale WAP effettua la richiesta della transazione al WAP Server (1) e riceve l’esito del servizio (6).
WAP Server
Il WAP Server è in attesa di richieste di servizio da parte dei Terminali WAP, una volta giunta una richiesta di servizio, deve richiedere l’esecuzione dell’operazione ad uno dei Server (Primario (2) o Secondario (2’)), bilanciando il carico in ingresso, adottando una politica di Load Sharing e deve anche inviare l’esito dell’operazione al Terminale WAP (6).
Server Primario/Secondario
I due Server sono in attesa di richieste di esecuzione dell’operazione da parte del WAP Server, che adottando una politica di bilanciamento del carico Load Sharing, smista le richieste su i due Server in maniera alternata. Il Server, che riceve la richiesta dal WAP Server (ad es. (2)) diventa il Server Primario e ha il carico di coordinarsi con l’altro Server (4), che diventa il Server Secondario. L’operazione viene eseguita prima dal Server Secondario che restituisce l’esito al Server Primario (5), solo a questo punto, se l’esito dell’operazione sul Server Secondario è positivo, il Server Primario esegue l’operazione e restituisce l’esito al WAP Server (3).
Coordinamento richiesta/risposta
Il modello di richiesta della transazione è un modello client/server a tre stadi come illustrato nella figura 3.
5. Fallimento della transazione (Recovery)
Le cause prese in considerazione, che possono portare al fallimento della transazione possono essere sintetizzate in due casi fondamentali :
1. Errori di accesso al file system locale del Server che sta eseguendo l’operazione:
2. Crash di uno dei due Server (ipotesi di guasto singolo):
Per la realizzazione e simulazione del progetto sono stati utilizzati degli strumenti messi a disposizione gratuitamente dalla Nokia ed in particolare un emulatore di Terminale WAP (Nokia Toolkit versione 1.3beta) ed un Server WAP (Nokia WAP Server versione 1.0.1). Come linguaggio di programmazione per l’implementazione dei Server Primario e Secondario è stato utilizzato un linguaggio ad oggetti ed in particolare la versione 2 di Java, che con il suo modello a processi leggeri (thread) si presta molto bene alla realizzazione di Server concorrenti e paralleli ed anche per la realizzazione di Servlet. Per la comunicazione tra il Server WAP ed i Server Primario e Secondario si è utilizzata una comunicazione con connessione (protocollo a livello di trasporto TCP), per avere una certa garanzia di continuità e affidabilità.
Un Terminale WAP (cellulare o PAD) è dotato delle seguenti caratteristiche:
Esistono, inoltre, altre limitazioni legate alla tipologia di rete cellulare:
Tutte queste caratteristiche fanno sì, che un Terminale WAP sia sostanzialmente diverso da un PC collegato in rete.
Per la realizzazione del progetto, come detto si è utilizzato un emulatore di Terminale WAP fornito gratuitamente dalla Nokia, che riesce a simulare abbastanza fedelmente le caratteristiche di un cellulare, permettendo anche di scegliere se effettuare un servizio con un collegamento con connessione o senza connessione come è stabilito dal protocollo WAP. Un Terminale WAP dispone di un microbrowser ovvero di una applicazione in grado di interpretare del codice WML, (linguaggio per i microbrowser dei dispositivi wireless) ed del codice WMLScript, (linguaggio che permette di dare un minimo di dinamicità alle pagine visualizzate sul microbrowser). Prima di trasmettere, il Terminale WAP effettua una codifica in formato binario dei dati, così da snellire i dati da trasmettere. Di seguito, figura 4, è mostrato il confronto tra il numero di pacchetti necessari ad una transazione effettuata da un browser che usa HTTP 1.0 e la stessa query originata da un microbrowser WAP. Il protocollo WAP utilizza un numero inferiore di pacchetti per consegnare lo stesso contenuto.
Nella figura 5 è rappresentato lo schema di comunicazione fra il Terminale WAP ed il Server WAP, con relativo scambio di parametri.
Come Server WAP si è utilizzata una versione messa a disposizione gratuitamente (30 giorni) dalla Nokia. La caratteristica di questa versione è che può essere utilizzata sia da Server WAP che da WAP Gateway, ma la cosa più importante, è quella di fornire la possibilità di realizzare dei servizi personalizzati che possono essere montati sul Server come dei semplici moduli, che vengono implementati con delle Servlet Java. Il Server WAP (Servlet Java) è implementato come un Server concorrente e parallelo, e questo lo si ottiene in maniera estremamente semplice con le Servlet Java. L’implementazione delle Servlet Java è realizzata, in maniera tale che per ogni richiesta di servizio proveniente da un Client (Terminale WAP) venga generato un thread in cui viene messo in esecuzione il metodo service() (nel nostro caso doGet()), in questo modo si riescono a gestire richieste concorrenti di più Client. Nel nostro caso, il Server WAP (Servlet Java) ha l’obbligo, oltre ad inviare al Terminale WAP l’esito della transazione (all’interno del codice WML), di tenere bilanciato il carico delle richieste in ingresso ai due Server che si trovano a valle. Uno schema, di come lavora il Server WAP ed in particolare della Servlet Java, che rappresenta il servizio fornito all’utente è rappresentato in figura 6.
Il ruolo giocato dai due Server a valle è quello di portare a compimento la transazione in maniera atomica, in modo che lo stato dei due sia sempre consistente anche in caso di eventuali problemi come quelli considerati precedentemente. Lo schema di implementazione dei due Server è identico, entrambe sono composti di due processi che attendono una connessione, uno dall’esterno, dal Server WAP ed uno dall’interno, dall’altro Server. Il Server che accetta la connessione dal Server WAP (dall’esterno), tra i due, diventa il Server Primario e ha il carico di effettuare la connessione (interna) con l’altro Server, il Secondario, per richiedere l’esecuzione dell’operazione. Uno schema dell’architettura dei due Server è mostrata in figura 7.
Solamente se l’esito dell’operazione sul Server Secondario è andata a buon fine, il Server Primario effettua l’operazione e invia il risultato al Server WAP. Questo schema simmetrico dei due Server, con una connessione interna incrociata è stato realizzato per mantenere bilanciato il carico in ingresso ai due Server, che arriva dall’esterno, dal Server WAP. Il sistema deve essere in grado di gestire più richieste contemporaneamente quindi, come per il Server WAP, anche qui il modello dei due Server è concorrente e parallelo e viene realizzato sfruttando i processi leggeri (threads) messi a disposizione dal linguaggio di implementazione Java. La sequenza delle azioni sul Server Primario e sul Server Secondario, all’arrivo di una richiesta di servizio proveniente dal Server WAP è mostrata nella figura 8.
Il Server Primario, accettata la connessione esterna dal Server WAP, genera un nuovo processo (thread) che ha il compito di gestire la richiesta e di connettersi con il Server Secondario per richiedere l’esecuzione dell’operazione. Il Server Secondario, accettata la connessione dal Server Primario, genera un nuovo processo (thread) che gestisce la richiesta, da questo momento in poi la comunicazione tra il Server Primario ed il Server Secondario avviene attraverso i due processi (threads) generati. I due Server sono realizzati in modo che abbiano un minimo di stato, perché devono essere in grado, in caso di crash di uno dei due, di accorgersene e quindi comportarsi di conseguenza attivando un protocollo di recovery. Un limite a questa architettura è dato dal numero di processi (thread) che il sistema permette di creare e di gestire con una certa efficienza.
7. Prestazioni dell’architettura
La catena di richiesta/risposta messa in gioco in questa architettura, porta a considerare una serie di fattori che sono più o meno importanti per quelle che sono le prestazioni stesse del sistema. Lo schema di base per analizzare le prestazioni del sistema è riportato in figura 9.
Abbiamo detto in precedenza che la caratteristica del servizio è che deve essere un servizio reliable, cioè deve essere garantita all’utente la correttezza della risposta, però un fattore che non deve essere trascurato è anche il tempo di risposta al servizio. Ad influenzare questo tempo di risposta al servizio, ci sono tutta una serie di fattori che dipendono sia dalla infrastruttura di comunicazione, sia da come sono implementati i vari Server.
Tempo di comunicazione
Per quanto riguarda l’infrastruttura di comunicazione, i tempi che vengono messi in gioco sono quelli della comunicazione sulla rete wireless e quelli sulla rete Internet/intranet:
Tc = 2*Tc (rete wireless) + 4*Tc (rete Internet/intranet)
Per la comunicazione sulla rete wireless è possibile avere comunicazione con connessione o senza connessione, quindi si avranno tempi diversi a seconda della scelta, se con garanzia di affidabilità o meno. Per la comunicazione sulla rete Internet/intranet si è scelta una comunicazione con connessione (protocollo a livello trasporto TCP), per avere una certa garanzia di affidabilità. Questo inevitabilmente porta a dei tempi di comunicazione maggiori a causa delle due connessioni che si devono instaurare (protocollo di connessione a tre fasi) tra il Server WAP ed il Server Primario e tra il Server Primario ed il Server Secondario.
Per quanto riguarda i Server, i tempi che vengono messi in gioco sono molteplici e dipendono anche dalla particolare implementazione dei Server stessi.
Tempo di servizio
E’ il tempo che il Server impiega per effettuare il servizio :
Ts = Ts_wap (Server WAP) + Ts_I° (Server I°) + Ts_II° (Server II°)
Tempo di accodamento
E’ un tempo che dipende dal numero di richieste (traffico) che il Server si trova e gestire in un determinato istante :
Tq = Tq_wap (Server WAP) + Tq_I° (Server I°) + Tq_II° (Server II°)
I due tempi successivi dipendono dal fatto che i Server sono implementati con un modello concorrente e parallelo, quindi, con la generazione di un processo (thread) per ogni richiesta effettuata dal client (Terminale WAP).
Tempo di generazione
E’ un tempo che si ha nella fase di generazione dei processi (thread) per la gestione delle singole richieste dei client (Terminali WAP):
Tg = Tg_wap (Server WAP) + Tg_I° (Server I°) + Tg_II° (Server II°)
Tempo di interleaving
Questo è un tempo che va ad influire positivamente sul tempo di risposta al servizio, per es. nei casi in cui ci sono delle attese per I/O :
Ti = Ti_wap (Server WAP) + Ti_I° (Server I°) + Ti_II° (Server II°)
Quindi, il Tempo di risposta al servizio è caratterizzato dalla somma dei seguenti termini:
Trs = Tc + Ts + Tq + Tg + T i
Il Nokia WAP Server fornisce un interessante parametro che è l’intervallo di tempo trascorso dall’arrivo della richiesta di servizio, all’invio della risposta al Terminale WAP. Quindi è possibile effettuare delle simulazioni del sistema e vedere quali sono i tempi di risposta del servizio su i tre Server.
Transazione con esito positivo
| N° Terminali WAP | Prova 1 (ms) | Prova 2 (ms) | Prova 3 (ms) | Prova 4 (ms) |
| 1 | 1162 | 1112 | 1162 | 1111 |
| 2 | 1422 | 1422 | 1181 | 1132 |
| 2344 | 1562 | 1462 | 1212 | |
| 3 | 1192 | 1101 | 1161 | 1122 |
| 1923 | 1142 | 1532 | 1152 | |
| 2923 | 2364 | 2684 | 1422 |
Transazione con esito negativo
| N° Terminali WAP | Prova 1 (ms) | Prova 2 (ms) | Prova 3 (ms) | Prova 4 (ms) |
| 1 | 1101 | 1092 | 1092 | 1081 |
| N° Terminali WAP | Prova 1 (ms) | Prova 2 (ms) | Prova 3 (ms) | Prova 4 (ms) |
| 1 | 1112 | 1132 | 1132 | 1111 |
| N° Terminali WAP | Prova 1 (ms) | Prova 2 (ms) | Prova 3 (ms) | Prova 4 (ms) |
| 1 | 2103 | 2052 | 2033 | 2093 |
N° Terminali WAP |
Prova 1 (ms) |
Prova 2 (ms) |
Prova 3 (ms) |
Prova 4 (ms) |
1 |
3255 |
3375 |
3305 |
3225 |