Valutazione critica
L’ambiente JavaCard 2.0 non può deludere le aspettative di chi lo utilizza: si tratta di un ambiente veramente ben progettato. L’utilizzo del linguaggio Java, le caratteristiche dell’ambiente d’esecuzione e l’utilizzo della JavaCard API per l’accesso alle risorse della carta permettono la realizzazione di servizi sulle carte sfruttando tutta la potenza dei paradigmi della progettazione orientata agli oggetti. Particolarmente utile è anche l’utilizzo del linguaggio di programmazione Java, che permette, una volta appresi i pattern relativi, di sviluppare velocemente servizi facilmente modificabili ed estendibili, usando fra l’altro un linguaggio di programmazione utilizzabile anche per lo sviluppo delle applicazioni di controllo esterne.
E importante notare un’altra cosa relativamente all’ambiente JavaCard: utilizzando i paradigmi della programmazione orientata agli oggetti, si ottengono spesso applicazioni JavaCard troppo esose in fatto di risorse, in particolare di memoria, a causa dell’immancabile overhead che questo tipo di progettazione implica. La maggior parte di queste applicazioni non possono poi essere eseguite sulle JavaCard attualmente disponibili in commercio, a causa della mancanza di memoria fisica per la memorizzazione delle classi e delle interfacce o per l’esecuzione dei metodi. L’unica soluzione possibile risulta essere quella di forzare a tal punto il progetto ad oggetti da rendere conveniente l’utilizzo di  tecniche di progetto che non utilizzano il paradigma della programmazione ad oggetti, quali la progettazione strutturata. In questo caso, al posto di creare un insieme di classi e di interfacce che collaborano fra loro, è sufficiente creare un’unica classe che implementa tutte le funzionalità, riducendo di fatto al minimo l’overhead.

E’ comunque molto importante notare come queste limitazioni siano dovute alla scarsità di risorse dei dispositivi e non all’ambiente JavaCard stesso, tale ambiente non pone, infatti, alcun limite alla memoria utilizzabile. Supponendo di disporre di dispositivi con risorse sufficienti, la progettazione ad oggetti potrebbe essere applicata senza problemi, ma visto che la stragrande maggioranza di dispositivi JavaCard attualmente disponibili pone limiti piuttosto severi alla memoria disponibile, appare chiaro, purtroppo, che il miglior stile di programmazione utilizzabile è quello della progettazione strutturata.
Qualche problema esiste anche in termini di portabilità. L’ambiente JavaCard standard fornisce un insieme di funzionalità veramente minimo, che non comprende la gestione del tipo di dato int, la presenza di un garbage collector, l’implementazione degli algoritmi di crittografia ed altro ancora, considerando queste come estensioni standardizzate dell’ambiente JavaCard. Nel momento in cui si utilizza una carta dotata di ambiente JavaCard, questa solitamente contiene una o più di queste estensioni, che spesso risulta necessario utilizzare (si pensi al tipo di dato int, per esempio). Purtroppo, nel momento in cui si utilizza un’estensione dell’ambiente JavaCard, il codice prodotto può essere utilizzato solamente su JavaCard che contengano a loro volta l’estensione utilizzata, riducendo, di fatto, la portabilità. A discolpa dei progettisti che hanno pensato l’ambiente JavaCard, va comunque detto che questa scelta è stata fatta per gestire il maggior numero di carte possibile, e quindi gli hardware più disparati, e che solitamente la scelta della JavaCard da utilizzare si orienta verso una classe di prodotti per un certo utilizzo pratico, che solitamente presenta le stesse estensioni.

Concludendo, l’ambiente JavaCard può essere considerato più che adatto ad un utilizzo industriale, cioè per la realizzazione di applicazioni reali per problemi reali. 

Passando al framework OpenCard, questo è indiscutibilmente uno strumento molto comodo per l’accesso alla carta e ai servizi installati su essa, come si può facilmente costatare analizzando le applicazioni che ne fanno uso, ma presenta alcuni problemi che attualmente ne limitano l’utilizzo.

In primo luogo, le applicazioni reali che utilizzano il framework OpenCard hanno dimostrato una certa mancanza di affidabilità, presentando numerosi problemi di accesso alla carta. Questi problemi sembrano in realtà riconducibili più ai driver di basso livello che forniscono l’interfaccia al framework OpenCard che al framework OpenCard stesso, ma è anche vero che la struttura del framework influenza pesantemente le scelte sulle funzionalità di basso livello che devono essere fornite dai driver.

In secondo luogo, il framework OpenCard non è così facilmente utilizzabile come si dovrebbe. La necessità di mantenere la massima generalità, necessaria per la gestione di tutti i possibili lettori di smartcard, richiede uno sforzo piuttosto elevato in fase di implementazione degli accessi alla carta dall’applicazione esterna. A questo si aggiunge anche la mancanza di una certa stabilità del framework, attualmente ancora in evoluzione a causa della sua relativa immaturità, che implica modifiche non banali al codice già scritto per passare da una certa versione del framework a quella successiva.

