Progettazione e implementazione di un sistema per la gestione dei processi di identificazione

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Progettazione e implementazione di un sistema per la gestione dei processi di identificazione"

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea Progettazione e implementazione di un sistema per la gestione dei processi di identificazione Anno Accademico 2005/2006 relatore Ch.mo prof. Massimo Ficco candidato Roberto Bifulco matr. 534/1758

2 A mio padre, a mia madre, a quanti, nel bene o nel male, incrociando la mia strada, mi hanno reso quel che sono. 2

3 Indice generale Introduzione...6 Capitolo I - La Tecnologia RFID e le sue applicazioni Gli ambiti in cui è necessaria l'identificazione L'infrastruttura necessaria all'identificazione Codice Supporto per il codice Lettore del codice Sistema di gestione dei dati Tecnologie di identificazione La tecnologia RFID Vantaggi e svantaggi della tecnologia RFID L'applicazione della tecnologia RFID Electronic Product Code (EPC) ID System EPC Information service (EPCIs) Object Naming Service (ONS) Il funzionamento della EPCglobal Network Gestione dei dati Sistema di Gestione dei Processi di Identificazione Analisi dei requisiti Requisiti Funzionali Funzione di recupero stato dispositivo Funzione di Richiesta di aggregazione dati Funzione di Specifica filtro sul dispositivo

4 Funzione di Inserimento politiche di instradamento sul dispositivo Requisiti non funzionali Modello dei casi d'uso Identificazione degli attori Identificazione dei casi d'uso Diagramma dei casi d'uso Descrizione dei casi d'uso Ascolto stato del dispositivo Creazione politica d'instradamento...36 Capitolo II - Le soluzioni software proposte GlobeRanger imotion SAP SAP RFID ORACLE ORACLE Application Server SUN Java System RFID Singularity Middleware EPC Information Service OATSystems OAT Fundation Suite Un esempio di errore nella rilevazione dei tag La proposta di OATSystems Confronto fra le soluzioni proposte...57 Capitolo III - Una soluzione alternativa Requisiti funzionali Requisiti non funzionali Architettura del SGPI Confronto con le soluzioni già presenti Risultati del confronto...75 Capitolo IV - Progettazione del SGPI La scelta della tecnologia da utilizzare Il protocollo XMPP Wildfire Architettura del sistema Data Management Server Remote Hardware Manager Application interface Protocollo interno di comunicazione Progettazione del Remote Hardware Manager Architettura Implementazione Progettazione del Data Management Server Architettura del sistema a plug-in Implementazione del plug-in Logger Progettazione della Application Interface Architettura

5 4.6.2 Implementazione Gestione dello stato Gestione degli eventi Gestione delle comunicazioni Problematiche di concorrenza Diagramma delle classi Dinamica delle operazioni Conclusioni Appendice A - Analisi dei requisiti Bibliografia

6 Introduzione L'identificazione automatica (Auto-ID) è una pratica sempre più diffusa nelle attività dell'uomo, talvolta una vera e propria necessità. La ricerca tecnologica è da sempre impegnata nella realizzazione di soluzioni per i problemi legati all'identificazione automatica. Fra queste tecnologie negli ultimi anni si sta distinguendo, per le potenzialità offerte, la Radio Frequence Identification (RFID). Come tutte le innovazioni, la RFID porta notevoli vantaggi ma anche nuove problematiche. Questo lavoro propone un sistema software utile alla risoluzione di queste problematiche, cui si fa riferimento, in questo testo, col nome di Sistema per la Gestione dei Processi di Identificazione (SGPI). La necessità di un sistema del genere è dettata dalla grande mole di dati che la RFID potrebbe riversare sui sistemi informatici di quanti operano con dati di identificazione. A questo vanno aggiunte le nuove possibilità offerte da questa tecnologia: ogni singolo prodotto potrà essere univocamente identificato, grazie ad un codice d'identificazione non più limitato in lunghezza come è avvenuto fino ad ora. Uno scenario comune, immaginato per i prossimi anni, prevede la possibilità di consultare i dati caratteristici di un prodotto (la data di fabbricazione, la temperatura di conservazione, la data di scadenza, il nome del produttore ecc.) semplicemente accedendo a degli appositi server tramite una rete informatica. I prodotti stessi potranno essere seguiti lungo la supply chain, consultando le informazioni presenti sui server, che saranno aggiornate da ogni attore della catena di distribuzione. 6

7 Il SGPI ha lo scopo di ridurre la complessità di realizzazione delle applicazioni, che, sfruttandone i servizi offerti, possono disinteressarsi di tutte le problematiche che non riguardino strettamente la logica di business. Il lavoro di tesi non si limita alla sola progettazione e implementazione del SGPI, ma compie una analisi più estesa, partendo dalle tecnologie di identificazione automatica e dagli ambiti di utilizzo, per ricavare i requisiti software di un SGPI. Sono poi analizzate le soluzioni proposte dalle principali software house, di cui si effettua uno studio comparativo. Nella seconda parte della tesi sono analizzate le motivazioni che hanno portato alla realizzazione di un sistema alternativo, ed, infine, viene presentata nel dettaglio la progettazione con alcuni particolari implementativi. Nel seguito sono presentati con maggior dettaglio i contenuti di ciascun capitolo: Capitolo I: il primo capitolo presenta in linea generale cosa significa identificare e cosa si intende con identificazione automatica. Sono esaminati alcuni dei principali ambiti in cui si richiede l'identificazione, con alcune delle problematiche connesse. Una breve panoramica alle tecnologie di identificazione è d'introduzione ad una dettagliata presentazione della tecnologia RFID, con i suoi vantaggi e svantaggi. Alla luce dello studio degli scenari contemplati da questa nuove tecnologia è compiuta una attenta analisi dei requisiti di un software di gestione dei processi di identificazione. Capitolo II: in questo capitolo vengono studiate le soluzioni software proposte dalle principali software house,. Fra queste aziende rientrano: Sun Microsystems, Oracle, SAP, GlobeRanger, ecc. Di ogni sistema software analizzato è compiuta una presentazione generale dell'architettura e delle funzionalità offerte. A fine capitolo vengono confrontate in modo schematico le soluzioni presentate. 7

8 Capitolo III: il terzo capitolo presenta le motivazioni alla base della scelta di implementare un sistema alternativo. Vengono analizzati i requisiti funzionali e non funzionali che dovrebbero essere risolti da un SGPI e viene descritta, in modo generale, l'architettura di un modello di sistema adatto a risolvere tali requisiti. Infine, è compiuto uno studio di confronto fra i servizi offerti dal modello proposto e quelli offerti dalle soluzioni studiate nel secondo capitolo. Capitolo IV: l'ultimo capitolo descrive nel dettaglio la progettazione del sistema. Sono presentate le tecnologie scelte per l'implementazione ed ogni singolo componente dell'architettura. Le soluzioni progettuali sono descritte con le motivazioni che hanno condotto a tali scelte e con i vantaggi o i problemi che comportano. Sono anche presentati alcuni dettagli implementativi, con spiegazione di alcuni frammenti di codice significativi e con l'analisi di alcune dinamiche di esecuzione. Appendice A: in questa parte del testo è riportata per intero l'analisi dei requisiti, con il modello dei casi d'uso, presentata in parte nel capitolo I. 8

9 Capitolo I La Tecnologia RFID e le sue applicazioni Identificazione è un termine che ricorre spesso nei più disparati campi, anche con accezioni diverse. Parlare dunque di processi di identificazione, senza specificarne il significato, risulterebbe vago. Letteralmente identificare significa accertare l'identità di qualcuno. Il concetto può facilmente estendersi ad animali, piante, oggetti. In questo caso identificare significa riconoscere in modo univoco l'entità (animale, oggetto, ecc.). Per il riconoscimento delle persone, spesso, l'identificazione si basa sulla semplice analisi dei tratti somatici. L'identificazione di un oggetto potrebbe risultare molto più complessa: distinguere due oggetti costruiti in modo seriale in una fabbrica è di certo arduo. In questi casi si rende necessario un artefatto per semplificare l'operazione. L'aggiunta di un nome, o meglio, di un codice univoco all'oggetto, certamente risolverebbe ogni problema. La Tecnologia RFID e le sue applicazioni 9

10 L'identificazione non si presenta però come necessità nei soli casi in cui l'aspetto esterno non permettere di distinguere due oggetti. Il vero vantaggio risiede nella possibilità di far riferimento a qualcosa, senza possibilità di errore. Un esempio della praticità dell'identificazione è rappresentato dal nostro codice fiscale. Il codice permette il trattamento di tutti i documenti e i dati che riguardano la nostra persona, senza possibilità di errori quali la confusione con un omonimo. Il codice fiscale è un esempio utile per evidenziare una ulteriore possibilità offerta dall'identificazione: la tracciabilità. Tramite il nostro codice fiscale è possibile (per chi ne ha le autorizzazioni!) accedere facilmente a tutti i documenti che ci riguardano e che sono gestiti dallo Stato. La tracciabilità è la base che permette allo stato di garantire il vivere civile. Senza identificazione non può esistere tracciabilità. Un ulteriore esempio permette di introdurre una problematica comune degli attuali processi di identificazione: l'identificazione automatica. Lo sviluppo di produzioni seriali, che sempre più spesso hanno richiesto processi di automatizzazione, ha fatto emergere necessità quali rendere possibile l'identificazione da parte di macchine. In questi casi il codice diviene una comoda soluzione, talvolta l'unica perseguibile. L'identificazione degli oggetti realizzata da macchine viene spesso definita identificazione automatica (Auto-ID). Le tecnologie per la risoluzione di questi problemi sono, tuttavia, ancora limitate. Rendere possibile l'identificazione automatica è un campo di ricerca in continuo sviluppo per superare questi limiti. La Tecnologia RFID e le sue applicazioni 10

11 1.1 - Gli ambiti in cui è necessaria l'identificazione I problemi di identificazione sono da sempre affrontati in tutti i settori in cui opera l'uomo. Per capirene la portata, e di conseguenza la vastità degli ambienti in cui sono presenti, nel seguito sono riportati alcuni degli ambiti in cui è necessaria l'identificazione. Gestione anagrafica La gestione dei dati personali richiede l'identificazione univoca della persona. Questo tipo di gestione è presente sia nella pubblica amministrazione che nelle aziende, nelle scuole, nelle università, ecc. Gestione autoveicoli La gestione dei mezzi di trasporto, privati e pubblici, implica la loro identificazione. Sulle strade di qualsiasi paese è possibile vedere la targa applicata al veicolo, per identificarlo univocamente. Gestione della supply chain La supply chain è una rete di organizzazioni, fra loro collegate, che sono coinvolte in diversi processi e attività per la creazione di prodotti e servizi destinati al consumatore finale. Uno degli articoli alimentari di una catena di supermercati è il prodotto finale di una supply chain, che molto probabilmente aveva a monte una azienda agricola. L'identificazione in questo ambito consente di tracciare i prodotti e di gestire al meglio le comunicazioni fra le aziende. La Tecnologia RFID e le sue applicazioni 11

12 Fra i problemi affrontati rientrano: Controllo delle spedizioni fra le aziende Distribuzione dei prodotti Monitoraggio dei prodotti Creazione dell'inventario Gestione degli approvvigionamenti Gestione dei pagamenti Controllo di prodotti alimentari o farmaceutici L'identificazione è necessaria qualora si debba tener traccia della data di produzione di un determinato articolo. Prodotti quali farmaci e alimentari, devono essere tracciati per garantire al consumatore l'integrità del prodotto stesso. Gestione prodotti nei punti vendita I prodotti gestiti da qualsiasi punto vendita devono essere identificati. In questo modo si garantisce una semplice gestione della vendita e dei pagamenti. Controllo presenze Per controllare la presenza o meno di una persona in un edificio, o di una vettura in un parcheggio, è necessario identificarla e provvedere a tener nota del suo ingresso/uscita dall'edificio. Anche in questi casi l'identificazione gioca un ruolo essenziale. Monitoraggio degli animali Per consentire il monitoraggio di animali è necessario identificarli per poi tracciarli. Il monitoraggio di animali è utile nella gestione del randagismo, per effettuare controlli medici o sterilizzazioni; nel controllo di animali appartenenti a specie in estinzione; nell'accertamento della proprietà di animali domestici. La Tecnologia RFID e le sue applicazioni 12

13 Gestione delle banconote Per garantire l'assenza di contraffazione, le banconote sono stampate con un numero seriale che le identifica. In questo modo è possibile anche tener traccia di eventuali azioni illegali o di riciclaggio del denaro. Gestione delle carte di credito Le carte di credito sono identificate anch'esse da un codice univoco che permette, associato ad un conto bancario, di effettuare pagamenti. L'identificazione della carte è la base per consentire la transazione. Gestione di pratiche e documenti Anche per la gestione dei documenti è necessario disporre di un codice che permetta di identificare univocamente il documento. Un esempio è la carta d'identità, identificata da un codice univoco. Le aziende utilizzano metodi di identificazione per le loro offerte commerciali o per la gestione degli ordini. Per i controlli fiscali la gestione dei documenti è garantita dall'identificazione di quest'ultimi Gestione dei processi industriali L'identificazione è utile anche nelle attività in cui è necessario controllare dei processi automatici. Un carrello su un nastro trasportatore potrebbe essere destinato su un percorso o sull'altro, a seconda del suo identificativo. La Tecnologia RFID e le sue applicazioni 13

14 1.2 - L'infrastruttura necessaria all'identificazione Fino ad ora si è parlato di cosa si intende per identificazione e degli ambiti in cui tale attività è utile, se non essenziale. Non è stato ancora detto però cosa sia necessario per consentire un servizio di identificazione. Nei precedenti paragrafi si è accennato alla necessità primaria per garantire l'identificazione: un codice. Il codice è una parte importante dell'infrastruttura, ma non è l'unica. Una infrastruttura per l'identificazione ha bisogno almeno delle seguenti parti: codice supporto per il codice lettore del codice sistema di gestione dei dati Codice Il codice è il primo mattone della struttura che consente l'identificazione. E' il codice a garantire l'univocità e l'assenza di ambiguità. La definizione del codice può essere del tutto arbitraria, tuttavia, per motivi pratici, è bene definire dei codici gerarchici e con sintassi precise. Questi accorgimenti consentono di effettuare i processi di identificazione con maggiore efficienza e velocità. La definizione dei codici è spesso portata avanti da organismi preposti alla creazione di standard. Quest'ultima affermazione è vera fino a quando si tratta di codici utilizzati su larga scala, ad esempio nella gestione di supply chain. Molti codici di identificazione, creati per un uso più ristretto, come può essere quello di una realtà aziendale, sono definiti in modo del tutto arbitrario. La Tecnologia RFID e le sue applicazioni 14

15 Supporto per il codice Il codice di per se è un'entità astratta e puramente teorica. Perché il codice sia utilizzabile è necessario scriverlo su di un supporto. Con scrivere si intende rendere il codice disponibile alla lettura dal supporto utilizzato. L'operazione di scrittura può variare da supporto a supporto. Potrebbe trattarsi di una scrittura su nastro magnetico, su supporto ottico, su etichetta di carta, ecc. Il supporto è forse dove si concentrano le maggiori difficoltà nel creare un'infrastruttura di identificazione. Il codice e il supporto sono fortemente legati: il primo dipende dal secondo. E' infatti il supporto che definisce la lunghezza massima del codice, o che comunque pone limiti fisici all'utilizzo di un codice Lettore del codice Il lettore del codice è il dispositivo che consente di recuperare il codice dal supporto e di fornirlo al sistema che lo elabora. Lettore e supporto del codice sono indissolubilmente legati. Un lettore viene realizzato per leggere uno specifico supporto; un supporto viene realizzato per essere letto da uno specifico lettore. Anche il lettore può presentare dei limiti fisici che precludono l'utilizzo di alcuni codici, anche se in maniera molto ridotta rispetto al supporto. L'insieme di codice, supporto e lettore rappresenta la tecnologia di identificazione. Sebbene in questo testo ci riferiremo al lettore considerandolo sempre un dispositivo, nulla vieta che il ruolo del lettore sia assunto da una persona. I primi sistemi di identificazione, ma anche molti degli attuali sistemi, utilizzano come lettori le persone. Ad esempio, l'agente di Polizia, che richiede la nostra carta d'identità per un controllo, svolge il ruolo di lettore per il sistema di identificazione della Polizia. La Tecnologia RFID e le sue applicazioni 15

16 Sistema di gestione dei dati Con sistema di gestione dei dati si intende un qualsiasi metodo, automatico (tramite ad esempio un software) o manuale, per l'archiviazione e la gestione dei dati raccolti dai lettori. Il sistema di gestione è il mezzo che consente ai dati di identificazione di divenire rilevanti ed utili. Il codice di identificazione è infatti solo un codice se a questo non c'è modo di associare delle informazioni. Esempi di sistemi di gestione possono essere i software utilizzati per la gestione di magazzino in un negozio di abbigliamento, o più semplicemente l'insieme di documenti cartacei dove vengono riportate le associazioni codice informazioni Tecnologie di identificazione La ricerca tecnologica ha cercato di risolvere i problemi di identificazione proponendo soluzioni che ne permettessero una gestione veloce e automatizzata. Fra le tecnologie attualmente più diffuse rientra il codice a barre. Per convincersi di questa affermazione è sufficiente osservare ciò che avviene alla cassa di una attività commerciale, sia questa un negozio di alimentari, di libri, di abbigliamento o altro. Ogni prodotto viene passato su di un lettore ottico per rilevarne il codice a barre, e quindi, ogni prodotto viene identificato. Molto spesso i prodotti presentano il codice a barre stampato direttamente sull'involucro. Questa caratteristica mostra come l'identificazione sia cominciata prima dell'arrivo del prodotto al negozio, seguendo le varie fasi della catena di produzione. Il codice a barre ha trovato larga diffusione per il basso costo e la semplicità di utilizzo. Le componenti della tecnologia di identificazione basata su codici a barre sono: La Tecnologia RFID e le sue applicazioni 16

17 Codice: il codice è composto da una serie di cifre numeriche, generalmente 13, che seguono diversi standard internazionali a seconda dell'applicazione in cui è necessaria l'identificazione. In realtà non è corretto parlare di un unico codice. Sono presenti diverse codifiche, in base alla particolare applicazione. Per i nostri interessi, tuttavia, non è necessario approfondire oltre la trattazione delle tecniche di codifica per i codici a barre. Supporto: il supporto per i codici deve garantire la possibilità di essere letto da lettori ottici. Generalmente il supporto è una semplice etichetta adesiva o anche un cartone di imballaggio, su cui viene stampata la caratteristica sequenza di bande verticali di diversi spessori. Lettore: i lettori utilizzano un sistema di rilevamento tramite laser per individuare lo spessore delle bande verticali del supporto e risalire quindi al codice. Sistema di gestione dati: il sistema di gestione dati è spesso un software capace di interfacciarsi con il lettore e di elaborare i dati che questo fornisce. Col passare del tempo, tuttavia, la tecnologia del codice a barre ha mostrato sempre maggiori limiti ed inadeguatezza rispetto alle esigenze delle attività in cui è impiegato. Fra i maggiori limiti rientrano: la necessità di leggere il codice a barre tramite contatto diretto fra il lettore e l'etichetta su cui è stampato il codice (il lettore deve trovarsi ad una distanza molto ridotta e deve vedere il codice); il supporto su cui è stampato il codice è una semplice etichetta. Questo si traduce in un codice di lunghezza limitata, e, di conseguenza, sono limitati anche i dati che può contenere; la facilità di degrado del supporto su cui è stampato il codice può causare l'impossibilità della lettura ottica, soprattutto per applicazioni svolte in condizioni ambientali particolari (acqua, alte temperature, ecc.). I limiti del codice a barre hanno portato allo sviluppo di tecnologie alternative; fra queste, quella che sta riscontrando il maggior successo è la tecnologia RFID. La Tecnologia RFID e le sue applicazioni 17

18 1.4 - La tecnologia RFID RFID è un acronimo di Radio Frequence Identification, ossia identificazione a radio frequenza. La possibilità di eseguire la lettura del codice identificativo tramite onde radio è infatti una delle principali caratteristiche di questa tecnologia. Il sistema RFID basa il suo funzionamento su due tipologie di dispositivi: reader e tag. Il reader rileva e legge i tag nel suo raggio di azione, rendendo disponibili le informazioni reperite a dispositivi di elaborazione quali PC, tramite apposite interfacce. Il tag è il dispositivo in cui vengono memorizzate le informazioni di identificazione. Un tag può essere di diverse tipologie: Attivo: è un dispositivo autoalimentato da una batteria. L'impianto di ricetrasmissione prende l'energia da tale batteria consentendo un raggio di rilevazione del tag anche oltre la decina di metri. Semi-attivo: è un dispositivo con una piccola batteria che alimenta i circuiti del tag quando entra nel campo elettromagnetico del reader, a differenza del tag attivo che genera un campo elettromagnetico proprio. La distanza massima di rilevazione è di circa 15 m. Passivo: il tag passivo contiene soltanto il chip che trasporta le informazioni e un'antenna. L'energia necessaria per l'alimentazione è fornita dal segnale generato dal reader. L'assenza di una batteria limita la portata di lettura a 4-5 m di distanza dal reader. Il grande vantaggio di questi dispositivi è nelle contenute dimensioni che consentono l'applicazione del tag in involucri di diversi tipi. I dispositivi RFID si differenziano generalmente in base alle frequenze di trasmissione che utilizzano. Le frequenze utilizzate sono 125 Khz, Mhz, sono inoltre prodotti dispositivi che lavorano nelle bande UHF (868\915 Mhz) e nelle microonde (2.5\5.8 Ghz). La Tecnologia RFID e le sue applicazioni 18

19 1.5 - Vantaggi e svantaggi della tecnologia RFID Come accennato in precedenza, la tecnologia RFID permette la lettura dei tag senza il contatto con il lettore, è infatti sufficiente che il tag si trovi entro il raggio di lettura di quest'ultimo. Questa caratteristica consente, ad esempio, di conoscere il contenuto di una scatola portandola in prossimità del lettore (purchè gli oggetti contenuti siano identificati tramite tag). Ulteriore vantaggio dell'assenza di contatto è la possibilità di effettuare un grande numero di letture in brevissimo tempo. Le dimensioni ridotte dei tag, specialmente per quelli passivi, permettono di utilizzare diversi tipi di involucri: resistenti all'acqua, alle alte temperature, ecc. L'utilizzo di un chip per memorizzare le informazioni di identificazione consente l'utilizzo di codici ben più lunghi rispetto a quelli riportati dai codici a barre. Le principali problematiche legate a questa tecnologia risiedono nelle difficoltà di standardizzazione. Ad oggi, infatti, manca ancora uno standard preciso che definisca gli aspetti legati all'utilizzo della RFID. L'utilizzo della radio frequenza comporta, inoltre, problematiche a livello legislativo. Negli USA si utilizzano frequenze anche attorno ai 900 Mhz, mentre in Europa non è una banda consentita. In aggiunta a questi problemi si presentano poi difficoltà per la tutela della privacy. Il tag infatti rimane sempre leggibile, rendendo tracciabile il prodotto anche quando ha abbandonato il punto vendita. I problemi presentati sono tuttavia in risoluzione, grazie anche all'istituzione di alcuni enti come EPCglobal che si occupano di definire gli standard a livello internazionale. La Tecnologia RFID e le sue applicazioni 19

