|
|||||||||||||||||||||||||||||||||
I Dallas Semiconductor Java iButton sono dispositivi miniaturizzati molto resistenti che integrano al loro interno l’ambiente JavaCard. L’involucro del dispositivo, come si può immaginare dal nome, ha il formato di un bottone ed è realizzato in acciaio: questo permette una resistenza agli urti, alle flessioni, alla polvere e all’acqua indubbiamente superiori alle normali JavaCard. Se a questo si aggiunge il basso costo, non solo dei dispositivi ma anche dei lettori che ne permettono l’interfacciamento con i dispositivi di controllo, ne risulta che questi dispositivi possono essere utilizzati con profitto per la realizzazione di una moltitudine d’applicazioni.. |
|||||||||||||||||||||||||||||||||
Introduzione
Nella prima parte di questo articolo si sono prese in considerazione le caratteristiche tecniche del dispositivo, sia dal punto di vista del hardware che del software, e le caratteristiche dell’interfaccia con i dispositivi di controllo, in particolare la MicroLAN, cioè il mezzo che permette di interfacciare più dispositivi utilizzando un unico bus collegato ad un’unica porta. Chi non abbia letto questo articolo può trovarlo pubblicato sul numero di Luglio 2000 di MokaByte. In questa seconda parte dell’articolo verrà invece analizzato l’ambiente di sviluppo utilizzabile per la creazione di applicazioni Java basate su iButton. Questo è in realtà un vero e proprio IDE, cioè un ambiente integrato di sviluppo, che contiene al suo interno un editore di testo per la scrittura del codice sorgente, un’interfaccia di compilazione per il codice delle applicazioni e applet Java, un’interfaccia di compilazione per le applet JavaCard e un sistema di debugging, nonché altri tool di supporto al test delle applicazioni sviluppate. Nel
proseguo dell’articolo verrà descritto, fra le altre cose, il wizard
di creazione di un nuovo progetto, molto utile per creare velocemente la
struttura sia dell’applicazione Java che dell’applet JavaCard, il debugger
integrato, utilizzabile per l’esecuzione passo-passo del codice prodotto,
l’APDU sender, strumento indispensabile per il test delle applet JavaCard
prodotte, e verranno discussi i principali parametri di configurazione
degli iButton disponibili.
Dallas iB-IDE
1.0
Questo
ambiente integrato di sviluppo, fornito gratuitamente, è scritto
interamente in Java. Questo permette di eseguire l’ambiente su una moltitudine
di piattaforme diverse: attualmente però sono distribuite, per via
dei driver di connessione ai lettori tramite porta parallela, solo due
versioni, una per piattaforme Windows (95/98/NT) e una per piattaforme
Solaris. Purtroppo la scelta di sviluppare l’intero ambiente in Java porta
a richieste di sistema piuttosto impegnative, almeno per la piattaforma
Windows. Per un utilizzo minimo dell’ambiente in questione è, in
pratica, necessario disporre di almeno un processore a 300 MHz ed almeno
64 MByte di RAM. Questo ambiente integrato di sviluppo è comunque
dotato di tutte le funzionalità necessarie allo sviluppo di applicazioni,
sia sul lato PC o workstation sia sul lato Java iButton, ed è realizzato
con estrema perizia. E’, infatti, presente un ottimo editore di testo a
cui si affianca la gestione dei progetti con una finestra per l’organizzazione
del codice delle JavaCard Applet e del codice da eseguire su PC o workstation
a cui è collegato il lettore (che d’ora in poi chiameremo Host,
come consigliato da Dallas Semiconductor). La figura 1 mostra iB-IDE in
modalità di gestione di un progetto.
Notare che il compilatore utilizzato è quello del JDK 1.2, che deve essere presente sulla macchina prima di eseguire l’installazione di iB-IDE. Questo ha come evidente vantaggio l’utilizzo di un compilatore Java altamente standardizzato e rispondente alle specifiche. Questo ambiente contiene anche un debugger, corredato da un utilissimo simulatore di iButton che permette l’esecuzione passo passo del codice delle JavaCard Applet. A questo si affianca anche uno strumento molto utile per la verifica delle JavaCard Applet: un APDU Sender, in pratica uno strumento che permette di inviare, tramite un’apposita interfaccia grafica, comandi APDU all’iButton simulato o all’iButton reale. Questi due strumenti saranno analizzati più in dettaglio nel proseguo dell’articolo. Notare
infine la presenza di un comodo help in linea integrato con l’ambiente
di sviluppo. Da questo help in linea è possibile avere informazioni
relativamente a iB-IDE ed al suo utilizzo, oltre che informazioni relative
alle classi che integrano il framework OpenCard e alle classi d’accesso
alle funzionalità aggiuntive messe a disposizione dall’hardware
dell’iButton. La figura 2 mostra l’help in linea relativo all’ambiente
integrato di sviluppo ed alle sue funzionalità.
La
prima funzionalità, estremamente comoda, messa a disposizione del
programmatore dall’ambiente integrato di sviluppo è la possibilità
di generare una parte consistente del codice della JavaCard Applet e dell’applicazione
Host in fase di creazione di un nuovo progetto. Durante questa fase è,
infatti, possibile utilizzare un wizard che genera tutto il codice relativo
allo scheletro della JavaCard Applet e dell’applicazione Host. La figura
3 mostra un passo del wizard, più precisamente quello che richiede
al programmatore quali istruzioni intende utilizzare per l’interfaccia
con la JavaCard.
La
figura 4 mostra invece un altro passo dello stesso wizard che richiede
al programmatore quali operazioni di conversione intende utilizzare sull’Host
e sulla JavaCard Applet.
In altre parole, è quindi richiesto di specificare i byte CLA, il nome logico dell’istruzione (da cui verrà ricavato il byte INS) e i byte P1 e P2 di ogni istruzione APDU, nonché le funzioni di conversione da e verso byte array dei tipi predefiniti Java più importanti. Questo permette al wizard di creazione di un nuovo progetto di generare automaticamente le seguenti parti della JavaCard Applet e dell’applicazione Host:
L’editor di testo è purtroppo afflitto, nella versione 1.0, da alcuni antipatici problemi di funzionamento che si presentano alla ripresa del fuoco da parte di una qualsiasi delle finestre. In questa occasione il cursore ritorna nell’ultima posizione assunta prima che la finestra perdesse il fuoco. Questo è particolarmente scomodo nelle finestre che visualizzano il codice sorgente quando si tenta di risalire dalla finestra dei messaggi ad una riga contenente un errore: puntualmente la finestra contenente il codice visualizza la riga che si deve modificare, ma appena si tenta di accedere alla finestra questa sposta la visualizzazione al punto in cui era precedentemente, vanificando, di fatto, il posizionamento precedente. Questo problema risulta corretto nella nuova versione di iB-IDE, la 1.01. Il debugger integrato in iB-IDE fornisce due strumenti appositi per il debug dei sorgenti JavaCard: uno permette l’inserimento di breakpoint all’interno del codice sorgente, mentre l’altro permette di visualizzare le variabili e lo stato dell’iButton simulato su cui viene eseguito il codice. In questo modo è possibile eseguire parti del codice tramite step-into o step-over (ovvero eseguendo passo passo il codice delle funzioni chiamate o meno), visualizzando contemporaneamente il contenuto delle variabili disponibili ad ogni istante. Purtroppo anche questi strumenti hanno dimostrato diversi problemi nella versione 1.0 dell’iB-IDE. Il debugger, in particolare, ha dimostrato una certa propensione al blocco, cosa che ne ha reso problematico l’utilizzo in diverse occasioni. E’ importante notare che il debugger si basa completamente sul simulatore di iButton fornito con l’ambiente IDE. Questo simulatore non permette di rilevare possibili errori dipendenti dall’esaurimento delle risorse di memorizzazione, in quanto il simulatore di iButton non prevede limiti alla memoria utilizzabile, come invece accade inesorabilmente per gli iButton reali. Se a questo si aggiunge che la finestra di visualizzazione dello stato dell’iButton simulato riporta una quantità di memoria utilizzata molto approssimativa e non tiene conto del funzionamento dei garbage collector, è facile immaginare che il debug di applicazioni che presentano problemi di occupazione di memoria è piuttosto problematico, anzi, per certe applicazioni non banali, questi tempi di debug possono rappresentate una percentuale significativa dei tempi complessivi di sviluppo. L’ADPU
Sender è uno strumento che permette di inviare comandi sia all’iButton
simulato sia agli iButton reali. I comandi inviabili possono essere sia
comandi indirizzati alle applet installate sull’iButton, sia comandi di
configurazione per la gestione dell’iButton. La figura 5 mostra l’interfaccia
grafica dell’APDU Sender.
Questo strumento permette di selezionare l’iButton a cui inviare il comando da una lista a discesa, contenente tutti gli ID degli iButton correntemente collegati al sistema. E’ inoltre previsto un campo di testo per l’immissione dell’eventuale Master PIN per permettere l’accesso all’iButton (nel caso in cui questo sia protetto da un PIN di protezione). I comandi inviabili all’iButton sono raccolti in un’ulteriore lista a discesa e, una volta selezionato uno di essi, è possibile inserire gli eventuali parametri dalla finestra apposita, modificata dinamicamente in funzione del comando correntemente selezionato. L’interfaccia grafica dell’APDU Sender è infine completata da un’area di testo per la visualizzazione delle JavaCard Applet correntemente caricate sull’iButton selezionato e da un’area di testo per la visualizzazione dei dati e della status word ottenute come risposta all’ultimo comando inviato. Di seguito sono riportati alcuni dei comandi più importanti messi a disposizione dall’APDU Sender (si tratta dei comandi più frequentemente utilizzati in sede di debug):
Conclusioni
Un altro problema è dato dalla forte integrazione del software sviluppato con i framework messi a disposizione dall’ambiente di sviluppo. Questo rende non immediata la distribuzione delle applicazioni sviluppate, richiedendo uno sforzo non banale da parte dello sviluppatore. Lodevole è la possibilità di sviluppare e testare applicazioni basate su iButton senza avere a disposizione i dispositivi veri e propri, utilizzando cioè il simulatore di iButton integrato nell’ambiente di sviluppo. Questo permette a chiunque di prendere confidenza con l’ambiente JavaCard e con il framework OCF senza investire nulla, visto che l’intero ambiente di sviluppo è distribuito gratuitamente e non è necessario acquistare iButton per eseguire i test del codice prodotto. Positiva
è stata anche la scelta di Dallas Semiconductor di sviluppare l’intero
ambiente integrato utilizzando Java. Questo permette, teoricamente, di
utilizzaree l’IDE su una moltitudine di piattaforme, tenendo anche conto
che l’accesso tramite porta seriale agli iButton è gestito a livello
di Factory del framework OCF, e quindi in maniera completamente indipendente
dalla piattaforma.
Bibliografia
- www.ibutton.com: il sito web di Dallas Semiconductor dedicato ai Java iButton e agli altri dispositivi della stessa azienda, denominati genericamente iButton; - 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.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.
Roberto Fabbrica, nato a Ravenna il 28 dicembre 1972, è laureato in Ingegneria Informatica alla Facoltà di Ingegneria dell’Università di Bologna dal 1999. Attualmente lavora come libero professionista, fornendo consulenze come analista programmatore in Visual Basic ed esperto SQL ad una software house bolognese e collaborando al progetto e all’implementazione di applicazioni Java web oriented presso il DEIS (Dipartimento di Elettronica, Informatica e Sistemistica) della Facoltà di Ingegneria dell’Università di Bologna, sede di Cesena. |
|||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||
|