Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Tesi Rfid - 05.03
Tesi Rfid - 05.03
di
Demis Castagna
Informatica
2007
__________________________________________
__________________________________________
__________________________________________
Data ________________________________________________
Università di Tor Vergata
Estratto
di Demis Castagna
01 Introduzione a Rfid
A Rfid Flessibili
C Rfid Tradizionali
D Trasponder
E Esempi di scenari
L Rfid e Privacy
O
ii
INDICE DELLE FIGURE
Numero Pagina
[Inserire qui l'indice delle figure]
iii
RINGRAZIAMENTI
iv
GLOSSARIO
v
Capitolo 1
Introduzione a Rfid
La sigla RFID significa “Radio-Frequency IDentifier”. Si
tratta sostanzialmente di piccolissime radio
rice/trasmittenti molto simili ai transponder
(Transmitter/Responder) usati in molte applicazioni
militari. Sia gli RFID che i transponder svolgono un solo
compito, molto semplice: quando vengono interrogati (via
radio), rispondono inviando un codice di identificazione e,
se del caso, alcune altre informazioni (solitamente
statiche e immodificabili).
RFID flessibili
2
Gli RFID flessibili sono l’ultima moda. Si tratta di piccoli
apparecchi radio rice/trasmittenti, privi di una propria
alimentazione (batteria), e realizzati stampando
direttamente la circuiteria su un substrato flessibile (una
lamina di plastica, un tessuto, etc.). La circuiteria può
essere realizzata in metallo (rame o argento) e/o in
polimero (semi)conduttore. Questi dispositivi di solito
possono memorizzare solo poche centinaia di Kb e devono
essere letti avvicinando il lettore (transceiver) a 2 o 3 cm
di distanza. Sono considerati ideali per sostituire le
targhette con i codici a barre nei vestiti.
RFID tradizionali
3
qualche centinaio di Kb di dati. Oltre al solito codice di
identificazione, possono contenere, ad esempio, la data di
nascita dell’animale e qualche informazione anagrafica sul
padrone, come il numero di telefono da contattare. In
alcuni casi dispongono di una loro batteria di
alimentazione interna ma più spesso dipendono da una
sorgente radio esterna per il loro funzionamento. Nel
primo caso possono essere “letti” mantenendo il lettore
ad una distanza di 1 o 2 metri dall’animale, nel secondo
caso bisogna avvicinare il lettore ad 1 o 2 centimetri.
Transponder
4
A questo verrebbe da chiedersi perché c’è tutto questo
interesse per i Tag RFID e quali sono i vantaggi rispetto ai
tradizionali codici a barra. Le riportiamo qui di seguito:
5
della induzione genera nell'antenna del tag una corrente
che alimenta il Chip. Il Chip alimentato comunica tutte le
sue informazioni che vengono irradiate tramite l'antenna
verso il Lettore.
Modalità read-only
6
4. Capacità di lavorare in ambienti contaminati, e
sporchi;
7
presenza di un tag con queste modalità può sostituire sia
il network sia la necessità di avere sempre attivo il
controllo di un sistema di gestione e in questo modo
automatizzare alcuni processi amministrativi o industriali,
localizzare in magazzino i differenti modelli, smistare in
distribuzione modelli e prodotti in funzione di alcune
caratteristiche (prezzo, dimensioni, packaging ecc.).
Questi tag si rivelano utili anche per generazione
automatica di bolle e fatture, grazie alla possibilità di
leggere contemporaneamente più codici. Anche la fase di
vendita trova vantaggi dall'uso dei tag, sia per realizzare
inventari real time all'ingresso e alla vendita del prodotto,
sia perché i tag possono essere utilizzati come dispositivi
antitaccheggio.
RFID e Privacy
8
1. la consapevolezza o meno dell'utente che un
prodotto contenga un RFID;
3. la associazione possessore/TAG.
9
hanno distanze di lettura limitate, anche se sono state
smentite da varie prove sul campo:
10
Capitolo 2
11
I tempi necessari alla implementazione di una fase
prototipale di un progetto in grado di dimostrare il
corretto funzionamento della tecnologia RFId, sono
riassunti nel seguente diagramma di GANTT:
12
L'Architettura di un sistema RFID:
13
Capitolo 3
1. La sicurezza;
14
Qui di seguito riportiamo una serie di esempi in cui è
possibile applicare i tag Rfid.
15
conto corrente) e l’ha associata al vostro nuovo RFID.
Mentre vi muovete per città, i lettori RFID dei negozi
associati alla stessa catena del centro commerciale
leggono l’RFID, vi riconoscono, “pescano” i vostri dati dal
database e vi fanno offerte “ritagliate su misura per voi”.
Ovviamente, ogni vostro passo viene registrato, per cui
diventa facile stabilire le vostre abitudini commerciali. Nel
caso ci fosse qualche dubbio, tenete presente che gli RFID
verranno infilati un po’ dovunque, per cui per il centro
commerciale diventa un gioco da ragazzi sapere cosa c’è
nel vostro guardaroba o nel vostro frigorifero. Se poi
comprate riviste o libri di carattere politico o religioso,
oppure “giocattoli” o qualunque altro prodotto possa
venirvi in mente.
16
cassiere, ovviamente, dovranno trovarsi un’altra
occupazione.
Applicazioni RFID
17
possibile pagare il biglietto della metropolitana con tali
soluzioni.
18
Trasporti: in questo caso i tag vengono applicati sia sugli
oggetti (scatole, pallet, ecc.) da trasportare, sia sui mezzi
di trasporto (vagoni, automobili, ecc.) In Italia, Francia e in
Giappone sono già funzionanti milioni di tessere RFID che
permettono ai pendolari di utilizzare diversi tipi di
trasporto con le diverse forme di abbonamento. Un'altra
applicazione della tecnologia RFID e' in sostituzione del
codice a barre come identificativo sui bagagli in aeroporto
permettendo un maggiore "tasso di lettura" ed errore
lungo gli scivoli di smistamento (35% di miglioramento
dell'efficienza presso l'aeroporto di Dallas)
19
dalle uscite e verificare automaticamente l'elenco delle
presenze all'interno di una determinata zona, permette
l'avvio o l'arresto di un PC a seconda che il proprietario si
trovi o meno nelle vicinanze. I tag possono essere
stampati o inseriti in oggetti di forma diversa, come ad
esempio un badge identificativo e, quindi, personalizzati
con stampe di immagini, scritte, loghi, fotografie e codici a
barre. Possono essere registrate informazioni come: dati
anagrafici, foto di riconoscimento, data e ora di transito,
verso di transito, altro.
20
Identificazione degli animali: rispetto agli altri metodi
utilizzati per l'identificazione degli animali (marca
auricolare, tatuaggio, passaporto cartaceo), con
l'applicazione dei tag tutte le informazioni necessarie sono
residenti anche sui capi di bestiame e, grazie all'emissione
di onde elettromagnetiche a bassa frequenza del tutto
innocue, risultano accessibili ovunque si trovi l'animale. Le
etichette possono contenere le informazioni indispensabili
a garantire la qualità del capo come ad esempio:
• Codice dell'animale;
• Trattamenti subiti.
21
automaticamente registrata. Alla restituzione dei libri,
l'utente dispone i volumi in un apposito cestello,
appoggiato su una stazione di lettura. Il sistema rileva il
rientro dei libri nella biblioteca e registra tale transazione,
quindi legge dal tag il codice dello scaffale e del ripiano su
cui ogni libro deve essere depositato.
22
dimensioni, possono essere collocati in punti "scomodi",
dove sarebbe difficile portare il cavo necessario ad
alimentare un apparecchio di misura, ed offrono, a costi
decisamente contenuti, una soluzione affidabile e di facile
implementazione.
23
Capitolo 4
3.
1. Un numero identificativo;
24
3. Tag e reader non sono sensibili all’orientamento;
25
Tag: vengono divisi in due grandi categorie. Passivi e
attivi e semi-passivi. La differenza sostanziale è che i tag
passivi non possono memorizzare informazioni a
differenza di quelli attivi. Spieghiamo un pò meglio i tag
appena citati fornendo qualche piccola informazioni:
2. Read/Write;
26
Rfid è il futuro della tecnologia e pare sostituirà i codici a
barra. Per questo motivo si è cercato di creare uno
standard, chiamato EPC global Network. L’EPC è un
insieme di tecnologie che gestiscono:
27
Andiamo a spiegare brevemente gli elementi che la
compongono:
28
I dati RFID possono contenere grandi flussi di dati e
contenere delle ripetizioni. Andiamo ora a vedere come è
possibile osservarli:
29
30
Capitolo 5
31
Fino ad ora abbiamo parlato sempre di Rfid Middleware,
andiamo ora a vedere come è composto:
1. Rfid Reader;
2. Event Manager:
32
14.Integration interface: integrare il sistema con le
altre applicazioni.
33
Andiamo a parlare prima di tutto di sicurezza. Al centro
della sicurezza troviamo le comunicazioni fra tag e reader
che sono sottoposte a possibili ascolti nascosti e ad analisi
del traffico. Durante la fase di rilevazione non è previsto
un protocollo di autenticazione reader – to – tag o tag – to
–reader.
34
1. Action threat: il comportamento di un individuo
può essere inferito monitorando le azioni di gruppi di
tag;
6. Produttore;
7. Tipo di prodotto;
35
36
Capitolo 6
37
1. Bea Portal per la realizzazione di un portale dove era
possibile, mediante interrogazione ad un database,
conoscere lo stato delle spedizioni.
38
mercato italiano ma soprattutto perché esso si presenta
come un filtro tra applicazioni realizzate in java e la parte
hardware. Spiegheremo nel prossimo capitolo i software
utilizzati riportando le caratteristiche di ognuno di essi.
Parte 1:
2. Cos’è RFID;
39
4. Perché utilizzare Rfid;
Parte 2:
40
effettuare le rilevazioni. In fase di presentazione
dovevamo far vedere come avvenivano le rilevazioni
dei pacchi contenenti delle scatole utilizzate per la
dimostrazione. Come già detto nei precedenti capitoli
la parte fondamentale di Rfid è che se alcuni beni di
una società sono all’interno di una scatola con dei
Tag, le antenne Rfid riescono a rilevare quali beni
sono contenuti all’interno della scatola. Nella parte
relativa alle rilevazioni in questa stessa tesi
spiegheremo poi quali sono stati i risultati delle
rilevazioni e in che modo era meglio posizionare le
scatole;
41
software che Bea vende in Italia. Basti che pensare che Bea
WebLogic detiene la percentuale più alta di usabilità da
parte amministratori di sistema che lo usano e lo
raccomandano.
Un’ ultima frase va detta per Hp. Prima, non a caso, nella
presentazione dei materiali utilizzati nel laboratorio ho
riportato il server Hp. Bea insieme ad Hp Italia hanno
lavorato, nella sede staccata di Milano, ad un altro progetto
pilota. E Hp ha un proprio laboratorio Rfid dove vengono
effettuare rilevazioni, prove e studi.
42
Capitolo7
43
Per dare al lettore una idea di come avviene una
rilevazione RFID facciamo un esempio. Questo stesso
esempio è stato preso in esame nel nostro laboratorio.
2
2
1
1
Figura1
44
La Figura1 rappresenta una catena di montaggio. Nel
nostro laboratorio, per problemi di spazio e per mancanza
di alcune strutture non abbiamo potuto avere a
disposizione un ambiente di sviluppo cosi completo,
l’abbiamo quindi simulato.
La prima parte indica la sezione della catena di montaggio
nella quale viene preparato l’ordine (indicata con un
numero 1 contenuto in un cerchietto). La seconda parte
invece (indicato con il numero (2)) indica l’ordine finito che
viene messo in una scatola e sulla quale viene applicato
poi un tag per essere rilevato.
Nel laboratorio avevamo due miniportali. Il primo serviva
per la preparazione degli ordini, mentre il secondo per la
spedizione.
45
L’esempio di studio che vi presentiamo è il seguente:
abbiamo una catena di montaggio come quella riportata
nella figura 1. Nella parte (1) prepariamo il materiale che
andrà a formare un ordine. Nella parte (2) introduciamo il
materiale in alcune scatole. È a discrezione dell’azienda
inserire tutte le scatole in una più grande o lasciarle divise.
In entrambi i casi questa scelta dipende dalla logistica
dell’azienda. Nell’esempio riportato in figura vengono prese
tutte le scatole e messe su un pallet. Ogni scatola avrà un
tag di rilevazione.
Nella parte (1) i prodotti non hanno un tag. Questo viene
applicato nella parte (2) sulla superficie di ogni scatola.
Passando questi elementi vicino ad uno scanner RFID e
utilizzando un software apposito di Bea riusciamo a sapere
quali prodotti vanno a formare l’ordine e altre
caratteristiche a loro inerenti.
46
Le informazioni che possono essere legate ad un tag sono
molteplici e dipendono dall’azienda. Noi riportiamo solo
quelle che sono servite al nostro caso di studio.
Sicuramente in una azienda le informazioni che possono
essere legate ad un tag sono molteplici e variano in base
all’ambiente di lavoro in cui ci troviamo.
L’ambiente che avevamo a disposizione era una stanza 20
mq. In questa stanza avevamo due tavoli, su uno avevamo
il miniportale per la preparazione degli ordini, sul secondo
tavolo avevamo il miniportale per la spedizione degli ordini
completati.
C’era poi un altro tavolo dove abbiamo messo il server.
Inizialmente abbiamo utilizzato un notebook, poi un server
Hp con caratteristiche hardware migliori. Su entrambi i pc
menzionati per effettuare le rilevazioni abbiamo utilizzato il
software di ConnectTerra.
È stato creato anche un portale (mediante Bea Portal) con
il quale poter gestire e visionare gli ordini. Al momento di
questa relazione in portale non è stato ancora completato,
per questo motivo non ci sono informazioni in merito.
47
32 cm
50 cm
80 cm
MiniVarco RFID
Realizzato in Legno o materiale che consente il montaggio
di 2 Antennne a Polarizzazione Circolare (materiale non
metallico).
Permette lo scorrimento manuale di un tray che contiene
items RFID (piccole scatole).
Contiene piccoli scivoli di entrata e uscita.
Deve essere poggiabile su un tavolo (larghezza: max 80
cm).
48
A seguito di numerose prove effettuate nel laboratorio
allestito presso Bea Systems Italia (filiale di Roma) mi è
stato possibile elaborare una serie di casi con i quali testare
una serie di prove per effettuare la rilevazione di differenti
prodotti sui quali avevamo applicato un tag. Lo scopo dello
studio era:
1. capire quali materiali potevano dare fastidio, quali
invece andavano bene in fase di rilevazione;
2. il tipo di collante da utilizzare per attaccare i tag sulle
scatole;
3. su quali superficie attaccare questi tag.
49
√ Studio di differenti collanti per attaccare i
TAG
Considerazioni Finali
a. Colla Stick
50
b. Scotch Bi-Adesivo
c. Scotch
Considerazioni Finali
51
Il tag è risultato attaccato in maniera ottimale nel seguente
modo: una sola striscia di scotch, sia esso bi-adesivo o
normale.
52
Capitolo8
2. Bea Portal;
53
Utilizzando la nostra pluri-premiata piattaforma
d’infrastruttura applicativa BEA WebLogic™, il tuo team di
sviluppo potrà creare un codice di sviluppo applicativo su
una specifica piattaforma Java, per definire le informazioni
necessarie nelle fasi iniziali di realizzazione della SOA, che
comprendono la costruzione e messa in opera dei servizi.
BEA WebLogic Platform — che comprende BEA WebLogic
Server®, BEA WebLogic Portal™, BEA WebLogic
Integration™, BEA WebLogic Workshop™, BEA JRockit™ —
è la application platform suite leader di mercato destinata
agli sviluppatori che vogliono abilitare le proprie
applicazioni ai servizi.
Ora, anche la tua azienda può utilizzare soluzioni BEA
AquaLogic™ per organizzare e gestire servizi, processi e
applicazioni composte indipendentemente dalle tecnologie
adottate. BEA AquaLogic è la prima Service Infrastructure
del mercato a permettere alle aziende di effettuare con
successo la transizione alle SOA, al fine di migliorare
l’efficienza IT e la reattività di business.
Questa famiglia di prodotti — che comprende BEA
AquaLogic Service Bus™, BEA AquaLogic Data Services
Platform™, BEA AquaLogic Enterprise Security™ e BEA
AquaLogic Service Registry™ — fornisce l’insieme più
completo di prodotti unificati disponibili oggi per
implementare, configurare, mettere in sicurezza e gestire
servizi eterogenei attraverso l’intero ciclo di vita SOA.
54
Insieme, l’application infrastructure platform BEA WebLogic
e la famiglia di prodotti BEA AquaLogic sono soluzioni
complementari ideali per aziende e organizzazioni che
vogliono implementare soluzioni basate su SOA di classe
enterprise.
seguente:
55
BEA offre prodotti e servizi che permettono alle aziende di
ottenere più velocemente un time-to-value per le
applicazioni critiche di business, utilizzando standard
aperti, web service e una Service-Oriented Architecture
(SOA).
56
BEA WebLogic Server
57
BEA WebLogic RFID Product Family
58
Abbiamo parlato di applicazioni SOA, quali sono le
applicazioni SOA e cosa sono? Spieghiamo brevemente qui
di seguito di cosa stiamo parlando.
• Data consistency
• Multistep Process
• Composite Application
descriviamole brevemente.
Data consistency
59
Figura 1 - Data consistency
Multistep Process
60
Composite Application
61
SOA
Qualunque sia il pattern di integrazione che dobbiamo
usare rimane il fatto che integrare è una attività difficile e
costosa. Questo induce a pensare che la difficoltà non
dipenda da come si affronta il problema, ma che la
difficoltà sia intrinseca all'attività di integrazione. Negli
esempi visti sopra abbiamo sempre delle applicazioni
complete su cui vogliamo innestare una nuova funzionalità
che implica una forma di integrazione. Questo porta ad
affrontare i problemi di integrazione in fase di
manutenzione/evoluzione delle applicazioni. Inoltre
normalmente in questi casi si tende a soluzioni particolari e
poco riutilizzabili nell'eventualità di nuove necessità di
integrazione.
62
Un miglioramento alla difficoltà del problema
dell'integrazione si avrebbe se le applicazioni fossero
concepite per essere integrate. Quindi se le problematiche
della fase di integrazione fossero affrontate nella fase di
inception dell'applicazione. Questo non elimina
completamente la difficoltà di integrazione però consente
di risolvere una serie di problemi nella fase di sviluppo
dell'applicazione (quando cioè toccare il codice costa
meno). Se l'applicazione invece esiste già si può costruire
sopra di essa un layer che la mostri al mondo esterno
"come se" fosse stata concepita per essere integrata.
Questa è una delle idee che stanno alla base dello stile
architetturale SOA (e per me la più importante). Vedremo
che il modo migliore (per quanto ne sappiamo oggi) per
avere applicazioni integrabili è quello di pensarle a servizi e
cercheremo di capire meglio cosa sono i servizi.
Ma SOA non è solo questo, SOA è anche una collezione di
idee e best practices sul tema dell'integrazione maturate in
seguito all'introduzione del modello di computazione
distribuita. Ad esempio una delle best practice più
importante è che disaccoppiare (ove possibile) porta molti
benefici.
63
La figura 4 segue mostra un blueprint di un'architettura
SOA. Come si può vedere esistono vari layer. Partendo dal
basso abbiamo il layer delle applicazioni a servizi e il layer
dell'ESB. Questi layer sono fondamentali per l'architettura
SOA e saranno esaminati più in dettaglio in seguito. Gli altri
layer invece elevano via via il livello di astrazione
permettendo di avvicinare gli aspetti tecnici di in sistema
informativo a chi dirige il business di una azienda. Infatti il
layer del workflow consente di disegnare e configurare
workflow di processi aziendali (piuttosto che cablare queste
informazioni nelle applicazioni come spesso accade). Una
volta che si hanno a disposizione dei processi aziendali è
possibile gestirli (layer BPM: Business Process
Management) cioè attivarli e disattivarli, ma anche gestire
situazioni di errore mediante applicazioni di backoffice.
64
Figura 4 - Blueprint architettura SOA
65
Infine il layer BAM (Business Activity Monitoring) consente
di analizzare le dinamiche dei processi di business al fine di
prendere decisione aziendali. Gli strumenti di questi tre
layer possono teoricamente essere usati da persone non
tecniche (con la dovuta assistenza) e consentono di
avvicinare le persone che prendono di decisioni di business
al settore IT facendoglielo meglio comprendere. In effetti
questi tre layer non sono nuovi e sono presenti anche nei
blueprint di altri modelli architetturali. Poche aziende li
hanno effettivamente realizzati. SOA grazie alla sua
flessibilità dovrebbe consentire finalmente di costruire
questi layer a costi accettabili, ma staremo a vedere, per il
momento ritengo conveniente concentrasi sui due layer più
bassi.
Implementare una architettura SOA a tappeto su un
sistema informativo già in essere può significare una
rivoluzione tale da rendere difficile la cosa e magari trovare
anche opposizioni legittime da parte delle persone più
scettiche. Come sempre nell'informatica più che rivoluzioni
bisogna fare evoluzioni. Questo consente di minimizzare i
rischi del cambiamento, salvaguardare gli investimenti
passati e di convincere a poco a poco gli scettici. SOA non è
differente da questo punto di vista e perché abbia successo
va fatta partire con progetti pilota.
66
I servizi
67
In questo caso i servizi sono pochi e per dare la copertura
funzionale necessaria all'applicazione CRM dovranno
mettere a disposizione più di una funzionalità. Ad esempio
possiamo immaginare che il servizio di gestione anagrafica
cliente consentirà di effettuare inserimenti, modifiche,
cancellazioni e ricerche di clienti. Le applicazioni in SOA
diventano quindi un substrato che riunisce assieme un
insieme di servizi che hanno affinità funzionale.
I servizi e l'analisi
68
Il passo richiesto agli analisti funzionali è dunque quello di
svincolarsi da questo modo procedere e pensare a servizi
riusabili cercando di prevedere le necessità di integrazione
future. Resta sottinteso ovviamente che se queste
necessità non ci sono, non conviene adottare
un'architettura SOA e probabilmente risulta meno costoso
limitarsi ad una architettura distribuita o addirittura ad un
client/server.
69
Una interfaccia chiara e documentata che rappresenti il
contratto del servizio è quindi il deliverable fondamentale
della fase di analisi di un servizio.
70
Per raggiungere questi obiettivi è sufficiente che il sistema
supporti più versioni in linea del medesimo servizio come
mostrato in figura 6.
71
Ci sono doversi modi per avere due versioni del servizio in
linea, ma fondamentalmente si ricade sempre in due
categorie:
Pubblicazione del medesimo servizio con nomi diversi.
Unico servizio con un parametro di ingresso che indica la
versione del servizio che si vuole richiamare.
I servizi possono richiamare altri servizi ad esempio nel
caso si implementino sistemi di workflow. Al fine di avere
un buon sistema di change management è necessario
tracciare le dipendenze fra servizi in modo da essere in
grado di prevedere gli impatti dovuti al cambiamento di un
servizio.
72
Questo naturalmente è fattibile più agevolmente se i
servizi sono disegnati in partenza per essere monitorati e
gestiti.
Il disaccoppiamento
73
Di seguito si prendono in esame tre tipi di accoppiamento
che SOA tenta di alleviare. E' probabile che se ne possano
trovare altri tipi che qui non sono analizzati.
Accoppiamento applicativo
74
Questo tipo di accoppiamento si ha ogni volta che due
applicazioni condividono qualche artefatto. Ad esempio se
due applicazioni condividono un IDL dal quale generano gli
stub e gli skeleton necessari all'erogazione del servizio esse
sono accoppiate applicativamente e ogni volta che l'IDL
cambia bisogna effettuare il deploy sia del fornitore che del
consumatore del servizio.
Un altro esempio di accoppiamento applicativo si ha
quando fornitore e consumatore si scambiano qualche
oggetto durante la fase di comunicazione. E' evidente che
gli oggetti scambiati che saranno i parametri e il risultato
dell'elaborazione devono essere noti ad entrambe le
controparti e di conseguenza se gli oggetti cambiano è
necessario effettuare il deploy delle due applicazioni.
Questa tipo di accoppiamento è piuttosto diffuso oggi e
anzi si può dire che è incoraggiato dagli strumenti di
sviluppo odierni quali CORBA e J2EE che spingono ad usare
IDL e pattern quali value object come modello di sviluppo
dei servizi. La mia opinione è che gli strumenti sopra citati
consentano agevolmente di rendere remote funzionalità
presenti in componenti/oggetti software. Queste
componenti sono però tutt'altro che servizi nel senso di
SOA.
Comunque anche nel caso delle componenti il problema di
gestire gli aggiornamenti rimane. Mi è capitato in un paio di
esperienze di vedere il problema aggirato applicando il
pattern command [J2EEPATTERN]. Mediante questo pattern
si può fare sì che l'interfaccia della componente remota sia
unica e fissa e che un value object che rappresenta la
75
richiesta attuale (comando) sia scambiato avanti e indietro
fra le due parti. In questo modo è possibile far svolgere più
compiti allo stesso componente remoto, basta definire
nuovi comandi. Inoltre introducendo nuovi comando o
evolvendo quelli esistenti non si modifica l'interfaccia
remota del componente quindi non è mai necessario
ricompilare stub e skeleton; può dunque sembrare che
questa sia la soluzione del problema dell'accoppiamento
applicativo.
In realtà non è vero, infatti col pattern command da un lato
l'interfaccia remota del servizio è troppo generica per
rappresentare un contratto fra le due parti, dall'altro però il
contratto è implicitamente e subdolamente definito
dall'oggetto comando che quindi deve essere noto ad
entrambe le controparti. Questo approccio scricchiola non
appena i consumatori del servizio sono più d'uno e magari
sono esterni al sistema informativo del fornitore del
servizio. In questo scenario (che è lo scenario in cui nasce
SOA) c'è bisogno di una maggiore formalizzazione del
contratto e inoltre come abbiamo già detto di una oculata
gestione degli aggiornamenti.
76
Figura 7 - Accoppiamento applicativo
77
Nell'esempio mostrato in figura l'applicazione mutui
effettua una richiesta che contiene l'oggetto cliente
all'applicazione CRM. La richiesta però viene serializzata in
un messaggio in un formato che sia facilmente
trasformabile. La trasformazione avrà il compito di rendere
la richiesta interpretabile dall'applicazione CRM. In questo
modo l'applicazione mutui e CRM non condividono nulla di
applicativo.
Accoppiamento tecnologico
78
In generale è bene limitare all'interno di un sistema
informativo le tecnologie usate (per i vari aspetti ad
esempio: DBMS, S.O., protocolli di comunicazione)
assestandosi su due o tre tipi. Un numero maggiore
provoca costi di amministrazione e formazione troppo
elevati.
Accoppiamento temporale
79
Due applicazioni sono accoppiate temporalmente se è
necessario che siano entrambe online affinché una delle
due possa funzionare correttamente. Può sembrare
impossibile che se due applicazioni sono integrate una
delle due possa funzionare correttamente se l'altra non è
online. Invece è possibile realizzare quatta situazione
adottando protocolli di comunicazione asincrona e
monodirezionale. Se teniamo a mente i pattern di
integrazione già citati solo nel caso delle composite
application non riusciamo a disaccoppiare temporalmente
le applicazioni, negli altri casi è possibile.
Si noti che se il pattern di comunicazione è sincrono (cioè
di tipo richiesta risposta) non importa quale protocollo di
comunicazione usiamo, il risultato sarà sempre che le
applicazioni sono accoppiate temporalmente. Anche se,
come mostrato in figura 8, usiamo protocolli asincroni per
esempio una coda di messaggi per la richiesta e una coda
di messaggi (con correlazione) per la risposta, le
applicazioni rimangono sempre temporalmente accoppiate.
80
Come nelle architetture distribuite è possibile distinguere
facilmente alcuni layer (tipicamente dati, business,
presentation) la stessa cosa si può fare per le architetture
SOA.
81
I nomi dei layer SOA sono liberamente tratti da
[ENTERPRISESOA] e non sono standard (per la verità non è
ancora stato sviluppato un lessico ufficiale per indicare i
layer SOA).
82
Come si vede dalla figura le applicazioni espongono servizi
di forme diverse. Questo sta ad indicare sia le diversità
nella modellazione dati sia le diversità tecnologiche e di
protocollo di comunicazione. Si consente di avere queste
diversità perché come spigato nell'architettura SOA non si
vogliono accoppiamenti applicativi e tecnologici.
83
Questo layer di solito si implementa con strumenti di
comunicazione asincrona tipicamente code di messaggi
(anche quando il pattern di comunicazione è quello delle
composite application). Il motivo è come già detto che in
SOA predilige la comunicazione asincrona perché aumenta
il disaccoppiamento ed in generale consente di creare
architetture più scalabili.
84
A livello di prodotti non c'è ancora uniformità di
accettazione di uno standard per cui alcuni prodotti
accettano BPEL, altri accettano standard che hanno meno
popolarità di BPEL, altri ancora hanno un linguaggio
proprietario. A mio avviso non essendo ancora chiaro quale
standard per la definizione del workflow si imporrà, oggi,
dovendo scegliere un motore di workflow conviene
scegliere in base alle caratteristiche del prodotto e non in
base al linguaggio supportato. Quando emergerà uno
standard universalmente accettato se il prodotto è un buon
prodotto saranno apportati dei miglioramenti per
supportare lo standard e saranno messi a disposizione tools
di migrazione per i workflow già definiti, altrimenti tanto
varrà affrontare i costi di migrazione di prodotto.
85
User end-point layer
86
ESB
Il layer 2 dell'architettura SOA che abbiamo chiamato
tecnologico e di normalizzazione dati ha forti caratteristiche
infrastrutturali (che come abbiamo visto la specifica JBI
cercava di catturare). Stando così le cose è naturale
pensare di realizzare questo layer con un framework
sviluppato internamente o con un prodotto acquisito sul
mercato. Dunque piuttosto che tanti gateway come in
figura 8, possiamo pensare questo layer come mostrato
nella figura 10.
Figura 10 -ESB
87
2. Supporto alla trasformazione dei dati. Questa
caratteristica consente di abbassare l'accoppiamento
applicativo;
3. Supporto a diversi protocolli di comunicazione e
compatibilità con vari connettori software. Questa
caratteristica consente di abbassare l'accoppiamento
tecnologico;
4. Routing intelligente dei dati. Questa caratteristica
consente di esporre tutti i servizi sul layer
tecnologico, sarà poi l'ESB a ruotare il messaggio
sulla corretto servizio nel layer delle applicazioni a
servizi.
88
Come abbiamo visto ci sono diverse pattern di integrazione
fra applicazioni ognuno dei quali richiede caratteristiche e
SLA differenti al canale di comunicazione. Mi aspetto
dunque che un unico tipo ESB non possa rispondere a tutti i
casi di integrazione presenti in una azienda. E' possibile
prevedere che esisteranno tre tipi di ESB:
89
Il mercato degli ESB pur essendo piccolo in termini
finanziari è molto dinamico per la presenza di svariati
player. Da un lato società che proponevano broker di
integrazione tradizionali (come webMethods
[WEBMETHODS] o IBM [IBM]) hanno fatto rebranding dei
loro prodotti convertendoli alle nuove tecnologie (java e
Web Services). Dall'altro spesso società di dimensioni più
limitate (come Sonic [SONIC] o Fiorano [FIORANO] ) che
proponevano sistemi di comunicazioni a messaggi hanno
migliorato il loro prodotto aggiungendo le features
necessarie ad un ESB. In totale ci sono diverse decine di
vendor nessuno dei quali possiede la leadership del
mercato. E' prevedibile che nel giro di un paio d'anni il
mercato si consolidi facendo emergere chiaramente
quattro o cinque vendor. E' importante notare che
nell'arena ci anche vendor che tipicamente vendono
software applicativo e non di integrazione (come SAP). Il
motivo di questo fatto è che il controllo del software di
integrazione è strategico in quanto consente di influenzare
molto le scelte evolutive del sistema informativo.
Il panorama degli ESB open source (almeno per quanto ne
so io) è piuttosto deludente. Infatti sono a conoscenza di
solo due progetti: Joram [JORAM] e Mule [MULE].
90
Il primo è un sistema di messaging piuttosto evoluto, ma
secondo me non può ancora dirsi un ESB. Il secondo è un
ESB forse ancora un po' carente di funzionalità, ad esempio
non ha un sistema di trasformazione dei messaggi.
Comunque mi aspetto che presto nasceranno diversi ESB
open source anche perché a ben vedere le tecnologie di
base di un ESB sono già disponibili (anche open source) e
consolidate; bisogna quindi assemblarle coerentemente in
un prodotto (anche se non è facile come può sembrare).
91
Come abbiamo detto i vendor cercheranno di piazzare il
proprio ESB all'interno del sistema informativo aziendale è
quindi possibile immaginare che presto in un sistema
informativo ci sarà più di una marca di ESB come mostrato
in figura 11.
92
Gartner [GARTNER] chiama questa situazione Arcipelagi di
ESB intendendo per arcipelago un gruppo di applicazioni a
servizi correlate e coordinate da un ESB.
Conclusioni
Un'azienda che decida di evolvere il proprio sistema
informativo verso una architettura SOA deve fare diverse
scelte e fronteggiare diverse sfide.
La più importante è certamente quella di evolvere le
applicazioni esistenti verso una logica a servizi.
93
In secondo luogo dovrà dotarsi della infrastruttura
organizzativa e tecnologica per gestire i servizi.
In ogni caso non credo che SOA sia il "Silver bullet" [MMM]
(cioè la tecnologia in grado di risolvere completamente) del
problema dell'integrazione delle applicazioni, sono certo
però che l'approccio di SOA possa portare notevoli
semplificazioni. Per capire quanto notevoli bisognerà
attendere ancora un po'.
94
Gaining the significant benefits that RFID offers requires
more than simply implementing RFID tags and readers. You
need infrastructure software that enables you to develop,
deploy, and manage RFID solutions that meet your needs
today — while providing a solid foundation to support
growth as you expand.
Our standards-based architecture and software support all
phases of RFID implementation, enabling greater
efficiency, significant cost savings, and new business value.
We help your RFID deployment succeed today, then evolve
to support new devices and processes as your business
needs change.
With innovative BEA software at the core of your RFID
infrastructure, your corporate assets (goods, products,
materials) become a new source of valuable operational
data. More than simply identifying and tracking these
assets, our products help you manage and use this data to
fuel business intelligence.
95
Integrate RFID and other devices into your business
processes and deliver real-time operational data to the
enterprise. BEA WebLogic RFID Edge Server infrastructure
software handles the complex interaction of tags, readers,
devices, machinery, and people at the edge of the
enterprise. Designed expressly for deployment outside the
data center environment, RFID Edge Server provides the
foundation for creating enterprise-scale RFID applications
with unmatched scalability and performance.
To maximize the benefits of RFID, you need enterprise-class
infrastructure software that makes it possible to develop,
deploy, and manage RFID solutions that meet your needs
today while providinga solid foundation for growth.
BEA WebLogic RFID Edge Server provides all necessary
software infrastructure at the edge of the enterprise where
RFID tags and readers are deployed. The edge server
handles all computation that must be carried out locally,
controlling RFID readers and other devices, filtering data,
carrying out local business logic in support of operational
processes, and delivering data to the enterprise.
BEA WebLogic RFID Edge Server also provides a
sophisticated administration console that allows for
dynamic configuration, monitoring, and management of all
devices and software infrastructure.
96
BEA WebLogic RFID Edge Server provides a compete
solution for single-site projects. For larger enterprise-wide
deployment, BEA WebLogic RFID Edge Server may be used
in conjunction with BEA WebLogic RFID Enterprise Server,
providing a complete, standards-based, end-to-end solution
for the most complex RFID applications.
BEA WebLogic RFID Edge Server delivers a comprehensive
software infrastructure for developing, deploying, and
managing robust RFID solutions at the edge of the
nterprise. BEA WebLogic RFID Edge Server provides broad
device support, robust data filtering and aggregation,
extensive RFID infrastructure administration, monitoring
and management, and seamless integration with existing
platforms. BEA WebLogic RFID Edge Server also guarantees
message delivery, protecting RFID data, and provides the
unique capability to create customized, local workflows
that integrate RFID data into your operational processes.
BEA WebLogic RFID Edge Server provides out-ofbox support
for over thirty makes and models of RFID readers, printers,
and other devices commonly employed in RFID applications
such as bar code readers, stack lights, numeric displays,
and programmable logic controllers (PLCs).
BEA WebLogic RFID Edge Server supports all relevant
industry standards including:
• EPC and ISO tag protocols
• EPC and US DoD tag data standards
• EPCglobal Application Level Events (ALE)
• EPC Information Services (EPCIS).
97
BEA supported tag types include EPCglobal UHF Class 1
Gen 2 (ISO 18000-6C) as well as all earlier EPC tag types
and several ISO HF tags.
98
BEA WebLogic RFID Edge Server provides native decoding
and encoding of EPCglobal Tag Data Standards, including
GS1 codes and US Department of Defense constructs. The
edge server also fully implements the EPCglobal
Application Level Events (ALE) 1.0 standard, along with
several functional enhancements including an easy-to-use
extension for tag writing.
BEA WebLogic RFID Edge Server includes a sophisticated
administration console that lets operations staff monitor,
manage, and configure RFID infrastructure in real time. The
ability to monitor and manage a large number of devices
ensures that the data coming in from RF devices is
accurate and that the devices are operating optimally.
Devices
may be added or reconfigured without restarting the edge
server or disturbing the operation of application software.
RFID readers generate a continuous stream of lowlevel raw
data. The BEA WebLogic RFID Edge Server receives, filters,
and aggregates RFID tag data with a powerful Application
Level Events (ALE) processing engine. Filtered, aggregated
data may then be delivered directly to enterprise
applications, or integrated with local workflows as part of
operations at the edge.
99
The simple but powerful BEA WebLogic RFID Edge Server
ALE API provides a fast and simple way for developers to
define high-level events needed by specific applications
and key operational groups. The ALE API lets developers
focus on the “what”—what data they want, from which
readers, over what intervals of time—and the edge server
takes care of the “how” by finding the most efficient way to
interact with readers to deliver the data. The ALE API is
based on web services standards, which makes it fully
ready
for integration into a Services-Oriented Architecture (SOA)
environment, as well as providing direct access to
developers working in Java, .NET, or any other web services
environment.
10
0
BEA WebLogic RFID Edge Server enables the creation of
customized, local workflows or “edge flows” which handle
the complex interactions between RFID devices, other
devices, and humans. Edge Flows allow these interactions
to take place without the intervention of enterprise-level
software. This insures the highest performance and
reliability in the face of intermittent connectivity to the
enterprise data center. Edge Flows provide the business
context for RFID data sent to enterprise applications.
10
1
Edge Flows available out-of-box in BEA WebLogic RFID Edge
Server can generate EPCglobal EPCIScompliant data, or in
any other format.
To deliver messages reliably between the edge and the
Enterprise and prevent loss of RFID data, BEA WebLogic
RFID Edge Server provides JMS Store and Forward (SAF)
capability.
10
2
A successful RFID deployment touches many points across
a company’s IT infrastructure and business operation, often
requiring a wide range of enterprise technologies. To meet
this challenge, BEA offers expertise throughout each phase
of the RFID program.
10
3
Executive management can rely on the ability of BEA to
meet current compliance mandates and facilitate internal
pilots while establishing a true infrastructure for enterprise-
scale RFID deployment—all at a low cost of ownership. BEA
WebLogic RFID Edge Server together with SOA-driven,
edge-to-enterprise RFID infrastructure will rapidly enable
new business processes leading to a step change in supply
chain visibility and efficiency;
10
4
Capitolo9
Presentazione e Descrizione
Apparato Hardware insieme ad
Antenne CAEN
10
5
10
6
Capitolo12
Conclusioni
10
7
IN questa relazione abbiamo riportato in che modo
abbiamo operato e proseguito il nostro lavoro sull’RFID. Lo
scopo di questa prima parte di studio era quello di riuscire
a mettere in piedi un laboratorio ed effettuare alcune prove
per avere un primo contatto con l’RFID.
10
8
Nel nostro esempio e anche nelle nostre conclusioni
abbiamo sempre parlato del controllo della produzione, in
generale di ordini che andavano ad essere preparati su una
linea di produzione. RFID però non ha solo questo compito
e non è applicabile solamente in questo ambito. Se leggete
i giornali, gli articoli, vedrete che RFID ha moltissimi ambiti
di utilizzo. Ci sono moltissime aziende che stanno
adottando soluzioni RFID e molte altre, come Bea Systems,
che puntano a vendere servizi evoluti e a svilupparli in
merito. Un altro ambito in cui RFID può essere applicato è
sul controllo del personale. RFID nei prossimi anni sarà
utilizzato in moltissimi ambiti, molti dei quali tuttora oscuri.
10
9
Possiamo quindi dire che le valutazioni che abbiamo
effettuato hanno portato a considera prima di tutto quali
materiali possono dare fastidio in fase di rilevazione e quali
invece risultano essere ottimali. Per esempio, in una catena
di montaggio non consiglierei mai di utilizzare scatole di
cartone rivestiti di plastica. Questo perché, per esperienza,
la plastica non permette di avere ottimi risultati in fase di
rilevazione. Inoltre non userei piani in plastica con bordi
metallici per far viaggiare la merce sui nastri trasportatori.
Anche in questo caso, come è possibile riportare nei
risultati ottenuti, questo darebbe fastidio, in fase di
rilevazione, allo scanner RFID.
11
0
Concludo il discorso dicendo che il software di Connect
Terra ha garantito ottima stabilità. Il problema più grande si
è riscontrato nella fase di rilevazione soprattutto per il fatto
che molto spesso si andavano ad utilizzare scatole di
plastica o bordi metallici o quanto altro dava problemi e
interferenze agli scanner RFID. Capito comunque il
problema e cosa eliminare il problema non esisteva più e in
fase di rilevazione, il software di Connect Terra insieme alle
antenne ci dava tutte le informazioni in merito ai tag che
identificavano una scatola. Ricordiamo che ogni tag
identifica solo ed esclusivamente un prodotto. E per non
sbagliare, ci eravamo scritti su una scatola le
caratteristiche della scatola e il codice del tag che veniva
rilevato.
11
1
11
2
11
3
11
4
11
5
NOTIZIE VARIE SU RFID
11
6
Abbiamo parlato di TAG e abbiamo spiegato brevemente a
cosa servono. Ma quanti tipi di TAG esistono? Due tipi:
1. Tag passivo, ossia capace solo di fornire un ID;
2. Tag attivo, ossia fornito di una batteria (che purtroppo
non dura in eterno) a cui rilegare una o più informazioni.
Ad esempio, in alcuni stabilimenti che producono cibo
congelato i Tag attivi potrebbero fornire informazioni
sull’identificazione del prodotto ma anche sulla
temperatura di quest’ultimo.
11
7
Insomma RFID di strada ne ha ancora molta da fare. La
notizia negativa è che ormai, specie in America, sono
molti gli istituti bancari che hanno immesso sul mercato
un numero crescente di carte wireless di nuova
generazione. Pare che ce ne siano più di 10 milioni. E
nonostante le numerose campagne pubblicitarie per
convicere i consumatori sulla sicurezza di queste carte e
sui sistemi di crittografia utilizzati, la ricerca in questione
dimostra che con poco si riesce a superare sistemi di
sicurezza, che addirittura, in alcuni casi, non risultavano
esserci.
Rfid e Cellulari
11
8
La GSM Application (GSMA il cui sito è
http://www.gsmworld.com/index.shtml) che è
l’organizzazione che rappresenta i carrier mobili in questi
giorni ha confermato il proprio impegno per la
realizzazione di una Standard (NFC - Near Field
Communication) compatibile con smartphone, palmari e
cellulari. NFC sarà una soluzione wireless a corto raggio
che permetta ai dispositivi mobile di comunicare tra loro.
11
9
A livello aziendale la sinergia tra Rfid e NFC porterà nuovi
posti di lavoro e nuove figure professionali altamente
qualificate. In Italia gli unici carrier mobile che si sono
interessati sono Vodafone e 3. Ancora però non si sa
niente su quali novità ci porterà il progetto. Per il
momento dobbiamo solo aspettare la fine dell’anno,
periodo in cui sarà presentato al NFC Forum una roadmap
su come eseguire questo progetto e su come si evolverà.
12
0
Al momento comunque lo stato italiano ha emesso un
emendamento per dare il tempo necessario (circa 2 anni)
alla parte militare italiana a lasciare libera la banda che
ora è in uso dal Ministero della Difesa.
12
1
12
2
Capitolo 7
12
3
BIBLIOGRAFIA
12
4
INDICE ANALITICO
A
Aristotele,3
3
4