Sviluppo di un client universale per la sperimentazione di sistemi mobili per micropagamenti

Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
2 
 
I sistemi software che possono garantire quest’obiettivo sono i Web Services che sono 
progettati per supportare l'interoperabilità e l’usabilità tra diversi elaboratori su di una 
medesima rete; caratteristica fondamentale di un Web Service è di offrire un'interfaccia 
software con la quale altri sistemi possono interagire con il Web Service stesso attivando le 
operazioni descritte nell'interfaccia tramite appositi "messaggi". 
Sfruttando questo forte miglioramento dell’interoperabilità, grazie a WS-I (Web Services 
Interoperability Organization), la forte crescita di EDGE e UMTS portando maggiore 
larghezza di banda sui dispositivi mobili e come detto in precedenze l’enorme sviluppo dei 
dispositivi mobili dotati di J2ME, il Java Community Process ha pensato di dover progettare 
delle librerie che permettevano anche ai cellulari di usufruire di tali servizi web. 
Quindi grazie alla JSR-172 da oggi anche i dispositivi mobili potranno sfruttare questa 
tecnologia nuova basata su standard aperti come HTTP e XML. 
Nel 2005 con il Decreto Legislativo n.82 all’articolo tre si diceva: 
“I cittadini e le imprese hanno il diritto a richiedere e ottenere l’uso delle tecnologie 
telematiche nelle comunicazioni con le pubbliche amministrazioni”.  
I servizi di e-governement sono ormai diffusi in tutti i paesi e basta guardarsi intorno per 
vedere quanti cittadini utilizzino il cellulare nelle forme più diverse. Di conseguenza nasce il 
concetto di m-governement che è l’insieme delle attività che possono aiutare la pubblica 
amministrazione a fornire informazioni e servizi ai cittadini che lo desiderano, ovunque e in 
qualunque momento con l’impiego del proprio cellulare. 
Grazie al CNIPA (Centro Nazionale per Informatica nella Pubblica Amministrazione) si sta 
realizzando in modo coordinato servizi di m-governement con i quattro operatori di telefonia 
mobile. Uno dei prodotti presenti nel catalogo dei servizi di m-governement sono i pagamenti 
e soprattutto il settore dei Micropagamenti mobili che si stanno diffondendo sempre più per i 
seguenti motivi: 
1. Celerita': Un pagamento tradizionale con carta di credito richiede tempo per 
l’autenticazione. I sistemi di pagamento tramite SMS o carte RFID richiedono meno di 
un secondo per la verifica e la certificazione dell'autorizzato e identificazione del 
destinatario; 
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
3 
 
2. Sicurezza: Le nuove architetture CHIP (sia SMS, che carte RFID) sono EMV 
compliant, in altre parole rispondono alle nuove e stringenti procedure di sicurezza a 
bordo delle carte (le carte RFID e i SIM dei telefoni sono difficilmente clonabili); 
3. Praticità: la possibilità di acquistare un biglietto della metro o un giornale, o fare un 
ordine in un fast food o una pizzeria senza dover fare la fila e potendo pagare l'importo 
esatto in pochi secondi permette al venditore di smaltire le code celermente, e 
contemporaneamente al cliente di ricevere un miglior servizio. 
Sono tutti questi i motivi per cui si è voluto creare un punto d’incontro che avrebbe potuto 
legare i Web Services, i dispositivi mobili e il mondo dei Micropagamenti. 
Di conseguenza la tesi è stata suddivisa nei seguenti capitoli: 
ƒ Capitolo 1: una panoramica delle tecnologie connesse ai dispositivi mobili in 
particolare della piattaforma J2ME, della sua architettura, i package più importanti tra 
cui quelli per la gestione della connettività e dell’interfaccia utente. 
ƒ Capitolo 2: una descrizione del mondo dei pagamenti. Particolare enfasi sarà data ai 
Micropagamenti mobili, schemi di pagamento come PayWord e PepperCoin e alcune 
riflessioni sulla necessità e importanza degli schemi di Micropagamento. 
ƒ Capitolo 3: una presentazione della JSR-229, una serie di API opzionali per permettere 
ai dispositivi dotati di J2ME di compiere dei pagamenti. 
ƒ Capitolo 4: argomento principale sono i Web Services, dei sistemi software progettati 
per supportare l’interoperabilità offrendo servizi di vario genere a diversi elaboratori 
(nel nostro caso con dispositivi mobili). Si parlerà dello stack d’interoperabilità dei 
WS e come i dispositivi operano per invocare servizi remoti in un’architettura Web 
Services. 
ƒ Capitolo 5: verrà presentato e discusso in dettaglio l’applicazione mobile sviluppata. 
Essa permette a un dispositivo mobile in grado di supportare i profili della JSR-172 e 
229 di gestire un portafoglio elettronico. È possibile quindi eseguire Micropagamenti 
utilizzando tutti i protocolli che sono stati implementati all’interno di un modulo di 
pagamento sotto forma di adattatori. In pratica l’utente potrà gestire all’interno del 
proprio dispositivo modalità di pagamento con carte di credito, con chiavette 
elettroniche, con addebito su credito telefonico, ecc. Tutte queste modalità all’interno 
di un unico dispositivo mobile.  
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
4 
 