20 1.6 - L'applicazione della tecnologia RFID La tecnologia RFID non rappresenta soltanto una alternativa al codice a barre, le possibilità offerte consentono infatti di immaginare un sistema di identificazione ben più complesso e potente, a cui proprio EPCglobal sta dando il maggior contributo. L'idea alla base del progetto è ben espressa dall'ex timoniere dell'epcglobal Kevin Ashton: Questo è più grande di Internet... Rivoluzionerà radicalmente il modo con cui controlliamo i beni dal produttore al consumatore e anche attraverso il riciclaggio. Noi stiamo creando una Internet of Things. L'obiettivo è quindi identificare ogni prodotto tramite un tag. Sarà possibile in questo modo seguire il percorso del prodotto lungo la supply chain, fino a quando giungerà nelle mani di un consumatore. Si può addirittura immaginare che l'oggetto sia seguito anche quando viene buttato via. Il centro di smistamento rifiuti sarà in grado di identificare il prodotto dal suo tag ed inviarlo alla corretta destinazione di smaltimento, eliminando le problematiche di raccolta differenziata dei rifiuti. Per realizzare questo ambizioso obiettivo, EPCglobal ha definito una architettura tecnologica, la EPCglobal Network, composta da più componenti: Electronic Product Code ID System EPC Information Service Object Naming Service La Tecnologia RFID e le sue applicazioni 20

21 Electronic Product Code (EPC) EPC è uno standard internazionale gestito dalla EPCglobal a supporto della tecnologia RFID che definisce uno schema di numerazione universale. Lo standard ha lo scopo di fornire indicazioni ai produttori di software, hardware ed agli utenti per l'utilizzo della struttura numerica EPC codificata sui tag RFID. Figura Lo standard di numerazione EPC Lo standard EPC è un sistema di numerazione a 96 bit (Figura 1.1) che fornisce un unico numero identificativo a 268 milioni di aziende, ognuna delle quali avrà a disposizione 16 milioni di categorie e 68 miliardi di numeri seriali per ciascuna categoria di prodotto. Tutte le strutture numeriche GS1 (GTIN, GLN, SSCC), ossia le strutture numeriche utilizzate nei codici a barre, sono integrate nella struttura numerica EPC, permettendo la totale compatibilità del metodo di identificazione basato su EPC con i precedenti (Figura 1.2). Figura Integrazione del GTIN nel codice EPC La Tecnologia RFID e le sue applicazioni 21

22 L'EPC consente anche una lettura efficace ed efficiente tramite un Filter Value che permette di discriminare fra i livelli di imballaggio/confezionamento, ossia riesce a distinguere se il tag è su di un prodotto singolo o su di una scatola di imballaggio che trasporta altri prodotti ID System L'ID System altro non è che il sistema di identificazione, ossia il sistema basato sui reader e sui tag RFID, in cui è memorizzato il codice EPC EPC Information service (EPCIs) Gli EPCIs sono risorse informative che registrano le informazioni relative ai singoli oggetti e consentono lo scambio di queste informazioni tra i partner commerciali attraverso il sistema EPCglobal Network. Un EPCIs, quindi, non è altro che un server collegato ad una rete di calcolatori (Internet) che mette a disposizione delle informazioni. Ogni EPCIs memorizza dei codici EPC ai quali fa corrispondere delle informazioni strutturate che possono generalmente suddividersi in: statiche: informazioni che non cambiano nel corso della vita delle referenze: nome del prodotto, dimensioni, ecc. dinamiche: informazioni che cambiano nel corso della vita della referenza identificata, ad esempio: il numero di lotto di produzione, la data di scadenza, la temperatura per il trasporto, ecc Object Naming Service (ONS) Il ruolo del ONS è simile a quello del DNS. Tramite l'ons è possibile, conoscendo un codice EPC, risalire all'indirizzo del server EPCIs che contiene le informazioni relative a quel EPC. Questo sistema, unito ai server EPCIs, permette di immagazzinare una enorme quantità di dati per ogni oggetto, consentendo di ricevere informazioni estremamente dettagliate senza influire sui dati scritti sul tag. La Tecnologia RFID e le sue applicazioni 22

23 1.6.5 Il funzionamento della EPCglobal Network Il funzionamento della EPCglobal Network comincia con la lettura di un codice EPC tramite l'id System. Dal codice, utilizzando il servizio ONS, è possibile risalire al server EPCIs che contiene le informazioni relative all'oggetto identificato dal codice. Accedendo al EPCIs, un sistema informativo può reperire le informazioni sull'oggetto ed utilizzarle (Figura 1.3). Figura Funzionamento dell'architettura EPCglobal Network Gestione dei dati L'architettura della EPCglobal mostra grandi potenzialità ed allo stesso tempo grande complessità. Se si verificassero le ipotesi presentate in precedenza, la mole di dati che investirebbe la EPCglobal Network sarebbe enorme e il districarsi fra questi risulterebbe arduo. Qualsiasi azienda fosse interessata ad integrare il proprio sistema di identificazione RFID con la EPCglobal Network dovrebbe gestire molteplici aspetti legati non solo all'hardware (ID System), ma anche al software (ONS, EPCIs). In questo contesto si mostra la necessità di un sistema che riduca la complessità del problema. La Tecnologia RFID e le sue applicazioni 23

24 Una azienda dovrebbe avere la possibilità di sviluppare il proprio software, che elabora i dati di identificazione, senza preoccuparsi della gestione dell'hardware che recupera i codici di identificazione, dei meccanismi che vengono utilizzati per arricchire di ulteriori informazioni (prese ad esempio da un EPCIs) tali codici, e di tutti gli altri aspetti relativi al rilevamento e alla gestione di errori nella fase di recupero dati. Un sistema con tali caratteristiche viene spesso definito Middleware RFID. In questo testo tenteremo di evitare, quando possibile, tale termine, poiché non è propriamente corretto seguendo il comune significato dato alla parola middleware in letteratura. Ci riferiremo a questa tipologia di software come ad un Sistema per la Gestione dei Processi di Identificazione (SGPI) Sistema di Gestione dei Processi di Identificazione Dopo aver appurato la necessità di un sistema software intermedio fra i sistemi aziendali e la gestione dei dati e dei dispositivi di identificazione, passiamo a definirne le responsabilità. Supporto di più siti fisici e di più applicazioni: il SGPI deve essere in grado di gestire dispositivi RFID situati in luoghi anche geograficamente distanti. Allo stesso tempo deve garantire che più applicazioni possano accedere ai dati gestiti. Gestione hardware: la prima responsabilità di un SGPI è gestire l'hardware di identificazione. Fino ad ora si è parlato della sola tecnologia RFID, è tuttavia conveniente che un SGPI sia in grado di supportare il funzionamento anche di altri ID System, in modo da poter essere integrato in processi già esistenti. La Tecnologia RFID e le sue applicazioni 24

25 Per gestione hardware si intende: controllo dello stato dei dispositivi, recupero dei dati letti dai dispositivi, invio di comandi di scrittura al dispositivo, gestione della topografia dei dispositivi (possibilità di dichiarare un dispositivo come membro di un gruppo). Gestione dei dati: un SGPI rappresenta anche un vigile urbano dei dati. I reader che rivelano la presenza di tag generalmente producono un flusso continuo di dati. Un SGPI deve catturare questo flusso dati e filtrarlo in base al processo in cui è coinvolto. I dati, una volta filtrati, devono essere inviati all'opportuno destinatario (routing dei dati). Ad esempio, nel caso in cui un pallet taggato, contenente diversi case taggati, si trovi in una baia di carico gestita da un varco RFID, si genererebbe un grande flusso di dati per le letture dei tag del pallet e dei case. Il SGPI, nel caso si voglia tracciare il solo pallet, deve filtrare i dati, scartando quelli provenienti dai tag dei case. I dati ottenuti dopo il filtraggio devono poi essere inviati al sistema informativo che controlla i pallet. La gestione dei dati comporta anche la risoluzione di errori quali la lettura duplicata di uno stesso tag. Aggregazione dei dati: per aggregazione dei dati si intende l'operazione tramite cui ad un codice EPC vengono associati dati relativi al prodotto (ricavati ad esempio da un EPCIs). Un SGPI deve essere in grado di recuperare i dati relativi ad un EPC utilizzando la EPCglobal Network e poi inviarli al corretto destinatario. Il SGPI si fa quindi carico di inoltrare la richiesta ONS, elaborare la risposta e recuperare i dati dal EPCIs ottenuto. Integrazione con i sistemi di back-end: un SGPI deve offrire la possibilità di fornire i propri servizi ad applicazioni sviluppate per processare i dati di identificazione. Deve quindi fornire meccanismi come librerie di programmazione, appoggiandosi su tecnologie quali XML, Web Service, SOAP, JMS. In questo modo, ogni applicazione può sfruttare nei suoi processi i servizi offerti dal SGPI. La Tecnologia RFID e le sue applicazioni 25

26 Gestione di task: fra i servizi opzionali che può offrire un SGPI rientra la possibilità di configurare dei task periodici. Ad esempio, si potrebbe impostare il sistema in modo che periodicamente controlli lo stato di uno scaffale intelligente. Gestione di politiche di elaborazione dei dati: un altro possibile servizio che un sistema SGPI può offrire è la gestione di politiche di elaborazione dei dati. Ad esempio, si può generare un evento di allarme da destinare ad una applicazione, all'identificazione di un particolare tag da parte di uno dei reader connessi al sistema. Monitoraggio delle attività: data la natura distribuita del sistema, e la possibilità di intervento di molteplici utenti, deve essere possibile eseguire controlli sulle operazioni effettuate. Un SGPI potrebbe quindi offrire un completo sistema di Logging dei comandi ricevuti. Sicurezza: per le considerazioni fatte poc'anzi, un SGPI deve offrire meccanismi di autenticazione, per garantire che utenti non autorizzati accedano a dati riservati. Scalabilità: considerando la grande mole di dati che investe un sistema di identificazione basato su RFID, e la necessità di processare questi dati velocemente, è auspicabile che si adotti un sistema scalabile. Un SGPI deve presentare quindi una struttura modulare, dove l'aggiunta di un modulo rappresenta la possibilità di elaborare un maggior numero di dati senza intaccare le prestazioni dell'intero sistema. Affidabilità: molto spesso i sistemi di identificazione sono punti critici di un processo di controllo. Un SGPI deve garantire affidabilità e immunità agli errori. Anche in situazioni critiche deve essere garantito il funzionamento del sistema. Questo obiettivo è raggiungibile adottando politiche di ridondanza che garantiscano adeguata continuità e qualità di servizio. Il ruolo del SGPI è mostrato graficamente in Figura 1.4. La Tecnologia RFID e le sue applicazioni 26

27 Figura Ruolo di un SGPI Alla luce di quanto affermato fin qui, per la tecnologia RFID le parti di un sistema di identificazione, specificate in precedenza, sono le seguenti: Codice: EPC Supporto del codice: Tag Lettore del codice: reader RFID Sistema di gestione dei dati: SGPI + EPCglobal Network + Business Application Analisi dei requisiti L'analisi dei requisiti è una tipica attività di ingegneria del software, che consente di ricavare dalla specifica di un problema i requisiti a cui deve rispondere il software, per la risoluzione di tale problema. Partendo dalle responsabilità individuate nel precedente paragrafo, sono stati ricavati i requisiti a cui deve rispondere un SGPI. La Tecnologia RFID e le sue applicazioni 27

28 I requisiti sono suddivisi in funzionali e non funzionali, a seconda che il requisito sia una funzionalità che deve presentare il software o una caratteristica di progetto o di prestazioni. In questo paragrafo non è presentata l'intera analisi dei requisiti condotta, per non appesantire la trattazione. In appendice a questo testo sono riportati con maggior dettaglio i risultati dell'analisi dei requisiti Requisiti Funzionali Nel seguito sono presentati a titolo esemplificativo alcuni dei requisiti individuati. Ogni requisiti è esposto in modo schematico, permettendo una immediata lettura degli input, degli output, delle elaborazioni e dei dati immagazzinati necessari allo svolgimento della funzionalità individuata Funzione di recupero stato dispositivo R-gh3 Nome: Recupero stato dispositivo Input: Dispositivo Codice di autenticazione Output: Stato del dispositivo Dati Immagazzinati: - Elaborazioni: Descrizione: Il sistema interroga il gestore del dispositivo per verificarne lo stato E' la funzione tramite cui viene fornito lo stato di un particolare dispositivo. La funzione di recupero stato del dispositivo è utile in molteplici contesti. Tramite questa funzione è infatti possibile conoscere lo stato di un dispositivo RFID (Attivo o meno) e regolare di conseguenza le proprie azioni. La conoscenza dello stato del dispositivo è utile sia per il monitoraggio del sistema da parte dell'amministratore, sia per gli utenti generici che richiedono dei servizi a quel particolare dispositivo. La Tecnologia RFID e le sue applicazioni 28

29 Funzione di Richiesta di aggregazione dati R-rd4 Nome: Richiesta di aggregazione dati Input: EPC del TAG di cui si vogliono aggregare i dati Output: I dati aggregati Dati Immagazzinati: Log della richiesta di aggregazione (provenienza della richiesta, data e ora) Elaborazioni: Descrizione: Il sistema esegue una ricerca tramite ONS, e recupera dal EPCIs specifico le informazioni di cui necessita. Permette di recuperare i dati aggiuntivi presenti su di un EPCIs in riferimento al TAG fornito in input. Come abbiamo visto in precedenza, è compito del SGPI recuperare i dati, relativi ad un EPC, dalla EPCglobal Network. Tramite questa funzione il SGPI attiva la richiesta ONS per un particolare EPC, recupera l'indirizzo di un EPCIs dalla risposta che ottiene e richiede i dati a quest'ultimo. I dati sono poi inviati al richiedente della funzione. E' bene notare come la richiesta di aggregazione sia monitorata. Le informazioni ricavate dalla EPCglobal Network potrebbero essere riservate. Tramite il log è possibile risalire a chi ha effettuato la richiesta e al momento in cui l'ha effettuata Funzione di Specifica filtro sul dispositivo R-id1 Nome: Specifica filtro sul dispositivo Input: Dispositivo Tipo di filtro Output: - Dati Immagazzinati: Log della creazione del filtro (provenienza della richiesta, data e ora, tipo) Elaborazioni: Descrizione: Viene inserito un filtro che processa tutte le letture eseguite dal Dispositivo E' la funzione che permette di creare un filtro che selezioni le letture da conservare nel database. Tale filtro agirà sul solo dispositivo specificato. Il filtro potrebbe anche essere temporale, definendo un intervallo di tempo entro il quale scartare determinate letture. Questa ultima opzione consente di annullare gli errori per letture duplicate. Fra le caratteristiche base di un SGPI rientra la possibilità di filtrare i dati. Questa funzione offre un meccanismo per consentire di definire dei filtri sui dati raccolti da un solo dispositivo. La Tecnologia RFID e le sue applicazioni 29

30 Il funzionamento prevede che tutti i dati letti dal dispositivo attraversino il filtro, che lascerà passare solo quelli che corrispondono a delle particolari specifiche. Un tipico utilizzo di questa funzione è nella definizione di un filtro temporale. Tale filtro non lascia passare la lettura di un determinato EPC se non è trascorso un certo intervallo di tempo dall'ultima volta che tale EPC è stato letto. Questo consente di ridurre gli errori causati da letture duplicate.un'ulteriore tipologia di filtro è rappresentata da quelli che lasciano passare solo determinati EPC, scartando i restanti. L'applicazione di questo filtro è utile per raccogliere informazioni riguardanti i soli pallet o i soli case. E' da notare che questa funzione installa il filtro su di un singolo dispositivo. E' possibile utilizzare altre funzioni per filtrare il traffico di dati proveniente da più dispositivi Funzione di Inserimento politiche di instradamento sul dispositivo R-id3 Nome: Input: Dispositivo Tipo di politica Output: - Inserimento politiche di instradamento sul dispositivo Dati Immagazzinati: Log della creazione della politica (provenienza della richiesta, data e ora, tipo) Elaborazioni: Descrizione: Viene creata una politica di instradamento per il dispositivo fornito in input E' la funzione che permette di creare una particolare politica di instradamento in riferimento alle letture provenienti dal dispositivo fornito in input. Tale politica consente ad esempio di far pervenire tutte le letture di quel dispositivo ad una particolare applicazione. Il sistema deve offrire la possibilità di gestire la destinazione dei dati raccolti. Questa funzione permette di dirigere tutto il traffico proveniente da un dispositivo verso una destinazione specificata. Ad esempio, si potrebbe scegliere di far consegnare tutti i dati raccolti ad un sistema di basi di dati, per archiviarli, o ad un altro sistema informatico per elaborarli. Anche in questo caso la politica di instradamento è installata sul singolo dispositivo, tuttavia il SGPI offre funzionalità che permettono di gestire le politiche di instradamento su più dispositivi. La Tecnologia RFID e le sue applicazioni 30

31 Requisiti non funzionali Il sistema prevede il trattamento di una grande mole di dati, anche riservati, fra molteplici utenti. Tale caratteristica impone diversi requisiti non funzionali che vengono nel seguito elencati: R-nf1: Scalabilità. Il sistema deve essere scalabile, permettendo l'aggiunta di moduli per il trattamento di maggiori quantità di dati, senza intaccare le prestazioni; R-nf2: Prestazioni. I dati trattati devono finire il loro processo di elaborazioni in tempi nell'ordine dei secondi. R-nf3: Interoperabilità. Deve essere possibile mettere in comunicazione hardware e software eterogenei. R-nf4: Sicurezza. Deve essere garantita la sicurezza dei dati gestiti, tramite meccanismi di autenticazione degli utenti del sistema. R-nf5: Recupero errori. Il sistema dovrebbe essere in grado di rimanere attivo e funzionante anche in presenza di errori. La Tecnologia RFID e le sue applicazioni 31

32 Modello dei casi d'uso Il modello dei casi d'uso descrive in modo intuitivo e dettagliato le funzionalità di un software. Ci serviremo di questo modello per illustrare le principali caratteristiche di un SGPI. Come per i requisiti, si rimanda alle appendici di questo testo per una trattazione più dettagliata Identificazione degli attori Attore Dispositivo User Application External Application System Admin Device Admin Descrizione Il generico dispositivo di identificazione (di tecnologia RFID o meno). La generica applicazione che fa uso del middleware. La generica applicazione esterna che interagisce col middleware (EPCIs). L'amministratore del sistema. Il gestore della configurazione dei dispositivi Identificazione dei casi d'uso C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 C17 Accesso al sistema Disconnessione dal sistema Attivazione dispositivo Disattivazione dispositivo Ascolto stato del dispositivo Fine ascolto stato del dispositivo Cambio stato del dispositivo Ricevimento letture dal dispositivo Scrittura su TAG Ascolto letture dispositivo Interruzione ascolto letture Recupero letture effettuate Richiesta aggregazione dati Creazione filtro Creazione politica d'instradamento Inserimento di un task Inserimento di una politica di elaborazione La Tecnologia RFID e le sue applicazioni 32

33 Diagramma dei casi d'uso Figura 5 - Modello dei casi d'uso La Tecnologia RFID e le sue applicazioni 33

34 Descrizione dei casi d'uso Nel seguito sono descritti alcuni dei casi d'uso presentati. La descrizione completa è disponibile in appendice a questo testo. Gli scenari presentati mantengono una certa generalità per essere usati come base per lo sviluppo di un SGPI non specifico, quindi sono totalmente slegati, nella descrizione, da vincoli derivanti dalle possibili implementazioni pratiche Accesso al sistema Attori coinvolti: Descrizione: Precondizioni: Flusso di eventi User Application, System Admin, Device Admin L'operazione necessaria ad autenticare un utente del sistema, perchè possa usufruire delle funzionalità messe a disposizione. Nessuna Post-condizioni: L'attore è connesso al sistema L'accesso al sistema è un caso d'uso che permette di evidenziare la soluzione offerta per garantire la sicurezza dei dati.il generico utente del sistema, sia questo l'amministratore di sistema, una applicazione di business o una qualsiasi altra applicazione, deve obbligatoriamente fornire i dati per la sua identificazione. La Tecnologia RFID e le sue applicazioni 34

35 Questo approccio garantisce non solo la sicurezza dei dati, ma permette anche di monitorare dinamicamente l'attività delle applicazioni. In sostanza, il SGPI può sapere se una determinata applicazione è connessa o meno e regolare di conseguenza l'instradamento dei dati Ascolto stato del dispositivo Attori coinvolti: User Application Descrizione: L'operazione con cui una User Application rileva lo stato di un dispositivo Precondizioni: La User Application deve essere connessa al sistema Flusso di eventi Post-condizioni: Il sistema informa la User Application dei cambiamenti di stato del Dispositivo Permettere politiche personalizzate di gestione dello stato, o consentire a business application di gestire tale stato, è una importante funzionalità che può offrire un SGPI. La prima necessità per offrire tale servizio è garantire la possibilità di verificare lo stato del dispositivo. Poiché l'ascolto dello stato può essere interdetto ad alcune applicazioni, è bene prevedere un sistema di sicurezza, basato su password, o sul riconoscimento di permessi, che ne regoli l'utilizzo. La Tecnologia RFID e le sue applicazioni 35

36 Creazione politica d'instradamento Attori coinvolti: Descrizione: Precondizioni: Flusso di eventi System Admin L'operazione con cui viene creata una politica di instradamento sui dati ottenuti dai dispositivi di identificazione Il System Admin deve essere connesso al sistema Post-condizioni: Il Sistema processa i dati secondo la nuova politica di instradamento creata. Le politiche di instradamento sono alla base della gestione dei flussi dati raccolti dai dispositivi. Un SGPI deve offrire molteplici politiche di instradamento, da qui la necessità di specificare al sistema il tipo di politica che si intende creare. Anche in questo caso può essere previsto un sistema di sicurezza per garantire la possibilità di creare politiche d'instradamento ad un ristretto numero di utenti. La Tecnologia RFID e le sue applicazioni 36

37 Capitolo II Le soluzioni software proposte La necessità di un sistema software che gestisse i dati raccolti dai dispositivi RFID, e i dispositivi stessi, è stata rilevata da molteplici aziende. La ricerca su questi tipi di sistema software, sebbene in un primo momento fosse ad appannaggio esclusivo degli operatori nel campo RFID, ha negli ultimi anni trovato sempre maggiore interesse anche in aziende non specializzate nel settore. Attualmente il mercato di software per la gestione degli aspetti riguardanti la tecnologia RFID mostra un buon numero di soluzioni, più o meno diversificate in base alle funzionalità proposte. Nel seguito sono presentate alcune di queste. Le soluzioni software proposte 37