I due punti precedenti fanno sì che un’interfaccia di accesso proprietaria, magari corredata da un framework sviluppato appositamente, possa ancora essere una soluzione accettabile per l’accesso a JavaCard in ambito industriale, soprattutto a causa della grande affidabilità che questa soluzione solitamente fornisce. Questo rimarrà vero fino a quando OpenCard Foundation avrà migliorato il suo framework e saranno disponibili implementazioni delle interfacce veramente affidabili. Solo allora i vantaggi in termini di indipendenza nell’accesso a SmartCard e ai servizi installati potranno effettivamente far diventare il framework OpenCard la soluzione più adatta in ambito industriale.

Per quanto riguarda, infine, i tool di supporto allo sviluppo di applicazioni accennati negli articoli precedenti, quelli forniti da De La Rue per la JavaCard GalactIC, pur non essendo integrati in un unico ambiente, sono affidabili e comodi da usare. Una volta appreso il loro funzionamento, è possibile realizzare molto efficientemente tutte le operazioni richieste normalmente. L’affidabilità di questi tool è veramente ottima: difficilmente sono osservabili problemi di alcun tipo, né di funzionamento né sul risultato delle operazioni. Naturalmente, la loro mancata integrazione e le loro interfacce avanzate richiedono un certo addestramento prima di un loro proficuo utilizzo.

Per quanto riguarda iB-IDE fornito da Dallas Semiconductor per gli iButton, questo ambiente integrato di sviluppo presenta alcuni problemi di funzionamento piuttosto fastidiosi, fra questi problemi nella gestione dell’interfaccia grafica e nell’utilizzo del debugger, oltre ad una certa lentezza di esecuzione, con richieste di risorse piuttosto elevate, come del resto tutti gli ambiente integrati di sviluppo scritti in Java attualmente disponibili. Tutti i problemi sembrano comunque riconducibili più a problemi di gioventù dell’ambiente integrato che a problemi concettuali veri e propri. Con il progredire delle versioni questi malfunzionamenti vengono, infatti, puntualmente corretti e sempre più è possibile apprezzare la rapidità con cui è possibile ottenere applicazioni funzionanti.

Tutto ciò sembra indicare che gli strumenti per lo sviluppo di applicazioni JavaCard attualmente disponibili sono al massimo carenti dal punto di vista della maturità: del resto, il concetto di smartcard programmabile in Java è relativamente nuovo. Comunque, visto l’interesse delle aziende mondiali in questo settore, probabilmente si assisterà, nel corso dei prossimi anni, ad una maturazione continua e repentina degli strumento di sviluppo, maturazione che porterà le JavaCard a sempre maggiori risultati nelle applicazioni reali del mondo reale.
 

Conclusioni 
Dalle valutazioni espresse in questo articolo, risulta lampante come l’ambiente JavaCard sia una delle soluzioni migliori applicabili nel campo delle smartcard: questo ambiente utilizza, infatti, il linguaggio principe in fatto di portabilità, è estremamente scalabile, prevede meccanismi standard di estensione e, non ultimo, permette la progettazione orientata agli oggetti. 
Come già detto precedentemente, l’esiguità di risorse disponibili impedisce, di fatto, l’applicazione della progettazione orientata agli oggetti. Questo è spesso dovuto ai requisiti in termini di costi dei dispositivi e all’effettiva necessità di risorse per le applicazioni a cui si orienta il dispositivo, per cui questa limitazione è spesso più che accettabile. Naturalmente, la mancanza di questa caratteristica non inficia più di tanto i meriti dell’ambiente JavaCard nei confronti degli altri ambienti attualmente disponibili per le smartcard. Ne risulta che, in ambito reale, l’utilizzo di questo ambiente è certamente consigliabile nella stragrande maggioranza delle applicazioni.

Diversa è la situazione del framework OpenCard di OpenCard Foundation e degli strumenti attualmente disponibili per lo sviluppo di applicazioni: in questi campi risulta infatti ancora prevalente una sorta di immaturità diffusa, dovuta, a mio avviso, alla ridotta cerchia di sviluppatori interessati ed alla gioventù dell’idea. Naturalmente, il framework OpenCard è, e sempre di più sarà, un entità da tenere bene in considerazione per lo sviluppo di applicazioni JavaCard, in quanto applica al lato applicativo gli stessi concetti applicati dall’ambiente JavaCard all’accesso alle funzionalità del dispositivo.

Del resto, la bontà dell’ambiente JavaCard, e di tutte le tecnologie che ruotano attorno ad esso, sembra essere confermata dall’attuale panorama di applicazioni orientate alle JavaCard disponibili. Si pensi che solo qualche tempo fa questo ambiente era perlopiù sconosciuto, mentre ora molti sostengono che un radioso futuro attende questa tecnologia.
 
 
 

Bibliografia
Chi intendesse approfondire i temi trattati in questo articolo, può trovare documenti ai seguenti indirizzi:
 

• www.javasoft.com: il sito web di SUN dedicato alla tecnologia Java, dove è possibile reperire informazioni sulle estensioni relative ad OpenCard e per le specifiche relative alla tecnologia JavaCard;
• www.opencard.org: il sito web della Fondazione OpenCard, da cui è possibili reperire tutte le informazioni sul framework OpenCard utilizzato dai Java iButton per l’interfacciamento con l’entità esterna di controllo;
• www.ibutton.com: il sito web di Dallas Semiconductor dedicato ai Java iButton e agli altri dispositivi della stessa azienda, denominati genericamente iButton;
• www.oberthurcs.com: il sito web di Oberthur, dove sono reperibili le informazioni sulle ultime versioni di JavaCard GalactIC.