Capitolo 1: Tecnologie per i servizi mobili 
 
 1.1 Introduzione a Java 
l linguaggio Java è un linguaggio di programmazione orientato agli oggetti, derivato dal 
C++ (e quindi indirettamente dal C) e creato da James Gosling e altri ingegneri di Sun 
Microsystems. Il gruppo iniziò a lavorare nel 1991, il linguaggio inizialmente si 
chiamava Oak. Il nome fu in seguito cambiato in Java a causa di un problema di copyright (il 
linguaggio di programmazione Oak esisteva già nel 1991). Java fu annunciato ufficialmente il 
23 maggio 1995 a SunWorld. La piattaforma di programmazione Java è fondata sul 
linguaggio stesso, sulla Java Virtual Machine (JVM) e sulle API. Java è un marchio registrato 
di Sun Microsystems. Il 13 novembre 2006 la Sun Microsystems ha rilasciato la sua 
implementazione del compilatore Java e della macchina virtuale sotto licenza GPL. L'8 
maggio 2007 SUN ha rilasciato anche le librerie (tranne alcune componenti non di sua 
proprietà) sotto licenza GPL rendendo Java un linguaggio di programmazione la cui 
implementazione di riferimento è libera.  
 
1.2 La piattaforma Java 
Vediamo ora una panoramica delle piattaforme Java disponibili: 
• J2EE (dall'inglese Java 2 Enterprise Edition) è la versione enterprise della 
piattaforma java. Essa è costituita da un insieme di specifiche che definiscono le 
caratteristiche e le interfacce di un insieme di tecnologie pensate per la realizzazione 
di applicazioni di tipo enterprise e mission critical. Chiunque può realizzare 
un’implementazione di tali specifiche e produrre application server compatibili con le 
specifiche J2EE. La specifica J2EE include molte tecnologie che estendono le 
funzionalità di base della piattaforma Java. Descrive i seguenti componenti: Enterprise 
JavaBeans definiscono un sistema a componenti distribuito che rappresenta il cuore 
della specifica J2EE. Tale sistema, infatti, fornisce le tipiche caratteristiche richieste 
dalle applicazioni enterprise, come scalabilità, sicurezza, persistenza dei dati e altro. Il 
JNDI definisce un sistema per identificare ed elencare risorse generiche, come 
componenti software o sorgenti di dati. Il JDBC è un'interfaccia per l'accesso a 
I
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
5 
 
qualsiasi tipo di basi di dati. Il JTA è un sistema per il supporto delle transazioni 
distribuite. Il JAXP è un API per la gestione di file in formato XML. Il Java Message 
Service descrive un sistema per l'invio e la gestione di messaggi.  
• J2SE (dall’inglese Java 2 Standard edition) versione della Virtual Machine del 
linguaggio di programmazione Java. Contiene le parti basilari della piattaforma Java, 
fornendo così un ambiente completo per produrre applicazioni non enterprise. La J2SE 
è stata organizzata in due parti fondamentali.Core Java è la parte che contiene le API 
fondamentali del linguaggio di programmazione fornisce un’astrazione dove le librerie 
formano il sistema operativo e la JVM un semplice processore, mentre Desktop Java è 
utilizzato per creare GUI di applicazioni o Applet.  
• J2ME (dall’inglese Java 2 Micro edition) è un runtime e una collezione di API per lo 
sviluppo di software dedicato a dispositivi a risorse limitate come PDA, telefoni 
cellulari e simili.J2ME è la tecnologia più diffusa per lo sviluppo di giochi e utilities 
per i cellulari. Come le altre edizioni di Java, J2ME è una piattaforma portabile. Il suo 
funzionamento può essere emulato con un personal computer, cosa che semplifica 
l'attività di sviluppo e di collaudo. Il 22 dicembre 2006 Sun Microsystems ha rilasciato 
il codice sorgente di J2ME. Il codice è stato rilasciato sotto licenza GPL e quindi 
liberamente modificabile da chiunque. IL nome del progetto è stato cambiato in 
phoneME. 
 
 
 
 
 
 
 
 
 
 
Figura 1.1: La piattaforma Java 
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
6 
 
1.3Introduzione a J2ME 
J2ME è stato sviluppato soprattutto come una tecnologia che si rivolge direttamente agli 
apparecchi con risorse (calcolo e banda) limitate. Molti dispositivi di questo tipo (telefoni 
cellulare, PDA, televisori, frigoriferi) non permettono di scaricare e installare software a parte 
quello che è stato configurato durante il processo di creazione. Con l’avvento di questa 
tecnologia i micro apparecchi non sono più statici ma diventano in grado di caricare e 
installare nuovi applicativi JAVA e vari altri tipi di contenuti. Poiché molti di loro hanno 
capacità limitate, non sarebbe realistico disporre di tutte le classi e interfacce J2SE su di un 
micro apparecchio. Per esempio un telefono cellulare dotato di uno schermo limitato non può 
fornire tutte le funzionalità disponibili nell’AWT (Abstract Window Toolkit). La micro 
edition è stata introdotta per rispondere ai bisogni specifici degli apparecchi che non 
supportano J2SE e J2EE.Un telefono cellulare e un palmare dispongono entrambi di 
dimensione fisica limitata ma un classico telefono cellulare non può avere una risoluzione 
sullo schermo che si avvicini a quella di un palmare. Per questo motivo non è sufficiente una 
sola piattaforma Java che sia adatta a tutte le applicazioni. È necessario quindi definire una 
piattaforma Java per un’ampia gamma di prodotti (Configurazione) e uno strumento di misura 
per classificare le periferiche di cui J2ME s’interessa (Profili). Il traguardo di questa 
piattaforma è di scrivere il codice una sola volta per i vari dispositivi creando una grande 
portabilità.  
 
1.3.1 Vantaggi e svantaggi 
I vantaggi rispetto ad altre tecnologie, come il WAP e Sim Toolkit, sono principalmente: 
- la possibilità di sfruttare le applicazioni in locale, residenti e funzionanti anche off-
line; 
- la capacità elaborativa; 
- la flessibilità nell'installazione di nuove applicazioni; 
- l'interfacciamento con le piattaforme web che lavorano con JAVA (Servlet o JSP) è 
immediato. 
 
Lo sviluppo in Java, inoltre, è facilmente derivabile dallo sviluppo in C++, si possono cioè 
riconvertire risorse e applicazioni agevolmente. Inoltre l'interfacciamento con le piattaforme 
web che lavorano con JAVA (Servlet o JSP) è pressoché immediato. Probabilmente è proprio 
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
7 
 
su questa seconda parte che vi sono più possibilità di business, non tanto quindi 
sull'applicazione residente sul device. Sebbene si tratti di uno standard aperto, non mancano 
alcune peculiarità che possono causare problemi di compatibilità tra terminali differenti. 
Siemens, ad esempio, ha definito una serie di librerie proprietarie che risiedono solo sui propri 
terminali, e che permettono di controllare alcune funzionalità del telefono (ad esempio la 
vibrazione).  
Oltre alle librerie proprietarie legate al terminale, vi è la disponibilità di differenti Virtual 
Machine (gli interpreti delle applicazioni Java), se ne citano due a titolo di esempio:  
• Aplix JBlend, diffuso in Giappone, non solo sui telefonini ma anche su PDA e 
videocamere (Sony, Sharp, Toshiba, Casio...); 
• PersonalJava, legato alla piattaforma Symbian e appoggiato su CDC.  
Le capacità multimediali sono attualmente limitate, infatti, non è prevista ad esempio la 
possibilità di riprodurre file audio e, soprattutto per ragioni di sicurezza, permettere ad 
applicazioni J2ME l'accesso alle informazioni sulla Sim o sui parametri di configurazione del 
terminale.  
Per far fronte ad applicazioni che richiedono l'appoggio di uno o più database, esistono due 
possibilità: 
1. utilizzare il terminale come semplice interfaccia client - quindi come un browser - 
verso un sistema server remoto dove risiedono i dati. Uno dei vantaggi, in questo caso, 
è il ridotto impegno nell'aggiornamento del software sul device. Non è inoltre critica 
un’eventuale rottura o sostituzione del terminale, per questo può essere adatta a 
personale a elevata mobilità sul territorio, come trasportatori o addetti alle riparazioni.  
2. disporre di applicazioni - ad esempio su Pda - che lavorano su un database locale, 
sincronizzato con quello remoto. In questo caso sono disponibili versioni ridotte di 
DB, come l'UltraLight di Sybase o DB tool di IBM, che in pochi KB raccolgono le 
funzionalità principali. In questo caso è importante che la suite di sviluppo SDK 
preveda una serie di librerie pronte per l'interfacciamento con tali DB. 
Le limitazioni rispetto alla classica piattaforma J2SE sono: 
- Gruppi di Thread: la JVM non supporta la classe ThreadGroup quindi non si possono 
lanciare (o fermare) più Thread in un colpo solo; 
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
8 
 
- Calcoli in virgola mobile: non ci sono numeri in virgola mobile ma è comunque 
possibile utilizzarli con opportune librerie; 
- Interfaccia Nativa Java (INJ): non è possibile chiamare funzioni native del S.O. 
ospitante per effettuare operazioni; 
- Caricatore di classi personalizzato: il caricatore di classi subisce severi controlli e non 
può essere sostituito, ignorato o modificato; 
- Riflessione: in J2SE si possono usare le classi Reflection per ottenere informazioni 
sulla JVM in esecuzione. 
 
1.4 Configurazioni 
Una Configuration è la descrizione di un Java Runtime completo per una determinata 
categoria di dispositivi con caratteristiche hardware simili. Essa si può considerare composta 
dalle seguenti tre parti: 
- Una JVM in grado di eseguire del byte code; 
- L’implementazione nativa di alcune interfacce per l’interazione con il SO su cui la JVM è in 
esecuzione; 
- Un insieme di classi core (API) standard. 
Definire una particolare Configuration significa quindi definire quelle che sono le possibili 
operazioni minime che la JVM può eseguire, quali di queste sono implementate in modo 
nativo e quali sono le librerie di classi disponibili per lo sviluppo di applicazioni. Come 
vedremo successivamente, alcune classi saranno un sottoinsieme di quelle disponibili nella 
J2SE e altre saranno invece caratteristiche della particolare Configuration concepita per una 
categoria 'orizzontale' di dispositivi. Si dirà inoltre che un dispositivo utilizza una particolare 
Configuration se dispone di tutte le funzionalità descritte nel relativo documento di 
specifiche. Al momento, le J2ME definiscono le seguenti due Configuration: 
- Connected Device Configuration (CDC): è una configurazione progettata per i 
dispositivi con più memoria e larghezza di banda più grande della rete. È adatta per 
sistemi di automazione domestica, navigazione e di telemetria. 
ƒ 512 kb (minimo) di memoria per l’esecuzione Java; 
ƒ 256 kb (minimo) per l’allocazione di memoria al momento dell’esecuzione; 
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
9 
 
ƒ Connettività di rete, possibilmente persistente e a banda larga. 
A questa categoria appartengono dispositivi quali telefoni abilitati al Web, sistemi di 
navigazione, Web TV e molti altri ancora. Notiamo come una delle caratteristiche 
fondamentali di questa Configuration sia quella relativa alla possibilità di poter supportare 
un’implementazione della JVM uguale a quella prevista per la J2SE e precisamente alla 
versione 1.3.1. Come vedremo, sebbene tutte le API della J2SE possano essere gestite dalla 
JVM di questa Configuration, solamente alcune saranno disponibili per 
ciascun’implementazione.  
- Connected Limited Device Configuration (CLDC): Questa configurazione è intesa 
per i dispositivi con i collegamenti di rete intermittenti, i piccoli processori e la 
memoria limitata.   
ƒ 128 kb di memoria per l’esecuzione Java; 
ƒ 32 kb di memoria per l’allocazione di memoria al momento dell’esecuzione; 
ƒ Interfaccia utente limitata; 
ƒ Alimentazione elettrica ridotta, fornita tipicamente da batteria; 
ƒ Connettività di rete, di solito wireless a banda stretta e ad accesso intermittente. 
A questa categoria appartengono dispositivi quali PDA, telefoni cellulari, palmari e molti 
altri. A differenza della CDC, la CLDC non può disporre di una JVM completa, per cui si 
renderà necessario l’utilizzo di una JVM più semplice, che è stata individuata nella KVM. 
Diciamo subito che una configurazione CLDC non implica necessariamente una virtual 
machine KVM, anche se, al momento, si tratta dell’unica VM disponibile per questo tipo di 
dispositivi e, d'altro canto, la KVM stessa supporta al momento soltanto la configurazione 
CLDC. E’ importante sottolineare come la CLDC sia un sottoinsieme della CDC. Questo ha 
come conseguenza il fatto che un’applicazione sviluppata per la CLDC dovrà necessariamente 
funzionare anche sulla CDC. 
Le relazioni tra la J2SE, la CDC e CLDC sono espresse molto bene dalla Figura 1.2. Notiamo 
come la CDC si possa considerare un’estensione di un sottoinsieme della J2SE, poiché 
include alcune nuove classi ad hoc per dispositivi con risorse limitate non presenti nella J2SE, 
e come la CLDC si possa considerare invece un sottoinsieme in senso stretto della CDC.  
 
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
10 
 
 
 
 
 
 
         
 
  
 
Figura 1.2 Relazione tra J2SE, CDC e CLDC 
 
 
1.4.1 Profili 
Abbiamo visto come i dispositivi, o meglio intere categorie anche eterogenee tra loro, siano 
classificate attraverso il concetto di Configuration sulla base delle loro capacità hardware. 
Abbiamo anche sottolineato come questa classificazione non tenga conto delle funzionalità 
del particolare tipo di dispositivo. Un'applicazione per un telefono cellulare dovrà comunque 
essere diversa da quella in esecuzione su un PDA perché le funzionalità dei due dispositivi 
sono molto diverse tra loro. L’insieme di API, costruite da un minimo comune denominatore 
quale può essere una stessa Configuration, che permettono di sfruttare le particolari 
caratteristiche di uno specifico dispositivo, definiscono quello che si chiama Profile. Quello di 
Profile è un concetto fondamentale in quanto, a livello d’implementazione, rappresenta un 
insieme di API e di librerie di classi, costruite sopra una determinata Configuration, che 
permettono di accedere alle funzionalità caratteristiche di una determinata tipologia di 
dispositivi.   
Normalmente quindi il concetto di Profile risulta strettamente legato a uno specifico segmento 
di mercato verticale, ma è possibile parlare di Profile anche per importanti gruppi di 
applicazioni di un determinato settore che possono girare su dispositivi di tipo diverso: è 
possibile ad esempio definire un Profile, con relativo set di API e librerie di classi per 
applicazioni di home-banking. Risulta così evidente come un particolare dispositivo sia in 
grado di gestire diversi Profile, oltre a quello tipico della propria categoria.  
Ci siamo soffermati a definire nel dettaglio il concetto di Profile perché deve essere chiaro sin 
da ora che tutte le applicazioni per dispositivi mobili devono essere scritte 'per' un determinato 
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
11 
 
Profile, e non per un particolare dispositivo o per una configurazione.  Il Profile si può quindi 
considerare il contratto tra un'applicazione e un segmento di mercato verticale. 
Alla luce di questo principio inderogabile, i costruttori di dispositivi conservano la libertà di 
decidere quale Profile implementare su un determinato dispositivo, ma una volta optato per 
uno o più profili hanno l'obbligo di implementarne necessariamente tutte le funzionalità.  
In quest'ottica assume anche un altro significato, il concetto di "portabilità", che nel panorama 
dei dispositivi mobili assume una connotazione e soprattutto un "raggio di azione" diversi 
rispetto all'omologo concetto nel mercato dei desktop e dei server: i dispositivi mobili 
possono differire tra di loro notevolmente per dimensioni di memoria, ampiezza del display, e 
via dicendo, e pertanto non avrebbe senso ricercare una portabilità universale a tutti i costi, 
soprattutto per motivi economici. I requisiti di portabilità assumono pertanto una valenza 
logica e soprattutto economica solamente nell'ambito di una categoria di dispositivi dello 
stesso tipo, quindi per meglio dire nel contesto di uno stesso Profile: a un utente interessa 
ovviamente che la sua applicazione per un'agenda elettronica funzioni correttamente sui suoi 
due cellulari di marche diverse, mentre poco importa se non gira anche sulla sua lavastoviglie! 
Tutte le applicazioni scritte per un determinato Profile dovranno quindi poter essere eseguite 
in ogni dispositivo che supporti il Profile stesso.  
I profili sono definiti da gruppi aperti d’industrie che lavorano aderendo al SUN Java 
Community Process Programm. In questo mondo le industrie del settore possono decidere 
autonomamente quali elementi sono necessari per fornire soluzioni migliori per i loro 
prodotti. 
Ecco una lista in dettaglio dei vari profili: 
 
• PDA Profile: è rivolto ai PDA, che hanno uno schermo migliore è più memoria di un 
cellulare. Offre una libreria d’interfaccia utente più sofisticata e delle API per un uso 
comodo delle funzioni del sistema operativo. 
 
• Foundation Profile: Il FP fornisce le API per la gestione di dispositivi privi di 
un’interfaccia grafica tradizionale e si rivolge quindi allo sviluppo di applicazioni 
embedded o rivolte a dispositivi di largo consumo. Si tratta di un Profile che fornisce 
funzionalità minime rispetto a quelle fornite dal CDC su cui si appoggia. Le sue 
caratteristiche principali sono quindi le seguenti: 
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
12 
 
ƒ le sue API sono basate sulle API della J2SE e quindi accessibili a tutti gli 
sviluppatori Java; 
ƒ è stata pensata per l’esecuzione di applicazioni in sistemi embedded; 
ƒ è rivolta a dispositivi che non dispongono di un’interfaccia grafica tradizionale; 
ƒ Si tratta quindi di un ambiente rivolto a dispositivi come ad esempio le stampanti, 
router, application server, lavatrici, etc.  
 
• Personal Basic Profile: Come il FP, essa fornisce delle API per lo sviluppo di 
applicazioni embedded o rivolte a dispositivi di largo consumo. Questa volta, però, si 
tratta di dispositivi con un’interfaccia grafica standard. Essa è caratterizzata da: 
ƒ un framework light per la creazione d’interfacce grafiche; 
ƒ supporta la xlet come modello per lo sviluppo delle applicazioni; 
ƒ comprende tutte le API del Foundation Profile; 
ƒ Ricordiamo che il modello di programmazione che va sotto il nome di xlet è molto 
simile a quello relativo allo sviluppo di Applet giacché esiste uno xlet manager che 
ne gestisce il ciclo di vita. L’unica differenza consiste nell’assenza del vincolo 
legato all’utilizzo di particolari API, quali possono essere quelle del package 
java.applet che ne permette quindi l’utilizzo in un numero elevato di scenari; 
ƒ Si tratta di un ambiente rivolto a quei dispositivi che richiedono lo sviluppo di 
un’interfaccia grafica senza però la necessità di tutti i componenti disponibili, ad 
esempio, nell’AWT.  Alcuni dispositivi in grado di eseguire applicazioni di questo 
tipo sono ad esempio televisioni interattive, gaming online e altre ancora. 
 
• Personal Profile: rappresenta un insieme di API per la gestione di applicazioni dotate 
d’interfacce grafiche basate sull’AWT completo. Le caratteristiche di questo Profile  
sono: 
ƒ piena compatibilità con l’AWT della J2SE; 
ƒ supporto all’esecuzione degli Applet; 
ƒ comprende tutte le API del Personal Basis Profile; 
ƒ Questo Profile si rivolge a scenari che utilizzano dei PDA o Web Browser 
embedded. 
 
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
13 
 
• RMI Optional Package (JSR-66): La Remote Method Invocation (RMI) è la 
tecnologia dell’J2SE che permette l’invocazione di alcuni metodi su oggetti remoti, in 
altre parole in esecuzione su un'istanza della JVM diversa da quella del client, il quale 
però usa questi oggetti come se fossero locali. E’ una tecnologia che si appoggia 
fortemente sulla serializzazione degli oggetti e quindi non disponibile in quei Profile 
basati sulla CLDC che non dispongono di questa feature. Le funzionalità fornite da 
quest’Optional Package sono un sottoinsieme di quelle disponibili nella J2SE nella 
versione 1.3. E’ possibile utilizzare queste API in alcuni Profile basati sul CDC che 
incorporano il Foundation Profile, tra cui il Personal Profile. Le funzionalità gestite 
da quest’OP sono relative all’utilizzo del Java Remote Method Protocol, 
serializzazione degli oggetti, GC distribuito, lookup degli oggetti e Network Class 
Loader per il caricamento del bytecode dalla rete. Non sono supportati il tunneling 
HTTP e l’utilizzo del protocollo Java 1.1 stub.  
 
• Wireless Messaging API (JSR-120): permette la realizzazione di applicazioni che 
utilizzano l’invio e la ricezione di messaggi attraverso l'uso di Short Message Service. 
Si tratta di un insieme di API che estendono il Generic Connection Framework (GCF), 
mettendo a disposizione una nuova interfaccia Connection per la gestione appunto dei 
messaggi SMS. Attraverso l’interfaccia javax.wireless.messaging.MessageConnection 
è, infatti, possibile gestire SMS classici e messaggi SBS (Short for Cell Broadcast 
Service). Ciascuna risorsa è individuata attraverso la definizione di una sintassi per la 
definizione degli Universal Resource Locator (URL) sms:// o cbs://. Quest’OP può 
essere utilizzato con un qualunque Profile J2ME. 
 
• Web service API (JSR 172): definiscono un subset di JAXP 1.2 e JAX-RPC 1.1. 
Comprendono quindi le API per il parsing di un documento XML supportando la 
specifica di SAX 2.0, XML namespace, codifiche UTF-8 e UTF-16 e un’eventuale 
validazione tramite le DTD. I limiti della prima subset sono che non supportano DOM 
1.0, DOM 2.0, XSLT e la validazione opzionale. La seconda subset comprende le API 
per l’invocazione remota di metodi tramite documenti XML supportando WSDL 1.1, 
SOAP 1.1 (in futuro 1.2), XML 1.0 e XML schema, binding su SOAP e trasporto su 
HTTP, WS-I Basic Profile 1.0. 
 
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
14 
 
• Payment (JSR 229): quest’API fornisce uno strumento per iniziare transazioni di 
pagamento permettendo agli sviluppatori di gestire differenti strumenti di pagamento.  
Questi ultimi saranno soprattutto indirizzati ai “operator charging”, clienti con account 
e ai fornitori di servizi presso terzi. 
 
Quello che interessa a noi maggiormente e tratteremo nel dettaglio oltre alla JSR 172 e 299 
sono i profili MIDP. Esso sta per Mobile Information Device Profile ed è un profilo che 
estende la configurazione CLDC. Esso, definisce un set di librerie minimo ma funzionale per 
la creazione d’interfacce grafiche per display, offre un servizio per il salvataggio persistente 
dei dati (RMS), implementa protocolli di comunicazione e soprattutto si occupa della gestione 
del ciclo di vita delle applicazioni. Esso risulta sufficientemente leggero e astratto da poter 
essere portato su una grande varietà di piattaforme ed è continuamente arricchito di librerie 
opzionali. 
La prima versione di MIDP 1.0 è stata rilasciata nel 2000 e consisteva di alcune classi 
ereditate da J2SE attraverso CLDC. Essa, forniva API per la gestione di display con limitata 
taglia, metodi d’input come penne, tastiere, persistenza dei dati, messaggistica (SMS, e-mail), 
servizi di reti basati su datagram, servizi orientati alla connessione e servizi di telefonia 
mobile (effettuare chiamate/ricevere). I vari package relativi alla versione 1.0 possono essere 
riassunto in queste seguenti categorie: 
• javax.microedition.lcdui: è il così detto User Interface Package che contiene le classi 
per creare delle interfacce utente sul display; 
• javax.microedition.rms: utilizzato per la memorizzazione persistente, fornisce dei 
meccanismi che permettono di memorizzare e recuperare dati in modo persistente; 
• javax.microedition.midlet: definisce le interfacce e il ciclo di vita delle MIDlet; 
• javax.microedition.io: detto anche il package del Networking include dei supporti per 
la connessione alla rete da un Connected Limited Device Configuration. Contiene 
molte interfacce ma una sola classe Connector utilizzata per creare gli oggetti 
connection; 
• java.io si occupa di gestire l'input e l'output da un generico stream di dati; 
Sviluppo di un client universale per la sperimentazione di sistemi mobili per Micropagamenti 
 
15 
 
• java.lang include tutte le classi tipiche del linguaggio Java incluse nella Java 2 
Standard Edition. In questo package troviamo tutte le classi per i tipi di dato (Boolean, 
Byte, Character, Integer, Long, Short, String, StringBuffer) oltre alle classi basi di 
sistema e per i Thread (Math, Object, Runtime, System, Thread, Throwable); 
• java.util include tutte le classi di utility incluse nella Java 2 Standard Edition. In 
questo package troviamo le più classi di utilità che un programmatore java è abituato a 
utilizzare (Calendar, Date, Hashtable, Random, Stack, Timer, TimerTask, TimeZone, 
Vector). 
Il successo di MIDP 1.0 e l'impressionante livello tecnologico raggiunto dai terminali di 
ultima generazione (ormai quasi tutti i cellulari sono dotati di sistema operativo e una discreta 
quantità di memoria), ha affrettato i tempi e alla fine del 2002 è stata rilasciata la specifica 
MIDP 2.0, l'evoluzione del precedente profilo, potenziato soprattutto per sfruttare le nuove 
capacità di calcolo messe a disposizione dei terminali. Le novità principali sono: 
- supporto per il protocollo HTTP con crittografia (HTTPS); 
- gestione della rete migliorata; 
- supporto migliorato alla distribuzione delle applicazioni; 
- nuovi componenti per le interfacce grafiche (GUI); 
- supporto per giochi; 
- supporto per capacità multimediali (suono e animazioni) un modello di sicurezza 
(trustet MIDlets). 
Il MIDP 2.0 aggiunge alle classi già esistenti nella versione 1.0 i seguenti package: 
• javax.microedition.lcdui.game: fornisce classi per lo sviluppo di giochi e di tutto ciò 
che riguarda il gaming per dispositivi mobili, la grafica in particolare; 
• javax.microedition.pki: fornisce le classi per la certificazione di connessioni sicure; 
• javax.microedition.media: fornisce le funzionalità audio di base come generazione 
dei toni e playback, e quindi per la gestione dell’audio. 
In effetti, quest’ultima versione introduce soltanto delle API che potevano essere già 
implementate nella sua versione precedente con un grande dispendio di codice. In questo 
modo si ottiene un vantaggio in termini di performance e di riduzione della dimensione delle 
applicazioni.