38 2.1 - GlobeRanger imotion GlobeRanger presenta una piattaforma software, sviluppata in ambiente.net, per lo sviluppo e la gestione sia di soluzioni RFID che di sensori in generale. La piattaforma è slegata dalla tipologia di dispositivo, garantendo la totale compatibilità con qualsiasi tipo di sensore. Seguendo questa strategia, GlobeRanger assicura non solo il supporto a qualsiasi dispositivo RFID, ma anche la possibilità di integrare la rete di identificazione RFID con altri sensori. L'architettura del sistema è distribuita. Un sistema di event and workflow management, seguendo la configurazione data dall'utente, permette la generazione e l'invio di avvertimenti e notifiche alle business application che utilizzano il sistema. I dati grezzi raccolti dai sensori sono quindi trasformati in eventi, che sono poi gestiti dal sistema secondo le regole specificate dall'utente. Lo scambio dei dati e la loro integrazione è ottenuto utilizzando Web Service. Quest'ultimo aspetto garantisce una facile compatibilità con i sistemi esistenti. Le comunicazioni sono rese affidabili da un sistema che assicura il continuo funzionamento della piattaforma, anche quando la rete informatica non è attiva. Le informazioni che devono essere scambiate vengono infatti memorizzate e inviate quando la rete ritorna funzionante. Per consentire la sicurezza dei dati, imotion utilizza nelle comunicazioni algoritmi di criptazione. Lo sviluppo di applicazioni che utilizzino il sistema è semplificato dall'utilizzo di librerie di programmazione, rilasciate da GlobeRanger a questo scopo SAP SAP RFID SAP è attiva nel campo RFID dal Dal 2001 ha cominciato lo sviluppo della infrastruttura software SAP RFID. Le soluzioni software proposte 38

39 La soluzione prevista è pacchettizzata e prevede la piena integrazione con i sistemi SAP preesistenti (Figura 2.1). I componenti dell'architettura SAP RFID sono: Figura L'architettura SAP RFID SAP Auto-ID Infrastructure: integra i dati di Auto-ID nei processi di business abilitando la gestione, la comunicazione e l associazione dei dati RFID come pure la comunicazione con sistemi di automazione e dispositivi di Auto-Capture (tra cui RFID, codici a barre e sensori). SAP Event Management: offre servizi informativi relativi a tag RFID e EPC, funzioni basate su dati di Auto-ID mirate a fornire visibilità sullo stock a livello cross-warehouse (inter-magazzino) e cross-company (inter-aziendale); consente di scambiare i dati di tracking tra i business partner e avvia automaticamente notifiche e allarmi riferiti ad azioni previste ed impreviste. SAP Enterprise Portal: offre una vista unica e unificata nonché un accesso basato su ruolo a dati e informazioni RFID, sia all interno dell azienda sia nell ambito di reti estese della catena di fornitura (supply chain). ERP adaptors: forniscono l integrazione nei processi di supply chain execution gestiti in ambienti SAP già operativi. Le soluzioni software proposte 39

40 SAP Web Application Server: coniuga l infrastruttura RFID con l interoperabilità e la flessibilità della tecnologia dei servizi Web. SAP Exchange Infrastructure (SAP XI): offre tecnologie mirate all integrazione che supportano la collaborazione centrata sui processi tra componenti SAP e componenti di terze parti, sia all interno che all esterno dei confini aziendali. Rappresenta il centro di instradamento dei messaggi generati dalle altre componenti. SAP Mobile Infrastructure: fornisce la base tecnica richiesta per la mobilità aziendale, estendendo le soluzioni SAP oltre i confini aziendali. Nell'architettura SAP RFID il componente SAP Auto-ID Infrastructure si occupa di gestire i dispositivi di identificazione e di catturare le informazioni da questi generate. Le business application utilizzano il sistema tramite un ERP adapter. Lo scambio di informazioni tra queste componenti è regolato dal SAP XI. Le informazioni catturate dal SAP Auto-ID Infrastructure vengono seguite anche dal componente SAP Event Management, che può contenere regole di elaborazione dettate dall'utente, utili, ad esempio, a generare allarmi automatici o eventi di notifica.il SAP Enterprise Portal garantisce la possibilità di comunicare con applicazioni esterne, consentendo anche di diffondere le informazioni di Auto-ID a terze parti ORACLE ORACLE Application Server La ORACLE, forte della grande esperienza accumulata nella creazione di software per la gestione dei dati, ha tentato anch'essa la strada segnata dalla tecnologia RFID. La proposta di ORACLE prende il nome di ORACLE Application Server. Le soluzioni software proposte 40

41 Figura Architettura di ORACLE Application Server L'architettura si basa su 6 componenti (Figura 2.2): Device Abstraction Layer Sensor Edge Server Administration Dispatchers Sensor Data Menagement Development Services Il Device Abstraction Layer si occupa di creare l'interfaccia con il dispositivo fisico. Il componente offre alle restanti parti dell'architettura un'interfaccia unica per tutti i dispositivi. Per comunicare con i dispositivi fisici adotta appositi driver. Questa soluzione risulta vantaggiosa per molteplici aspetti: l'interfaccia comune per ogni dispositivo ne permette una semplice amministrazione da parte degli applicativi, che possono ignorarne i dettagli hardware; la comunicazione del dispositivo fisico con il componente tramite un driver permette di inserire nuovi dispositivi senza difficoltà, a patto di avere a disposizione il driver adatto. Le soluzioni software proposte 41

