Capitolo 5 L`architettura WAP

Transcript

Capitolo 5 – L’architettura WAP: background
Capitolo 5
L’architettura WAP
Il Wireless Application Protocol (WAP) è il risultato degli sforzi del WAP Forum per
promuovere specifiche largamente appoggiate dagli ambienti industriali, riguardanti la tecnologia
per lo sviluppo di applicazioni e servizi che operano su reti di comunicazione wireless: WAP,
insomma, definisce strutture applicative e protocolli di rete per dispositivi wireless (telefoni
cellulari, PDA, ecc.).
Le specifiche estendono e influenzano sia le tecnologie delle reti mobili (come gli standard per
le reti di dati digitali) sia le tecnologie Internet (come XML, URL, i linguaggi di scripting e vari
formati di contenuto): tutti questi sforzi hanno come obiettivo quello di aiutare gli operatori, gli
industriali e gli sviluppatori a fronteggiare le sfide che si presentano nella costruzione di servizi
avanzati e differenziati e nella loro implementazione veloce e flessibile.
Gli obiettivi del WAP Forum sono:
• portare contenuti Internet e servizi avanzati sui telefoni cellulari ed altri terminali wireless;
• creare specifiche globali del protocollo che possano essere valide per differenti tecnologie di
rete;
• abilitare la creazione di contenuti ed applicazioni adattabili ad una grande varietà di portatori
e dispositivi;
• abbracciare ed estendere gli standard e le tecnologie esistenti.
Le specifiche riguardanti l’architettura WAP (liberamente scaricabili all’indirizzo
www.wapforum.org) si propongono di presentare il sistema e l’architettura del protocollo essenziali
per realizzare gli obiettivi del WAP Forum: esse rappresentano il punto di partenza per la
comprensione della tecnologia WAP.
5.1. Background
WAP si posiziona come punto di convergenza di due tecnologie di rete in rapida evoluzione:
comunicazioni wireless e Internet. Entrambi i mercati del wireless e di Internet stanno crescendo
molto velocemente e stanno continuamente raggiungendo nuovi clienti; la crescita esplosiva di
Internet ha alimentato la creazione di nuovi servizi di informazione, ma la maggior parte della
tecnologia sviluppata per Internet è stata progettata per computer desktop potenti, connessi a reti
affidabili dotate di banda di ampiezza medio-alta.
I dispositivi wireless presenti sul mercato di massa, al contrario, sono caratterizzati da un
ambiente computazionale primitivo, se confrontato con quello dei desktop: a causa delle loro
limitazioni tendono ad avere CPU deboli, poca memoria (ROM e RAM), severe limitazioni sul
consumo di potenza (batterie limitate), display piccoli (se non piccolissimi), e scomodi meccanismi
di immissione dati (ad esempio il tastierino alfanumerico). Analogamente, le reti per le
comunicazioni wireless presentano un ambiente di comunicazione ristretto, se confrontato alle reti
wired: a causa di limitazioni di base riguardanti l’energia delle onde, lo spettro delle frequenze
1
disponibile e la mobilità, le reti wireless tendono ad avere minore ampiezza di banda, maggiore
latenza, minore stabilità di connessione, disponibilità di servizio meno predicibile.
Le reti mobili stanno crescendo in complessità insieme al costo per l’approvvigionamento di
servizi a valore aggiunto. Per venire incontro alle richieste degli operatori delle reti mobili, le
soluzioni devono rispettare i seguenti principi:
• interoperabilità: terminali di diversi produttori devono poter comunicare attraverso reti
diverse tramite WAP;
• scalabilità: gli operatori delle reti mobili devono poter adattare i servizi alle necessità dei
clienti;
• efficienza: gli sviluppatori devono garantire qualità di servizio, compatibilmente con il
comportamento e le caratteristiche della rete mobile;
• affidabilità: gli operatori devono fornire un servizio consistente la cui disponibilità sia
predicibile;
• sicurezza: gli sviluppatori devono abilitare l’estensione dei servizi a reti potenzialmente non
protette, preservando comunque l’integrità e la privacy dei dati dell’utente;
• disponibilità: gli sviluppatori devono proteggere gli utenti da problemi come la negazione
del servizio.
Molte delle attuali reti mobili rendono disponibili agli utenti servizi avanzati: gli operatori delle
reti mobili si sforzano di presentarli in modo semplice ed allettante, anche per promuovere un
aumento nell’uso dei servizi stessi e per evitare che le adesioni calino. Funzioni standard, come il
controllo di chiamata, possono essere potenziate usando la tecnologia WAP, per fornire
un’interfaccia personalizzabile, mentre, per esempio, il suo utilizzo in servizi come il trasferimento
di chiamata può fornire la possibilità di scegliere, tramite un’interfaccia, se accettare la chiamata,
inviarla ad un’altra persona o a una casella vocale ecc.
Le specifiche WAP sono indirizzate agli operatori delle reti mobili e agli sviluppatori del
software, che potrebbero anche aver bisogno di adattare l’esistente tecnologia alle particolari
richieste del mercato di massa, ai dispositivi wireless commercialmente disponibili, eventualmente
introducendo nuove soluzioni tecnologiche, quando ciò possa rivelarsi utile.
Gli imperativi individuati dal WAP Forum per favorire il successo del protocollo WAP sono:
• sfruttamento degli standard esistenti dove sia possibile;
• definizione di una architettura a livelli, scalabile ed estensibile;
• supporto di quante più reti wireless sia possibile;
• ottimizzazione per portatori con banda ristretta ed alta latenza;
• ottimizzazione per un uso efficiente delle risorse del dispositivo;
• garanzia di supporto per applicazioni e comunicazioni sicure;
• abilitazione della creazione di MMI (Man Machine Interface) con la massima flessibilità e
controllo;
• garanzia di accesso alle funzionalità del dispositivo, come l’indicazione del controllo di
chiamata;
• facilitazione dell’approvvigionamento del servizio proveniente dall’operatore di rete e da
terze parti;
• supporto all’interoperabilità, con la definizione degli elementi obbligatori e facoltativi nelle
specifiche;
• creazione di un modello di programmazione e integrazione per i servizi di telefonia vera e
propria.
5.1.1. L’architettura WWW
L’architettura Internet WWW (World Wide Web) fornisce un modello di programmazione
flessibile e potente, basato su quello client/server, come si può vedere in Figura 5.1. Le applicazioni
e i contenuti sono presentati in formati di dati standard e sono gestiti da applicazioni note come
2
Web browser, che inviano sulla rete richieste di oggetti identificati da nomi precisi ai server di rete,
i quali a loro volta rispondono con dati codificati, usando formati standard.
Gli standard WWW specificano la maggior parte dei meccanismi necessari per costruire una
applicazione general purpose, includendo tra essi:
• modello di naming standardizzato: tutti i server e i loro contenuti sul Web sono nominati
univocamente attraverso lo standard Internet URL (Uniform Resource Locator):
• tipizzazione dei contenuti: a tutti i contenuti presenti sul Web viene assegnato un tipo
particolare, permettendo così ai Web browser di elaborare in modo corretto il contenuto
basandosi sul tipo;
• formati standardizzati: tutti i Web browser supportano un insieme di formati di contenuto
standard, che includono HTML (Hyper Text Markup Language), il linguaggio di scripting
JavaScript e una grande numero di altri formati;
• protocolli standardizzati: i protocolli di rete sono standardizzati e permettono a qualsiasi
Web browser di comunicare con qualsiasi Web server; il protocollo più comunemente usato
su WWW è HTTP (Hyper Text Transfert Protocol).
Tale infrastruttura permette agli utenti di raggiungere facilmente un grande numero di
applicazioni e servizi prodotti da terze parti e agli sviluppatori di creare facilmente applicazioni e
contenuti per una grande comunità di utenti.
Figura 5.1: modello WWW client/server.
Il Web definisce tre classi di entità di rete:
• server di origine: server sul quale una data risorsa (contenuto) risiede o viene creata;
• proxy: programma intermedio che agisce sia come server sia come client, con l’obiettivo di
rispondere a richieste da parte di altri client. Il proxy tipicamente si trova tra un client e un
server che non hanno la possibilità di comunicare in modo diretto, ad esempio a causa di un
firewall, e allora si provvede alla gestione delle richieste tramite il proxy o passandole oltre,
con un’eventuale traduzione, ad altri server;
• Gateway: server che si comporta da intermediario per conto di altri server. Diversamente dal
proxy, un Gateway riceve richieste come se fosse il server di origine per le risorse cercate: il
3 ruolo del Gateway.
Figura 5.2: il
client che ha fatto la richiesta può non essere consapevole di stare comunicando con un
Gateway. Il Gateway è un elemento fondamentale dell’architettura WAP, come si può
facilmente capire osservando la Figura 5.2.
5.1.2. L’architettura WAP
Il modello di programmazione WAP è simile al modello di programmazione tradizionale del
Web, che, da parte sua, fornisce tutta una serie di benefici alla comunità degli sviluppatori, essendo
un modello di programmazione intuitivo, con una architettura collaudata e la capacità di sfruttare
tool esistenti (ad esempio Web server, tool XML, ecc.). Naturalmente è stata messa a punto una
serie di ottimizzazioni ed estensioni per adattare le caratteristiche dell’ambiente wired a quelle
dell’ambiente wireless, ma, dove è stato possibile, sono stati adottati gli standard esistenti o sono
comunque stati usati come punto di partenza della tecnologia WAP.
Il formato di applicazioni e contenuti WAP è stato scelto in modo da risultare simile al classico
formato utilizzato sul Web; il contenuto è trasportato usando un insieme di protocolli di
comunicazione standard concettualmente simili ai protocolli di comunicazione WWW e un
microbrowser nel terminale wireless coordina l’interfaccia utente, risultando, così, analogo ad un
Web browser.
Anche WAP definisce un insieme di standard che abilitano la comunicazione tra i terminali
mobili e la rete, includendo tra essi:
• modello di naming standardizzato: per identificare il contenuto WAP sui server di origine
sono usati i medesimi URL del WWW;
• tipizzazione dei contenuti: tutti i contenuti WAP sono dotati di uno specifico tipo,
consistente con la tipizzazione WWW; questo permette all’interfaccia utente (User Agent)
WAP di trattare correttamente il contenuto, basandosi sul suo tipo;
• formati standardizzati: i formati WAP hanno preso spunto dalla tecnologia utilizzata sul
Web, includendo marcatori per la formattazione del contenuto su schermo (nel linguaggio
WML), il set di caratteri (UNICODE: www.unicode.org), un linguaggio di scripting
(WMLScript), informazioni sul calendario (Electronic Calendaring and Scheduling
Exchange Format: vCalendar) e immagini (formato WBMP);
• protocolli di comunicazione standardizzati: i protocolli di comunicazione WAP abilitano la
comunicazione tramite le richieste effettuate dal browser del terminale mobile verso il Web
server di rete. I tipi di contenuto WAP e i protocolli sono stati ottimizzati per il mercato di
massa dei dispositivi mobili, sfruttando la tecnologia dei Gateway per connettere il dominio
wireless con il WWW e spostando su essa molto del peso computazionale necessario per
l’ottimizzazione. Il WAP è caratterizzato dai seguenti componenti software:
Ø convertitore di protocollo: traduce le richieste provenienti dallo stack del
protocollo WAP (WAE, WSP, WTP, WTLS e WDP) per adattarle allo stack
del protocollo WWW (HTTP e TCP/IP) e viceversa;
Ø codificatori e decodificatori di contenuto: i codificatori traducono il
contenuto WAP in un formato codificato compatto, per ridurre la
dimensione dei dati da far viaggiare sulla rete mobile; questa traduzione
assicura che gli utenti dei terminali mobili possano accedere ad una
grande varietà di contenuti ed applicazioni WAP e che, nello stesso
tempo, lo sviluppatore possa costruire servizi ed applicazioni supportati
da una larga base di dispositivi mobili.
L’intermediazione effettuata dal Gateway WAP permette a contenuti ed applicazioni di essere
ospitati su server WWW standard e di essere sviluppati usando tecnologie collaudate, come lo
scripting CGI.
4
WAP
Gateway
Web
Server
HTML
Filter
Client WAP
WTA
Server
Figura 5.3: esempio di rete WAP.
Mentre l’uso classico di WAP prevede un Web server, un Gateway e un client WAP,
l’architettura WAP può anche supportare altre configurazioni: ad esempio è possibile creare un
server di origine che includa le funzionalità del Gateway. Un tale server potrebbe essere usato per
facilitare la realizzazione di soluzioni di sicurezza end-to-end o applicazioni che richiedono un
miglior controllo degli accessi o una garanzia di responsabilità.
Nell’esempio di Figura 5.3 il client WAP comunica con due server della rete mobile: una di esse
è il Gateway WAP, che traduce le richieste WAP in richieste WWW, permettendo quindi al client
WAP di dialogare con un qualsiasi Web server, e codificando le risposte provenienti dal Web server
nel formato binario compatto comprensibile dal client. Se il Web server fornisce contenuto WAP
(ad esempio WML), il Gateway WAP lo recupera direttamente dal Web server, mentre invece, se il
Web server fornisce contenuto WWW (come HTML), viene utilizzato un filtro per tradurre il
contenuto WWW in contenuto WAP: per esempio un filtro HTML può trasformare HTML in
WML.
Il server WTA (Wireless Telephony Application), invece, è un esempio di server di origine o di
Gateway che risponde direttamente a richieste provenienti dal WAP client: viene usato
generalmente per fornire un accesso WAP alle infrastrutture di telecomunicazione del provider della
rete wireless.
Figura 5.4: architettura WAP.
WAP abilita una infrastruttura di sicurezza flessibile che si focalizza non solo sul compito di
fornire sicurezza alla connessione in sé tra un client WAP e un server, ma anche attraverso tecniche
crittografiche applicate ai contenuti stessi. Se un browser e un server di origine vogliono una
sicurezza end-to-end, essi possono comunicare direttamente usando il protocollo WAP: la sicurezza
end-to-end, però, può essere realizzata solamente se lo stesso Gateway WAP è affidabile, ad
esempio essendo situato nello stesso luogo fisicamente sicuro in cui è situato anche il server di
origine.
5
L’architettura WAP fornisce un ambiente scalabile ed estensibile, adatto allo sviluppo di
applicazioni per dispositivi di comunicazione mobili: questo obiettivo è raggiunto attraverso una
progettazione a livelli dell’intero stack del protocollo, come si può vedere dalla Figura 5.4.
Ognuno dei 5 livelli dell’architettura è accessibile dai livelli superiori, così come anche da altri
servizi ed applicazioni: infatti, questa architettura a livelli abilita altri servizi all’utilizzo delle
potenzialità dello stack WAP, attraverso un insieme di ben definite interfacce, in modo tale che
applicazioni esterne possano accedere direttamente ai livelli di sessione, transazione, sicurezza e
trasporto.
5.2. WAE (Wireless Application Environment)
Il WAE è un ambiente per applicazioni general purpose basato sulla combinazione di tecnologie
World Wide Web e Mobile Telephony. L’obiettivo primario di WAE è quello di stabilire un
ambiente di interoperabilità che permetta agli operatori e ai fornitori di costruire applicazioni e
servizi che possano raggiungere una larga varietà di differenti dispositivi wireless in modo
efficiente e semplice. WAE include un microbrowser che fornisce le seguenti funzionalità:
• Wireless Markup Language (WML): linguaggio a marcatori leggero, simile a HTML, ma
ottimizzato per l’uso in terminali mobili per non congestionare il canale di comunicazione,
normalmente così ristretto, tra un client mobile e un server. Il protocollo WAP prevede la
codifica di WML in una forma bytecode binaria a token, che può portare ad una consistente
diminuzione della dimensione delle informazioni trasmesse al dispositivo client. Il
Codificatore WML esegue la conversione del formato WML nel formato compresso
chiamato WAP Binary XML (WBXML). Questa conversione in WBXML può essere
realizzata al volo sul server, ma più spesso viene fatta off- line, se il contenuto non ha la
necessità di essere cambiato dinamicamente durante una richiesta da parte di uno User Agent
WAP. Naturalmente può essere utile agli sviluppatori essere in grado di decodificare un
codice WML codificato in formato binario per fargli assumere una forma plaintext leggibile
da un essere umano: questo obiettivo può essere raggiunto grazie all’utilizzo di un
decodificatore.
• WMLScript: linguaggio di scripting leggero, simile a JavaScript™, anche se tra i due ci
sono tante differenze che, come al solito, servono per ottimizzare la comunicazione su un
canale di trasmissione wireless. La differenza maggiore consiste nel fatto che nelle
specifiche di WMLScript sono stati definiti sia un formato bytecode sia il relativo interprete;
WMLScript viene trasformato in bytecode e poi trasmesso al client mobile, mentre dal lato
client c’è un interprete in grado di eseguire il bytecode stesso. WMLScript è un linguaggio
tipato dinamicamente nel senso che è in grado di eseguire una conversione del tipo delle
variabili, è case sensitive, permette l’uso delle funzioni, contiene vari controlli di flusso.
• Wireless Telephony Application (WTA) e Wireless Telephony Application Interface
(WTAI): servizi di telefonia ed interfacce di programmazione; questa estensione fornisce
una interfaccia alle classiche applicazioni telefoniche dei telefoni mobili, come ad esempio
metodi per il controllo di chiamata, per l’invio di messaggi, per la manipolazione di rubriche
telefoniche, ecc.
• Supporto per ben precisi formati di dati: immagini, rubriche telefoniche e calendario.
Il WAE è stato costruito senza fare alcuna assunzione sul tipo di modello MMI (Man Machine
Interface) supportato, in modo da fornire agli sviluppatori solo un metodo generico per progettare le
applicazioni WAP. La mappatura di una applicazione WAP in un particolare MMI diventa un
compito specifico dello User Agent, che si occupa dell’interfaccia utente sul microbrowser.
L’architettura WAE è rivolta principalmente agli aspetti client side dell’architettura WAP, cioè
tutto ciò che riguarda l’interfaccia utente: è definita principalmente in termini di schemi di rete,
formato dei dati, linguaggio di programmazione e servizi condivisi. Internet ed il mondo WWW
6
Capitolo 5 – L’architettura WAP: WAE (Wireless Application Environment)
hanno ispirato e motivato molti aspetti delle specifiche del WAE: ne segue, quindi, un approccio
simile.
5.2.1. Il modello
WAE adotta un modello molto simile a quello WWW: tutti i dati sono specificati in formati
simili; per quanto riguarda il trasporto degli stessi si utilizza un protocollo standard nel dominio
WWW ed un protocollo HTTP- like nel dominio wireless. WAE migliora alcuni standard WWW in
modo da preservare le caratteristiche dei terminali e della rete mobile.
WAE assume l’esis tenza di un Gateway con funzionalità di codifica e decodifica dei dati verso e
da il client mobile, come si può vedere in Figura 5.5: lo scopo della codifica dei dati è quello di
minimizzarne la dimensione in modo da ridurre la banda occupata e l’energia richiesta in fase di
computazione dei dati dal lato client.
Figura 5.5: modello logico di WAE.
I principali elementi del modello WAE sono:
• WAE User Agent (interfaccia utente): software client-side che permette la visualizzazione
dei dati sul dispositivo dell’utente finale. L’interfaccia utente è integrata nell’architettura
WAP ed è a tutti gli effetti come un browser: serve per la visualizzazione di WML
codificato e WMLScript compilato;
• generatore di contenuto: applicazione o servizio di un server di origine (come ad esempio un
CGI script) che produce dati in formati standard, in risposta ad una richiesta proveniente
dallo User Agent del terminale mobile. WAE non specifica un generatore di contenuto
standard, ma si aspetta che sia uno dei tanti server di origine comunemente usati oggi nel
mondo WWW;
• decodificatore standard dei dati: un insieme ben definito di codifiche dei dati permette allo
User Agent (browser) di interpretare correttamente i dati. Lo standard di codifica include la
codifica compressa del WML, la codifica dei bytecode per WMLScript ed un formato
standard per le immagini ed altri tipi di dati.
7
Figura 5.6: modello di Push WAE.
Non è sempre vero, però, che tutti i dati ricevuti dal terminale arrivino in risposta a particolari
richieste dell’utente: il WTA, per esempio, è in grado di generare un meccanismo che permette al
server di origine di distribuire dati al terminale senza che questi ne abbia fatto specifica richiesta: si
tratta del modello basato sul Push illustrato in Figura 5.6. (si consulti il Capitolo 7 per ulteriori
dettagli).
In alcuni casi, inoltre, ciò che il server di origine invia al terminale dipende dalle caratteristiche
del dispositivo stesso: queste sono comunicate al server di origine attraverso un meccanismo
standard di negoziazione che permette alle applicazioni di determinare le qualità peculiari dello
User Agent (come ad esempio la versione WML/WMLScript supportata, il formato delle immagini
supportato, eventuali supporti per il floating point, ecc.).
La situazione in cui un browser deve connettersi attraverso un proxy per raggiungere un server
di origine è molto simile al caso dei dispositivi wireless in cui l’accesso al server avviene attraverso
il Gateway. La maggior parte delle comunicazioni tra il browser ed il Gateway avviene usando
WSP, disinteressandosi del protocollo di comunicazione del server di destinazione. L’URL, usato
per trovare il contenuto desiderato, specifica sempre il protocollo di comunicazione usato dal server
di origine ed è indipendente da quello usato tra il browser del dispositivo mobile ed il Gateway. Il
Gateway è il responsabile delle conversioni di protocollo: in fase di richiesta traduce da WSP in un
altro protocollo (quello del server) ed in fase di risposta dal protocollo usato dal server a WSP.
Come esempio pensiamo ad un utente con un telefono WAP che effettua una richiesta usando uno
specifico URL. Il browser del terminale si connette al Gateway attraverso il protocollo WSP ed
invia una richiesta GET per quell’URL specifico. Il Gateway individua, attraverso l’URL,
l’indirizzo dell’host e crea con questo una sessione HTTP. Il server HTTP contattato esegue la
richiesta ed invia una risposta al Gateway che la codifica e la restituisce al browser, tramite la
sessione precedentemente aperta sul protocollo WSP.
L’esistenza del Gateway è obbligatoria, ma è concepibile immaginare un server di origine che
inglobi al proprio interno il WAP Gateway, con il relativo Codificatore WML e il relativo
compilatore WMLScript; inoltre è possibile memorizzare staticamente (o in cache) servizi del
server direttamente sottoforma di token WML e/o sottoforma di bytecode WMLScript per evitare la
conversione al volo del deck.
L’interazione tra l’utente ed il server d’origine avviene per mezzo di WML: quando un utente
desidera accedere ad un particolare servizio del server di origine, gli invia una richiesta attraverso lo
User Agent usando uno schema URL (ad esempio utilizzando il metodo HTTP GET). Il server
risponde inviando un singolo deck (normalmente in formato testuale). Il codificatore WML
(Encoder in Figura 5.7) residente nel Gateway (il Gateway in questo esempio è inglobato all’interno
del server di origine) converte ogni deck WML nel corrispettivo formato binario che viene restituito
al client, in modo che questi possa interpretarlo e visualizzarlo. Inoltre il Gateway può eseguire
alcune ottimizzazioni, basandosi sulle caratteristiche del client (ciò avviene solo se vi è stata una
effettiva negoziazione tra il client ed il Gateway).
8
Nel caso di WMLScript il concetto è del tutto analogo, con la sola differenza che il Gateway ha
al suo interno un compilatore che compila la risposta del server in bytecode da inviare al client
(WMLScript Compiler, in Figura 5.7).
Figura 5.7: architettura logica dello User Agent con Gateway inglobato nel server di origine.
5.2.2. I componenti
WAE è diviso in due livelli logici, come si può vedere in Figura 5.8:
• User Agent: include elementi come il browser, un editor dei messaggi, una rubrica, ecc.;
• servizi e formati: include gli elementi ed i formati accessibili dal browser quali il WML, il
WMLScript, il formato delle immagini, ecc.
WAE separa i servizi dallo User Agent pensando ad un ambiente con più di un User Agent.
Questo punto di vista logico, però, non preclude né forza nessuna implementazione standard: è
possibile riunire tutti i servizi in un unico User Agent o distribuirne uno per ogni User Agent. La
scelta è lasciata agli sviluppatori.
5.2.2.1. User Agent
Lo User Agent fondamentale per il WAE è il WML User Agent. Il WAE permette inoltre
l’integrazione di un User Agent WTA per consentire l’accesso e le interazioni con le caratteristiche
dei telefoni mobili, come ad esempio il controllo di chiamata.
Figura 5.8: componenti del client.
I servizi e i formati supportati dagli User Agent sono:
• WML
• WMLScript
• Formato dei dati supportati dal WAE
9
5.2.2.2. WML
WML è un linguaggio basato sui tag ed è specificato come tipo di documento XML; inoltre è
ottimizzato per l’interazione con utenti che hanno a disposizione dei terminali aventi display
piccoli, possibilità di input limitate, connessioni aventi a disposizione una banda ridotta, limitate
risorse di memoria e limitate risorse computazionali.
Il WML risultante ha un’implementazione basata su card e deck. Una interazione con un utente
è descritta da un insieme di card, raggruppate insieme in un unico documento (deck). Dal punto di
vista logico un utente naviga attraverso un insieme di card: può spostarsi da una card all’altra, può
effettuare delle scelte, può richiedere informazioni. Le istruzioni presenti in una singola card
possono invocare servizi che necessitano di particolari interazioni con il server di origine.
I deck WML possono essere memorizzati in un file statico o in un server di origine o possono
essere generati dinamicamente dal server. Ogni card in un deck contiene una specifica per una
particolare interazione con l’utente. Il WML lascia ampia libertà di azione agli sviluppatori per
quanto riguarda l’implementazione dell’interfaccia MMI (Man Machine Interface): è libera la scelta
dell’implementazione della richiesta da parte dell’utente ed inoltre lo User Agent deve decidere
come presentare gli elementi all’interno di una card in base alle caratteristiche del dispositivo stesso
(se si ha a disposizione un display ampio si può scegliere di visualizzare tutte le informazioni della
card, altrimenti le si frammenta in più unità). Il WML include inoltre le seguenti caratteristiche:
• supporto per testi ed immagini: il WML lascia una ampia libertà di scelta per quanto
riguarda la rappresentazione dei dati all’utente finale. Il WML fornisce vari elementi di testo
(come ad esempio il grassetto, il corsivo, le maiuscole, ecc.); vari modelli di line break (line
wrapping, line wrapping suppression, ecc.); vari modelli di tabulazione;
• supporti per l’input utente: WML include un piccolo insieme di meccanismi di input; per
esempio supporta la classica modalità della casella di testo da riempire con i propri dati,
oppure una option selection che presenta una lista di opzioni selezionabili;
• navigazione e Stack History: la navigazione include link ipertestuali stile HTML, elementi di
navigazione tra le card, storia degli elementi navigati;
• supporto internazionale: l’insieme dei caratteri presenti nei documenti WML è UNICODE:
questo abilita la rappresentazione della maggior parte delle lingue e dei dialetti;
• ottimizzazioni per connessioni a banda ristretta: il WML include un’ampia varietà di
tecnologie per ottimizzare la comunicazione. Queste comprendono la possibilità di
specificare un insieme di pagine utente in un unico trasferimento di rete. Inoltre sono
supportati una serie di meccanismi che velocizzano il tempo di risposta e diminuiscono la
quantità dei dati scambiati;
• gestione dello stato e del contesto: ogni controllo di input WML può introdurre delle
variabili. Lo stato delle variabili può essere utilizzato per modificare il contenuto o
parametrizzare una card senza dover comunicare con il server. Inoltre il tempo di vita di una
variabile può essere maggiore del singolo deck e può essere condiviso tra più deck senza
dover usare un server per salvare lo stato intermedio tra due invocazioni a deck.
Un esempio di codice WML è il seguente:
<?xml version=“1.0”?>
<!DOCTYPE wml PUBLIC”//WAPFORUM//DTD WML 1.1//EN”
“http://www.wapforum.org/DTD/wml_1.1.xml”>
<wml>
<template>
<do type=“prev”>
<noop/>
</do>
</template>
10
<card id=“Orario”title=“Orario”>
<p align=“center”>
<img src=“logo.gif”alt=“Logo”align=“top”/>
</p>
<p align=“left”>
<b>Inserire il codice:</b>
<br/>
<input maxlength=“5”type=“text”name=“Cod”/>
<do type=“accept”>
<go href=“$(Cod).wml”></go>
</do>
</p>
</card>
</wml>
Per una descrizione più ricca di WML si consulti il Capitolo 6.
5.2.2.3. WMLScript
WMLScript è un sottoinsieme del linguaggio JavaScript (ovviamente ne ridefinisce alcune
caratteristiche per adattarlo ai dispositivi mobili) e permette di aggiungere una logica procedurale ai
deck del WML. In particolare il WMLScript consente di abilitare:
• un controllo validità dell’input utente senza dover inviarlo prima al server di origine;
• un semplice accesso al dispositivo e alle periferiche;
• una interazione con l’utente senza dover continuamente far riferimento al server.
WMLScript è in grado di trattare diversi tipi di dato: boolean, integer, floating point e stringhe;
supporta diversi tipi di operazioni, quali:
• operazioni di assegnazione;
• operazioni aritmetiche;
• operazioni logiche;
• operazioni di confronto;
e fornisce inoltre una serie di categorie di funzioni, quali:
• funzioni di script locali;
• funzioni di script esterne;
• funzioni di librerie standard.
Un esempio di codice WML che richiama funzioni WML Script è il seguente:
<?xml version=“1.0”?>
<!DOCTYPE wml PUBLIC”//WAPFORUM//DTD WML 1.1//EN”
“http://www.wapforum.org/DTD/wml_1.1.xml”>
<wml>
<card id=“card1”title=“Stato”newcontext=“true”>
<p>
Seleziona un paese:
<select name=“nome_paese”tabindex=“2”>
<optgroup title=“PaesiScandinavi”>
<option value=“Danimarca”>Danimarca</option>
<option value=“Finlandia”>Finlandia</option>
<option value=“Norvegia”>Norvegia</option>
<option value=“Svezia”>Svezia</option>
11
</optgroup>
<optgroup title=“EuropaOccidentale”>
<option value=“Francia”>Francia</option>
<option value=“Germania”>Germania</option>
<option value=“Italia”>Italia</option>
<option value=“Spagna”>Spagna</option>
</optgroup>
</select>
<br/>La capitale di<br/>
$(nome_paese)<br/>
è: <u>$(capitale)</u><br/>
<!Vengono inviati ad uno script WML il simbolo dello stato,
una variabile per lo stato e una per il nome della capitale.
Lo script determinerà la capitale dello stato specificato
e la memorizzerà nella variabile “capitale”.>
<do type=“accept”label=“Trova capitale”>
<go href=“getCapitale.wmls#getCapitale(‘capitale’, ‘$(nome_paese)’)”/>
</do>
<do type=“help”label=“Help”>
<go href=“#helpCard”/>
</do>
</p>
</card>
<card id=“helpCard”title=“Help”>
<do type=“prev”label=“Back”><prev/>
</do>
<p>
Seleziona il nome dello stato e ne verrà determinata
la capitale.
</p>
</card>
</wml>
/*
* Codice dello script: dato un nome di stato e una variabile, pone
* in questa la capitale dello stato.
*/
extern function getCapitale(capitale, stato) {
var returnCapitale=“Sconosciuto;
if (“Danimarca”== stato) {
returnCapitale =“Copenhagen”;
} else if (“Finlandia”== stato) {
returnCapitale =“Helsinki”;
} else if (“Norvegia”== stato) {
returnCapitale =“Oslo”;
12
} else if (“Svezia”== stato) {
returnCapitale =“Stoccolma”;
} else if (“Germania”== stato) {
returnCapitale =“Berlino”;
} else if (“Francia”== stato) {
returnCapitale =“Parigi”;
} else if (“Spagna”== stato) {
returnCapitale =“Madrid”;
} else if (“Italia”== stato) {
returnCapitale =“Roma”;
}
WMLBrowser.setVar(capitale, returnCapitale);
/*
* e poi si accerta che il browser aggiorni il display.
*/
WMLBrowser.Refresh();
};
5.2.2.4. Formato dei dati supportati dal WAE
Come abbiamo visto, i due più importanti formati definiti nel WAE sono il WML e il
WMLScript, ma questi due non sono gli unici supportati. Infatti il WAE definisce ed adotta altri
formati, quali:
• immagini: il loro formato è caratterizzato da una codifica molto ridotta e richiede poca
memoria e bassi utilizzi della CPU;
• messaggi multipart: uno schema di codifica multipart è ottimizzato per permettere lo
scambio di dati di tipi diversi su WSP;
• formati specifici dell’interfaccia utente: sono due formati specifici aggiuntivi per lo scambio
di dati sia tra il client ed il server sia direttamente tra due client.
5.2.2.5. Caratteristiche dello User Agent
Per ottimizzare il modello client server, lo User Agent può spedire al WAP Gateway e al server
di origine un certo numero di sue caratteristiche che permettono così al server di rispondere solo
con dati appropriati, correttamente interpretabili dal client.
Come detto in precedenza, lo User Agent per comunicare con la rete mobile usa il protocollo
WSP (in particolare i dati e le intestazioni sono nella forma WSP/HTTP 1.1). L’intestazione del
WSP/HTTP 1.1 è usata per definire la negoziazione del formato dei dati nonché il set di caratteri ed
il linguaggio usato dallo User Agent. Per ogni tipo di dato incluso nell’intestazione Accept del
WSP/HTTP, lo User Agent può includere un parametro (uaprof) specificando l’URI che contiene un
profilo delle sue caratteristiche.
Un esempio di intestazione Accept potrebbe essere:
Accept: application/xWAP.wmlc; uaprof=http://www.vendor.com/phone1,
application/xWAP.wmlscriptc; uaprof=http://www.vendor.com/phone1,
text/xvcard,
text/xvcal
dove wmlc significa WML codificato, analogamente wmlscriptc significa WMLScript compilato,
xvcal specifica il formato per il calendario, ecc.
13
Per i tipi di dato WAP, il parametro uaprof, insieme alle intestazioni Accept WSP/HTTP,
AcceptLanguage e AcceptCharset, descrive completamente tutti i parametri del dato negoziabili. La
combinazione di queste tre viene generalmente indicata come intestazione delle caratteristiche.
Si noti infine che alcuni Gateway hanno una cache per memorizzare gli ultimi dati ricevuti dal
server di origine. Se lo User Agent invia una richiesta al Gateway specificando le sue caratteristiche
ed i dati richiesti sono in cache, il Gateway li può spedire direttamente al client senza passare dal
server solo se questi hanno caratteristiche identiche a quelle specificate dallo User Agent, altrimenti
occorre demandare la richiesta al server (specificandogli le caratteristiche desiderate).
5.2.2.6. Il trattamento delle immagini
WAE introduce un formato bitmap ottimizzato, il Wireless BitMaP(WBMP), per il trattamento
delle immagini sui terminali mobili (che come visto hanno display limitati, poca memoria, CPU
ridotte, ecc.). Una immagine WBMP ha le seguenti caratteristiche:
• codifica binaria compatta;
• ottimizzazioni per bassi costi computazionali sul client.
Il formato WBMP è indipendente dal terminale e contiene solo le informazioni grafiche. Le
specifiche del formato WBMP si dividono in due parti:
• una intestazione generica che contiene le seguenti informazioni (comuni a tutti i tipi di
formato delle immagini):
Ø tipo (fino ad oggi ne è stato specificato solo uno: il tipo 0);
Ø larghezza e lunghezza;
Ø numero versione WBMP.
• formato dei dati per quel particolare tipo di immagine WBMP.
Il formato WBMP è configurato in accordo con il valore del campo Type (TypeField) che rivela
le più importanti informazioni riguardo la codifica delle informazioni quali ad esempio:
• organizzazione dei pixel e codifica;
• organizzazione delle palette e codifica;
• caratteristiche di compressione;
• codifica delle animazioni.
Quando si inizia una sessione con il server lo User Agent comunica tutti i tipi WBMP supportati
usando Accept o ContentType. Ad esempio:
Accept: image/vnd.WAP.wbmp; level = 0; (oppure)
ContentType: image/vnd.WAP.wbmp; level = 0;
Per ora è supportato solo il tipo 0 (codifica in bianco e nero senza compressione).
La codifica delle immagini WBMP usa per i valori interi una rappresentazione multibyte, che
consiste in una serie di ottetti in cui il bit più significativo è il flag di prosecuzione (usato per
indicare se l’ottetto presente è l’ultimo della sequenza multibyte), mentre i restanti sette contengono
un valore scalare. Un singolo valore intero è codificato in una sequenza di N ottetti, in cui i primi
N-1 ottetti hanno il bit di prosecuzione a 1, mentre l’ultimo ottetto lo ha a zero. I rimanenti sette bit
sono codificati seguendo la codifica big-endian, nella quale i bit più significativi sono trasmessi per
primi.
Il campo dell’header contiene un identificatore numerico del tipo di immagine codificato a
multi-byte (Type Field), un ottetto di informazioni generali sull’header stesso (FixHeaderFiled),
zero o più campi di header aggiuntivi (ExtField), infine due campi di specifica della larghezza e
della lunghezza dell’immagine, sempre codificati a multi-byte (Width e Height).
L’intestazione di un’immagine WBMP è mostrata in Tabella 5.1.
14
Data Type
TypeField
FixHeaderField
ExtHeaderField
Width
Height
Lunghezza in bit (h e k sono interi arbitrari)
8
8
0
8...8*h
8...8*k
Tabella 5.1. Intestazione di una immagine WBMP.
WBMP di tipo 0 ha le seguenti caratteristiche:
• no compressione;
• colore: 1 bit (bianco = 1, nero = 0);
• profondità: 1 bit di profondità (monocromatico, non a livelli di grigio);
L’immagine WBMP è organizzata in righe di pixel, ognuna rappresentata da una sequenza di
ottetti. Il singolo bit rappresenta l’intensità del pixel (1=bianco).
5.3. WSP (Wireless Session Protocol)
Il WSP fornisce al livello di applicazione una interfaccia consistente per due differenti servizi di
sessione : il primo è un servizio connection oriented che opera sopra il protocollo di livello
transazionale (WTP), mentre il secondo è un servizio connectionless che opera sopra il servizio
datagram (WDP). La differenza essenziale tra le due classi di servizio è che il servizio connection
oriented usa il protocollo WTP per realizzare un servizio affidabile, in cui non vengono persi i dati,
attraverso un paradigma richiesta/risposta con ritrasmissione di dati perduti, ritrasmissioni selettive,
segmentazione e riassemblamento di pacchetti voluminosi, indirizzamento con numero di porta,
metodi per il controllo di flusso, connessioni di lunga durata con scambio di dati bidirezionale. Il
servizio connectionless, invece, lascia viaggiare le informazioni in maniera completamente
indipendente, disordinata, in cui i dati possono essere persi o duplicati.
Il WAP Gateway negozia le sessioni WSP con i terminali, consentendo a tutti i terminali
abilitati di creare una sessione. Ovviamente ad un servizio connectionless non è associata alcuna
informazione di sessione: ciò significa che non può essere usato nessun header per ottimizzare
l’utilizzo della banda. Entrambi i servizi possono operare su un canale sicuro (WTLS).
Il WSP consiste di servizi adatti per applicazioni di browsing (WSP/B) garantendo le seguenti
funzionalità:
• funzionalità e semantica HTTP/1.1 in codifica OTA (Over The Air) compatta;
• sessioni di lunga durata attraverso scambio di token tra il client e il server;
• possibilità di interrompere le transazioni processate sul server;
• sospensione e ripresa della sessione con eventuale migrazione della stessa su un’altra
macchina, per l’implementazione del meccanismo di bilanciamento del carico (load
balancing);
• gestione di push dal server al client;
• estensione dei metodi di richiesta/risposta;
• gestione delle chiavi e autenticazione;
• negoziazione delle caratteristiche del protocollo e dei tipi di contenuto;
• negoziazione per il supporto di transazioni multiple, simultanee, asincrone;
WSP è ottimizzato per reti a banda ristretta con latenza relativamente lunga, attraverso un uso
efficiente della banda stessa (codifica binaria compatta di header e tipi di contenuto) ed è progettato
per permettere ad un Gateway WAP di connettere un client WSP ad un server HTTP standard.
WSP fornisce un mezzo per lo scambio organizzato di dati tra applicazioni client/server. In
particolare fornisce alle applicazioni un mezzo per:
15
Capitolo 5 – L’architettura WAP: WSP (Wireless Session Protocol)
• stabilire una sessione stabile tra il client e il server e rilasciarla in modo ordinato;
• accettare attraverso la negoziazione un livello comune di servizi tra il client ed il server;
• scambiare dati tra il client ed il server usando una codifica compatta;
• sospendere e ripristinare la sessione.
L’implementazione del WSP segue fedelmente l’HTTP/1.1 per quanto riguarda la negoziazione
delle modalità di trasmissione: di conseguenza tutti i suoi metodi sono supportati e inoltre le
richieste spedite dal client al server e le corrispondenti risposte includono sia un’intestazione
(header: sono usati generalmente per definire i tipi di dati utilizzati, il set di caratteri usato, la
lingua, ecc.) sia i dati.
È prevista una codifica binaria compatta per tutti gli header generici (cioè gli header usati nella
maggioranza dei casi) per ridurre l’overhead del protocollo.
Una delle caratteristiche principali del WSP è quella che riguarda il tempo di vita di una
sessione: questo tempo non è infatti legato in alcun modo al livello di trasporto sottostante (ad
esempio una sessione può essere sospesa mentre si trova nello stato di idle per liberare le risorse di
rete e salvaguardare il consumo della batteria del dispositivo wireless). Inoltre una sessione può
essere ripristinata su una rete di un portatore diverso da quello che era attivo prima della
sospensione della stessa.
Tra le novità portate dal WSP vi è l’introduzione di tre meccanismi di push per il trasferimento
dei dati:
• push confermato all’interno di una sessione esistente;
• push non confermato all’interno di una sessione esistente;
• push non confermato all’esterno di una sessione esistente.
Nel primo caso il server riceve una conferma dal client che i dati (non richiesti) che gli ha
consegnato sono arrivati, mentre nel secondo non vi è nessuna conferma. Entrambi i meccanismi,
però, operano su una sessione esistente e stabile. Nel terzo caso invece vi è un meccanismo di push
all’esterno di una sessione esistente: in questo caso si assume che esista una sessione di default.
Il WSP supporta richieste asincrone, cosicché il client può inviare simultaneamente al server più
di una richiesta. Questa opzione permette di migliorare l’utilizzo della banda in quanto è possibile
riunire in pochi messaggi richieste o risposte multiple.
5.3.1. Tipi di primitive e parametri
La comunicazione tra i livelli e tra le entità all’interno di una sessione è compiuta per mezzo di
primitive di servizio. Le primitive di servizio rappresentano in modo astratto lo scambio logico di
informazioni e controlli tra il livello di sessione e i livelli adiacenti.
Le primitive di servizio sono un mezzo per illustrare i servizi forniti da un livello di protocollo
ai livelli superiori. La sintassi generale di una primitiva è la seguente: X-Servizio.tipo(parametri)
dove X definisce il livello del servizio. I tipi di primitive definiti sono descritti in Tabella 5.2.
Tipo
Request
Indication
Response
Confirm
Abbreviazione
req
ind
res
cnf
Descrizione
Un’entità richiede che il servizio faccia qualcosa.
Un’entità viene informata di un evento.
Un’entità vuole rispondere a un evento.
È arrivata la risposta a una richiesta precedente.
Tabella 5.2. Tipi.
Le primitive di servizio sono definite usando tabelle indicanti quali parametri e di che tipo è
possibile usare con i diversi tipi di primitive. In seguito ana lizzeremo le primitive di servizio (ed i
loro parametri) utilizzate dalle due modalità operative previsti dal WSP: quello con connessione e
quello senza connessione.
16
5.3.2. Servizi di sessione con connessione
Una sessione con connessione è composta da una serie di servizi (alcuni dei quali opzionali)
asimmetrici (le operazioni disponibili per il client ed il server connessi dalla sessione sono
differenti). I principali servizi sono:
• Session Management: permette ad un client di connettersi con un server e di concordare le
opzioni del protocollo da usare. Un server può rifiutare il tentativo di connessione o
ridirigere il client ad un altro server. Se accetta, durante la costituzione della sessione il
client ed il server si scambiano delle informazioni e negoziano dei parametri che si aspettano
siano validi per tutta la durata della sessione. Sia il server che il client possono poi terminare
la sessione.
• Method Invocation: permette al client di chiedere ad un server l’esecuzione di una
operazione e la restituzione del risultato.
• Exception Reporting: permette al fornitore del servizio di notificare all’utente il verificarsi di
eventi che non causano il cambiamento di stato di una sessione.
• Push: permette al server di inviare al client informazioni non richieste: questo servizio non è
confermato.
• Confirmed Push: come sopra, ma in questo caso il client conferma la ricezione delle
informazioni.
• Session Resume: mezzo attraverso il quale è possibile sospendere la sessione preservandone
lo stato; è usato ad esempio quando il fornitore del servizio scopre che le future
comunicazioni non potranno avere luogo fino a che non vengono effettuate delle azioni
correttive dall’utente o dalle entità di gestione della sessione.
I primi due tipi di servizi sono sempre disponibili, gli altri sono definiti dalla negoziazione tra il
client ed il server in fase di costituzione della sessione.
5.3.3. Variabili di connessione o capabilities
Durante la costituzione della sessione vengono negoziati tra il client ed il server le
caratteristiche della connessione o capabilities (Tabella 5.3).
17
Nome capability
Aliases
Tipo
Lista di indirizzi
Client SDU Size
Intero positivo
Extended Method
Insieme di nomi di
metodi
Descrizione
Indica una lista di indirizzi alternativi attraverso
i quali è possibile accedere allo stesso servizio.
Indica la massima dimensione che può
assumere una SDU (Service Data Unit) spedita
dal client durante la sessione.
Insieme di metodi supplementari che il client
ed il server possono supportare durante questa
sessione.
Numero massimo di metodi invocati che
possono essere attivi nello stesso istante
durante la sessione.
Numero massimo di data push da confermare
che possono essere attive nello stesso istante
durante la sessione.
Abilita caratteristiche e servizi opzionali
Maximum Outstanding Intero positivo
Method Request
Maximum Outstanding Intero positivo
Push Request
Protocol Options
Server SDU Size
Insieme di
caratteristiche e
facilitazioni
Intero positivo
Indica la massima dimensione che può
assumere una SDU (Service Data Unit) spedita
dal server durante la sessione
Tabella 5.3. Capabilities.
Per ulteriori dettagli si rimanda all’Appendice B.
5.4. WTP (Wireless Transaction Protocol)
Il WTP svolge le sue funzioni al di sopra del servizio datagram: si tratta di un protocollo leggero
ed orientato alla transazione, adeguato per una implementazione su client poco potenti. WTP opera
in modo efficiente su reti datagram wireless sicure e non sicure.
A differenza del TCP, che trasmette una grande quantità di informazioni per ciascuna
transazione richiesta/risposta, il WTP non mantiene traccia dell’instradamento, perché esiste una
unica possibile strada tra il WAP Gateway e il microbrowser wireless.
Il protocollo di transazione è definito per fornire i servizi necessari al browsing interattivo
(richiesta/risposta). Durante una sessione, il client richiede informazioni ad un server, fisso o
mobile, che risponde con i dati richiesti. WTP si appoggia direttamente al livello datagram (nel caso
di connessioni non sicure), oppure al livello sicurezza WTLS (nel caso di connessioni sicure).
I benefici derivanti dall’utilizzo del WTP sono:
• miglioramento dell’affidabilità su servizi datagram. WTP solleva i livelli più alti dal compito
delle ritrasmissioni e degli acknowledgement che sono necessari quando si opera su servizi
datagram.
• miglioramento dell’efficienza su servizi connection oriented.
Il WTP è “message oriented” ed è progettato per servizi orientati alla transazione, quali ad
esempio il browsing; le due entità fondamentali che, dialogando tra loro, permettono la
comunicazione su tale protocollo sono:
• Initiator: provider WTP che dà inizio effettivamente una transazione;
• Responder: provider WTP che risponde ad una richiesta di inizio transazione.
18
Capitolo 5 – L’architettura WAP: WTP (Wireless Transaction Protocol)
5.4.1. Caratteristiche
Le caratteristiche principali del WTP sono di seguito riportate:
• tre classi di servizi di transazione:
Ø Classe 0: richieste unidirezionali non affidabili con invocazione di
messaggi in modo instabile e senza messaggi di ritorno;
Ø Classe 1: richieste unidirezionali affidabili con invocazione di messaggi in
modo stabile e senza messaggi di ritorno;
Ø Classe 2: transazioni bidirezionali richiesta/risposta affidabili con
invocazione di messaggi in modo stabile ed esattamente un messaggio di
ritorno;
• stabilità e resistenza della transazione ottenuta attraverso identificatori, acknowledgement,
rimozione dei duplicati e ritrasmissioni;
• affidabilità tramite conferma di ogni messaggio ricevuto da parte dell’utente (opzionale);
• utilizzo della concatenazione (dove possibile) per trasmettere Protocol Data Unit (PDU)
multipli in un unico Service Data Unit (SDU) di un datagram; la concatenazione è una
procedura che permette di trasportare PDU multiple in un’unica SDU, mentre la separazione
è la procedura che permette di estrarre PDU multiple da un’unica SDU;
• orientamento dei messaggi: l’unità base di scambio è un intero messaggio e non un flusso di
byte;
• minimizzazione del numero di transazioni: trasmissione di dati fuori banda e
acknowledgement ritardati per ridurre il numero di messaggi inviati;
• supporto dell’abort di transazioni pendenti: l’abort può essere provocato dall’utente
cancellando una richiesta di servizio;
• utilizzo transazioni asincrone: il Responder invia indietro il risultato appena il dato diventa
disponibile.
5.4.2. Relazione con gli altri protocolli
La Tabella 5.4 illustra il tipo di servizi forniti al WTP user (ad esempio il livello WSP).
WTP user
WSP
WTLS
(opzionale)
WDP Datagram
Transport
Bearer Network
(IP, GSM/SMSUSSD)
Servizio garantito dal livello WTP
Gestione transazioni, ritrasmissione e rimozione
duplicati, concatenazione e separazione
Compressione, crittografia, autenticazione
Port number addressing, segmentazione e
riassemblaggio, rilevazione errori
Instradamento, Device addressing (IP address,
numero di telefono), segmentazione e
riassemblamento, rilevazione errori.
Tabella 5.4. Servizi forniti al WTP user
WTP è specificato per funzionare sopra un servizio di trasporto datagram: poiché i datagram
sono instabili, al WTP è richiesto di eseguire eventuali ritrasmissioni necessarie e inviare
acknowledgement per fornire così un servizio stabile al WTP user. Inoltre il WTP è anche
responsabile della concatenazione di molteplici PDU in un unico SDU.
Il Datagram Transport è richiesto per instradare i datagram in arrivo ai corretti WTP user.
Normalmente il WDP user (ad esempio il livello WTP) è identificato da un unico numero di porta.
Il compito del WDP è quello di fornire un servizio datagram all’user WTP il quale non deve curarsi
19
Capitolo 5 – L’architettura WAP: WTP (Wireless Transaction Protocol)
assolutamente delle capacità del tipo di rete mobile sottostante. Fortunatamente, il servizio
datagram è un semplice meccanismo di trasporto e la maggior parte dei portatori lo fornisce già
come un servizio (ad esempio l’IP utilizza l’UDP per questo servizio).
Il portatore è responsabile dell’instradamento dei datagram ai dispositivi destinazione.
L’indirizzamento dipende dal tipo di rete (indirizzamento IP o numero del telefono). Inoltre alcune
reti utilizzano l’allocazione dinamica degli indirizzi ed un server deve essere coinvolto nel cercare
l’indirizzo corrente di un dispositivo specifico.
Il WTP non prevede meccanismi di sicurezza: tale gestione è interamente svolta dal livello
WTLS (se presente).
5.4.3. Entità di gestione
L’entità di gestione WTP è usata come interfaccia tra il livello WTP e l’ambiente del dispositivo
(WAE). Questa entità fornisce informazioni al livello WTP riguardo ai cambiamenti dell’ambiente
del dispositivo che potrebbero influire sulle corrette operazioni del WTP stesso.
Il protocollo WTP è progettato con l’assunzione che l’ambiente in cui opera sia in grado di
ricevere e trasmettere dati. Questa semplice assunzione richiede che:
• il dispositivo mobile sia all’interno di una zona di ricezione;
• il dispositivo mobile abbia sufficiente potenza;
• il dispositivo mobile abbia sufficienti risorse (CPU e memoria);
• il protocollo WTP sia correttamente configurato;
• l’utente voglia ricevere/trasmettere dati.
L’entità monitorizza queste caratteristiche e notifica al WTP eventuali cambiamenti. Per
esempio, se il dispositivo esce da una zona di copertura (non c’è ricezione) l’entità di gestione del
portatore comunica all’entità di gestione del WTP che la trasmissione/ricezione su quella rete non è
più possibile. Di conseguenza l’entità di gestione del WTP gli comunica di chiudere tutte le
connessioni attive con quel portatore.
5.4.4. Requisiti necessari del livello sottostante
Il servizio datagram (che è il livello sottostante al WTP) deve trattare le seguenti funzioni:
• instradare i datagram in arrivo al livello WTP;
• aggiungere informazioni alle SDU sfuggite al livello WTP;
• individuare errori (ad esempio utilizzando il checksum).
Inoltre il WTP si aspetta che i livelli sottostanti forniscano la segmentazione ed il
riassemblaggio (SAR). Normalmente questo tipo di servizio è fatto dal livello sottostante al
datagram (ad esempio nelle reti IP il protocollo IP supporta il SAR).
Per ulteriori dettagli sul protocollo WTP si rimanda all’Appendice B.
5.5.WTLS(Wireless Transport Layer Security)
WTLS è un protocollo di sicurezza che trova il suo fondamento nel protocollo industriale
standard Transport Layer Security (TLS), formalmente noto come Secure Sockets Layer (SSL).
WTLS viene proposto insieme ai protocolli di trasporto WAP, dopo essere stato ottimizzato per
l’uso su canali di comunicazione con banda ristretta. WTLS garantisce le seguenti funzionalità:
• integrità dei dati: il dato spedito tra il terminale e il server non deve essere modificato o
corrotto;
• privacy: il dato spedito tra il terminale e il server è privato e non deve essere compreso da un
qualunque intermediario che intercetti il flusso dei dati;
• autenticazione: il protocollo stabilisce l’autenticità del terminale e dell’applicazione server;
20
Capitolo 5 – L’architettura WAP: WTLS (Wireless Transport Layer Security)
•
protezione con negazione del servizio: WTLS contiene funzioni per il controllo ed il rigetto
di dati che non siano stati verificati con successo e attua in caso di bisogno la negazione del
servizio per proteggere i livelli superiori del protocollo da attacchi indesiderati.
Le applicazioni possono abilitare o disabilitare selettivamente WTLS a seconda dei requisiti di
sicurezza e delle caratteristiche della rete sottostante (ad esempio la privacy può essere disabilitata
su reti che già garantiscano questo servizio ad un livello più basso).
5.5.1. Il modello di sicurezza WAP
L’architettura WAP però non è completamene adattabile al modello di sicurezza del Web per i
seguenti due motivi:
• il protocollo SSL è stato progettato per comunicazioni di tipo wired (ampia banda a
disposizione e basse latenze) che vedono coinvolti desktop con elevate capacità di calcolo e
memorizzazione: una transazione SSL con un terminale WAP comporterebbe notevoli
ritardi nella comunicazione andando a incidere enormemente sia sulle prestazioni sia sui
costi della comunicazione);
• il mondo WAP non prevede una comunicazione diretta tra il client ed il Web Server: tra loro
vi è sempre il WAP Gateway che fa da tramite tra il terminale mobile ed il Web Server.
Per risolvere il problema delle prestazioni è stato progettato un nuovo protocollo (il WTLS)
appositamente progettato per i terminali mobili, tenendo in considerazione i loro limiti fisici: tale
protocollo garantisce comunque un buon livello di sicurezza riducendo enormemente gli overhead
del protocollo SSL. Il problema legato alla presenza del WAP Gateway è stato invece risolto
facendo utilizzare a quest’ultimo il protocollo SSL per comunicare in modo sicuro con il Web
Server, mentre per comunicare con il WAP browser utilizza il protocollo WTLS. La necessità di
passare da WTLS a SSL (e viceversa) è resa obbligatoria dalla natura delle comunicazioni wireless,
che sono caratterizzate da una banda di trasmissione ristretta ed una elevata latenza. Il modello di
sicurezza WAP attuale è mostrato in Figura 5.9.
Si noti che tale soluzione non porta alla realizzazio ne di un unico canale sicuro tra il client ed il
Web Server (come avviene nel mondo WWW quando si utilizza il protocollo SSL), ma si creano
due canali sicuri separati: il primo, tramite il protocollo WTLS, collega il WAP Browser al WAP
Gateway, mentre il secondo, tramite il protocollo SSL, collega il WAP Gateway al Web Server. Il
punto critico di tale modello è proprio il WAP Gateway. Il WAP Gateway, infatti, è il punto di
Figura 5.9: il modello di sicurezza WAP.
collegamento tra i due canali ed è il responsabile delle traduzioni WTLS/SSL (e viceversa): qui i
dati, seppur per brevi istanti, passano in chiaro, perché per tradurre, ad esempio, il WTLS in SSL
occorre prima decifrare i dati in WTLS portandoli in chiaro e poi cifrarli in SSL. Tali traduzioni,
necessarie al fine di permettere una connessione sicura e virtuale tra i due protocolli, richiedono
21
tempo e necessitano di una memorizzazione (seppur temporanea) nella memoria del WAP Gateway.
Affinché un certo livello di sicurezza sia garantito, diventa allora assolutamente indispensabile che:
• i WAP Gateway non memorizzino mai informazioni decrittografate su mezzi di
memorizzazione secondari;
• il processo di traduzione sia il più veloce possibile in modo da eliminare velocemente i dati
residenti nella memoria volatile interna del WAP Gateway;
• si garantisca una sicurezza fisica del WAP Gateway, in modo che vi possano accedere solo
amministratori autorizzati;
• siano limitati gli accessi remoti al WAP Gateway per effettuare operazioni di manutenzione.
Per evitare i problemi legati alle traduzioni WTLS/SSL la tendenza attuale da parte dei fornitori
di servizio è quella di inglobare il WAP Gateway all’interno del proprio Web Server: tale soluzione,
se da una parte aumenta il livello di sicurezza, dall’altra limita le prestazioni della navigazione
Internet.
Prendiamo infatti in considerazione il Nokia 7110 (il primo cellulare entrato in commercio con
supporto WAP): per effettuare la navigazione Internet occorre settare, prima di cominciare il
collegamento, l’indirizzo IP del WAP Gateway attraverso il quale le richieste saranno trasferite in
HTTP al Web Server specificato. Una volta settato l’indirizzo IP del WAP Gateway si può
effettuare il classico collegamento Internet specificando il numero del fornitore di servizio, con il
quale abbiamo l’accesso alla rete, e la classica coppia username e password, attraverso le quali ci
autentichiamo con il provider stesso. A questo punto se non si è interessati ad una comunicazione
sicura ed il WAP Gateway specificato prima del collegamento ha una visone globale della rete, la
navigazione Internet avviene in modo del tutto analogo a come la conosciamo. Supponiamo invece
di voler comprare un libro e di voler effettuare una operazione di trading on- line: non possiamo fare
le due operazioni in un unico collegamento, se si desidera che queste siano realizzate in modo
sicuro e che i due Web server interessati incorporino anche due diversi WAP Gateway. Infatti prima
settiamo il 7110 con l’indirizzo IP del Gateway gestito dal server che vende i libri, ci colleghiamo
ed acquistiamo il libro. Dopodiché siamo costretti a disconnetterci, cambiare l’indirizzo IP del
WAP Gateway inserendo quello gestito dalla banca con cui fare l’operazione di trading on- line, e
infine ci colleghiamo ed eseguiamo l’operazione.
Oltre al discorso della sicurezza va notato che un particolare ISP che gestisce un Gateway ne
può anche limitare la visibilità nei confronti della rete. Un portale, ad esempio, che gestisce anche
un WAP Gateway può avere particolari interessi economici a limitare la visibilità della rete solo nei
confronti di alcuni siti/servizi con i quali ha stipulato particolari contratti di sponsorizzazione.
L’alternativa rimane quella della gestione completa e accurata del WAP Gateway e delle traduzioni
che esso deve effettuare rispettando i vincoli sopra descritti. Tale soluzione ha sicuramente il grande
vantaggio di disaccoppiare il Gateway da un particolare fornitore di servizi (evitando i problemi di
prestazioni esistenti per la soluzione che prevede l’accoppiamento Gateway/Web Server) ma
richiede una amministrazione più difficoltosa.
A prescindere comunque dalla gestione dei WAP Gateway, rimane immutata la fiducia che il
client deve avere nei loro confronti. Ovviamente il client, prima di riporre la propria fiducia (e
magari il proprio denaro) verso un particolare WAP Gateway, deve accertarsi della sua identità
analizzandone accuratamente il certificato. È bene chiarire inoltre che l’unico certificato che il
client riceve è proprio quello del WAP Gateway con cui comunica e non quello del Web Server che
restituisce i servizi richiesti. Anche l’autenticazione infatti è spezzata dalla presenza del WAP
Gateway: il client sceglie il WAP Gateway e ne verifica l’attendibilità, mentre il WAP Gateway a
sua volta verificherà l’attendibilità dei siti con cui il client vorrà comunicare.
Supponiamo, per chiarire la situazione, che un client debba acquistare on-line un libro su
Amazon appoggiandosi al WAP Gateway di O.T.Consulting: il client non può verificare
direttamente che il sito cui destina il proprio denaro sia proprio Amazon e non uno shadow server;
tale verifica, infatti, la può svolgere solo il WAP Gateway. È proprio ora che entra in gioco il
rapporto di fiducia client/WAP Gateway: il client, una volta che ha verificato che il WAP Gateway
22
con cui comunica è proprio quello di O.T.Consulting, non si pone il problema della veridicità dei
dati che questi gli fornisce.
Il WTLS fornisce tutta una serie di meccanismi che permettono la mutua autenticazione tra il
client ed il WAP Gateway (anche quest’ultimo, infatti, può richiedere il certificato del client per
controllarne l’identità). L’autenticazione del client da parte del WAP Gateway è però ancora poco
utilizzata per via dell’impossibilità da parte dei dispositivi wireless attualmente in commercio di
memorizzare certificati. In futuro tale problema sarà superato integrando dispositivi di
memorizzazione simili alle Smartcard nei terminali mobili.
Le problematiche relative al modello di sicurezza WAP attuale sono allo studio del WAP Forum
e l’obiettivo prefissato è quello di realizzare un meccanismo di sicurezza punto-punto tra WAP
Browser e Web Server. Fino a che non verrà raggiunto tale obiettivo il WTLS fornirà una
connessione sicura solo tra il WAP Gateway ed il WAP Browser garantendo privacy, integrità e
autenticazione tra se stesso ed il client WAP. Inoltre i fornitori di WAP Gateway possono
implementare dei meccanismi per permettere l’utilizzo della certificazione del client (se il
dispositivo lo consente) e dell’uso di firma digitale per garantire anche il concetto di non ripudio.
5.5.2. Il funzionamento su datagram
Il WTLS, come detto in precedenza, si basa sulle specifiche dell’SSL, ma a differenza di
quest’ultimo funziona anche su protocolli di trasporto datagram. Tali protocolli sono caratterizzati
dal fatto che i dati viaggiano in maniera completamente indipendente tra di loro e inoltre possono
essere persi, arrivare non in ordine o addirittura essere duplicati.
Queste caratteristiche rendono non utilizzabile il protocollo SSL, così come è stato progettato,
su un protocollo di trasporto datagram. Si pensi infatti alla fase di handshake tra un client ed un
server: non è pensabile che possa avere un buon esito se, ad esempio, il messaggio di Client Hello
non giunge mai al server o se l’accettazione di un certificato da parte di una delle due entità non
arriva mai all’altra.
Per poter supportare i datagram sono stati allora introdotti nel WTLS una serie di meccanismi
che fronteggiano l’eventualità che i dati non arrivino mai o arrivino in disordine o siano duplicati.
In particolare, per superare questi problemi, il WTLS si basa su una macchina a stati asimmetrica
(cioè una per il client ed una diversa per il server), sull’uso dei time out per non bloccare una delle
due entità nell’attesa infinita della risposta dell’altra, sul controllo della validità del numero di
sequenza dei pacchetti in arrivo e sulla concatenazione di più messaggi di handshake che viaggiano
nella stessa direzione in un unico pacchetto da spedire.
Si rimanda, per ulteriori dettagli in proposito, all’Appendice B.
5.6. WDP (Wireless Datagram Protocol)
Il protocollo a livello di trasporto nell’architettura WAP è il Wireless Datagram Protocol (WDP)
che opera a stretto contatto con i servizi di trasporto dei portatori supportati dalle diverse tecnologie
di rete wireless. Configurandosi come servizio di trasporto a carattere generale, WDP offre un
servizio consistente agli strati superiori del protocollo, comunicando, in modo trasparente, con uno
dei tanti portatori (bearer) disponibili. Grazie al fatto che il protocollo WDP fornisce una interfaccia
comune ai protocolli di livello più alto, i protocolli di sicurezza, sessione e applicazione sono in
grado di funzionare in modo indipendente dalla rete wireless sottostante: questo risultato viene
raggiunto adattando il livello di trasporto alle specifiche caratteristiche del portatore sottostante.
Conservando consistente l’interfaccia del livello di trasporto e le sue caratteristiche basilari, pur
cambiando l’implementazione interna (in un’ottica simile a quella ad oggetti), si può raggiungere
l’obiettivo di una interoperabilità globale. Nella Figura 5.10 è mostrato un modello di architettura
per il WDP.
23
Capitolo 5 – L’architettura WAP: WDP (Wireless Datagram Protocol)
Il protocollo WAP è progettato per operare su una varietà di differenti servizi forniti dai
portatori (GSM, CDPD, Mobitex, CDMA), inclusi quelli per gli Short Message (SMS), per i dati a
commutazione di circuito e per i dati a pacchetto (GPRS). I portatori offrono differenti livelli di
qualità di servizio nel rispetto di parametri quali lo throughput, la frequenza di errore e i ritardi: i
protocolli WAP sono progettati proprio per compensare o tollerare questa variabilità nel livello del
servizio.
Figura 5.10: architettura del Wireless Datagram Protocol.
Dal momento che il livello WDP porta alla convergenza tra il servizio del portatore e il resto
dello stack WAP, le specifiche WDP devono fornire la lista dei portatori supportati e le tecniche
usate per permettere ai protocolli WAP di funzionare sopra qualsiasi portatore. Naturalmente la lista
dei portatori supportati cambia nel tempo, con l’aggiunta di nuovi portatori, man mano che il
mercato wireless si evolve. L’architettura a livelli di WAP permette anche ad altri servizi ed
applicazioni di utilizzare le caratteristiche dello stack WAP attraverso un insieme di interfacce ben
definite. Le applicazioni esterne possono accedere ai livelli di sessione, transazione, sicurezza e
trasporto direttamente: questo permette allo stack WAP di essere usato per applicazioni e servizi
non correntemente specificati da WAP, ma giudicati validi per il mercato wireless. Per esempio, le
applicazioni come la posta elettronica, i calendari, le rubriche telefoniche e il commercio
elettronico, o i servizi, come le pagine gialle, possono essere sviluppati per l’uso sul protocollo
WAP. Questo è in linea con i principi enunciati dal WAP Forum, secondo i quali la tecnologia
WAP dovrà essere utile per applicazioni e servizi anche al di là di quelli specificati nelle specifiche.
Il livello di trasporto nell’architettura WAP consiste nei livelli WTP (Wireless Transaction
Protocol) e WDP (Wireless Datagram Protocol).
In Figura 5.10 sono evidenziati le differenti funzioni (diverse altezze nella Figura 5.10) offerte
dai portatori e quindi i diversi protocolli WDP necessari per garantire lo stesso livello di servizi.
WDP supporta diverse istanze simultanee di comunicazione da un livello superiore ad un
singolo servizio portatore sottostante. Il numero di porta identifica l’entità del livello superiore
sopra il WDP: questa entità può essere un altro protocollo (come il WTP o il WDP) o una
applicazione (come ad esempio la posta elettronica). Il livello Adaptation è il livello del WDP che
mappa le funzioni del protocollo direttamente sopra le caratteristiche specifiche del portatore; il
livello Adaptation inoltre è diverso per ogni tipo di portatore.
Esiste una entità di gestione del WDP che è usata come interfaccia tra il livello WDP e
l’ambiente del dispositivo: questa entità fornisce informazioni al livello WDP riguardo eventuali
cambiamenti avvenuti nell’ambiente del dispositivo che potrebbero influire sul corretto
funzionamento del WDP stesso. L’entità di gestione del WDP svolge le stesse funzioni ed ha le
stesse caratteristiche dell’entità di gestione del WTP. Il WDP inoltre utilizza il Wireless Control
Message Protocol (WCMP) per la gestione ed il trattamento degli errori in modo da migliorare le
prestazioni del protocollo WAP e delle applicazioni.
24
5.6.1. I profili del WDP a seconda del tipo di portatore
sottostante
Figura 5.11: WDP su GSM-SMS.
Figura 5.12: WDP su GSM-USSD.
Come detto in precedenza il WDP assume un particolare comportamento a seconda del tipo di
portatore su cui opera.
25
I portatori principali attualmente operativi sono GSM-SMS (vedi Figura 5.11), GSM-USSD
(vedi Figura 5.12), GSM-CSD (Figura 5.13), GSM-GPRS, CDPD, IS-136 GUTS, CSD, Packet
Figura 5.13: WDP su GSM-Circuit Switched Data Channel
Data, CDMA, iDEN ed altri ancora. Per ognuno di loro il WDP assume un profilo particolare con
comportamenti specifici a seconda del portatore. Per brevità e al solo scopo illustrativo di seguito
sono riportati i profili WDP sui portatori GSM.
Per ulteriori dettagli sulle primitive di servizio WDP si consulti l’Appendice B.
5.7. Interoperabilità e futuri sviluppi
Il WAP Forum vede l’interoperabilità tra diversi venditori come un importante elemento per il
successo di WAP. Per fornire la più alta probabilità tecnicamente possibile che due prodotti WAP
sviluppati indipendentemente da due diversi venditori possano interoperare con successo, deve
essere sviluppata una rigorosa definizione di conformità e di adesione e deve essere sviluppato un
testing comune. Per raggiungere questo obiettivo il WAP Forum ha creato una specifica di
conformità per WAP e sta lavorando per mantenere le informazioni correnti in relazione con tutti i
punti chiave dell’interoperabilità di WAP. Un’interoperabilità di successo può essere raggiunta
solamente con attività di testing del prodotto. Il testing può essere suddiviso nelle due categorie
principali:
• testing statico;
• testing dinamico.
Il testing statico consiste in un resoconto del costruttore delle capacità e funzionalità del
prodotto: esso identifica aree ovvie di incompatibilità tra due prodotti (ad esempio dove uno
implementa una funzione che l’altro non supporta): tutte le specifiche WAP forniscono i mezzi per
il testing statico sottoforma di un Protocol Implementation Conformance Statement (PICS).
Il testing dinamico è l’unico che possa dare la garanzia che due prodotti interagiranno con
successo; esso include l’utilizzo di un prodotto sul campo, dimostrando definitivamente se il
prodotto si comporta oppure no come dichiarato nel test statico. Ci sono generalmente diversi
approcci generali al testing dinamico, ma conviene usarne uno di riferimento che serva per
esaminare tutti i prodotti; è importante definire un insieme di test formali per verificare il
comportamento di un prodotto in laboratorio. Il WAP Forum promuoverà il metodo con il miglior
rapporto prezzo/prestazioni, che possa condurre al più alto grado di confidenza di interoperabilità
tra prodotti WAP disponibili sul mercato in un determinato momento. Questo è un approccio
evolutivo che naturalmente cambierà nel tempo, man mano che l’industria del WAP maturerà. Nelle
specifiche redatte dal WAP Forum è contenuta anche una lista di futuri sviluppi, non ordinata in
base alle priorità in nessun modo: aree di lavoro possono essere aggiunte o tolte in ogni mo mento. È
26
Capitolo 5 – L’architettura WAP: interoperabilità e futuri sviluppi
interessante scorrerla, poiché dà un’idea di quello che manca e quindi fornisce una migliore
comprensione delle direzioni che saranno date allo sviluppo:
• trasporto di dati connection oriented;
• integrazione del SIM Toolkit e di Smartcard in WAP;
• integrazione di MExE (ETSI) in WAP;
• integrazioni addizionali con la rete telefonica;
• librerie WMLScript scaricabili via Internet;
• compressione WTLS;
• sicurezza a livello applicazione (librerie di script con crittografia);
• portata più ampia della architettura di sicurezza, incluso il supporto per Smartcard, il
miglioramento della gestione della sicurezza end-to-end, gerarchie di CA;
• supporto di flussi di contenuto multimediale per portatori a banda più ampia, ad esempio
GPRS;
• supporto per dati multicast (uno a molti);
• supporto per servizi mobili dipendenti dalla localizzazione;
• possibilità di fare il download di applicazioni;
• API (Application Programming Interfaces) per programmi vocali e per ogni livello dello
stack WAP;
• Test di interoperabilità.
27

Capitolo 5 L`architettura WAP

Transcript

Documenti analoghi

Cosa è Letteralmente WAP significa Wireless Application Protocol

Samsung SGH Z510 UMTS – WAP GPRS

samsung z510

Zero9, Melita Toniolo testimonial dei servizi wap e web

Navigare da pc su apn Wap

configurazione email su cell.cdr

Mobile Services da intrattenimento privato a mezzo di

The Speed of Sports

IC-92 D: configurazione per collegamento generico via

nokia n95 - Total Erg