I passi fondamentali e le scelte da effettuare in base alle specifiche esigenze. Pubblicato sul numero 13 maggio 2001
La strada che porta all’Internet Mobile, ossia la possibilità di accedere ai contenuti e ai servizi online, indipendentemente da dove ci si trovi, è ormai intrapresa. Gli scenari disegnati per il futuro prevedono l’utilizzo di connessione broadband per l’implementazione di servizi avanzati come lo streaming audio/video, il mobile commerce, servizi di georeferenziazione e quant’altro si possa immaginare.
Allo stato attuale però, le reti di telefonia cellulare non sono ancora pronte per la trasmissione di dati a banda larga e ci si deve spesso accontentare della risibile velocità di 9,6 baud.
Per quanto riguarda il protocollo per l’Internet mobile invece, non sembrano esserci particolari dubbi in quanto quello già esistente, il WAP (Wireless Application Protocol) sarà ampliamente supportato per il futuro e sarà presto integrato con nuove funzionalità in grado di supportare la banda larga e i tipi di content quindi trasmissibili.
Allo stato attuale delle cose è possibile realizzare servizi di content sharing; la colpa ricade tutta sulla banda di trasmissione che nel 90% dei casi è di 9.6 baud.
Entro fine anno le cose dovrebbero cambiare radicalmente, infatti, sarà disponibile la tecnologia GPRS (General Packet Radio Service) che, sebbene in un primo momento non permetterà velocità superiori ai 20 Kbps, con l’aggregazione multipla di canali permetterà di arrivare fino a una velocità superiore ai 128 Kbps.
Inoltre il GPRS avrà un sistema di tariffazione totalmente nuovo e diverso: non si pagherà più a tempo ma a pacchetto, cioè a dato scambiato.
Come soddisfare
la voglia di wireless
Quali sono le risorse, sia economiche sia umane, che bisogna mettere in campo per realizzare un servizio dedicato al mondo mobile?
Per prima cosa bisogna capire quale servizio si vuole implementare. Attualmente i servizi realizzabili sono divisi in due grosse categorie: quelli che richiedono di un livello di sicurezza sufficientemente alto, a garantire delle transazioni, e quelli che forniscono dei contenuti senza un elevato livello di sicurezza. Tra i primi rientrano sicuramente i servizi di mobile commerce, mobile banking e tutti quei servizi che prevedano la transazione di denaro o comunque la compravendita di beni o quant’altro. Per realizzare un servizio simile, si dovrà prevedere una serie di strutture e costi aggiuntivi. Invece, se si vuole realizzare un servizio di semplice content sharing, come news, giochi, email e altro, allora molto probabilmente gli investimenti necessari saranno minori.
Configurare il server
per i servizi
Tralasciando la programmazione del servizio a un’altra sede, in entrambi i casi però, quello che si dovrà fare è predisporre l’origin server, ossia la macchina sulla quale si trovano i contenuti o le procedure da utilizzare (di solito un Web server), alla pubblicazione di contenuti WML (il linguaggio del WAP). Per fare ciò bisogna specificare alcuni tipi MIME, ossia delle particolari istruzioni che specificheranno al browser Wap il tipo di contenuto da interpretare. Questi sono illustrati nella tabella alla pagina successiva.
Specificare i tipi MIME è sempre consigliato anche se non sempre è necessario. Infatti, se le pagine che si andranno a servire sono tutte generate dinamicamente da un linguaggio di scripting server side, il tipo MIME adatto potrà anche essere specificato all’interno dello script stesso. Invece, se vi sono anche pagine statiche, scritte in WML puro, ciò non può essere fatto. Non esiste infatti in WML un’istruzione per settare i tipi MIME corretti, né tantomeno in WML Script. Riportiamo di seguito, per informazione, l’istruzione necessaria a configurare gli appropriati tipi mime per le pagine ASP: <%response.contenttype=”text/vdn.wap.wml”%>. La configurazione hardware della macchina è impossibile da fare; dipende, infatti, da quello che deve essere elaborato, dal numero di connessioni concorrenti previste e così via. Questa può essere determinata solo in un fase di progettazione del servizio.
Gateway pubblico
o gateway privato
Installare un gateway WAP in casa non è sempre necessario, ma deve esserlo quando si vuole gestire un servizio sicuro oppure tracciare la provenienza degli utenti. Negli altri casi, si può utilizzare un gateway pubblico di un operatore sul quale far transitare il traffico destinato al nostro server Web/WAP.
Utilizzare un gateway pubblico però, se da un lato diminuisce di molto i costi di setup del servizio, dall’altro fa perdere visibilità sulla provenienza dell’utente. Qualora, infatti, si volessero utilizzare degli script per tracciare in un sito WAP la provenienza di un utente, questi risulterebbe sempre come proveniente dall’IP del gateway; non solo, l’IP dell’utente sarebbe indicato come l’IP del gateway attraverso il quale è collegato. Si capisce quindi quanto possa essere importante un gateway proprietario per quei servizi che implementano architetture sicure come m-commerce, m-banking oppure che necessitino semplicemente di una buona profilazione dell’utente. Inoltre, se si utilizza un gateway WAP pubblico, bisogna considerare il fatto che questi ormai sono abbastanza intasati e, sebbene attualmente non ci siano ancora problemi, è previsto con l’aumentare dell’utenza l’aumento della lentezza nell’accedere a siti WAP. In ultimo non bisogna dimenticare che utilizzando un gateway pubblico, questo parlerà col nostro WAP server attraverso il protocollo HTTP e quindi con una connessione non sicura. L’utilizzo di un proprio gateway WAP, invece, risolve tutti questi problemi. Per servizi particolarmente esigenti in termini di sicurezza, è poi possibile configurare un proprio gateway WAP per essere utilizzato come proxy di un gateway pubblico (magari presso l’operatore) il quale potrà passare oltre all’IP dell’utente anche il suo MSISDN (ossia il numero telefonico).
Il numero di accessi
come discriminante
Il posizionamento del gateway è molto soggettivo rispetto all’architettura di rete adottata: è buona cosa comunque porlo sulla stessa parte di rete dell’origin server, senza il firewall di mezzo.
Bisogna però ricordarsi che, se le richieste dovranno passare attraverso un firewall, vi dovranno essere aperte le seguenti porte: 9200 (per servizi senza connessione continua), 9201 (per servizi con connessione continua), 9202 (per servizi sicuri senza connessione continua), 9203 (per servizi sicuri con connessione continua).
Anche il gateway ottimale per i propri servizi è una scelta abbastanza complessa: di solito si utilizza come criterio discriminante il numero di accessi che si vuole gestire contemporaneamente e la presenza o meno di moduli per la gestione di connessioni sicure WTLS (Wireless Transport Layer Security).
Così, se per servizi non molto esigenti possono andare bene anche gateway da pochi milioni, per servizi più complessi (dove si utilizza la sicurezza WTLS oppure dove si prevede di generare molto traffico) bisogna per forza rivolgersi a sistemi più costosi.
Benché la maggior parte dei gateway sia modulare e facilmente upgradabile, se si prevede di implementare, anche in un secondo tempo, servizi sicuri bisogna accertarsi al momento dell’acquisto del gateway che questo disponga di plug-in adeguati alle esigenze previste.
Implementare
un servizio RAS
Anche installare un servizio RAS (Remote Access Server) può essere un’ipotesi da tenere in considerazione quando si progetta di implementare servizi sicuri.
La realizzazione di un servizio RAS per una piccola intranet può essere una cosa abbastanza semplice da farsi: basta collegare a un pc dei modem e configurarlo in modo da consentire l’accesso in rete a chi si collega attraverso quei numeri.
Concettualmente invece, per quanto riguarda il WAP, un servizio RAS non fa nient’altro che aumentare considerevolmente la sicurezza del servizio. Innanzitutto con un servizio RAS, l’architettura WAP può anche rimanere scollegata da Internet: l’accesso avviene attraverso appositi modem su specifici numeri.
Implementando questa soluzione si riducono praticamente a zero i rischi di intrusione da parte di utenti non autorizzati, poiché sia il gateway che l’origin server rimangono su una rete privata e pertanto non accessibile dall’esterno.
I contro di una soluzione del genere ovviamente sono però gli elevati costi telefonici (si chiamerà da telefono mobile un numero fisso o un altro numero mobile) e la necessità di configurare un terminale con i parametri (telefono, username, password e gateway) specifici per il servizio. Questa soluzione rimane tuttavia quella da prediligere per servizi WAP di intranet dove si suppone di aver sempre a che fare con dati estremamente riservati e dove la sicurezza nelle connessioni è da ritenersi fondamentale.