42 Le informazioni catturate dal Device Abstraction Layer vengono gestite dal centro di passaggio di tutti i dati del sistema: il Sensor Edge Server. La gestione dei dati avviene seguendo vari stadi. Il primo passo consiste nel filtrare i dati. In questo modo si garantisce che gli eventi di lettura generati dai dispositivi non contengano informazioni inutili per le applicazioni connesse al sistema. Il filtraggio può essere selezionato su di un singolo dispositivo o su gruppi (definiti dall'utente) di dispositivi. Il sistema presenta un buon numero di filtri già implementati. Il vero punto di forza è però nella possibilità di definire filtri personalizzati tramite linguaggi di script come JavaScript, o anche tramite la combinazione di filtri già esistenti. A valle del filtraggio avviene lo smistamento dei dati verso i sistemi di comunicazione (Dispatchers) e/o verso i sistemi di basi dati che memorizzano le informazioni raccolte (Sensor Data Menagement) I meccanismi con cui i dati vengono resi disponibili alle business application risiedono nel componente Dispatchers. Come avviene per l'interfaccia con l'hardware, anche in questo caso si utilizzano diversi metodi di comunicazione a fronte di un'unica interfaccia utilizzata dal sistema per passare i dati ai Dispatchers. I meccanismi base utilizzati fanno affidamento su Web Service, HTTP, Oracle Streams, ecc. Anche in questo caso è possibile inserire un meccanismo di comunicazione creato ad hoc dall'utente. Oltre alla comunicazione con applicazioni esterne al sistema, l'architettura offre un componente per l'integrazione del sistema con applicativi utente. I Development Services hanno infatti il proposito di offrire meccanismi di programmazione per consentire l'integrazione dell'architettura di ORACLE nelle applicazioni sviluppate dagli utenti. Le soluzioni software proposte 42

43 L'ultimo componente è utilizzato per la gestione del sistema, per supportare quindi le azioni di amministrazione. In Administration sono offerti i meccanismi per la gestione dei dispositivi, dal semplice monitoraggio alla possibilità di definirne una topologia. E' possibile inoltre utilizzare thin client per una amministrazione centralizzata, o sfruttare le possibilità di programmazione offerte per creare client remoti di amministrazione. Da questa interfaccia è anche possibile configurare la politica di sicurezza sui dati da utilizzare (criptazione e autenticazione degli utenti), oltre alle politiche di routing dei dati SUN Java System RFID La SUN ha abbracciato con largo interesse lo sviluppo della tecnologia RFID. L'idea della SUN è di fornire un supporto variegato per garantire un servizio utile ad un grande numero di utenti dalle necessità diverse. Le soluzioni presentate spaziano da semplici applicazioni della tecnologia RFID per la gestione di piccole moli di dati, ad applicazioni su larga scala per il supporto alla supply chain. In particolare SUN punta sulla formazione del personale oltre che sulla realizzazione del software di supporto. Per quanto riguarda il sistema di gestione dei processi di identificazione, SUN propone una architettura di riferimento sulla quale basa i suoi prodotti, e che punta ad essere il riferimento generale per chiunque voglia sviluppare sistemi RFID (Figura 2.3). Le soluzioni software proposte 43

44 Figura Architettura Java System RFID Tale architettura prende il nome di Java System RFID ed è composta di due componenti: Java System RFID Event Manager Java System RFID Information Server Il funzionamento prevede che i dispositivi di identificazione inviino continuamente i dati rilevati al sistema. Il Java System RFID Event Manager prende il flusso dei dati e lo filtra prima di inviarlo alle applicazione richiedenti. I filtri possono essere programmati a seconda delle necessità specifiche di un utente. E' possibile che si utilizzino molteplici Java System RFID Event Manager, consentendo in questo modo la localizzazione del traffico. Le informazioni che passano i filtri del Java System RFID Event Manager vengono inviate al Java System RFID Information Server. Quest'ultimo rappresenta essenzialmente un integration layer, che rende disponibili le informazioni alle applicazioni. Nel seguito i due componenti sono analizzati con maggior dettaglio: Le soluzioni software proposte 44

45 Java System RFID Event Manager: il componente presenta un'architettura distribuita che punta ad essere altamente scalabile ed affidabile. La SUN assicura che il sistema sia in grado di riallocare dinamicamente le risorse computazionali qualora uno dei nodi di elaborazione smettesse di funzionare. L'architettura del componente è mostrata in figura 2.3. Figura Architettura del Java System RFID Event Manager Un Java System RFID Event Manager può gestire molteplici dispositivi (RFID e non) con cui si interfaccia grazie al layer Adapter che ha la funzione di astrarre gli aspetti hardware del dispositivo, operando come driver. I Filter consentono di selezionare il traffico proveniente dai dispositivi prima di inviarlo a più complessi meccanismi di elaborazione. In questo componente possono essere inseriti anche meccanismi di preelaborazione non complessi per favorire le necessità degli utenti. Il Logger è un interessante componente che si occupa di rendere disponibili i dati ottenuti dai dispositivi a sistemi esterni. L'Enterprise Gateway fornisce un modo per consentire alle business application, che richiedono direttamente le informazioni all'event Manager, di ottenerle tramite meccanismi di comunicazione quali XML, SOAP, HTTP, ecc. Le soluzioni software proposte 45

46 Java System RFID Information Server: tutti i dati provenienti dagli Event Manager convergono nell'information Server, dove sono archiviati e messi a disposizione delle applicazioni che li richiedono. In sostanza l'information Server permette di introdurre ulteriori funzionalità al sistema di gestione dei dati (l'archiviazione è una di queste funzionalità) che altrimenti sarebbero responsabilità delle business application. In aggiunta l'information Server presenta svariati meccanismi per garantire una facile integrazione del Java System RFID con applicazioni sviluppate ad hoc, ma anche con sistemi preesistenti. I principali meccanismi sono Web Service, JMS, J2EE Connector Architecture Singularity Fra le soluzioni fino ad ora presentate, Singularity è l'unica ad essere open source. Le informazioni sull'architettura del sistema sono molto dettagliate e mostrano una complessità rilevante rispetto alle alternative commerciali. Figura Architettura di Singularity Le soluzioni software proposte 46

47 L'architettura di Singularity è formata da due macro-componenti principali: il Middleware e l'epc Information Service (EPC-IS). Entrambi sono organizzati in ulteriori sotto-componenti che esamineremo nel dettaglio più avanti. I sotto-componenti comunicano fra loro tramite un bus software. Si delinea dunque la presenza di due bus software, uno per il Middleware, il Service Component Bus, e l'altro per l'epc-is, l'enterprise Service Bus (Figura 2.5). Le macro-componenti comunicano tra loro attraverso i bus, che sono messi in collegamento dall'event Process Manager (EPM). Il componente Middleware ricopre il ruolo di gestore dei dispositivi e degli eventi. L'EPC-IS fornisce un accesso, alle applicazioni enterprise e ai sistemi esterni, alle informazioni raccolte dal sistema Middleware Il ruolo di questo componente è quello di gestire i dispositivi hardware, monitorandone lo stato e configurandone le funzionalità, e di gestire i dati da questi raccolti, inglobandoli in degli eventi da inviare al resto del sistema. Il Middleware si suddivide in due sotto-sistemi: Device Manager e Event Process Manager. Device Manager: Il Device Manager, come lo stesso nome suggerisce, ha il compito di gestire i dispositivi. Il Device Manager non è unico nell'architettura di Singularity, ma è possibile replicare più volte questo componente per gestire grandi quantità di dispositivi. Per permettere la trasformazione dei dati grezzi, raccolti dai dispositivi, in eventi, ogni Device Manager utilizza degli interrogator. Questi componenti ricevono i dati letti dai dispositivi e li trasformano in Sensor Event. Le soluzioni software proposte 47

48 Perché l'interrogator possa ricevere le informazioni dall'hardware, è necessario un ulteriore componente: il Physical Device Profile (PDP). Quest'ultimo si comporta come dirver per il componente. E' importante notare come un Device Manager possa gestire molteplici interrogator, ma che ad un interrogator corrisponde un solo e unico PDP. Il PDP a sua volta può essere collegato a più dispositivi (Figura 2.6). Figura Architettura del componente Middleware Il processo di acquisizione dei dati da parte dei dispositivi e la relativa propagazione di questi dati nel sistema segue queste fasi: il dispositivo esegue una lettura, il PDP la rileva e passa la lettura all'interrogator; l'interrogator prende i dati e li incapsula in un Sensor Event; il Device Manager recupera il Sensor Event e lo incapsula in un Reader Event. E' da notare che, a seconda della configurazione, più Sensor Event possono andare a formare un unico Reader Event; il Device Manager associa, eventualmente, uno o più Reader Event ad un Logical Reader Event, per supportare particolari necessità delle applicazioni utente. Le soluzioni software proposte 48

49 Event Message Space: l'event Message Space rappresenta il bus di comunicazione del Middleware. E' un event message broker con caratteristiche di tolleranza ai guasti e di consegna affidabile dei messaggi. Tramite questo sistema si assicura la comunicazione fra i Device Manager e l'event Process Manager (EPM). Event Process Manager: l'accesso al EPM si può ottenere tramite interfacce quali HTTP, JMS, Web Service o altro. I servizi offerti dal EPM consentono ad applicazioni utente di gestire meccanismi di filtraggio o di preelaborazione dei dati. Analizziamo nel dettaglio le possibilità offerte: Business Process Execution: permette di definire meccanismi di filtraggio dei dati. Complex Event Processing: consente la definizione di politiche di preelaborazione. Config Menagement: è possibile impostare delle caratteristiche tecniche di configurazione sia per la gestione dei dati che per quanto riguarda l'hardware. ALE Service: è il servizio che consente di generare Application Level Event. Questi eventi sono destinati all'enterprise Service Bus. Gli ALE sono particolari eventi che vengono processati dalle applicazioni connesse al sistema. Tramite questo servizio è possibile per una applicazione reperire in tempo reale i dati catturati dai dispositivi, ed elaborarli. Tramite l'epm gli eventi generati dal Middleware vengono instradati alla corretta destinazione per poi subire logiche di elaborazione definite dall'utente. L'EPM, infatti, è collegato ad entrambi i bus facenti parte dell'architettura di Singularity, e rappresenta il punto di raccordo fra le due macro-componenti. Volendo identificare in modo conciso il ruolo del EPM, potremmo affermare che rappresenta il punto di accesso ai servizi del Service Component Bus. Le soluzioni software proposte 49

50 EPC Information Service L'EPC-IS è il componente dell'architettura che si mette in ascolto di eventi ALE e che ne gestisce le informazioni contenute. Per comunicare con il resto del sistema, l'epc-is è connesso all'enterprise Service Bus. Sono molteplici le responsabilità che competono a questo componente. Innanzitutto è il punto di accesso alle informazioni memorizzate riguardanti i dati raccolti dai dispositivi. Un EPC-IS risponde, infatti, alle query di ricerca informazioni provenienti dalle business application connesse al sistema Singularity. I dati possono essere reperiti da un archivio locale al EPC-IS, da un altro EPC-IS o dalla EPCglobal Network. I padri dello sviluppo di Singularity pongono l'accento sulla natura distribuita del servizio di recupero dati. L'idea di base presenta una Federated Query che si propaga fra EPC-IS disposti in modo gerarchico. L'identificazione del EPC-IS corretto avviene tramite il servizio Enterprise Discovery Service (EDS), simile nel funzionamento al DNS, o al già citato ONS. L'ideale per lo sviluppo di questo sistema sarebbe poter collegare tutti gli EPC-IS tramite un Enterprise Service Bus comune. Nell'eventualità in cui questa ipotesi non fosse realizzabile, sono offerte svariate interfacce di comunicazione per l'accesso al EPC-IS. L'architettura del EPC-IS è organizzata in tre livelli (Figura 2.7), ed offre altre funzionalità oltre al semplice recupero dati. Nel seguito sono esaminati i componenti dell'architettura nel dettaglio. Le soluzioni software proposte 50

51 Figura Architettura del componente EPC-IS Interfaces: è il livello che provvede a fornire le interfacce utili alla comunicazione con l'epc- IS. Fra le molteplici offerte è possibile anche inserire interfacce sviluppate dall'utente. Service Logic: a questo livello appartengono dei componenti utili alla gestione di logiche di business e al recupero delle informazioni archiviate. Fra i componenti di questo livello rientrano: EPC Information Manager: fornisce servizi alle interfacce pubbliche contenute nel livello Interfaces. Consente anche di associare informazioni di business all'identificativo EPC di un prodotto. Event Agents: sono i componenti che ricevono le informazioni dal bus. Il loro compito è processare gli eventi ALE. E' possibile definire degli Event Agents personalizzati o anche combinarne le funzionalità. Administration: è il punto di accesso alle funzionalità di amministrazione del sistema. E' anche possibile definire dei tool di amministrazione personalizzati per eventuali configurazioni aggiunte dall'utente agli altri livelli del sistema. Le soluzioni software proposte 51

52 Business Process Management: appartengono a questo componente tutte le logiche di business definite dall'utente. Gli altri componenti di questo livello fanno riferimento al BPM per definire i comportamenti che deve assumere il sistema al verificarsi di particolari eventi. Data Abstraction Layer: è il livello che si occupa della gestione dei dati. Permette di astrarre la gestione dei dati dalla loro effettiva locazione. E' possibile infatti utilizzare come archivi dei database locali, delle applicazioni esterne, o anche altri EPC-IS. Altre funzionalità offerte sono i servizi utili alla gestione delle query distribuite OATSystems OAT Fundation Suite La OATSystems ha contribuito alla creazione degli standard riguardanti la tecnologia RFID. Da sempre questa azienda opera nel settore della gestione dei processi di identificazione, e, abbracciando lo sviluppo della RFID, ha esteso il suo interesse anche alla creazione di un software che permettesse la gestione dei dati raccolti tramite questa tecnologia. Il software proposto è è in realtà un insieme di tre componenti separati: OATaxiom OATxpress OATlogic Con questa struttura la OAT divide nettamente gli aspetti legati alla gestione dei dispositivi da quelli di gestione e presentazione dei dati. Anche la possibilità di introdurre logiche di business nell'applicazione è ottenuta tramite un componente separato. Le soluzioni software proposte 52

53 L'attenzione maggiore nella soluzione di OATSystems è posta ai problemi di consistenza dei dati. La tecnologia RFID infatti, per quanto innovativa, non è infallibile. Uno dei problemi più comuni è che una lettura di un tag non venga eseguita, anche se il tag è passato nell'area del reader. La OAT Fundation Suite prova a risolvere questi problemi a livello software, sfruttando le logiche di business e l'analisi dei dati per riscontrare gli errori e correggerli. Per comprendere come OATSystems abbia affrontato il problema, adopereremo un semplice esempio Un esempio di errore nella rilevazione dei tag Supponiamo di aver predisposto un sistema di identificazione, basato sulla tecnologia RFID, come mostrato in figura 2.8 Figura Scenario d'esempio Una business application potrebbe cercare di risalire alla posizione dell'item, tramite i dati letti dai reader. Supponendo che le letture siano avvenute come mostrato in Figura 2.9, è facile per l'applicazione stabilire che l'item sia nella Room 6. Le soluzioni software proposte 53

54 Time West Door Reader East Door Reader Corridor Reader Item Figura Tabella delle letture dei reader Dalle letture si comprende infatti che l'item è passato per la west door, e poi non ha avuto ulteriori spostamenti. Se le letture fossero invece avvenute come mostrato in Figura 2.10, il programma non sarebbe in grado di comprendere cosa è accaduto. Time West Door Reader East Door Reader Corridor Reader Item Item Figura Tabella delle letture dei reader con errore Dalla lettura, infatti, sembra che l'oggetto sia entrato nella Room 6, e poi sia uscito dal Corridor 14, senza uscire prima dalla Room. Chiaramente tale situazione si presenta nel caso in cui il reader della East Door, per qualche motivo, non ha letto il tag dell'item. Le soluzioni software proposte 54

55 La proposta di OATSystems Lo scenario appena presentato è il motivo della decisione di OATSystems di fornire un supporto per la risoluzione di questi fastidiosi problemi. La soluzione consiste nell'esaminare i processi di business per comprende se le informazioni lette da un reader sono corrette. Un utente dell'oat Foundation Suite ha il compito di rendere noto al programma la topologia della rete di lettori, le attività in cui i lettori concorrono e le funzioni che li caratterizzano nei processi di business. Conoscendo queste informazioni, il software è in grado di verificare se i dati hanno una logica accettabile e, quindi, validarli oppure correggerli. Gli sviluppatori OATSystems affermano che il loro software può essere in grado di comprendere dove è l'errore e di renderlo trasparente alle applicazioni di business, correggendo anche eventuali errori dovuti, ad esempio, alla mancanza o alla presenza in esubero di una lettura. La OATSystems, quindi, costruisce il suo software non come semplice gestore dei dati e dei dispositivi, ma come una applicazione capace di operare anche a più alto livello. La scelta impone una stretta collaborazione con le applicazioni business e grandi responsabilità da parte della suite. Le informazioni generate, infatti, non sono il semplice risultato delle letture effettuate, ma potrebbero essere anche delle informazioni generate artificialmente dal software di gestione, per coprire degli errori. Come accennato in precedenza, la suite è composta di tre componenti, responsabili ciascuno di particolari funzionalità (Figura 2.11). Le soluzioni software proposte 55

56 Figura Architettura OAT Foundation Suite OATaxiom: è il componente che fornisce l'accesso alle informazioni raccolte e che le organizza per permetterne il consumo alle applicazioni di business. Responsabilità di questo livello è reperire le informazioni da fonti esterne, così come mettere a disposizione di applicazioni esterne le informazioni raccolte dal sistema. Il Consistency Engine è la parte del componente che effettua i controlli di consistenza delle informazioni. E' questa la vera innovazione presentata dalla soluzione di OATSystems. OATxpress: la gestione dei dispositivi, la cattura delle informazioni e il loro filtraggio sono le responsabilità fondamentali di questo componente. OATlogic: è questo il componente in cui è possibile inserire logiche di business per la gestione dei dati. Sono forniti dispositivi di sviluppo applicazioni e tool grafici per definire estensioni e regole del sistema di gestione. Perché sia possibile implementare logiche di elaborazione, anche complesse, la OATSystems ha creato il linguaggio rfxml, estensione del XML, che fornisce costrutti per descrivere scenari RFID e processi di business. Le soluzioni software proposte 56

57 2.7 Confronto fra le soluzioni proposte Nel seguito sono presentate in modo schematico le caratteristiche offerte dalle soluzioni proposte. Dalla tabella 2.1 risulta chiaro come ogni soluzione abbia incentivato i propri sforzi in particolari ambiti, tralasciandone altri. Fra le altre, la soluzione di SUN e quella di OAT sono quelle che maggiormente si evidenziano. La prima per l'offerta dell'unico sistema realmente scalabile; la seconda per il sistema di correzione dei dati realizzato. E' importante ad ogni modo citare anche le soluzioni di Oracle e Singularity, che offrono comunque un supporto completo per un processo di identificazione. Queste ultime, assieme alla soluzione di SUN, sembrano essere i sistemi più completi. Le soluzioni software proposte 57

58 Software Gestione remota dei dispositivi Gestione topologia dei dispositivi Supporto di più dispositivi di diverse tipologie Filtraggio locale al dispositivo Filtraggio centrale dei dati Gestione politiche di instradamento Creazione di task automatiche Creazione di politiche di elaborazione Architettura estendibile Interfacce verso le applicazioni estendibili Disponibilità di tool di sviluppo Grado di interfacciamento con le applicazioni di business imotion SAP RFID Oracle AS Java System RFID Singularity OAT Foundation Suite x x x x x x - x - x x x x x x x x x x x x x x x x x x x x x - x - - x x - - x x x x x x x x - x - x - - x Solo tramite Web Service Buono Ottimo Ottimo Ottimo Buono Sistema Scalabile x - - Comunicazioni criptate Meccanismi automatici di correzione degli errori Piattaforma di funzionamento x - x - x x Windows Portabile Portabile Portabile Portabile Portabile Tabella Comparazione fra le soluzioni proposte Le soluzioni software proposte 58

59 Capitolo III Una soluzione alternativa Dopo lo studio condotto nel precedente capitolo, si sente comunque la necessità di una alternativa alle soluzioni trattate. I software presentati, infatti, soffrono di diverse carenze o svantaggi. Innanzitutto è bene notare come di tutte le soluzioni solo una sia open source e gratuita. E' questa una caratteristica molto importante per lo sviluppo della tecnologia RFID. Le soluzioni commerciali hanno spesso prezzi molto alti, nell'ordine di diverse decine di migliaia di euro. Un loro utilizzo all'esterno di grandi aziende potrebbe risultare proibitivo per i costi, frenando di fatto la diffusione dell'identificazione tramite RFID. A questa problematica si affiancano problemi di poca estensibilità dell'architettura software. Molte delle soluzioni presentate hanno infatti una architettura rigida che non ne permette estensioni o modifiche per venire incontro alle esigenze di business di un utente. Sono spesso consentite solo modifiche alle logiche di filtraggio, mentre i restanti aspetti, come ad esempio la sequenza di elaborazioni subita dai dati, non sono modificabili. Una soluzione alternativa 59

60 Lo stesso Singularity, pur essendo open source, presenta una architettura sostanzialmente rigida, a cui difficilmente possono essere aggiunte componenti non previste in fase iniziale, se non tramite un riassetto dell'intero sistema. Altri limiti risiedono nelle offerte di sistemi scalabili. In un sistema scalabile è possibile sostenere un carico di lavoro maggiore aumentando le risorse del sistema con proporzionalità lineare all'aumento del carico. Larga parte dei software esaminati presentano una architettura che non supporta la possibilità di accrescere le risorse del sistema. Molto spesso viene utilizzato un punto centrale di smistamento di tutti i dati ed è plausibile che, in presenza di un numero elevato di dati, questo punto veda le sue prestazioni ridotte per la grande quantità di elaborazioni da compiere. Nessuno dei sistemi offre possibilità di estensione modulare del sistema per venire incontro a tali necessità, ed, anzi, tale soluzione risulta spesso inapplicabile alle architetture presentate. Questi ed altri sono i problemi che affliggono gli attuali sistemi di gestione RFID. Sulla base di questa analisi si è deciso di sviluppare un sistema alternativo, che sopperisse alle mancanze delle soluzioni attualmente sul mercato. In questo capitolo si esaminano con attenzione i requisiti, funzionali e non funzionali, di un SGPI e viene proposta un'architettura di massima per offrire una soluzione ai problemi esaminati. 3.1 Requisiti funzionali In questo paragrafo riassumeremo i requisiti funzionali, ossia i servizi, che un SGPI dovrebbe offrire. Non verranno trattati i dettagli tecnici per la loro realizzazione, che saranno invece affrontati nei paragrafi successivi. Una soluzione alternativa 60

61 Supporto di più siti fisici e di più applicazioni: il SGPI deve permettere la gestione di molteplici dispositivi, dislocati anche in luoghi geograficamente distanti. Più applicazioni devono poter usufruire dei servizi del sistema e richiedere i dati catturati dai dispositivi gestiti. Gestione hardware: deve essere possibile collegare al sistema qualsiasi dispositivo di identificazione di cui sia disponibile l'apposito driver. Di ogni dispositivo va monitorato lo stato. La verifica dello stato deve essere resa disponibile alle applicazioni di business autorizzate. E' infatti conveniente immaginare che lo stato di un dispositivo sia visibile non a tutte le applicazioni collegate al sistema. Un meccanismo di sicurezza deve permettere di discernere le applicazioni che sono autorizzate a vedere lo stato dei dispositivi da quelle che invece non possono. Le letture del dispositivo devono essere catturate dal sistema e rese disponibili alle applicazioni che le richiedono. Se i driver lo consentono, deve essere anche possibile inviare comandi di scrittura su tag ai dispositivi. Si deve consentire la possibilità di riunire in gruppi i dispositivi, gestendone in questo modo la topografia. Gestione dei dati: un SGPI deve permettere di definire filtri, politiche di elaborazione e di instradamento dei dati: Filtri: deve essere offerto un sistema a due livelli di filtraggio, in entrambi i casi personalizzabile. Il primo livello è caratterizzato da filtri grezzi che operano su un singolo dispositivo. E' il caso di filtri temporali, sul EPC, ecc. Il secondo livello è fatto di filtri, anche definiti dall'utente, che operano analisi più complesse su dati provenienti da più dispositivi. Elaborazioni: anche le elaborazioni sono definibili a due diversi livelli. Il primo livello deve consentire di definire quale sia la destinazione di particolari eventi, quali la lettura di un tag da parte di un dispositivo. Una soluzione alternativa 61

62 Il secondo livello deve offrire complessi meccanismi di personalizzazione, garantendo la possibilità di realizzare delle vere e proprie applicazioni per l'elaborazione dei dati. Instradamento: l'instradamento dei dati deve essere gestito tramite l'azione combinata dei due livelli di elaborazioni previste dal sistema. Aggregazione dei dati: l'interfacciamento del sistema verso la EPCglobal Network è un argomento molto delicato dal punto di vista della realizzazione poiché, allo stato attuale, ancora non è presente uno standard riconosciuto per la gestione di questa rete. Questa funzionalità andrebbe quindi offerta come Estensione del sistema, eventualmente sostituibile o facilmente aggiornabile. Integrazione con i sistemi di back-end: il sistema deve rendere disponibili librerie di programmazione per consentire l'integrazione con le applicazioni. Oltre a tale sistema deve essere possibile dialogare con il SGPI tramite protocolli di comunicazione o interfacce esterne come ad esempio Web Services. Ulteriori interfacce di comunicazione devono essere aggiungibili facilmente tramite definizione di estensioni al sistema. Gestione di task: quanto affermato precedentemente per la gestione dei dati, trova validità anche per la creazione di task automatici. Una elaborazione personalizzata deve consentire, infatti, di prevedere meccanismi automatici quali la generazione di eventi di allarme o simili, la disattivazione di dispositivi o la loro attivazione ecc. Monitoraggio delle attività: il SGPI deve offrire un completo sistema di logging delle attività per garantire il monitoraggio dei processi del sistema. Ogni operazione che riguardi la gestione dei dati deve mantenere memoria del richiedente dell'operazione e della data e ora in cui l'operazione è richiesta. In questo modo deve essere possibile risalire alle attività svolte dal sistema, a chi le ha svolte ed in quale momento. Una soluzione alternativa 62

63 3.2 - Requisiti non funzionali I requisiti non funzionali rappresentano dei vincoli sul progetto del sistema, riguardanti solitamente le prestazioni. Nel seguito sono presentati i principali requisiti non funzionali cui deve rispondere un sistema SGPI. Sicurezza: la sicurezza del sistema deve essere garantita da gestione autenticata degli accessi al sistema: ogni applicazione che intende utilizzare il sistema deve fornire un suo identificativo. In questo modo si garantisce che il sistema sia fruibile solo da chi ne ha l'autorizzazione. Un database interno al sistema (o esterno a seconda della configurazione scelta dall'utente) deve raccogliere i dati sugli utenti che hanno il permesso di accedere al sistema. Un amministratore gestisce i permessi di accesso. Deve essere possibile gestire dei livelli di accesso differenziati: ad esempio ad alcuni utenti si può concedere di leggere i dati di identificazione ma non di controllare lo stato dei dispositivi, mentre ad altri si deve poter assegnare anche questa possibilità. Questa necessità è fondamentale per la definizione di almeno due livelli di accesso: il livello amministratore che deve poter anche, in caso di necessità, bloccare il sistema, ed il livello utente, che si limita a sfruttarne le funzionalità. Un secondo aspetto, non meno importante, è garantire che i dati scambiati fra le componenti distribuite del sistema vengano protetti tramite meccanismi di criptazione. Questa necessità nasce per la salvaguardia della riservatezza delle informazioni trattate dal sistema, in caso di intercettazione delle comunicazioni. Scalabilità: la scalabilità è forse l'aspetto più complesso da progettare in un sistema. Nei precedenti capitoli abbiamo visto come i sistemi software proposti difficilmente riuscissero a realizzare questo requisito. Il problema fondamentale risiede nella necessità di avere un punto centrale di gestione dati che si occupi di elaborarli e di instradarli. Una soluzione alternativa 63

64 E' necessario quindi prevedere un meccanismo di aggiunta di moduli di estensione al sistema, che consentano di aggiungere risorse di elaborazione per supportare carichi di lavoro maggiori. Potrebbe sembrare non strettamente necessario un sistema scalabile per la gestione dei processi di identificazione, poiché i dati scambiati sono sufficientemente ridotti, spesso costituiti da una semplice stringa di pochi byte. La difficoltà non risiede, tuttavia, nella dimensione dei dati scambiati, ma nella quantità di dati, anche brevi, che attraversano il sistema. Se infatti sono connessi un consistente numero di reader, ciascuno di questi effettua un invio di dati anche piu' volte al secondo, di centinaia di tag rilevati in contemporanea. Dunque, la mole di dati è piccola se venissero letti pochi tag, ma aumenta esponenzialmente con l'aumentare del numero di questi ultimi. Portabilità: gli ambiti di utilizzo di un sistema di gestione dei processi di identificazione sono vasti ed eterogenei. Il sistema potrebbe essere utilizzato per implementare una applicazione di controllo degli accessi, ma anche per gestire un magazzino o una catena di produzione. Queste caratteristiche richiedono una adattabilità del software a diversi ambienti di lavoro. E' quindi necessario che il software sia del tutto slegato dalla piattaforma su cui si appoggia, e che sia dunque portabile. In questo modo si garantisce che il sistema possa essere utilizzato in qualsiasi applicazione, senza condizionare cambiamenti significativi nei sistemi informativi preesistenti Architettura del SGPI Sulla base di quanto affermato nei precedenti paragrafi, possiamo delineare una architettura di massima per un SGPI. L'architettura presentata è slegata da qualsiasi implementazione tecnologica e punta a definire un modello per la realizzazione di un sistema per la gestione dei processi di identificazione. Una soluzione alternativa 64

65 Da un'attenta analisi dei requisiti presentati, risulta che il vero nucleo delle funzionalità del sistema risiede nella gestione delle comunicazioni fra i dati generati dai dispositivi e le applicazioni che utilizzano tali dati. La parte centrale di un SGPI è quindi la gestione delle comunicazioni, a cui si affiancano solo in un secondo momento i meccanismi per la risoluzione degli altri requisiti. La progettazione di un efficiente sistema di comunicazione necessita della conoscenza dei tipi di dati da scambiare e della frequenza con cui questi dati vengono scambiati. A questo scopo è bene fare alcune considerazioni: Un'analisi dei dati generati dai dispositivi di identificazione è sufficiente a caratterizzare la quasi totalità dei dati che devono essere gestiti dal sistema. Tipicamente i dati generati da un dispositivo di identificazione sono costituiti da una semplice stringa di caratteri, di poche decine di byte di lunghezza (20 byte è una dimensione già più grande della maggior parte dei dati generati dai dispositivi). A questi dati si potrebbe pensare di aggiungere una ulteriore stringa che riporti la data e l'ora della loro generazione. In definitiva i dati da trattare sono nell'ordine di poche decine di byte. Per le necessità delle applicazioni di business si prevede che i dati generati siano tempestivamente inviati a chi li ha richiesti. Questo comporta che non sia possibile aggregare più dati generati da un dispositivo, in un certo intervallo di tempo, e poi inviarli tutti assieme. Nella quasi totalità dei casi si sarà quindi costretti ad inviare dei pacchetti che trasportano solo poche decine di byte di carico utile. Questa considerazione suggerisce l'utilizzo di un protocollo di comunicazione che limiti l'overhead, ossia che riduca la quantità di dati aggiunta dalle informazioni per gestire la comunicazione. Ultima considerazione da fare è la frequenza con cui i dati vengono inviati. Ad ogni rilevamento di dati da parte di un dispositivo corrisponde l'invio di questi sulla rete informatica utilizzata dal sistema. Una soluzione alternativa 65

66 Considerando l'attività di un dispositivo RFID che può leggere più volte al secondo centinaia di tag presenti nella sua area di lavoro, si ha un'idea della quantità di pacchetti inviati sulla rete. Si suppone, quindi, che il sistema di smistamento dei dati sia in grado di gestire quantità enormi di pacchetti che arrivano a brevissima distanza di tempo l'uno dall'altro. Inoltre, è conveniente immaginare un sistema che consenta di filtrare i dati non utili alle applicazioni, in modo da evitare di inviare sulla rete pacchetti che poi saranno comunque scartati. Precedentemente si è detto che i dati generati dai dispositivi corrispondono alla quasi totalità di quelli gestiti dal sistema. Non rappresentano la totalità poiché, oltre a questi, viaggiano anche dati utili alla comunicazione dello stato dei dispositivi alle applicazioni. Questa seconda tipologia di dati è di certo meno consistente come quantità rispetto alla prima, tuttavia la loro gestione prevede un meccanismo ben più complesso. Senza addentrarsi eccessivamente nei particolari, un sistema per il controllo dello stato prevede che le entità, di cui lo stato deve essere controllato, comunichino la loro presenza, e la loro disconnessione, ad un server centrale. Questo server gestisce una lista di tutte le entità connesse al sistema, conservando le rispettive informazioni sul loro stato. Inoltre, quando una entità cambia stato, il server si fa carico di comunicare questo cambiamento a tutte le altre entità connesse al sistema. Il server è responsabile anche dell'attuazione di meccanismi che verifichino la coerenza dello stato delle entità (se un'entità per un problema si disconnette senza avvisare il server, quest'ultimo deve riuscire a rilevare la sua disconnessione). Le problematiche, che emergono in queste considerazioni sul sistema di comunicazione, sono a grandi linee le stesse che si affrontano nei sistemi di messaggistica e presenza istantanee (IM&P: Istant Messaging and Presence). L'architettura generale del sistema segue quindi il modello presentato in Figura 3.1, che si ispira a questa tipologia di sistemi. Una soluzione alternativa 66

67 Il modello presentato prevede la presenza di un punto centrale di gestione e smistamento dei dati, costituito da uno o più server. A questi si collegano le applicazioni di business e i software che si interfacciano con i dispositivi hardware di identificazione. Figura Modello di architettura Oltre a quanto detto, sulla scelta del modello architetturale ha pesato un'ulteriore considerazione sulla natura delle entità distribuite che devono comunicare. Il sistema prevede infatti componenti decisamente semplici, il cui unico compito è garantire la comunicazione con le altre componenti distribuite. Questo compito è esattamente quello assolto dai client di un sistema di messaggistica e presenza istantanee. Possiamo allora immaginare non solo di mutuare l'architettura del SGPI da un sistema di messaggistica e presenza istantanee, ma anche di utilizzare uno di questi sistemi per risolvere la comunicazione fra le componenti. Figura Modello di comunicazione fra le componenti In Figura 3.2 è mostrato come è possibile utilizzare un sistema di IM&P per risolvere la comunicazione fra le componenti dell'architettura del SGPI. I client del sistema di messaggistica si occupano delle comunicazioni dei dati e dei messaggi sullo stato di presenza. Una soluzione alternativa 67

68 Ad alcuni di questi client sono attaccate le applicazioni di business, ad altri i dispositivi di identificazione. Chiaramente, in entrambi i casi è necessario adattare l'interfaccia dei client per la comunicazione con le applicazioni e con i dispositivi. Dopo aver chiarito la base su cui un SGPI dovrebbe fondare la sua architettura, passiamo ad esaminare come le varie componenti individuate debbano operare per risolvere i requisiti esaminati nei precedenti paragrafi. Da quanto affermato fino ad ora risulta chiaro che dovrebbero essere individuate principalmente tre componenti: il server, il client che comunica con le applicazioni e il client che comunica con i dispositivi. Per chiarezza ci riferiremo a queste con ponenti, rispettivamente, con i nomi di: data management server (DMS), application interface (AI), remote hardware manager (RHM). In Figura 3.3 sono mostrate le componenti del sistema con le rispettive funzionalità. Figura Componenti del SGPI e loro funzionalità Application Interface: deve semplicemente offrire le funzionalità messe a disposizione dal SGPI alle applicazioni. Una soluzione alternativa 68

69 Data management server: realizza lo smistamento dei dati gestiti dal sistema. Questo componente deve offrire una console di amministrazione per impostare le caratteristiche di configurazione del sistema. In questa sede devono avvenire i meccanismi di filtraggio previsti dai requisiti funzionali. Deve essere inoltre presente un meccanismo che consenta di definire elaborazioni personalizzabili dall'utente o, eventualmente, estensioni al sistema, quali potrebbero essere il supporto alla EPCglobal Network. Remote hardware manager: è il componente che deve dialogare con i dispositivi. L'interfacciamento con questi ultimi deve avvenire tramite driver, in modo da consentire che molteplici dispositivi possano essere utilizzati dal sistema. Deve essere previsto un meccanismo di filtraggio grezzo, che consenta, ad esempio, di definire filtri per evitare l'invio di letture replicate al DMS Confronto con le soluzioni già presenti Dopo aver fatto una panoramica sulle funzionalità e sull'architettura che un SGPI, che risponda a tutti i requisiti presentati in precedenza, debba offrire, passiamo a confrontare il modello di sistema, sviluppato nel precedente paragrafo, con le soluzioni software presentate nel Capitolo II. Lo scopo del confronto è verificare la presenza di una soluzione che si avvicini al modello esposto, valutandone differenze ed eventuali mancanze. Una soluzione alternativa 69

70 GloberRanger imotion GlobeRanger ha deciso di sviluppare il suo prodotto tramite il framework.net, operante solo in ambienti Microsoft Windows. Non entrando nel merito dei vantaggi/svantaggi in prestazioni di questa decisione, è possibile comunque affermare che il sistema di GlobeRanger è strettamente dipendente dal sistema operativo utilizzato. In un contesto di utilizzo vasto come quello presentato dalla tecnologia RFID, questo è uno svantaggio considerevole, che non rispetta i requisiti non funzionali che ci siamo posti all'inizio di questo capitolo. Una azienda, che, per questioni legate alla sicurezza e alla stabilità, utilizza sistemi operativi UNIX, se volesse usare la soluzione di GlobeRanger sarebbe costretta a rinnovare l'intero sistema informatico. Per quel che riguarda la gestione dei dati, imotion offre un meccanismo di gestione degli eventi e dei flussi di lavoro. Non è ben chiaro, tuttavia, se avviene un qualche genere di filtraggio prima di affrontare la gestione degli eventi impostata dall'utente. Da come è presentata l'architettura è comunque plausibile ipotizzare che l'unica elaborazione dei dati avvenga in siti remoti rispetto ai dispositivi. Questo approccio, garantendo da un lato un controllo totale sui dati raccolti, penalizza dall'altro le prestazioni della rete informatica. Molto spesso, infatti, potrebbero viaggiare dati di puro overhead, per nulla utili allo svolgimento dei processi di business. La sicurezza dei dati trasmessi utilizza meccanismi di criptazione, ma non un sistema di accesso autenticato al sistema, anche il requisito non funzionale della sicurezza è quindi non rispettato. Una soluzione alternativa 70

71 SAP SAP RFID La soluzione di SAP, come quella di GlobeRanger, presenta poca attenzione al filtraggio sul punto di raccolta dati per salvaguardare le prestazioni della rete informatica. I dati raccolti attraversano un unico nodo, prima di essere distribuiti fra i vari sistemi. Anche in questo caso la scalabilità sembra difficile da ottenere. L'unico nodo infatti costituisce una necessità per garantire il corretto trattamento dei dati, ed è impossibile prevedere aggiunte di moduli per supportare un traffico maggiore. Il maggior punto a favore di SAP RFID è nella possibilità di definire topografie complesse, che riconducano i dati, ad esempio, a magazzini diversi, o addirittura ad aziende differenti. Questa funzionalità offre quindi la possibilità di gestire anche complesse topografie, facilitando l'organizzazione della raccolta dati. La soluzione di SAP sembra in ogni caso mancare di sufficienti supporti per la personalizzazione delle logiche di elaborazione dei dati. Oltre a presentare una carente gestione del filtraggio, sembra infatti difficoltoso poter definire logiche di elaborazione personalizzate dell'utente o meccanismi di task automatici. ORACLE ORACLE Application Server La soluzione di ORACLE utilizza anch'essa un componente di gestione locale al dispositivo basato sull'interazione tramite driver. Il filtraggio dei dati, tuttavia, anche in questo caso è remoto e risiede nel Sensor Edge Server. Si presentano dunque tutti gli svantaggi elencati per le precedenti soluzioni. La personalizzazione dei filtri e delle politiche è invece molto ben gestita. E' possibile definire filtri personalizzati tramite linguaggi di script quali Javascript, o combinare filtri già esistenti. Una soluzione alternativa 71

72 Un altro vantaggio offerto dall'oracle Application Server è la gestione delle interfacce di comunicazione verso le applicazioni esterne. Il sistema prevede infatti un Dispatcher comune a più moduli che, prendendo le informazioni dal Dispatcher, le rendono disponibili sotto varie forme. Questo meccanismo semplifica di molto la creazione di nuove interfacce di comunicazione verso terze applicazioni. ORACLE offre anche un sistema per la creazione di console di amministrazione remota. Ultima funzionalità offerta in aggiunta da ORACLE è la criptazione dei dati, a cui pero' non si affianca un meccanismo di autenticazione degli utenti del sistema. SUN Java System RFID Il Java System RFID fornisce un interessante approccio per garantire la scalabilità. I componenti che gestiscono gli eventi sono infatti non legati ad un unico nodo. Si possono avere più Event Manager che gestiscono ciascuno un certo numero di dispositivi. E' questo un grande vantaggio dell'architettura di SUN. I dati sono poi resi disponibili tramite interrogazione diretta al Event Manager o tramite l'accesso alle funzioni del secondo componente dell'architettura: l'information Server. Di fatto SUN ha disaccoppiato la gestione della raccolta dati dalla loro presentazione alle applicazioni, senza comunque precludere la possibilità ad una applicazione di raccogliere direttamente i dati. La soluzione garantisce la scalabilità del sistema nella gestione delle letture dei dispositivi. La difficoltà che si presenta è nella necessità di conoscere l'indirizzo fisico del Event Manager qualora un'applicazione volesse ottenere i dati letti dai dispositivi senza utilizzare l'information Server (Accelerando di fatto il reperimento degli stessi). L'architettura generale del sistema risulta inoltre macchinosa oltre che complessa, non in linea, quindi, col modello da noi presentato che punta invece alla semplicità. Una soluzione alternativa 72

73 Per quanto non siano previsti meccanismi di filtraggio locali al dispositivo, il traffico su rete è gestibile senza influenzare le prestazioni grazie all'utilizzo di un numero adeguato di Event Manager. Chiaramente questa pratica, anche se risolve il problema, va a discapito dei costi di installazione e gestione del sistema. Dal punto di vista delle personalizzazioni, il sistema offre la possibilità di inserire logiche di elaborazione personalizzate al livello dell'event Manager. Tali logiche sono comunque decisamente ridotte rispetto a quanto auspicato nel nostro modello. In conclusione la soluzione di SUN offre un sistema parzialmente scalabile ma decisamente rigido nella sua architettura di base. Non è comunque da poco il contributo alla scalabilità offerto per la gestione delle letture dei dispositivi. Contributo che allo stato attuale la SUN è l'unica a fornire. Singularity Singularity è l'unica soluzione ad essere open source e gratuita. I dati vengono gestiti tramite la generazione di eventi. Questa gestione permette di inviare in un solo evento dati provenienti da più dispositivi. Il risultato è una gestione della topografia dei dispositivi ed una ottimizzazione del traffico su rete. Viene tuttavia riservato ad un componente remoto il vero filtraggio dei dati. Anche in questo caso si può quindi affermare che il modello da noi presentato non è accomunabile all'architettura di Singularity. La possibilità di definire logiche di pre-elaborazione è garantita anche in questo sistema, pur non consentendo la flessibilità auspicata dal nostro modello. Una soluzione alternativa 73

74 Per rendere disponibili le informazioni alle applicazioni di business, il componente Information Service si occupa di fare da interfaccia. Singularity immagina di realizzare una federazione di Information Service. Una richiesta ad un server può essere risolta accedendo alle informazioni gestite anche da un altro server. Questa soluzione, per quanto sia progettata per la scalabilità del sistema, non può garantirla. Se infatti le informazioni richieste sono tutte residenti su di un Information Service server unico, questo server verrà investito di richieste e rappresenterà un collo di bottiglia per l'intero sistema. E' possibile pensare a logiche di ridondanza per risolvere questo problema, ma resta alla responsabilità dell'utente trovare una soluzione, quindi, in sostanza, il problema non è risolto al livello del SGPI. Come per la soluzione SUN, anche in questo caso l'architettura mostra non poche complessità, in totale disaccordo con quanto proposto invece nel modello presentato nei precedenti paragrafi. OATSystems OAT Foundation Suite La principale caratteristica offerta dalla soluzione di OATSystems è il componente Consistency Engine che garantisce la correzione automatica di errori di lettura dei dati, sulla base dell'esame dei processi di business. E' questa una funzionalità che il nostro modello non prevede, ma che può essere aggiunta come estensione del sistema. Altro vantaggio di OAT Foundation Suite è la presenza di tool grafici per la definizione dei processi di business. E' questo un vantaggio non da poco per quanti non volessero scrivere del codice per implementare le proprie elaborazioni. Per quanto riguarda gli aspetti di personalizzazione dell'architettura del sistema, OATSystems presenta forse la soluzione più statica fra quelle trattate. Una soluzione alternativa 74

75 3.5 - Risultati del confronto Dallo studio dei vari sistemi elencati in questo testo emergono una serie di risultati che hanno portato alla decisione di realizzare un sistema alternativo a quanto già presente. Molti dei sistemi presentati hanno funzionalità peculiari, legate molto spesso all'esperienza delle software house che li hanno realizzati: ad esempio, la gestione della scalabilità da parte di SUN, da sempre impegnata nella realizzazione di grandi sistemi, o la riparazione degli errori realizzata da OATSystems. Tutte queste soluzioni sono, tuttavia, decisamente lontane dal modello immaginato all'inizio di questo capitolo: le architetture sono per lo più rigide e talvolta molto complesse, inoltre, non sempre tutti i requisiti individuati vengono rispettati. Si è quindi giunti alla decisione di proporre un sistema alternativo che come obiettivo si pone, non di risolvere tutte le problematiche affrontate dai sistemi esaminati, ma di fornire una solida base che risolva i requisiti presentati in questo capitolo. Una soluzione alternativa 75

76 Capitolo IV Progettazione del SGPI Nei precedenti capitoli si è presentato esaurientemente il modello di sistema immaginato e le problematiche che intende risolvere. E' nostro interesse a questo punto mostrare come è stato realizzato un sistema alternativo basato su tale modello. Saranno presentate con dettaglio le tecnologie utilizzate e le motivazioni che hanno portato al loro impiego, le soluzioni tecniche e la progettazione compiuta. E' bene notare come il SGPI non sia stato sviluppato per intero in questo lavoro di progettazione. Il sistema risulta infatti complesso, richiedendo un impegno più lungo per una realizzazione completa. Questo lavoro ha concentrato la sua attenzione nello sviluppo del nucleo del sistema, realizzando i meccanismi di comunicazione fra le componenti, ed alcune delle componenti stesse. Progettazione del SGPI 76

77 Sebbene incompleto, il SGPI mostra comunque parte delle sue funzionalità, permettendo la realizzazione di semplici applicativi. Il meccanismo di comunicazione fra le componenti è la parte del sistema maggiormente sviluppata. Su questa base si sono realizzati, in un secondo momento, alcuni dei componenti base del sistema fra cui l'interfaccia con l'hardware, i meccanismi di integrazione per le applicazioni di business e una parte del sistema di filtraggio ed elaborazione ad alto livello dei dati. Nel seguito, verrà presentata l'architettura completa del SGPI con le sue componenti. Le parti dell'architettura sviluppate saranno trattate in dettaglio, mettendo in luce gli aspetti della realizzazione più interessanti La scelta della tecnologia da utilizzare La tecnologia utilizzata per la realizzazione del SGPI è stata dettata da due principali parole chiave: portabilità e real time. La scelta del linguaggio in cui realizzare il sistema è immediatamente ricaduta sul Java. La tecnologia di SUN, visto il suo grande successo, dispone ormai di una virtual machine per tutti i sistemi operativi più diffusi. Le ultime versioni della piattaforma Java hanno poi presentato notevoli miglioramenti in prestazioni, assottigliando lo svantaggio dato dall'utilizzo di una virtual machine. A questo si aggiunge che alcuni sistemi operativi si stanno attrezzando per interpretare il bytecode di Java senza l'utilizzo della JVM, consentendo, di fatto, prestazioni ad altissimo livello. Dopo tutto, la scelta di Java in applicazioni che richiedono alte prestazioni non è più una sorpresa, ed il suo utilizzo è diffuso anche in applicazioni critiche, come la gestione dei comandi automatici degli aereoplani. Progettazione del SGPI 77

78 Dovendo realizzare un sistema distribuito, è stato necessario compiere una scelta anche sul meccanismo di comunicazione da utilizzare fra le componenti del sistema. Anche in questo caso, come per la scelta del linguaggio, le problematiche principali erano la portabilità e i tempi di risposta. La scelta è ricaduta su di un sistema di comunicazione basato sul protocollo XMPP, prima conosciuto come Jabber. Il protocollo è progettato per funzionare in una architettura client-server che ben si adatta alle necessità del SGPI. Ulteriore vantaggio del protocollo è la presenza di un buon numero di implementazioni del lato server. Una di queste, WILDFIRE, di altissime prestazioni, è anche open source e gratuita, rispondendo, quindi, alle nostre necessità Il protocollo XMPP XMPP è un protocollo aperto, leggero e semplice, scritto in XML. Il protocollo consente a due entità di scambiarsi messaggi ed informazioni strutturate, in tempo reale, tramite Internet, creando uno streaming XML. L'applicazione per cui nasce Jabber è l'instant messaging. Il protocollo si è però rilevato ben presto adatto anche ad altre applicazioni. Alcuni dei vantaggi sono elencati di seguito: Libero il protocollo è gratuito e pubblico, oltre che di facile comprensione. Molteplici sono le implementazioni dei client e dei server che lo supportano. Standard l'internet Engineering Task Force (IETF) ha standardizzato XMPP considerandolo una importante tecnologia di messaggistica istantanea. Collaudato sono centinaia gli sviluppatori che utilizzano XMPP e migliaia i server e le applicazioni sparse nel globo che lo utilizzano. Decentralizzato l'architettura di XMPP è simile a quella utilizzata dal sistema di e- mail. Chiunque può attaccare il proprio server ad una rete XMPP. Progettazione del SGPI 78

79 Sicuro un server XMPP può essere isolato da Internet. Può inoltre utilizzare SASL e TLS. Estendibile utilizzando i namespace XML, è possibile realizzare funzionalità personalizzate al di sopra del protocollo centrale. Flessibile oltre all'istant messaging, il protocollo offre servizi per la gestione delle reti, diffusione di contenuti, file sharing, ecc. L'architettura del protocollo è organizzata secondo uno schema simile a quello del sistema di . I client si collegano ad un server, a loro volta, i server possono essere fra loro collegati. In questo modo due client collegati a server differenti possono comunicare fra loro, purché i server siano fra loro collegati (Figura 4.1). Figura Architettura del protocollo XMPP Il protocollo consente anche di comunicare con sistemi di messaggistica esterni, purché sia presente un particolare componente, detto gateway, che faccia da traduttore con i sistemi esterni. Per quanto riguarda la struttura vera e propria, il protocollo mette in comunicazione diretta due entità (client-server o server-server) creando due stream XML, ciascuno a senso unico. Su tali stream viaggiano delle strutture dette stanza, rappresentate da una regione delimitata da un particolare tag, a seconda del tipo di stanza. Progettazione del SGPI 79

80 In particolare, ogni tipo di stanza individua un tipo di messaggio. Sono quattro i messaggi definiti in seno al protocollo XMPP: Message: rappresenta il messaggio vero e proprio, utile a scambiare informazioni in formato testo. Il messaggio ha 3 campi: header, type, body Presence: la stanza di tipo presence è utilizzata per gestire i messaggi che consentono al protocollo di rilevare lo stato di presenza dei client. IQ: tramite queste stanza vengono gestite le liste contatti e i messaggi personalizzati. Queste stanza possono essere anche personalizzate tramite la definizione di namespace XML. Error: è il tipo di stanza utilizzata per gestire i messaggi di errore. Questi tipi di messaggi servono a gestire tutte le caratteristiche offerte dal protocollo. Come accennato in precedenza, infatti, lo scambio di messaggi non è l'unica funzionalità offerta. XMPP garantisce un meccanismo per gestire una lista contatti (definita in seno al protocollo roster) per ogni utente del sistema. Il meccanismo basa il suo funzionamento sulle sottoscrizioni. Un utente A può chiedere di aggiungere alla sua lista contatti un utente B. Se l'utente B concede il permesso, l'utente A aggiungerà B al suo roster. Il protocollo assegna al server la responsabilità di memorizzare il roster. Ogni utente che si collega al sistema riceve, quindi, una serie di messaggi che gli comunicano il suo roster e lo stato di presenza degli utenti cui è sottoscritto. Il riconoscimento di un utente da parte del server avviene tramite identificazione basata su username e password. All'utente viene associato un indirizzo univoco che servirà poi al routing dei messaggi e alla gestione dei roster. Questo indirizzo prende il nome di JID ed è nella forma In realtà, per il routing dei messaggi l'indirizzo utile è quello formato dal solo Progettazione del SGPI 80

81 Il campo resource è per ulteriori funzionalità, come consentire ad applicazioni particolari di capire da quale risorsa l'utente ha effettuato l'accesso. I nomi utente sono gestiti dal server su cui risiedono. Il nome del server viene risolto tramite DNS. Un indirizzo di esempio potrebbe essere L'indirizzo del server, venendo risolto tramite DNS, consente a due utenti, residenti su server diversi, di poter comunicare fra loro conoscendo solo i reciproci JID. Se ad esempio Chiara, residente sul server WFserver.it, vuole contattare Roberto, residente su Jivesoftware.org, inserirà come destinatario del messaggio l'indirizzo JID di Roberto. Il server di Chiara prenderà il messaggio e, verificando dal JID di destinazione che l'utente non risiede su quel server, aprirà una comunicazione con il server di Roberto, risolvendo l'indirizzo tramite DNS, a partire dal nome del server contenuto nel JID. Ultima nota positiva riguardo il protocollo XMPP è la presenza di librerie di programmazione open source per la sintassi XML del protocollo. Le librerie utilizzate, in particolare, sono realizzate da Jivesoftware e prendono il nome di Smack Wildfire Wildfire è un server open source che implementa il protocollo XMPP. E' interamente scritto in Java, e presenta una attiva comunità di sviluppo. La scelta di questo server è stata dettata dalle sue caratteristiche in prestazioni e dal suo supporto completo alle specifiche del protocollo XMPP. L'installazione e la configurazione del server sono molto semplici e consentono di regolare molti degli aspetti di funzionamento. Fra le configurazioni più importanti rientra la scelta del sistema di database management. E' infatti possibile scegliere di usare un DBMS integrato in Wildfire, o fornire i dati per il collegamento ad un DBMS esterno. Progettazione del SGPI 81

82 Una comoda console di amministrazione, con interfaccia web, permette di gestire gli utenti del server (a cui è associato un account). In aggiunta è possibile definire dei roster predefiniti per gli utenti, e dei gruppi in cui organizzare più utenti. Altra interessante opzione è la possibilità di scegliere la conservazione di messaggi inviati a destinatari off-line, garantendo la consegna del messaggio. La struttura dati utilizzata da Wildfire (dettata dalle specifiche di XMPP) è mostrata in Figura 4.2. Figura Struttura dati gestita da Wildfire La possibilità più interessante offerta da Wildfire è forse il meccanismo di aggiunta di funzionalità personalizzate. Tramite un sistema a plug-in è infatti possibile definire dei moduli applicativi aggiuntivi. Questi moduli possono essere sviluppati adottando le librerie di programmazione di Wildfire. L'inserimento nel server avviene tramite una particolare procedura in cui i moduli aggiuntivi vengono trattati come librerie jar. I moduli aggiuntivi possono avere grandi potenzialità, ad esempio, possono ridefinire i meccanismi di routing dei messaggi. Progettazione del SGPI 82

83 4.2 Architettura del sistema L'architettura del sistema è basata sull'affermato paradigma client-server. Il server centrale offre una serie di funzionalità e i client sfruttano tali funzionalità per la risoluzione di particolari problemi. E' tuttavia scorretto considerare il sistema funzionante a tutti gli effettisecondo il modello client-server. Analizzando con attenzione l'architettura, è facile rendersi conto di come alcuni client svolgano il ruolo di server per altri client. E' dunque conveniente affermare che il sistema adoperi tale paradigma, purché si immagini il server come punto di accesso per le funzioni offerte dalle altre componenti. Tutte le comunicazioni fra componenti passano infatti attraverso il server, realizzato tramite Wildfire. Si viene quindi a creare un punto centrale di smistamento dei dati, che consente una gestione monitorata di tutti i flussi dati in transito nel sistema. E' chiaro che tale soluzione presenta lo svantaggio di problemi in prestazioni, quando un numero considerevole di dati deve essere processato. Una stima sulla capacità di gestire connessioni simultanee di Wildfire, compiuta da Jivesoftware, ha dato un risultato di circa connessioni simultanee gestite senza risentimenti sulle prestazioni. Ulteriori test hanno dimostrato che le prestazioni rimangono buone anche in presenza di / connessioni simultanee, se non si considera l'allungamento dei tempi necessari all'autenticazione degli utenti da parte del sistema (operazione necessaria solo durante il login al sistema). Sebbene il punto centrale di smistamento dati sia quindi unico, è possibile gestire buone quantità di dati senza eccessivi problemi. In aggiunta a quanto detto, Wildfire supporta anche la comunicazione fra server, è quindi possibile immaginare di replicare più server per supportare carichi di lavoro maggiori. La schema di comunicazione fra le componenti è presentato in Figura 4.3. Progettazione del SGPI 83

84 Figura Schema di comunicazione fra le componenti distribuite del SGPI Chiariti gli aspetti alla base dell'organizzazione architetturali delle componenti, analizziamo ora le componenti stesse del sistema. E' possibile individuare tre principali componenti: Data Management Server (DMS) Remote Hardware Manager (RHM) Application interface Data Management Server Il Data Management Server è il componente centrale dell'architettura. E' questo il punto di smistamento dei dati, nonché il componente che garantisce l'accesso all'amministrazione dell'intero sistema. La sua realizzazione è stata effettuata ampliando le funzionalità offerte da Wildfire. Tramite la definizione di appositi plug-in si sono infatti definite logiche di routing ed elaborazioni necessarie allo sviluppo del SGPI Remote Hardware Manager Il Remote Hardware Manager ha il compito di interfacciarsi con l'hardware e di gestire dei semplici meccanismi di filtraggio ed elaborazione. Progettazione del SGPI 84

85 E' un componente che risiede localmente al dispositivo con cui è in comunicazione. L'intera realizzazione è stata effettuata utilizzando il linguaggio Java e le librerie Smack per gestire la sintassi XML del protocollo XMPP Application interface L'Application interface è il componente che ha il compito di integrarsi con le applicazioni di business per permettere l'utilizzo delle funzionalità del sistema. Anche questo componente è realizzato in Java, utilizzando le librerie Smack. In Figura 4.4 è presentata l'architettura del SGPI. Le frecce dell'illustrazione rappresentano il senso del flusso dati all'interno del sistema e fra le sue componenti. Figura Architettura del SGPI Progettazione del SGPI 85

86 4.3 Protocollo interno di comunicazione Per gestire le comunicazioni fra le componenti del sistema è stato necessario definire un protocollo di comunicazione, che estendesse XMPP, a cui è stato dato il nome di MP. Tutte le funzionalità legate alla gestione dei dispositivi ed all'utilizzo di aspetti specifici del sistema richiedono, infatti, appositi comandi per essere utilizzate. Il protocollo nasce come estensione di XMPP. Nulla vieta, in futuro, di aggiungere ulteriori caratteristiche al protocollo per estenderne ulteriormente le sue funzionalità. Le comunicazioni regolamentate, a questo punto dello sviluppo del SGPI, riguardano fondamentalmente la gestione della richiesta dati e del loro invio alle applicazioni richiedenti. A tale scopo sono stati definiti quattro tipi base di messaggi: Single Request Continue Request Stop Request Info Message Questi messaggi consentono di richiedere le letture effettuate da un dispositivo gestito da un RHM e di trasportare in modo strutturato le informazioni lette. Per favorire l'utilizzo dei messaggi del protocollo MP, è stata implementata una libreria di programmazione che contenesse funzioni utili alla definizione dei messaggi, al loro popolamento con le informazioni raccolte e all'estrapolazione di queste stesse informazioni da un messaggio. Un diagramma delle classi, di questa libreria, è mostrato in Figura 4.5. Progettazione del SGPI 86

87 Figura Class Diagram della libreria di programmazione per il protocollo MP Oltre ai sopracitati messaggi, ne sono stati definiti ulteriori, per supportare la gestione del sistema di filtraggio ed elaborazione di alto livello. La definizione di messaggi, elaborati da appositi plug-in, per la gestione di filtri e politiche di elaborazione è una delle possibilità di amministrazione remota offerte dal sistema. Il funzionamento di questi processi sarà chiarito nei successivi paragrafi, quando si tratterà in modo più approfondito del DMS. E' bene sottolineare che MP, essendo definito in seno ad XMPP, è strettamente dipendente da questo protocollo, o meglio, ne è parte integrante. MP, infatti, definisce i suoi messaggi come estensione dei messaggi di XMPP. Questo procedimento assicura che lo stesso MP sia estensibile, così come il protocollo di cui è a sua volta estensione. Lo stack protocollare così formatosi è rappresentato in Figura 4.6. Figura Pila dei protocolli utilizzati dal sistema Progettazione del SGPI 87

88 4.4 Progettazione del Remote Hardware Manager Architettura Figura Architettura del RHM Il Remote Hardware Manager ha come primo compito la gestione dei dispositivi. Dovendo garantire il supporto ad un hardware eterogeneo, è necessario compiere dei processi di astrazione. L'astrazione si rende necessaria poiché le applicazioni non possono interessarsi di ogni differente dispositivo hardware, ma devono comunicare con un'interfaccia unica. L'interfaccia unica è proprio quella offerta dal RHM, che si assume, poi, tutte le responsabilità per la corrispondenza fra l'interfaccia unica, astratta, e l'interfaccia reale del dispositivo. Questa corrispondenza è garantita dall'utilizzo di driver. Il termine driver, ossia guidatore, rende appieno l'idea del ruolo svolto. Se immaginiamo il dispositivo come un mezzo di trasporto (una automobile o un camion ad esempio), il driver corrisponde al suo conducente. Per un'azienda di trasporti, il modo di comunicare la destinazione di un carico al conducente non varia, sia se quest'ultimo guidi un camion di grandi dimensioni che un furgone poco più grande di una normale vettura. Evidentemente il modo di condurre i due mezzi è differente, ma è il conducente che si fa carico guidare il mezzo, non l'azienda. Progettazione del SGPI 88

89 Allo stesso modo, il driver dialoga con il dispositivo, fornendo al RHM sempre un'interfaccia unica di comunicazione. Interfaccia che viene poi, tramite altre elaborazioni, ulteriormente astratta per essere offerta alle applicazioni. Questo comodo meccanismo consente di utilizzare qualsiasi dispositivo di identificazione, purché sia disponibile il driver adatto. I dati raccolti dal driver entrano in un sistema di filtri organizzato secondo il modello pipe and filter. Il modello prevede una serie di filtri collegati in cascata: l'uscita di un filtro è l'ingresso per il filtro successivo. L'architettura del RHM prevede che sia possibile inserire sempre nuovi filtri, in modo da gestire delle particolari logiche di business. Chiaramente se uno qualsiasi dei filtri non viene superato, l'informazione raccolta viene scartata. Questo meccanismo è stato pensato per garantire un supporto ai sistemi che richiedono il controllo solo di particolari informazioni. In aggiunta, è possibile utilizzare i filtri per eliminare informazioni provenienti ad esempio da letture duplicate. I dati che hanno passato i filtri vengono analizzati dal successivo componente dell'architettura, Raw elaborations, che contiene dei semplici processi elaborativi. Allo stato attuale la sola funzione di questo componente è quella di decidere la destinazione dei dati raccolti, in base ad alcune impostazioni definite dall'esterno. E' possibile ipotizzare, in successive modifiche, l'aggiunta di supporti per elaborazioni dei dati che comprendano, ad esempio, l'archiviazione di questi in database o altre funzioni. L'impostazione delle politiche che consentono di definire la destinazione dei dati è ottenuta tramite il protocollo MP. Dopo aver definito la destinazione, i dati sono pronti ad essere inviati tramite il protocollo MP e Wildfire. Progettazione del SGPI 89

90 Il componente Event thrower ha la responsabilità di prendere i dati e la destinazione impostata da Raw Elaborations per poi prepararli all'invio. In particolare, l'event thrower si occupa di creare il messaggio secondo il protocollo MP, di popolarlo con i dati raccolti e di inoltrarlo al server Wildfire L'ultimo componente del RHM, il Configuration Command Listener, ascolta il canale di comunicazione con Wildfire. Qualora dovesse ricevere messaggi formattati secondo il protocollo MP, li interpreta e ne estrae i comandi contenuti. Tali comandi possono servire ad impostare le politiche di filtraggio o a comunicare le politiche per gestire la destinazione dei dati Implementazione L'implementazione del RHM è praticamente completa, ad esclusione del sistema per l'aggiunta dinamica di filtri, basato su plug-in. In Figura 4.8 è rappresentato il diagramma delle classi che realizzano il RHM. Figura Diagramma delle classi che implementano il RHM Progettazione del SGPI 90

91 Fra le caratteristiche degne di nota, possiamo segnalare la presenza delle classi EventThrower e ConfigurationCommandListener, che implementano i rispettivi componenti descritti nell'architettura. Entrambe le classi utilizzano le funzioni messe a disposizione dalla libreria che implementa il protocollo MP. Sono queste le classi che hanno il compito di comunicare con il server WILDFIRE, gestendo il canale di comunicazione e i messaggi che su questo viaggiano, in particolare, l'eventthrower inoltra i messaggi sul canale, il ConfigurationCommandListener ascolta il canale per raccogliere i messaggi destinati al RHM. L'interfaccia driver realizza l'astrazione dell'interfaccia del dispositivo. Il driver del dispositivo deve implementare l'interfaccia driver per essere riconosciuto ed usato dal RHM. Quest'interfaccia, assieme all'interfaccia DeviceListener, realizza il design pattern Observer. In questo modo, alla lettura di informazioni da parte del dispositivo, le altre classi del componente, registrate come DeviceListener, vengono informate dell'avvenuto evento e possono operare di conseguenza. L'interfaccia RawFilter deve essere implementata dalle classi che intendono realizzare un filtro per il RHM. La gestione del sistema di filtri è realizzata dalla classe RHMclient, tramite un semplice vettore che raccoglie i filtri da applicare ai dati. Le seguenti righe di codice mostrano la realizzazione del meccanismo di filtraggio: Progettazione del SGPI 91

92 Interfaccia RawFilter: public interface RawFilter { public String filter(string data); } Parte del codice della classe RHMclient che implementa il filtraggio: 1. private Vector filters = new Vector(0); [...] public void processiddata(string data){ [...] Iterator it = this.filters.iterator(); 10. while(it.hasnext()){ 11. RawFilter rawfilter = (RawFilter)it.next(); 12. data = rawfilter.filter(data); 13. } if(data==null) 16. return; [...] } In sostanza, la funzione filter del RawFilter restituisce i dati senza modifiche se superano il filtro, altrimenti resistuisce null. Tutti i filtri sono contenuti nel vettore filters (Riga 1). Scorrendo il vettore, viene chiamata la funzione filter per ogni filtro (Righe 10-13). Se al termine del procedimento la stringa contenente i dati è nulla, la funzione non invia i dati al EventThrower (Righe 15,16). La classe RHMclient contiene anche funzioni per aggiungere o eliminare filtri in modo dinamico. Nelle illustrazioni che seguono sono presentate alcune dinamiche di funzionamento del componente. Progettazione del SGPI 92

93 Figura Ricezione di informazioni dal dispositivo e invio al sistema La Figura 4.9 mostra il procedimento che permette l'invio di informazioni al sistema. Il driver fa un continuo ciclo di sondaggio sul dispositivo alla ricerca di nuove letture di informazioni. Quando queste vengono rilevate, viene generato un DeviceEvent che è ricevuto dalla classe RHMclient. In questa classe vengono risolte le logiche di elaborazione, che consentono di definire i destinatari delle informazioni raccolte, e vengono filtrati i dati tramite l'utilizzo dei filtri definiti dall'utente. Il destinatario e le informazioni filtrate sono passate alla classe EventThrower per essere incapsulate in un messaggio e inviate sul canale di comunicazione. La successione di eventi che avvengono in seguito alla ricezione di comandi di configurazione dal canale di comunicazione è mostrata in Figura Figura Ricezione di comandi di configurazione da remoto Progettazione del SGPI 93

94 La classe ConfigurationCommandListener non fa altro che attendere che giungano messaggi dal canale di comunicazione con Wildfire. Quando questo avviene, il messaggio ricevuto viene analizzato per estrapolare i comandi che seguono il protocollo di comunicazione MP. A seconda del comando viene chiamata un'opportuna funzione sulla classe RHMclient. 4.5 Progettazione del Data Management Server Il DMS è il fulcro dell'intero sistema. La realizzazione del DMS è ottenuta in larga parte con l'utilizzo di Wildfire. Il server realizzato da Jivesoftware è infatti in grado di assolvere molteplici dei compiti necessari al SGPI. Fra questi ricordiamo la gestione dell'accesso autenticato e il routing dei messaggi in base all'identificativo utente (l'indirizzo JID). L'implementazione di logiche aggiuntive è stata ottenuta sfruttando il meccanismo di plug-in messo a disposizione da WILDFIRE. Le logiche aggiuntive sono necessarie per un duplice motivo. Innanzitutto per l'implementazione di filtri e politiche di elaborazione di alto livello, in secondo luogo per gestire la configurazione di componenti aggiuntivi, siano questi veri e propri componenti per l'elaborazione di dati o console remote di amministrazione, o altri tipi ancora di componenti. Questa è la parte del sistema che richiede ancora il maggior impegno per uno sviluppo completo. Progettazione del SGPI 94

95 4.5.1 Architettura del sistema a plug-in L'architettura del sistema a plug-in di Wildfire ricalca il modello pipe and filter di cui si è discusso in precedenza in questo capitolo. (Figura 4.11). Figura Architettura del sistema a plug-in di Wildfire E' possibile immaginare i plug-in di Wildfire come delle componenti che si innestano sul normale flusso dati interno al server. Ogni plug-in ha modi differenti di porsi nei confronti del flusso dati. Una delle possibili configurazioni è registrare il plug-in come packet interceptor. Questa operazione non fa altro che includere il plug-in in un vettore gestito da Wildfire. Alla ricezione di un nuovo messaggio (un packet) il server, prima di effettuarne il routing, richiama una particolare funzione dell'interfaccia PacketInterceptor, utilizzata dai plug-in, scorrendo l'intero vettore. Il risultato è che il messaggio viene processato da tutti i plug-in che possono cambiarne totalmente il contenuto. In questo modo è possibile definire particolari protocolli di comunicazione. E' infatti possibile cambiare oltre al contenuto del messaggio, tutti i campi che lo compongono, compreso l'indirizzo JID del destinatario. La grande flessibilità dei plug-in consente di definire intere nuove applicazioni in aggiunta a Wildfire. Nulla impedisce, infatti, di creare un plug-in che instauri un canale di comunicazione con un ulteriore componente esterno, come ad esempio un DBMS. Progettazione del SGPI 95

96 Sfruttando queste potenzialità è stato possibile sviluppare un semplice sistema di elaborazione che consentisse, in base alle richieste dell'amministratore di sistema, di mantenere traccia dei dati di identificazione in passaggio per il server, memorizzandoli in un database Implementazione del plug-in Logger L'applicazione sviluppata ha permesso di mostrare parte delle potenzialità del SGPI per quanto riguarda l'estensibilità. Si è creato dunque un meccanismo che permettesse, ad un amministratore di sistema, di selezionare i dispositivi di cui memorizzare il traffico di dati. L'amministratore, con una semplice interfaccia grafica, può accedere alle funzioni del plug-in. Per rendere possibile lo sfruttamento delle funzionalità dell'applicazione, è stato innanzitutto necessario ampliare il protocollo MP con messaggi utili per indicare di quali dispositivi memorizzare il traffico dati. Il funzionamento è molto semplice: se un messaggio contenente dati di identificazione proviene da un RHM (e quindi da un dispositivo) è incluso nella lista dei flussi dati da archiviare, viene esaminato e ne vengono estratte le informazioni contenute che sono inviate al database. Il messaggio prosegue, poi, il suo normale percorso. Per impostare i dispositivi di cui archiviare il traffico dati si utilizzano particolari messaggi che vengono riconosciuti ed interpretati dall'applicazione, anche se non contengono informazioni di identificazione. In Figura 4.12 è mostrato il diagramma delle classi del plug-in. Progettazione del SGPI 96

97 Illustrazione 1: Figura Diagramma delle classi del plug-in "Logger" Come per la realizzazione del RHM, il plug-in utilizza dei filtri per capire se il messaggio contiene informazioni utili. I filtri definiti sono due: ProtocolFilter e FromFilter. Il primo ha il compito di verificare che il messaggio sia conforme al protocollo MP, il secondo verifica se la sorgente del messaggio rientra nella lista delle sorgenti di cui archiviare i dati. La classe DBManager ha il solo compito di fare da interfaccia con il DBMS. All'arrivo di un messaggio, la classe LoggerPlugin interroga prima il ProtocolFilter e poi il FromFilter, per comprendere l'azione da intraprendere. Se il messaggio supera entrambi i filtri, vengono estratte le informazioni contenute e passate alla classe DBManager che si occuperà di archiviarlo tramite il DBMS. (Figura 4.13). Figura Dinamica di funzionamento del plug-in "Logger" Progettazione del SGPI 97

98 I messaggi che consentono di impostare le sorgenti dati di cui memorizzare il traffico sono in grado di superare il ProtocolFilter. Quando giungono nel FromFilter, vengono riconosciuti come comandi di configurazione e la lista contenente le sorgenti viene opportunamente aggiornata. In questo plug-in è stato utilizzato il DBMS MySQL, ma nulla vieta l'utilizzo di altri DBMS, semplicemente cambiando le impostazioni di configurazione del plug-in stesso. 4.6 Progettazione della Application Interface L'Application Interface è il componente del sistema che permette alle applicazioni che lo utilizzano di accedere ai servizi offerti. Attualmente è possibile utilizzare questo componente solo tramite librerie di programmazione Java. E' tuttavia possibile estendere le interfacce di comunicazione senza eccessive difficoltà. L'Application Interface non è altro che un client del server Wildfire. Implementa quindi il protocollo XMPP e apposite funzioni per richiamare i servizi delle altre componenti del sistema, oltre a fornire ulteriori funzionalità per semplificare l'utilizzo del SGPI alle applicazioni di business Architettura L'Application Interface deve occuparsi principalmente di: Gestione dello stato interno per l'utilizzo delle funzioni del SGPI Offrire meccanismi per ottenere lo stato Gestione della comunicazione con WILDFIRE Progettazione del SGPI 98

99 E' auspicabile che l'interfaccia verso le business application sia unica, e, quindi, che sia presente un unico componente che collabori con le business application. Poiché la gestione della comunicazione è isolabile dalla gestione dello stato, si è scelto di dividere questi aspetti, distribuendo le responsabilità fra più componenti. Si delinea una struttura come quella rappresentata in Figura Figura Architettura del componente Application Interface Tale struttura identifica nel gestore delle comunicazioni tutte le responsabilità riguardanti la comunicazione con la rete esterna. Il gestore dello stato ha la duplice responsabilità di gestire lo stato e di renderlo disponibile alle applicazioni di business. Nei successivi paragrafi verrà chiarito cosa si intende per stato e come è stato implementato quanto mostrato precedentemente. Progettazione del SGPI 99

100 4.6.2 Implementazione Gestione dello stato Lo stato del Application Interface è dato dalle seguenti informazioni: stato della connessione lista contatti contatti online cronologia breve dei messaggi scambiati con i contatti E' bene specificare che un contatto rappresenta un'entità connessa a WILDFIRE identificata tramite un indirizzo JID. Nei contatti rientrano quindi gli RHM connessi al sistema a cui l'application Interface ha richiesto la sottoscrizione 1. La cronologia breve è una funzionalità aggiuntiva introdotta per offrire, alle applicazioni di business, un metodo di monitoraggio dello scambio di informazioni con le entità remote. La gestione dello stato è sufficientemente complessa da giustificare l'utilizzo di più classi. In particolare le classi principali individuate sono: ContactList, Contact e Chronology. Un oggetto ContactList contiene più oggetti Contact. Un oggetto Contact contiene un oggetto Chronology e le informazioni sulla presenza del contatto. E' possibile immaginare anche la necessità di gestire più ContactList, in quel caso, sarà possibile istanziare più oggetti di tale tipo. Una necessità del genere può presentarsi se, ad esempio, una applicazione vuole gestire in modo separato due liste di dispositivi. 1 Ricordiamo che la sottoscrizione è il procedimento necessario ad un utente per vedere lo stato di presenza di un altro utente Progettazione del SGPI 100

101 La gestione dello stato della connessione è assegnata ad una classe che conterrà a sua volta le istanze di ContactList e che chiameremo Client. La struttura dati delineatasi è raffigurata in Figura Figura Struttura dati del Application Interface La classe Client si occuperà di offrire le interfacce verso le business application e comunicherà con il gestore delle comunicazioni, che verrà trattato in seguito Gestione degli eventi L'Application Interface deve garantire un meccanismo per generare eventi, che saranno poi consumati dalle applicazioni di business, quando, ad esempio, si riceve un messaggio. Il meccanismo utilizzato è ancora una volta quello del design pattern Observer. La realizzazione è ottenuta mediante la creazione di tre entità: CoreEventListener CoreEventThrower CoreEvent Il nome delle entità deriva dall'aspetto centrale che occupa l'application Interface per una applicazione di business che fa uso del SGPI. Progettazione del SGPI 101

102 Il CoreEventListner è un'interfaccia che deve essere implementata da quelle classi che intendono ascoltare gli eventi CoreEvent. Questa interfaccia contiene la sola funzione processcoreevent. L'interfaccia CoreEventThrower deve invece essere implementata dalle classi che devono notificare un evento. Questa interfaccia contiene funzioni per gestire una lista di CoreEventListener. Quando deve essere notificato un evento, il CoreEventThrower non fa altro che richiamare la funzione processcoreevent di tutti i CoreEventListener che ha nella lista. La classe CoreEvent rappresenta l'evento, che è generato dal CoreEventThrower e scambiato come argomento nella funzione processcoreevent. Da quanto detto è chiaro che un evento deve essere generato quando cambia lo stato, quindi, quando viene modificata una delle informazioni precedentemente specificate. Poiché la gestione dello stato è stata risolta tramite la suddivisione delle informazioni da gestire fra più oggetti, sorge il problema di individuare chi debba generare un evento e come tale evento debba essere comunicato all'esterno del componente. Figura Esempio di ricezione messaggio A titolo d'esempio consideriamo il caso in cui il CommunicationManager(Gestore delle Comunicazioni) riceve un messaggio M1 dalla rete (Figura 4.16). Progettazione del SGPI 102

103 (Messaggio 1) M1 sarà passato al gestore dello stato (Client). (Messaggi da 2 a 7) Il Client dovrà aggiungere M1 alla cronologia dei messaggi scambiati col mittente di M1. Poiché la cronologia è contenuta nel Contact, il Contact a sua volta è contenuto nella ContactList, è necessario far riferimento a più oggetti per giungere all'aggiornamento della cronologia. (Messaggio 8) Una volta che il Client ha ricevuto il riferimento alla cronologia specifica, aggiorna il suo stato. A questo punto sorge il problema: la notifica dell'evento è responsabilità del Client o della Chronology che è la vera entità che vede modificarsi il suo stato? Le soluzioni esaminate sono tre: Soluzione 1: l'oggetto che cambia il suo stato genera l'evento. Il problema principale in questo caso è nella necessità di ogni osservatore di registrarsi ad ogni oggetto che mantiene parte dello stato del Application Interface. Inoltre, gli oggetti che mantengono lo stato dovrebbero preoccuparsi di gestire le liste di osservatori. E' quindi una soluzione inefficiente. Soluzione 2: il Client è osservatore unico e sempre in ascolto degli stati degli oggetti che gestisce. Soluzione 3: Il Client prevede il cambiamento di stato. In sostanza, viene generato l'evento di notifica di cambiamento dopo aver richiesto l'aggiornamento dello stato. Tale richiesta avviene a seguito della ricezione di un messaggio ricevuto dal CommunicationManager che richiede il cambiamento di stato di uno degli oggetti gestisti dal Client. Si parla di previsione perché l'evento di variazione dello stato è generato senza ottenere una conferma dall'effettivo avvenimento del cambiamento. Progettazione del SGPI 103

104 Si decide di adoperare la Soluzione3, poiché la previsione del Client non è un'attività soggetta ad errori. Il cambiamento dello stato è infatti gestito unicamente dal Client stesso, senza possibilità che altre entità esterne agiscano sullo stato di un oggetto gestito dal Client. Tutte le attività di gestione dello stato non richiedono inoltre accesso a sistemi esterni, e, dunque, non si presenta il rischio di fallimenti. Infine, tale soluzione non aumenta la complessità del componente Gestione delle comunicazioni Come specificato in precedenza, la gestione della comunicazione avviene tramite un'entità apposita: il gestore della comunicazione che trova realizzazione nell'interfaccia CommunicationManager. Tale entità ha i compiti di: 1. ricevere informazioni dalla rete e tradurle in cambiamenti di stato o richieste per il Client; 2. ricevere richieste dal Client ed inviarle alla rete come richiesto dai protocolli di comunicazione XMPP e MP. Alla ricezione di un messaggio dalla rete, il CommunicationManager chiama le funzioni opportune del Client. Poiché l'accesso al gestore delle comunicazioni avviene, da parte delle business application, sempre tramite il Client, è necessario che quest'ultimo abbia operazioni che consentano l'accesso alle funzioni del CommunicationManager. A tale scopo, si definisce un'interfaccia CommunicationOperations che contiene tutte le operazioni utili alla comunicazione con la rete, e che viene implementata dal CommunicationManager e dal Client.(In Figura 4.18 è mostrata la struttura delle classi). Progettazione del SGPI 104

105 Problematiche di concorrenza L'applicazione presenta un doppio flusso di controllo, infatti, un comando può giungere dall'eventmanager a seguito di un input dall'utente, o dal server WILDFIRE, tramite comunicazione remota. Tale aspetto non crea un effettivo problema nella gestione dello stato interno dell'applicazione, poiché le informazioni trattate non presentano problematiche di consistenza e poiché un cambiamento viene in ogni caso notificato, generando quindi immediatamente una nuova lettura dello stato. E' tuttavia necessario gestire la modalità di notifica di cambiamento e l'aggiunta o eliminazione di Listener, infatti, potrebbe verificarsi un problema di modifica del vettore contenente i Listener, mentre quest'ultimo viene esaminato per generare la notifica. La gestione viene effettuata definendo tre tipologie di Thread: ListenerWriter, ListenerRemover, CoreEventNotifier. Quando è necessario eseguire un'operazione di aggiunta o eliminazione Listener, o di notifica di un CoreEvent, la funzione è eseguita dallo specifico Thread. Le tre distinte operazioni sono in mutua esclusione (Ottenuta tramite un semaforo) Diagramma delle classi In Figura 4.17 sono rappresentate le classi per l'implementazione del pattern Observer. Figura Classi del Application Interface che implementano il pattern Observer L'intero diagramma delle classi che realizzano il componente Application Interface è rappresentato in Figura Progettazione del SGPI 105

106 Figura Diagramma delle classi del Application Interface Progettazione del SGPI 106

107 Dinamica delle operazioni Nel seguito sono mostrate alcune delle dinamiche che interessano le classi dell'application Interface per la realizzazione delle funzioni del componente. Figura Dinamica dell'operazione di avvio In Figura 4.19 è mostrata la sequenza di operazioni necessarie all'avvio dell'application Interface. La business application istanzia un oggetto della classe Client, che sarà il centro dell'intera Application Interface. Il Client crea a sua volta il Communicator che gestisce le comunicazioni con Wildfire. Quando viene avviata, su comando dell'applicazione di business, la connessione al sistema, il Client chiede al Communicator di avviare la sequenza di connessione. Sempre il Communicator, si fa carico di ricevere i messaggi riguardanti il roster, provenienti da Wildfire, e di aggiornare il corrispondente stato del Client. A seguito di ogni cambiamento di stato, il Client genera eventi di notifica. Progettazione del SGPI 107

108 FIgura Dinamica dell'operazione di aggiunta contatto In Figura 4.20 è evidenziata la sequenza che porta alla creazione di un nuovo contatto, e, quindi, all'aggiornamento dello stato del componente. Nel caso dell'avvio, si è infatti omesso quanto avviene per aggiungere un contatto fra quelli gestiti dall'application Interface. La dinamica dell'operazione è una chiara conseguenza del modo in cui si è deciso di gestire queste informazioni. Quando Wildfire informa della presenza di un nuovo contatto sul Roster, il Communicator raccoglie il messaggio e richiama una apposita funzione di aggiunta contatto sul Client. Quest'ultimo fa riferimento alla ContactList da lui gestita, chiedendo a sua volta l'aggiunta di un contatto. La ContactList crea dunque un nuovo oggetto Contact, che a sua volta crea un nuovo oggetto Chronology. Progettazione del SGPI 108

109 Conclusioni La gestione dei processi di identificazione è un campo molto complesso, che richiede uno sforzo congiunto di più discipline. Questo lavoro ha inteso offrire un prodotto software che potesse in qualche modo semplificare le attività di quanti operano in questo settore. Lo sviluppo del sistema è tuttavia ancora in uno stato embrionale. Per quanto siano stati definiti i meccanismi di comunicazione e le basi dell'architettura, ancora molto è il lavoro da fare prima di poter definire il SGPI completo. Quanto progettato è infatti solo la base di un sistema, che, se vuole trovare spazio in applicazioni del settore, deve sviluppare solidi meccanismi che garantiscano sicurezza ed affidabilità. Nonostante queste limitazioni, va comunque sottolineato come gli obiettivi di base preposti alla creazione del sistema siano stati raggiunti. I requisiti funzionali, esaminati nei primi capitoli di questo testo, sono stati in larga parte soddisfatti, fornendo un prodotto agile e facilmente estendibile. Per quanto incompleto, il SGPI proposto è, quindi, un ottimo punto di partenza per lo sviluppo di sistemi più complessi e con specifiche più restrittive. Conclusioni 109

110 Appendice A Analisi dei requisiti Partendo dalle responsabilità individuate nel Capitolo I, sono stati ricavati i requisiti a cui deve rispondere un SGPI. I requisiti sono suddivisi in funzionali e non funzionali, a seconda che il requisito sia una funzionalità che deve presentare il software, o una caratteristica di progetto o di prestazioni. Requisiti Funzionali Sono nel seguito elencate tutte le funzioni che dovrà rendere disponibile un SGPI. I requisiti sono raggruppati in categorie distinte per chiarire i vari livelli a cui opera il sistema. Ogni requisito è esposto in modo da evidenziarne gli input, gli output e le elaborazioni che comporta, oltre ai dati che devono essere immagazzinati. Gestione Hardware R-gh1 Nome: Attivazione dispositivo Input: Dispositivo da attivare Codice di autenticazione Dati di attivazione Output: Conferma di attivazione Dati Immagazzinati: Log della richiesta di attivazione (provenienza della richiesta, data e ora) Elaborazioni: Descrizione: Il sistema attiva il dispositivo e rende noto il suo cambiamento di stato. E' la funzione tramite cui viene attivato un dispositivo collegato al SGPI, i dati passati servono a configurare la modalità di funzionamento del dispositivo. Appendice A Analisi dei requisiti 110

111 R-gh2 Nome: Disattivazione dispositivo Input: Dispositivo da disattivare Codice di autenticazione Output: Conferma di disattivazione Dati Immagazzinati: Log della richiesta di disattivazione (provenienza della richiesta, data e ora) Elaborazioni: Descrizione: Il sistema disattiva il dispositivo e rende noto il suo cambiamento di stato. E' la funzione tramite cui viene disattivato un dispositivo collegato al SGPI. R-gh3 Nome: Recupero stato dispositivo Input: Dispositivo Codice di autenticazione Output: Stato del dispositivo Dati Immagazzinati: - Elaborazioni: Descrizione: Il sistema interroga il gestore del dispositivo per verificarne lo stato E' la funzione tramite cui viene fornito lo stato di un particolare dispositivo. R-gh4 Nome: Ricevimento lettura del dispositivo Input: Dati letti Output: - Dati Immagazzinati: Il codice EPC letto, il timestamp della lettura, il reader che ha effettuato la lettura Elaborazioni: Descrizione: Il sistema riceve i dati letti dal dispositivo e li invia al sistema di filtri e instradamento per poi memorizzarli. E' la funzione tramite cui il dispositivo fornisce i dati letti. R-gh5 Nome: Scrittura su TAG Input: Dispositivo Dati da scrivere Output: Conferma scrittura Dati Immagazzinati: Log della scrittura (provenienza, dati scritti, data) Elaborazioni: Descrizione: Il sistema comunica al dispositivo di scrivere i dati in input sul TAG. E' la funzione tramite cui vengono scritti dei dati su di un TAG. Appendice A Analisi dei requisiti 111

112 Recupero Dati R-rd1 Nome: Ascolto letture dispositivo Input: Dispositivo Codice di autenticazione Output: Letture effettuate dal dispositivo dall'arrivo della richiesta in poi. Dati Immagazzinati: Log della richiesta di ascolto (provenienza della richiesta, data e ora) Elaborazioni: Descrizione: Il sistema raccoglie le letture del dispositivo e le invia al richiedente. Permette di recuperare i dati in lettura da un dispositivo. R-rd2 Nome: Interruzione ascolto letture dispositivo Input: Dispositivo Output: - Dati Immagazzinati: Log della richiesta di fine ascolto (provenienza della richiesta, data e ora) Elaborazioni: Descrizione: Termina l'invio dei dati letti dal dispositivo. R-rd3 Nome: Recupero letture effettuate Input: Dispositivo Dati della richiesta di recupero Output: Le letture effettuate corrispondenti ai criteri forniti con i dati della richiesta Dati Immagazzinati: Log della richiesta di recupero (provenienza della richiesta, data e ora) Elaborazioni: Descrizione: Il sistema esegue una query sul database che raccoglie le letture. Consente di recuperare le letture presenti nel database del sistema corrispondenti ai vincoli forniti assieme alla richiest R-rd4 Nome: Richiesta di aggregazione dati Input: EPC del TAG di cui si vogliono aggregare i dati Output: I dati aggregati Dati Immagazzinati: Log della richiesta di aggregazione (provenienza della richiesta, data e ora) Elaborazioni: Descrizione: Il sistema esegue una ricerca tramite ONS, e recupera dal EPCIs specifico le informazioni di cui necessita. Permette di recuperare i dati aggiuntivi presenti su di un EPCIs in riferimento al TAG fornito in input. Appendice A Analisi dei requisiti 112

113 Instradamento Dati R-id1 Nome: Specifica filtro sul dispositivo Input: Dispositivo Tipo di filtro Output: - Dati Immagazzinati: Log della creazione del filtro (provenienza della richiesta, data e ora, tipo) Elaborazioni: Descrizione: Viene inserito un filtro che processa tutte le letture eseguite dal Dispositivo E' la funzione che permette di creare un filtro che selezioni le letture da conservare nel database. Tale filtro agirà sul solo dispositivo specificato. Il filtro potrebbe anche essere temporale, definendo un intervallo di tempo entro il quale scartare determinate letture. Questa ultima opzione consente di annullare gli errori per letture duplicate. R-id2 Nome: Specifica filtro sul EPC Input: Categoria di EPC Tipo di filtro Output: - Dati Immagazzinati: Log della creazione del filtro (provenienza della richiesta, data e ora, tipo) Elaborazioni: Descrizione: Viene inserito un filtro che processa tutte le letture eseguite. E' la funzione che permette di creare un filtro che selezioni le letture da conservare nel database. Tale filtro agirà su di una particolare categoria di EPC. R-id3 Nome: Input: Dispositivo Tipo di politica Output: - Inserimento politiche di instradamento sul dispositivo Dati Immagazzinati: Log della creazione della politica (provenienza della richiesta, data e ora, tipo) Elaborazioni: Descrizione: Viene creata una politica di instradamento per il dispositivo fornito in input E' la funzione che permette di creare una particolare politica di instradamento in riferimento alle letture provenienti dal dispositivo fornito in input. Tale politica consente ad esempio di far pervenire tutte le letture di quel dispositivo ad una particolare applicazione. R-id4 Nome: Inserimento politiche di instradamento sul EPC Input: Categoria di EPC Tipo di politica Output: - Dati Immagazzinati: Log della creazione della politica (provenienza della richiesta, data e ora, tipo) Elaborazioni: Descrizione: Viene creata una politica di instradamento per la categoria di EPC fornita in input E' la funzione che permette di creare una particolare politica di instradamento in riferimento alla categoria di EPC. Tale politica consente, ad esempio, di far pervenire ad una applicazione tutte le letture che presentano un EPC appartenente ad una determinata categoria. Appendice A Analisi dei requisiti 113

114 Politiche di automazione R-pa1 Nome: Inserimento di un task Input: Tipo di task Parametri di configurazione Output: - Dati Immagazzinati: Log della creazione del task (provenienza della richiesta, data e ora, tipo) Elaborazioni: Descrizione: Viene creato un task con i parametri forniti in input. E' la funzione che permette di creare un particolare processo di controllo da parte del sistema. Un task può essere di tipo periodico o può verificarsi al riconoscimento di un particolare EPC R-pa2 Nome: Inserimento di una politica di elaborazione Input: Tipo di politica di elaborazione Parametri di configurazione Output: - Dati Immagazzinati: Log della creazione della politica (provenienza della richiesta, data e ora, tipo) Elaborazioni: Descrizione: Viene creata una politica di elaborazione con i parametri forniti in input. E' la funzione che permette di creare una politica di elaborazione. Una politica di elaborazione può prevedere la generazione di un evento di allarme al riconoscimento di un EPC, o per altre cause specificabili fra i parametri di configurazione. Appendice A Analisi dei requisiti 114

115 Requisiti non funzionali Il sistema prevede il trattamento di una grande mole di dati, anche riservati, fra molteplici utenti. Tale caratteristica impone diversi requisiti non funzionali che vengono nel seguito elencati: R-nf1: Scalabilità. Il sistema deve essere scalabile, permettendo l'aggiunta di moduli per il trattamento di maggiori quantità di dati, senza intaccare le prestazioni; R-nf2: Prestazioni. I dati trattati devono finire il loro processo di elaborazioni in tempi nell'ordine dei secondi. R-nf3: Interoperabilità. Deve essere possibile mettere in comunicazione hardware e software eterogenei. R-nf4: Sicurezza. Deve essere garantita la sicurezza dei dati gestiti, tramite meccanismi di autenticazione degli utenti del sistema. R-nf5: Recupero errori. Il sistema dovrebbe essere in grado di rimanere attivo e funzionante anche in presenza di errori. Appendice A Analisi dei requisiti 115

116 Modello dei casi d'uso Il modello dei casi d'uso descrive in modo intuitivo e dettagliato le funzionalità di un software. Ci serviremo di questo modello per illustrare le principali caratteristiche di un SGPI. Identificazione degli attori Attore Dispositivo User Application External Application System Admin Device Admin Descrizione Il generico dispositivo di identificazione (di tecnologia RFID o meno). La generica applicazione che fa uso del middleware. La generica applicazione esterna che interagisce col middleware (EPCIs). L'amministratore del sistema. Il gestore della configurazione dei dispositivi. Identificazione dei casi d'uso C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 C17 Accesso al sistema Disconnessione dal sistema Attivazione dispositivo Disattivazione dispositivo Ascolto stato del dispositivo Fine ascolto stato del dispositivo Cambio stato del dispositivo Ricevimento letture dal dispositivo Scrittura su TAG Ascolto letture dispositivo Interruzione ascolto letture Recupero letture effettuate Richiesta aggregazione dati Creazione filtro Creazione politica d'instradamento Inserimento di un task Inserimento di una politica di elaborazione Appendice A Analisi dei requisiti 116

117 Diagramma dei casi d'uso Figura 5 - Modello dei casi d'uso Appendice A Analisi dei requisiti 117

118 Descrizione dei casi d'uso Accesso al sistema Attori coinvolti: Descrizione: Precondizioni: Flusso di eventi User Application, System Admin, Device Admin L'operazione necessaria ad autenticare un utente del sistema, perchè possa usufruire delle funzionalità messe a disposizione. Nessuna Post-condizioni: L'attore è connesso al sistema Appendice A Analisi dei requisiti 118

119 8.4.2 Disconnessione dal sistema Attori coinvolti: Descrizione: Precondizioni: Flusso di eventi User Application, System Admin, Device Admin L'operazione di disconnessione dal sistema L'attore deve essere connesso al sistema 1. L'Attore invia la richiesta di disconnessione 2. Il sistema disconnette l'attore e registra in un file di log l'avvenuta disconnessione. Post-condizioni: L'attore non è più connesso al sistema Attivazione dispositivo Attori coinvolti: Dispositivo, Device Admin Descrizione: L'operazione con cui il Device Admin attiva un Dispositivo Precondizioni: Il Device Admin deve essere connesso al sistema. Flusso di eventi Post-condizioni: Il Dispositivo diviene attivo Appendice A Analisi dei requisiti 119

120 8.4.4 Disattivazione dispositivo Attori coinvolti: Descrizione: Precondizioni: Flusso di eventi Dispositivo, Device Admin L'operazione con cui il Device Admin disattiva un Dispositivo Il Device Admin deve essere connesso al sistema. Il Dispositivo deve essere attivo Post-condizioni: Il dispositivo non è più attivo Ascolto stato del dispositivo Attori coinvolti: User Application Descrizione: L'operazione con cui una User Application rileva lo stato di un dispositivo Precondizioni: La User Application deve essere connessa al sistema Flusso di eventi Post-condizioni: Il sistema informa la User Application dei cambiamenti di stato del Dispositivo Appendice A Analisi dei requisiti 120

121 8.4.6 Fine ascolto stato del dispositivo Attori coinvolti: Descrizione: Precondizioni: Flusso di eventi User Application L'operazione con cui una User Application smette di rilevare lo stato di un dispositivo La User Application deve essere connessa al sistema e deve essere in ascolto dello stato del dispositivo Post-condizioni: Il sistema non informa più informa la User Application dei cambiamenti di stato del Dispositivo Cambio stato del dispositivo Attori coinvolti: Descrizione: Precondizioni: Flusso di eventi User Application L'operazione con cui una User Application viene informata dei cambiamenti di stato di un dispositivo La User Application deve essere connessa al sistema e deve essere in ascolto dello stato del dispositivo Post-condizioni: - Appendice A Analisi dei requisiti 121

122 8.4.8 Ricevimento letture dal dispositivo Attori coinvolti: Dispositivo Descrizione: L'operazione con cui il dispositivo fornisce i dati letti al sistema Precondizioni: Il Dispositivo deve essere attivo Flusso di eventi Post-condizioni: Scrittura su TAG Attori coinvolti: Descrizione: Precondizioni: Flusso di eventi Dispositivo, User Application L'operazione con cui una User Application invia il comando di scrittura a un Dispositivo Il Dispositivo deve essere attivo La User Application deve essere connessa al sistema Post-condizioni: Il Dispositivo avvia la scrittura su TAG Appendice A Analisi dei requisiti 122

123 Ascolto letture dispositivo Attori coinvolti: Descrizione: Precondizioni: Flusso di eventi User Application L'operazione con cui una User Application comunica al sistema di instradarle le letture di un dispositivo La User Application deve essere connessa al sistema Post-condizioni: Il Sistema instrada le letture del dispositivo verso la User Application Interruzione ascolto letture Attori coinvolti: Descrizione: Precondizioni: Flusso di eventi User Application L'operazione con cui una User Application comunica al sistema di non instradarle più le letture di un dispositivo La User Application deve essere connessa al sistema Post-condizioni: Il Sistema termina di instradare le letture del dispositivo verso la User Application Appendice A Analisi dei requisiti 123

124 Recupero letture effettuate Attori coinvolti: User Application Descrizione: L'operazione con cui una User Application recupera le letture memorizzate nel database del sistema. Precondizioni: La User Application deve essere connessa al sistema Flusso di eventi Post-condizioni: Richiesta aggregazione dati Attori coinvolti: User Application, External Application Descrizione: L'operazione con cui una User Application richiede che siano aggregati i dati per un codice EPC. Precondizioni: La User Application deve essere connessa al sistema Flusso di eventi Post-condizioni: - Appendice A Analisi dei requisiti 124

125 Creazione filtro Attori coinvolti: System Admin Descrizione: L'operazione con cui viene creato un filtro sui dati ottenuti dai dispositivi di identificazione Precondizioni: Il System Admin deve essere connesso al sistema Flusso di eventi Post-condizioni: Il Sistema processa i dati attraverso il nuovo filtro creato Creazione politica d'instradamento Attori coinvolti: Descrizione: Precondizioni: Flusso di eventi System Admin L'operazione con cui viene creata una politica di instradamento sui dati ottenuti dai dispositivi di identificazione Il System Admin deve essere connesso al sistema Post-condizioni: Il Sistema processa i dati secondo la nuova politica di instradamento creata. Appendice A Analisi dei requisiti 125

126 Creazione task Attori coinvolti: System Admin Descrizione: L'operazione con cui viene creato un task Precondizioni: Il System Admin deve essere connesso al sistema Flusso di eventi Post-condizioni: Il Sistema monitora la necessità di eseguire o meno il task Creazione politica di elaborazione Attori coinvolti: System Admin Descrizione: L'operazione con cui viene creata una politica di elaborazione Precondizioni: Il System Admin deve essere connesso al sistema Flusso di eventi Post-condizioni: Il Sistema procede nel suo funzionamento con la nuova politica di elaborazione impostata Appendice A Analisi dei requisiti 126

Un sistema di identificazione basato su tecnologia RFID

Un sistema di identificazione basato su tecnologia RFID tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Stefano Russo correlatore Ch.mo prof. Massimo Ficco candidato Alessandro Ciasullo Matr. 831/166 Obiettivo Progettazione ed implementazione

Dettagli

Un sistema di identificazione basato sulla tecnologia RFID

Un sistema di identificazione basato sulla tecnologia RFID tesi di laurea Un sistema di identificazione basato sulla tecnologia RFID Anno Accademico 2005-2006 relatore Ch.mo prof. Stefano Russo correlatore Ch.mo prof. Massimo Ficco candidato Giacomo Scibelli Matr.

Dettagli

SinerAccess. Sistema integrato per controllo accessi e videosorveglianza. Sviluppo Innovazione Ricerca

SinerAccess. Sistema integrato per controllo accessi e videosorveglianza. Sviluppo Innovazione Ricerca SinerAccess Sistema integrato per controllo accessi e videosorveglianza Sviluppo Innovazione Ricerca Tecnologie RFiD RFId (acronimo di Radio Frequency Identification) è una tecnologia per la identificazione

Dettagli

Costanzo Fabrizio. Facoltà di Ingegneria. La tecnologia RFID : Aspetti di sicurezza. Corso di Laurea in Ingegneria delle Telecomunicazioni

Costanzo Fabrizio. Facoltà di Ingegneria. La tecnologia RFID : Aspetti di sicurezza. Corso di Laurea in Ingegneria delle Telecomunicazioni Facoltà di Ingegneria Corso di Laurea in Ingegneria delle Telecomunicazioni Tesi di Laurea di Primo Livello La tecnologia RFID : Aspetti di sicurezza Laureando: Costanzo Fabrizio Matricola : 801491 Relatore

Dettagli

OmniAccessSuite. Plug-Ins. Ver. 1.3

OmniAccessSuite. Plug-Ins. Ver. 1.3 OmniAccessSuite Plug-Ins Ver. 1.3 Descrizione Prodotto e Plug-Ins OmniAccessSuite OmniAccessSuite rappresenta la soluzione innovativa e modulare per il controllo degli accessi. Il prodotto, sviluppato

Dettagli

La tecnologia RFId nel settore Fashion. Milano, Gennaio 2014

La tecnologia RFId nel settore Fashion. Milano, Gennaio 2014 La tecnologia RFId nel settore Fashion Milano, Gennaio 2014 Eximia: il miglior partner per soluzioni RFId Fondata nel 2003, Eximia è totalmente focalizzata su soluzioni RFId chiavi in mano Coprendo l'intera

Dettagli

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni White paper Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni Panoramica Questo documento analizza il supporto alla programmabilità nell'infrastruttura ACI (Application Centric

Dettagli

Software per la gestione di musei di arte contemporanea1

Software per la gestione di musei di arte contemporanea1 Software per la gestione di musei di arte contemporanea1 Identificativo del progetto: CA Nome documento: System Design(SD) Identificativo del documento: 6 CA_SD_E1_R1 Data del documento: 21/05/2012 Prima

Dettagli

Negozio con RFID. Una soluzione innovativa per l'identificazione dei prodotti. Negozio con RFID. RF:: Radio Frequency ID:: IDentification

Negozio con RFID. Una soluzione innovativa per l'identificazione dei prodotti. Negozio con RFID. RF:: Radio Frequency ID:: IDentification Una soluzione innovativa per l'identificazione dei prodotti RF:: Radio Frequency ID:: IDentification Ha un costo per etichetta che, per volumi molto grandi (ordine del milione di pezzi), può arrivare a

Dettagli

Le soluzioni gestionali Microsoft Dynamics

Le soluzioni gestionali Microsoft Dynamics Le soluzioni gestionali Microsoft Dynamics Le soluzioni gestionali Microsoft Dynamics La suite Microsoft Dynamics comprende soluzioni integrate, flessibili e semplici da utilizzare per automatizzare i

Dettagli

L'integrazione della supply chain tramite RFID ed EPCglobal Network: il caso Goglio Lavazza

L'integrazione della supply chain tramite RFID ed EPCglobal Network: il caso Goglio Lavazza L'integrazione della supply chain tramite RFID ed EPCglobal Network: il caso Lavazza Milano, 22 Aprile 2009 Agenda Progetto Lavazza Obiettivi del progetto La supply chain AS-IS La supply chain TO-BE EPC

Dettagli

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali Università degli Studi di Milano Polo di Crema Corso di laurea in Scienze Matematiche, Fisiche e Naturali INFORMATICA Corso di Ingegneria del Software progetto IL SISTEMA CALENDAR Presentato al dott. Paolo

Dettagli

Fixed asset management. Servizi e applicazioni Censit RFID per gestione patrimoniale, identificazione e tracciabilità

Fixed asset management. Servizi e applicazioni Censit RFID per gestione patrimoniale, identificazione e tracciabilità Fixed asset management Servizi e applicazioni Censit RFID per gestione patrimoniale, identificazione e tracciabilità CHI SIAMO COME LE IDEE... Censit nasce dall esperienza pluriennale di una società COMMERCIAL

Dettagli

UTILIZZO DI RFID IN AMBITO DOMESTICO: RILEVAMENTO E IDENTIFICAZIONE DEI PRODOTTI

UTILIZZO DI RFID IN AMBITO DOMESTICO: RILEVAMENTO E IDENTIFICAZIONE DEI PRODOTTI UNIVERSITÀ DEGLI STUDI DI BOLOGNA FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI Corso di Laurea in Scienze dell Informazione UTILIZZO DI RFID IN AMBITO DOMESTICO: RILEVAMENTO E IDENTIFICAZIONE DEI

Dettagli

Introduzione (2/3) A seconda dei casi, l elemento di accoppiamento è costituito da una spira o da una antenna

Introduzione (2/3) A seconda dei casi, l elemento di accoppiamento è costituito da una spira o da una antenna Introduzione (1/3) Radio Frequency IDentification (RFID) = possibilità di acquisire informazioni su di un oggetto per mezzo della radio-comunicazione ( contactless) fra un Tag ( etichetta ) fisicamente

Dettagli

SINER ACCESS. Sistema per il controllo degli accessi

SINER ACCESS. Sistema per il controllo degli accessi SINER ACCESS Sistema per il controllo degli accessi INTRODUZIONE Sia in ambito civile che industriale, è da anni costantemente più avvertita l esigenza di sviluppare forme evolute di controllo di determinate

Dettagli

PROGETTO CITYCARD PER LA GESTIONE MENSA SCOLASTICA E TRASPORTO ALUNNI

PROGETTO CITYCARD PER LA GESTIONE MENSA SCOLASTICA E TRASPORTO ALUNNI PROGETTO CITYCARD PER LA GESTIONE MENSA SCOLASTICA E TRASPORTO ALUNNI CityCard è un acronimo che sta ad indicare un sistema di servizi che vengono autenticati e riferiti ad una smart card con tecnologia

Dettagli

SISTEMI DI CONTROLLO ACCESSI

SISTEMI DI CONTROLLO ACCESSI WWW.PARCHEGGI.COM Advanced access control solutions SISTEMI DI CONTROLLO ACCESSI SESAMO ACCESSI Registrare gli eventi Fornire la visibilità sugli eventi Controllare gli eventi Generare eventi di consenso

Dettagli

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori Roma, 30 gennaio 2003 La realtà della carta di identità elettronica (nel seguito CIE) e della carta nazionale dei servizi (nel seguito CNS) rende ineluttabile l individuazione di servizi da erogare in

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

PROGETTO Easy Book PER LA GESTIONE MENSA SCOLASTICA E TRASPORTO ALUNNI. Easy Book

PROGETTO Easy Book PER LA GESTIONE MENSA SCOLASTICA E TRASPORTO ALUNNI. Easy Book PROGETTO Easy Book PER LA GESTIONE MENSA SCOLASTICA E TRASPORTO ALUNNI Easy Book sta ad indicare un sistema di servizi che vengono autenticati e riferiti ad una card che racchiude in se la gestione di

Dettagli

RFID Middleware. Andrea Borsic. Laboratorio Servizi ed Applicazioni Istituto Superiore Mario Boella

RFID Middleware. Andrea Borsic. Laboratorio Servizi ed Applicazioni Istituto Superiore Mario Boella RFID Middleware Andrea Borsic Laboratorio Servizi ed Applicazioni Istituto Superiore Mario Boella Tecnologia RFID e Tracciabilità - Scenari ed Opportunità per le PMI Camera di Commercio di Torino Giugno

Dettagli

SOLUZIONI RFID ZEBRA

SOLUZIONI RFID ZEBRA SOLUZIONI RFID ZEBRA EMEA_Zebra_RFID_Capabilities_brochure_6pp_italian.indd 3 12/01/2011 16:18 La più ampia gamma di codificatori/stampanti RFID Supportata da una comprovata esperienza nell ambito dell

Dettagli

DiploETR. Sistema integrato di Etichettatura e Tracciabilità

DiploETR. Sistema integrato di Etichettatura e Tracciabilità Pag. 1 di 16 1. Descrizione DiploETR è un sistema completo ed integrato per la tracciabilità di prodotti confezionati e dei loro componenti. L obiettivo di DiploETR è consentire di rintracciare i lotti

Dettagli

Applicazione: Piattaforma di Comunicazione Unificata

Applicazione: Piattaforma di Comunicazione Unificata Riusabilità del software - Catalogo delle applicazioni: Amministrativi/Contabile Applicazione: Piattaforma di Comunicazione Unificata Amministrazione: Regione Piemonte - Direzione Innovazione, Ricerca

Dettagli

SISTEMI DI AUTOMAZIONE BARCODE & RFID

SISTEMI DI AUTOMAZIONE BARCODE & RFID SISTEMI DI AUTOMAZIONE BARCODE & RFID Sidera Software sviluppa soluzioni per la logistica e l automazione mediante la gestione di strumenti quali PLC per la gestione di apparecchiature, macchinari e sensori

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

JUNAK3 SISTEMA GESTIONE AZIENDALE

JUNAK3 SISTEMA GESTIONE AZIENDALE JUNAK3 SISTEMA GESTIONE AZIENDALE Modulo di Gestione Magazzino www.kisar.it JUNAK3 - SISTEMA DI GESTIONE AZIENDALE Il Sistema di Gestione Aziendale JUNAK3 è una piattaforma realizzata in ambiente Windows,

Dettagli

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione BANCA VIRTUALE/1 Il termine indica un entità finanziaria che vende servizi finanziari alla clientela tramite le tecnologie dell informazione e della comunicazione, senza ricorrere al personale di filiale

Dettagli

Oltre a questo propone infrastrutture per magazzini, hardware, materiale informatico, materiali di consumo e l'assistenza postvendita.

Oltre a questo propone infrastrutture per magazzini, hardware, materiale informatico, materiali di consumo e l'assistenza postvendita. La CIERREMME I.T. opera in ambito logistico ed organizzativo, proponendo soluzioni per l'identificazione automatica dei prodotti, mediante la fornitura di: - etichette, - etichette RFID - stampanti per

Dettagli

Città di Vico Equense Provincia di Napoli

Città di Vico Equense Provincia di Napoli DECRETO N. 20 DEL 08/04/2014 OGGETTO: INCARICO DI AMMINISTRATORE DI RETE DEL SISTEMA INFORMATICO DELL'ENTE E REFERENTE ICT TERRITORIALE PER L ATTUAZIONE DEL CAD CODICE AMMINISTRAZIONE DIGITALE" IL SINDACO

Dettagli

I principi dell RFID: comprendere e utilizzare l identificazione a radiofrequenza

I principi dell RFID: comprendere e utilizzare l identificazione a radiofrequenza White paper I principi dell RFID: comprendere e utilizzare l identificazione a radiofrequenza INDICE Introduzione 2 Funzionamento della tecnologia RFID 2 Tag (transponder) 2 Opzioni 3 Uso dell RFID 4 Conclusioni

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

Gli standard GS1 per il settore sanitario

Gli standard GS1 per il settore sanitario Gli standard GS1 per il settore sanitario Pharmintech Bologna, 18 aprile 2013 Gli standard GS1 per il settore sanitario Pharmintech BO, 18 aprile 2013 1 GS1 Italy Indicod-Ecr Lo spazio dove nascono le

Dettagli

***** Il software IBM e semplice *****

***** Il software IBM e semplice ***** Il IBM e semplice ***** ***** Tutto quello che hai sempre voluto sapere sui prodotti IBM per qualificare i potenziali clienti, sensibilizzarli sulle nostre offerte e riuscire a convincerli. IBM and Business

Dettagli

ché chi WEB DOCUMENT & PROCESS MANAGEMENT BUSINESS MANAGEMENT CONSERVAZIONE SOSTITUTIVA REVISIONI SPOOL RECOGNITION PEC WORKFLOW PRATICHE

ché chi WEB DOCUMENT & PROCESS MANAGEMENT BUSINESS MANAGEMENT CONSERVAZIONE SOSTITUTIVA REVISIONI SPOOL RECOGNITION PEC WORKFLOW PRATICHE DOCUMENT R & PROCESS MANAGEMENT ché chi BUSINESS PROCESS MANAGEMENT WEB CONSERVAZIONE SOSTITUTIVA WORKFLOW FASCICOLI REVISIONI DOCUMENT MANAGEMENT PRATICHE SPOOL RECOGNITION INTEGRAZIONE MAIL e FAX PEC

Dettagli

Ph@ses 3003. Sistema informativo di fabbrica 1/12

Ph@ses 3003. Sistema informativo di fabbrica 1/12 Ph@ses 3003 Sistema informativo di fabbrica 1/12 1 Indice 1 Indice...2 2 Introduzione...3 3 Il prodotto: Ph@ses 3003...3 4 Tecnologia...3 5 Schema logico generale di produzione...4 5.1 Layuot logico di

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Accesso alle applicazioni protetto. Ovunque.

Accesso alle applicazioni protetto. Ovunque. Scheda tecnica Accesso alle applicazioni protetto. Ovunque. Utenti mobili protetti Nelle organizzazioni odierne, ai responsabili IT viene spesso richiesto di fornire a diversi tipi di utente l'accesso

Dettagli

Introduzione al mondo RFID

Introduzione al mondo RFID Introduzione al mondo RFID RFID è l acronimo di Radio-Frequency Identification, una tecnologia che permette il riconoscimento a distanza di un oggetto tramite la trasmissione di onde elettromagnetiche.

Dettagli

Soluzioni Videojet per Codentify

Soluzioni Videojet per Codentify Sistemi per la codifica e la marcatura Soluzioni Videojet per Codentify Verifica digitale delle imposte, tracciabilità e autenticazione dei prodotti... L'implementazione di Codentify non solo richiede

Dettagli

Var Group Approccio concreto e duraturo Vicinanza al Cliente Professionalità e metodologie certificate In anticipo sui tempi Soluzioni flessibili

Var Group Approccio concreto e duraturo Vicinanza al Cliente Professionalità e metodologie certificate In anticipo sui tempi Soluzioni flessibili Var Group, attraverso la sua società di servizi, fornisce supporto alle Aziende con le sue risorse e competenze nelle aree: Consulenza, Sistemi informativi, Soluzioni applicative, Servizi per le Infrastrutture,

Dettagli

CARATTERISTICA / MODULO

CARATTERISTICA / MODULO NextWare Doc è il prodotto che consente di amministrare semplicemente tutte le p roblematiche inerenti la gestione dei documenti; è rivolto sia la settore privato che alla Pubblica Amministrazione, e copre

Dettagli

Parte 1: L architettura Tecnologica RFId di EPCglobal

Parte 1: L architettura Tecnologica RFId di EPCglobal Parte 1: L architettura Tecnologica RFId di EPCglobal 16.05.2011 1 Sommario Disclaimer... 3 1. L Architettura Tecnologica RFId di EPCglobal... 4 1.1. EPCglobal Inc.... 4 1.2. Intellectual Property Policy...

Dettagli

roj X Soluzione SCM Experience the Innovation www.solgenia.com

roj X Soluzione SCM Experience the Innovation www.solgenia.com roj X Soluzione SCM www.solgenia.com Experience the Innovation OBIET T IVO: catena del valore www.solgenia.com Experience the Innovation 2 Proj è la soluzione Solgenia in ambito ERP e SCM per l ottimizzazione

Dettagli

Ridisegnare i Sistemi Operativi per una Nuova Sicurezza

Ridisegnare i Sistemi Operativi per una Nuova Sicurezza Andrea Pasquinucci, Febbraio 2013 pag. 1 / 6 Ridisegnare i Sistemi Operativi per una Nuova Sicurezza Sommario I nuovi strumenti informatici, dagli smartphone ai tablet che tanto ci sono utili nella vita

Dettagli

Protezione delle informazioni in SMart esolutions

Protezione delle informazioni in SMart esolutions Protezione delle informazioni in SMart esolutions Argomenti Cos'è SMart esolutions? Cosa si intende per protezione delle informazioni? Definizioni Funzioni di protezione di SMart esolutions Domande frequenti

Dettagli

Funzioni di Back Office

Funzioni di Back Office Funzioni di Back Office SOCIETA' PER I SERVIZI BANCARI - SSB S.p.A. Sede Sociale e Direzione Generale: Via Faravelli, 14-20149 Milano - Cap.Soc. 10.763.984,27 int.vers. T: +39 02 3484.1 F: +39 02 3484.4098

Dettagli

ALLEGATO TECNICO SUL MODELLO DI SICUREZZA IN INTERNET IL PRODOTTO VORTAL

ALLEGATO TECNICO SUL MODELLO DI SICUREZZA IN INTERNET IL PRODOTTO VORTAL ALLEGATO TECNICO SUL MODELLO DI SICUREZZA IN INTERNET IL PRODOTTO VORTAL 1 Introduzione Il mondo del Web ha assunto negli ultimi anni una forza dirompente su tutti i fronti della comunicazione e della

Dettagli

Eagle RFId Supply Chain Management

Eagle RFId Supply Chain Management RFId Supply Chain management 24 marzo 2010 Il team per le Soluzioni RFID La società svizzera che aggrega le competenze RFID e ICT per fornire soluzioni di elevata competenza ed esperienza La società di

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

automation using workflow technology and web services Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3,

automation using workflow technology and web services Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3, Emergency healthcare process automation using workflow technology and web services M. Poulymenopoulou, F. Malamateniou, G. Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3, 195 207 Processo

Dettagli

Nexsoft. Business Solutions. Tracciabilità dei cicli di lavoro

Nexsoft. Business Solutions. Tracciabilità dei cicli di lavoro Nexsoft Business Solutions Tracciabilità dei cicli di lavoro Tracciabilità e Rintracciabilità La Tracciabilità è la capacità di risalire alla storia e all uso o alla localizzazione di una entità mediante

Dettagli

Interoperabilità dei sistemi di identificazione RFID e Contactless. P&STech Genova 22/11/2010

Interoperabilità dei sistemi di identificazione RFID e Contactless. P&STech Genova 22/11/2010 Internet of Things: Interoperabilità dei sistemi di identificazione RFID e Contactless P&STech Genova 22/11/2010 Marco Magnarosa CUBIT CUBIT Consortium Ubiquitous it Technologies nasce nel 2007 per volontà

Dettagli

CLASSROOM 3.0 : Mondi reali e virtuali si incontrano mediante ambient sensing per il settore smart education

CLASSROOM 3.0 : Mondi reali e virtuali si incontrano mediante ambient sensing per il settore smart education CLASSROOM 3.0 : Mondi reali e virtuali si incontrano mediante ambient sensing per il settore smart education Alessandro Fiore, Luca Mainetti, Roberto Vergallo Università del Salento roberto.vergallo@unisalento.it

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

Una soluzione software integrata : dal magazzino al test automatico delle unità con utilizzo di RFID/Barcode.

Una soluzione software integrata : dal magazzino al test automatico delle unità con utilizzo di RFID/Barcode. areakappa software solutions MapWarehouse Una soluzione software integrata : dal magazzino al test automatico delle unità con utilizzo di RFID/Barcode. www.areakappa.com 1 areakappa software solutions

Dettagli

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012 Architetture dei WIS Prof.ssa E. Gentile a.a. 2011-2012 Definizione di WIS Un WIS può essere definito come un insieme di applicazioni in grado di reperire, cooperare e fornire informazioni utilizzando

Dettagli

Xerox SMart esolutions. White Paper sulla protezione

Xerox SMart esolutions. White Paper sulla protezione Xerox SMart esolutions White Paper sulla protezione White Paper su Xerox SMart esolutions La protezione della rete e dei dati è una delle tante sfide che le aziende devono affrontare ogni giorno. Tenendo

Dettagli

10 argomenti a favore dell over IP

10 argomenti a favore dell over IP Quello che i fornitori di telecamere analogiche non dicono 10 argomenti a favore dell over IP Le telecamere di rete non sono certo una novità, infatti il primo modello è stato lanciato nel 1996. Nei primi

Dettagli

Realizzazione di un sistema di logging prototipale per la piattaforma

Realizzazione di un sistema di logging prototipale per la piattaforma tesi di laurea Realizzazione di un sistema di logging prototipale per la piattaforma Android Anno Accademico 2011 / 2012 relatore Ch.mo prof. Marcello Cinque candidato Dario De Meis Matr. 528 / 741 Smartphone

Dettagli

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti Sviluppo di applicazioni web con il pattern Model-View-Controller Gabriele Pellegrinetti 2 MVC: come funziona e quali sono vantaggi che derivano dal suo utilizzo? La grande diffusione della tecnologia

Dettagli

Politecnico di Milano

Politecnico di Milano 1 Politecnico di Milano Facoltà di Ingegneria dell Informazione Progetto di Ingegneria del Software 2: SWIMv2 Prof.ssa Mirandola Raffaella A.A 2012/2013 SWIMv2: Small World hypotesis Machine v2 Realizzato

Dettagli

INNOVATION CASE. Sistema di controllo del traffico in una galleria autostradale

INNOVATION CASE. Sistema di controllo del traffico in una galleria autostradale Sistema di controllo del traffico in una galleria autostradale INNOVARE: COSA? L IDEA Ovunque nel mondo si assiste ad un aumento della densità del traffico veicolare. Il fenomeno porta con sé un enorme

Dettagli

Via S. Leonardo, 120 - loc. Migliaro - 84100 Salerno 089 330254 tel - 089 330443 fax info@jobiz.com - www.jobiz.com

Via S. Leonardo, 120 - loc. Migliaro - 84100 Salerno 089 330254 tel - 089 330443 fax info@jobiz.com - www.jobiz.com Via S. Leonardo, 120 - loc. Migliaro - 84100 Salerno 089 330254 tel - 089 330443 fax @jobiz.com - www.jobiz.com uno strumento dinamico per fare e-business che cos'è e.cube ECMS le quattro aree configurazione

Dettagli

Modulo 8. Architetture per reti sicure Terminologia

Modulo 8. Architetture per reti sicure Terminologia Pagina 1 di 7 Architetture per reti sicure Terminologia Non esiste una terminologia completa e consistente per le architetture e componenti di firewall. Per quanto riguarda i firewall sicuramente si può

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

OPTILOG. La soluzione Siemens per la gestione del magazzino in ambito farmaceutico. Pagina 1 Siemens IS IT MES Solutions

OPTILOG. La soluzione Siemens per la gestione del magazzino in ambito farmaceutico. Pagina 1 Siemens IS IT MES Solutions La soluzione Siemens per la gestione del magazzino in ambito farmaceutico Pagina 1 I requisiti di un WMS Certezza operativa Utilizzo pieno dell impianto Conoscenza dello stato impianto Riduzione dei costi

Dettagli

Ean/ucc. il governo della rintracciabilità e gli obblighi di legge (CEE 178/2002)

Ean/ucc. il governo della rintracciabilità e gli obblighi di legge (CEE 178/2002) Rintracciabilità SSCC/gtin Regolamento CEE 178/2002 Gestione lotti Ean/ucc il governo della rintracciabilità e gli obblighi di legge (CEE 178/2002) Documento redatto con Openoffice Writer 1.1 www.openoffice.org

Dettagli

OnGuard. Gestione Integrata t della Sicurezza Aziendale

OnGuard. Gestione Integrata t della Sicurezza Aziendale OnGuard Gestione Integrata t della Sicurezza Aziendale LA PROPOSTA DI SICUREZZA 3S Team Access Control System Intrusion System Tecnologie Biometriche e Tradizionali Gestione Beni Aziendali Sensoristica

Dettagli

Organization Intelligence: Approccio e Tecnologia

Organization Intelligence: Approccio e Tecnologia Organization Intelligence: Approccio e Tecnologia [Knowledge] «In organizations it often becomes embedded not only in documents or repositories but also in organizational routines, processes, practices

Dettagli

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

Dettagli

I N F I N I T Y Z U C C H E T T I ACCESSI WEB

I N F I N I T Y Z U C C H E T T I ACCESSI WEB I N F I N I T Y Z U C C H E T T I ACCESSI WEB ACCESSI WEB Accessi web è la soluzione Zucchetti che unisce le funzionalità del controllo accessi con la praticità e la comodità dei sistemi web. Visualizzabile

Dettagli

Tracciabilità strumentario e teleria chirurgica in sala operatoria e nelle centrali di sterilizzazione. Riccione, 13 ottobre 2012

Tracciabilità strumentario e teleria chirurgica in sala operatoria e nelle centrali di sterilizzazione. Riccione, 13 ottobre 2012 Tracciabilità strumentario e teleria chirurgica in sala operatoria e nelle centrali di sterilizzazione Riccione, 13 ottobre 2012 1 INTRODUZIONE La tracciabilità e rintracciabilità dello strumentario chirurgico

Dettagli

POLISWEB e l integrazione in Suite Avvocato Elite

POLISWEB e l integrazione in Suite Avvocato Elite POLISWEB e l integrazione in Suite Avvocato Elite Sommario POLISWEB e l integrazione in Suite Avvocato Elite... 1 L'architettura del sistema Polisweb nazionale e il Polisweb PCT... 2 I punti di Accesso...

Dettagli

Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione. Facoltà di Ingegneria. Laurea Magistrale in Ingegneria Informatica

Università degli Studi Roma Tre Dipartimento di Informatica ed automazione. Facoltà di Ingegneria. Laurea Magistrale in Ingegneria Informatica Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione Facoltà di Ingegneria Laurea Magistrale in Ingegneria Informatica Tesi di Laurea Sistema informativo per la gestione dei processi

Dettagli

MANUALE www.logisticity.it. Copryright 2015 - All rights reserved Email: info@logisticity.it - P.IVA 04183950403

MANUALE www.logisticity.it. Copryright 2015 - All rights reserved Email: info@logisticity.it - P.IVA 04183950403 MANUALE www.logisticity.it Copryright 2015 - All rights reserved Email: info@logisticity.it - P.IVA 04183950403 INDICE Presentazione... pag. 02 Applicativo... pag. 03 Amministrazione...pag. 06 Licenza...pag.

Dettagli

CORSO WEB SERVER, DBMS E SERVER FTP

CORSO WEB SERVER, DBMS E SERVER FTP CORSO WEB SERVER, DBMS E SERVER FTP DISPENSA LEZIONE 1 Autore D. Mondello Transazione di dati in una richiesta di sito web Quando viene effettuata la richiesta di un sito Internet su un browser, tramite

Dettagli

Mexal SAR. SAR (Servizio Assistenza Remota) TARGET DEL MODULO

Mexal SAR. SAR (Servizio Assistenza Remota) TARGET DEL MODULO SAR (Servizio Assistenza Remota) TARGET DEL MODULO Il modulo SAR, destinato ad Aziende e Professionisti, è stato progettato per fornire assistenza e consulenza a distanza. Se da una parte, i professionisti

Dettagli

Facoltà di Ingegneria

Facoltà di Ingegneria Facoltà di Ingegneria Corso di laurea in Ingegneria dell Informazione FONDAMENTI DI INFORMATICA PRIMA PARTE Manuale di Installazione dell ECMs SharePoint PROFESSORE: STUDENTE: Prof. Mario Bochicchio Paiano

Dettagli

Reti di computer. Agostino Lorenzi - Reti di computer - 2008

Reti di computer. Agostino Lorenzi - Reti di computer - 2008 Reti di computer Telematica : termine che evidenzia l integrazione tra tecnologie informatiche e tecnologie delle comunicazioni. Rete (network) : insieme di sistemi per l elaborazione delle informazioni

Dettagli

I N F I N I T Y P R O J E C T ACCESSI WEB

I N F I N I T Y P R O J E C T ACCESSI WEB I N F I N I T Y P R O J E C T ACCESSI WEB ACCESSI WEB Accessi web è la soluzione Zucchetti che unisce le funzionalità del controllo accessi con la praticità e la comodità dei sistemi web. Visualizzabile

Dettagli

C.R.M. Custom Relationship Management

C.R.M. Custom Relationship Management Web Solution C.R.M. Custom Relationship Management Overview La soluzione CRM Portal Builder è una piattaforma innovativa per la gestione delle relazioni con i clienti, basata su una struttura modulare

Dettagli

RELAZIONE TECNICA ILLUSTRATIVA

RELAZIONE TECNICA ILLUSTRATIVA RELAZIONE TECNICA ILLUSTRATIVA I SERVIZI AL CITTADINO E ALLE IMPRESE Il Comune di CALTAVUTURO attraverso il presente progetto intende attivare e rafforzare i servizi offerti al cittadino, per dare maggiore

Dettagli

Affiancare una gestione documentale alla registrazione di documenti in un gestionale: dalla fattura cartacea alla conservazione sostitutiva

Affiancare una gestione documentale alla registrazione di documenti in un gestionale: dalla fattura cartacea alla conservazione sostitutiva Affiancare una gestione documentale alla registrazione di documenti in un gestionale: dalla fattura cartacea alla conservazione sostitutiva INTRODUZIONE In ogni organizzazione pubblica o privata, grande

Dettagli

Alessandro Bottaioli Responsabile Tecnico Progetti InFarma. Pieralberto Nati Responsabile progetto FrontEnd Studiofarma

Alessandro Bottaioli Responsabile Tecnico Progetti InFarma. Pieralberto Nati Responsabile progetto FrontEnd Studiofarma Alessandro Bottaioli Responsabile Tecnico Progetti InFarma Pieralberto Nati Responsabile progetto FrontEnd Studiofarma COME SIAMO ARRIVATI QUI C era una volta la signorina che rispondeva al telefono finalmente

Dettagli

7.1 Livello di completezza degli esempi

7.1 Livello di completezza degli esempi Luca Cabibbo Analisi e Progettazione del Software Capitolo 7 marzo 2013 Buono, poco costoso, rapidamente. Puoi scegliere due di queste caratteristiche. Anonimo 1 *** AVVERTENZA *** I lucidi messi a disposizione

Dettagli

Descrizione servizio Websense Hosted Mail Security

Descrizione servizio Websense Hosted Mail Security Descrizione servizio Websense Hosted Mail Security Alla luce della crescente convergenza delle minacce nei confronti del Web e della posta elettronica, oggi è più importante che mai poter contare su una

Dettagli

Ingegneria dei Requisiti

Ingegneria dei Requisiti Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Ingegneria dei Requisiti E. TINELLI Contenuti I requisiti del software Documento dei requisiti I processi

Dettagli

PREMESSA. B2B vs B2C PERCHÉ B QUADRO?

PREMESSA. B2B vs B2C PERCHÉ B QUADRO? PREMESSA PERCHÉ B QUADRO? Se per alcuni aspetti c è una convergenza delle soluzioni di e-commerce B2B e B2C - come ad esempio l esperienza di utilizzo e la fruizione da dispositivi mobile - le finalità

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

Dettagli

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati Affidabilità nel servizio precisione negli strumenti Chanda LPR Chanda LPR è una piattaforma

Dettagli

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router Rete di reti (interrete, internet) 2 Prof. Roberto De Prisco TEORIA - Lezione 8 Rete di reti e Internet Università degli studi di Salerno Laurea e Diploma in Informatica Una rete di comunicazione è un

Dettagli

2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011. Andrea Carnevali R&D Director GESINF S.r.l.

2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011. Andrea Carnevali R&D Director GESINF S.r.l. 2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011 Andrea Carnevali R&D Director GESINF S.r.l. Il progetto 2G è il nome della piattaforma che consentirà l evoluzione tecnologica

Dettagli