Post on 07-Jun-2015
INTRODUZIONE A RFID
di
Demis Castagna
Tesi presentata per la discussione del diploma di
laurea in
Informatica
Università degli Studi di Tor Vergata
2007
Relatore: Demis Castagna Controre latore:
___________________________________________________
___________________________________________________
___________________________________________________
Università degli Studi di Tor Vergata
Data _________________________________________________________
Università di Tor Vergata
Estratto
RFID E SUE POSSIBILI APPLICAZIONI
di Demis Castagna
Professore Giorgio GambosiDipartimento di Scienze Matematiche Fisiche e Naturali
[Digitare qui l'estratto]
SOMMARIO
Rif.t
o
Descrizione Argomento Pagin
a
01 Introduzione a Rfid
A Rfid Flessibili
B Micro o Nano Rfid
C Rfid Tradizionali
D Trasponder
E Esempi di scenari
F Vantaggi dei tag rispetto ai codici a
barre
G Fig Tag e Rfid Trasponder
H Modalità Read – Only
I Esempi di Applicazioni Rfid
L Rfid e Privacy
M Architettura di un Sistema RFID
N Realizzazione di una struttura Rfid
O
ii
iii
INDICE DELLE FIGURE
Numero Pagina[Inserire qui l'indice delle figure]
iv
RINGRAZIAMENTI
Si desidera ringraziare per la preziosa collaborazione
v
GLOSSARIO
Rif.t
o
Descrizione Termine Pagin
a
01 Rfid: Radio Frequency Identification.
vi
C a p i t o l o 1
Introduzione a RfidLa 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).
Le origini della tecnologia RFID risalgono alla seconda
guerra mondiale. Gli eserciti tedesco, giapponese,
americano e britannico utilizzavano un radar per rilevare
i velivoli in avvicinamento. Tuttavia, non c'era modo di
identificare quali aerei appartenessero al nemico e quali
invece fossero piloti connazionali di ritorno da una
missione. I tedeschi scoprirono che se i piloti effettuavano
un rollio durante il rientro alla base, veniva riflesso un
segnale radio diverso. Questa semplice manovra
avvertiva il personale radar di terra che gli aerei in
avvicinamento erano tedeschi e non degli Alleati. In
pratica, questo è il primo sistema RFID passivo.
Naturalmente, i sistemi radar e di comunicazione RF
hanno continuato a progredire nel corso degli anni
Cinquanta e Sessanta. La tecnologia RFID più recente è
stata inventata nel 1969 e da allora è stata utilizzata in
tutti gli ambiti della vita quotidiana. I sistemi RFID
vengono utilizzati in applicazioni quali controllo
dell'accesso, sistemi di pagamento e smart card senza
contatto, oppure anche come dispositivi antifurto nelle
auto.
Esistono diversi tipi di RFID che si differenziano l’uno
dall’altro sostanzialmente per due caratteristiche: la
presenza o meno di una fonte di alimentazione e le
dimensioni.
I tipi più piccoli di RFID sono solitamente privi di una loro
fonte di alimentazione (batteria o rete) e quindi devono
essere alimentati inviando loro un segnale radio ad un
frequenza particolare. L’RFID cattura il segnale radio, ne
ricava una certa dose di energia e la usa per inviare il suo
segnale di risposta. Negli altri casi si usa una normale
batteria, di solito al litio o qualcosa di simile. Le batterie
usate in quasi tutti gli RFID hanno una durata (di reale
funzionamento) di 5 o 10 anni.
Le dimensioni degli RFID possono andare da qualche
frazione di millimetro (come un grando di sale) a quelle
tipiche di un grosso telefono cellulare. La “portata radio”
di questi aggeggi può andare da qualche millimetro, per
gli RFID più piccoli e privi di alimentazione, a qualche
metro, per gli RFID “tradizionali” dotati di batteria
interna, sino a migliaia di km per i transponder satellitari
usati per tracciare i veicoli.
Qui di seguito riportiamo una descrizione dei modelli
esistenti.
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.
Micro o nano RFID
Gli RFID di dimensioni micro (circa come un chicco di
riso) o nano (come un grano di sale) sono quasi sempre
dispositivi passivi, privi di una loro fonte di alimentazione
interna, e devono essere letti avvicinando il lettore a
pochi millimetri dal RFID. Possono contenere qualche
decina o qualche centinaio di Kb e di solito vengono usati
solo per contenere un codice di identificazione univoco,
come un numero a 64, 128 o 256 cifre. Tra le altre
applicazioni, possono usati per identificare in modo
univoco le pasticche di certi farmaci ed i proiettili delle
armi da fuoco.
RFID tradizionali
Gli RFID tradizionali sono i classici “chip” che vengono
impiantati sotto la pelle di cani e gatti per “marcarli” e
renderli identificabili. Questi dispositivi hanno dimensioni
paragonabili a quelle di un chicco di mais o, nei casi più
3
estremi, a quelle di un chicco di riso, e possono contenere
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
I Transponder sono molto più complessi, costosi,
ingombranti e pesanti degli RFID ma svolgono lo stesso
mestiere. Di solito hanno dimensioni e pesi che vanno da
quelle di un normale accendino a quelle di un grosso
telefono cellulare. Sono sempre dotati di una propria
alimentazione interna e/o vengono alimentati dalle
batterie del veicolo che li ospita. In alcuni casi, sono
dotati di un sistema GPS interno che fornisce loro, in ogni
istante, gli estremi della loro posizione geografica.
Possono contenere grandi quantità di dati e vengono
usati soprattutto per tracciare veicoli o parti di veicoli
(come la scatola nera di un aeroplano). Un particolare
tipo di transponder è il diffusissimo TelePass della società
autostrade.
Perchè ne sto parlando qui, insieme al Trusted
Computing ed ai DRM? Perchè nel prossimo futuro le
versioni più piccole di questi oggetti verranno utilizzate
un po’ dappertutto e permetteranno ad aziende e governi
di tracciare ogni nostro movimento.
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:
1. La tecnologia RFID ha alcuni vantaggi semplici
rispetto alle tradizionali tecnologie di Codici a
Barre e Bande magnetiche;
2. Non deve essere vicino per essere letto come le
bande magnetiche;
3. Non deve essere visibile per essere letto come per i
codici a barre;
4. Si può anche aggiungere informazioni sui chip in
funzione della tipologia del Chip (Read Only, Read
Once, Read and Write);
5. L'identificazione e la verifica avviene in 10/100 di
secondo;
6. La comunicazione può essere in chiaro o criptata;
7. RFID utilizzato su un'automobile per il pagamento
automatico dei pedaggi.
FID TAG e RFID Transponder
L'elemento che caratterizza un RFID è il transponder o
tag. Il Tag è un componente elettronico composto da un
Chip ed una antenna. Il Chip (grande pochi millimetri) e'
la parte "intelligente" costituita da una memoria non
volatile contenente un codice unico, il quale viene
trasmesso tramite l'antenna (circuito di trasmissione del
segnale) all'apparato lettore che controllerà i dati
ricevuti.
5
Funzionamento di un tag passivo: il Lettore emette un
campo elettromagnetico/elettrico che tramite il processo
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.
Un Tag può essere alimentato da una piccola batteria
interna (RFID attivi).
Transponder e antenna sono inseriti in un supporto, che
caratterizza l'uso specifico di ognuno di questi oggetti. É
possibile realizzare RFID in infiniti formati: inseriti in
etichette del tutto simili a quelle normalmente utilizzate
nei capi di abbigliamento, oppure sotto forma di adesivi
da applicare sulle confezioni di cartone dei prodotti, o
all'interno di tessere formato carta di credito.
Per accedere alle informazioni contenute nell'etichetta è
necessario un lettore fisso o portatile. Il vantaggio offerto
da questo tipo di tecnologia rispetto ai sistemi di
identificazione attualmente più utilizzati (codici a barre e
lettori a banda magnetica), è che il lettore non ha bisogno
di avere la visibilità ottica rispetto all'etichetta e funziona
in tempi estremamente ridotti (c.a. 10 centesimi di
secondo).
Modalità read-only
La modalità Read Only hanno i seguenti pregi:
1. L’RFID aperto si utilizza come tecnologia sostitutiva
del codice a barre sfruttando i seguenti vantaggi;
2. Affidabilità della lettura;
3. Eliminazione della necessità di "vedere" l'etichetta
(le etichette radio possono essere contenute
6
all'interno dei prodotti ed essere lette anche in più
esemplari contemporaneamente);
4. Capacità di lavorare in ambienti contaminati, e
sporchi;
5. Capacità di resistere, con opportuni package,
all'aggressione di agenti chimici, ambientali, di
poter operare immerso in un fluido, dentro l'oggetto
che si vuole identificare oppure all'interno di un
altro contenitore (fatti salvi quelli completamente
metallici);
6. Possibilità di leggere, nello stesso contenitore, il
codice di decine o centinaia di etichette in un lasso
temporale di pochi secondi, e di trasmetterlo al
sistema informativo di gestione;
7. I tag dotati di memorie non volatili (qualche
kilobyte) possono contenere informazioni molto
articolate sull'oggetto cui sono associate. La
modalità Read/Write permette non solo una
trasmissione di informazioni ma un loro
aggiornamento sul chip. il Tag diventa un sistema
di identificazione che può tenere traccia della storia
di un prodotto fin dalla fase di lavorazione ed
essere poi utilizzata in modo interattivo lungo tutta
la filiera fino alla distribuzione al dettaglio e in
alcuni casi sino al consumatore;
Alcuni vantaggi di questa modalità sono costituiti dalla
possibilità di memorizzare dati relativi agli indici di
qualità, ai problemi riscontrati e successivamente, dalla
semplice lettura del tag, valutare le caratteristiche
positive e negative dei prodotti o dei lotti; per esempio
applicati alle confezioni di prodotti deperibili alle alte
temperature sono in grado di informare il consumatore
7
che il livello di guardia di queste è stato superato (es:
camion guasto fermo ore sotto il sole). Nei sistemi
industriali particolarmente complessi e operanti in
ambienti ostili, la 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
L'annuncio dell'utilizzo della tecnologia RFID ha generato
diverse domande da parte dei consumatori. Negli Stati
Uniti ad esempio è stata effettuata una campagna di
boicottaggio su Benetton che aveva annunciato
semplicemente l'introduzione dei tag nei capi per finalita'
di logistica.
Alcuni Stati USA hanno approvato legislazioni per
regolare l'utilizzo delle etichette elettroniche. Dal punto
di vista della logistica non sussistono problemi di Privacy
(EPC Gen2 prevede che i tag contengono solamente un
codice univoco (un numero di serie)). Le preoccupazioni
principali riguardano la possibilità che la tecnologia
possa essere utilizzata per violare la privacy del
8
possessore degli oggetti taggati. Al momento le principali
obiezioni sono articolate sui seguenti elementi:
1. la consapevolezza o meno dell'utente che un
prodotto contenga un RFID;
2. le informazioni contenute nell'RFID;
3. la associazione possessore/TAG.
Il primo punto e' al momento allo studio delle diverse
legislature ma emerge un quadro univoco sulla necessita'
che i clienti siano informati dell'esistenza del tag, che i
tag possano essere disattivati (tramite il comando /KILL),
e che sia data la possibilita' agli utenti di verificare la
disattivazione o più semplicemente rimossi.
Il secondo punto riguarda la informativa contenuta nei
tag. Nel caso di prodotti di largo consumo le informazioni
nei tag sono codificate secondo EPC Gen2, ovvero il tag
sui prodotti contiene solo un indicativo seriale. La
pubblica opinione richiede che tali dispositivi siano
"oscurabili" o semplicemente rimossi una volta varcate le
casse del supermercato e/o negozio. La disattivazione
avviene tramite il flagging di una cella nel chip che lo
rende disattivo e non riattivabile. Il problema è che una
non riattivazione non è mai garantita al 100%, se non con
la definitiva rimozione del tag stesso.
Il terzo punto riguarda la possibilita' di associare una
persona ad un prodotto. E' possibile che una persona
male intenzionata possa leggere i codici dei tag dei
prodotti che uno acquista a distanza e possa sapere le
abitudini di consumo di ciascuna famiglia. Teoricamente
questo sarebbe possibile se una persona raccogliesse la
"spazzatura" di casa nostra e l'analizzasse leggendo
ciascun codice RFID. Oppure se creasse dei portali in
giro per la citta' che leggessero tutto quello che passa
9
sotto. Nei tag non si identifica il proprietario, ma ha
comunque un numero univoco con cui è possibile
risalirne. E i tag hanno distanze di lettura limitate, anche
se sono state smentite da varie prove sul campo:
1. nel caso dei tag 13.56Mhz la distanza di lettura
prevista é cm 30 -cm 60, al di sopra si crea una
nuvola elettromagnetica fuori normativa e
2. nel caso di tag UHF, usati per la logistica, e' 6 metri
- 10 metri
I tag UHF non funzionano in presenza di liquidi (il corpo
umano e' composto al 95% da liquidi) e quindi male si
prestano per pedinare una persona. Inoltre e' meno
costoso seguire gli spostamenti tramite la triangolazione
del GSM che disseminare il territorio di antenne (che
costano Euro 3,000 ) ogni 10 metri... È possibile leggere
oltre i 10 metri alimentando le antenne oltre i 2 Watt, ma
in tale caso si sta commettendo un crimine (ovvero
occorre una licenza da parte del Ministero delle
Telecomunicazioni oppure possono farlo agenti ed
investigatori in quanto molto costoso e rischioso e non
scalabile su una intera popolazione).
Il problema della privacy sussite ed è aggravato da fattori
come la localizzazione dei dati (nei sistemi centrali o sui
CHIP RFID), a quali dati siano scritti sui CHIP RFID oltre
al numero univoco del chip stesso, e a quale finalita' tali
dati sono scritti. E' chiaro che il semplice fatto che ogni
RFID abbia un numero univoco lo renda nei fatti un
"braccialetto elettronico" con il quale è possibile tracciare
gli spostamenti e le abitudini di una persona, nonché un
pericolo per la sicurezza per la persona stessa, potendo
essere seguita da malintenzionati dotati di lettore RFID.
10
11
C a p i t o l o 2
Realizzazione di una Struttura RfidQuanto tempo può servire per la realizzazione di una
infrastruttura RFID? Sicuramente molto dipende dal tipo
di applicazione che stiamo per andare a creare.
Riportiamo qui di seguito un esempio di grafico che
rappresenta le fasi di cui necessità la realizzazione di una
applicazione RFID.
Lo schema risulta essere il seguente:
Nel caso di utilizzo di una applicazione già esistente, i
tempi e lo sforzo necessario per lo sviluppo del prototipo
e della soluzione software saranno più brevi.
12
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:
13
L'Architettura di un sistema RFID:
Quella riportata qui di seguito risulta essere
l’architettura di un sistema RFID.
14
C a p i t o l o 3
Esempi di applicazioni RfidAndiamo qui di seguito a spiegare in quali ambiti siamo
andati a operare per la realizzazione di una applicazione
Rfid.
E’ stato possibile realizzare una applicazione Rfid
mediante i software, l’infrastruttura e le persone presenti
in Bea Systems e in k-Tech.
Spiegheremo più avanti gli ambiti in cui operano le due
aziende e soprattutto i software messi a disposizione.
La maggior parte delle prove che siamo andati a
realizzare sono state studiate e organizzate all’interno del
laboratorio Rfid creato presso la sede di Bea Systems
Italia a Roma. La parte invece di realizzazione del
software è stata implementata presso la sede di K-tech di
Roma.
L’applicazione Rfid sviluppata doveva mettere in risalto le
seguenti caratteristiche di Rfid:
1. La sicurezza;
2. La stabilità dei software realizzati medianti i
prodotti Bea;
3. La funzionalità di un sistema di controllo per una
ipotetica azienda;
15
Qui di seguito riportiamo una serie di esempi in cui è
possibile applicare i tag Rfid.
Scenario 1: realizzazione di jeans
Si sa, la moda cambia. Qualche anno fa erano di moda i
jeans a vita bassa lanciati da Madonna, l’anno prossimo
saranno di moda i jeans chissà di quale tipologia lanciati
dal solito personaggio famosa della prossima edizione del
Grande Fratello. Ammettiamo per un istante che
decidiate di comprarne un paio in un centro commerciale.
Il personale del centro commerciale ha impiantato nei
passanti della cintura dei vostri jeans un tag RFID per
tenere traccia delle scorte e per determinare il prezzo di
vendita. Sarebbe più logico ed economico usare un
normale RFID flessibile, ma questo tipo di RFID ha una
portata radio limitata, per cui il centro commerciale
decide di usare un RFID “micro” dotato di batteria
interna, che può essere letto da qualche metro di
distanza. Voi passate alla cassa (senza cassiera) ed il
costo dei jeans vi viene addebitato automaticamente sul
conto corrente (o viene chiamata la polizia, se questo non
risulta possibile). Poi fate un giro per città e
improvvisamente vi accorgete che i televisori piazzati
nelle vetrine e dentro i negozi vi mostrano offerte
imperdibili che sembrano fatte apposta per voi. Per
quanto possa sembrare incredibile, vi chiamano
addirittura per nome per attirare la vostra attenzione!
16
Niente paura: si tratta semplicemente di un effetto
collaterale del vostro RFID. Il sistema informatico del
centro commerciale ha registrato la vostra identità (dal
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.
Scenario 2: l’auto aziendale
A questo punto dovreste già essere in grado di
immaginare cosa può succedere se vi azzardate a usare
l’auto aziendale per scopi non aziendali o se vi permettete
di prendervi più di un’ora per il pranzo mentre siete in
trasferta. Dispositivi RFID (transponder) dotati di GPS e
leggibili via satellite sono già in uso da tempo per
tracciare i camion.
Ah, naturalmente gli RFID nano, micro e flessibili sono
destinati a sostituire i codici a barre. La loro lettura può
essere effettuata automaticamente da apposite stazioni
automatiche di lettura poste all’uscita dei negozi e dei
supermercati. Il sistema informatico del centro
commerciale può provvedere automaticamente ad
addebitare sul vostro conto corrente la spesa (od a
chiamare la polizia, nel caso non si riuscisse ad effettuare
17
l’addebito) nello stesso tempo che impiega per
memorizzare in un apposito database tutti le preziose
informazioni statistiche che riguardano i vostri acquisti.
Le cassiere, ovviamente, dovranno trovarsi un’altra
occupazione.
Queste sono le ragioni che hanno spinto il Garante della
Privacy (al tempo, Stefano Rodotà) ad intervenire. Presso
il sito del garante, potete trovare le linee guida che
devono essere rispettate nell’uso degli RFID. La legge
italiana prevede, tra le altre cose, che l’utente abbia il
diritto di rimuovere o distruggere l’RFID al momento del
pagamento. Purtroppo però molti dispositivi RFID non
possono essere rimossi (per esempio perchè sono
“annegati” o nascosti nel prodotto) e, in genere, non
esiste una procedura irreversibile per distruggerli che
non sia, allo stesso tempo, dannosa per il prodotto. Ad
esempio, si può distruggere alcuni tipi di RFID infilandoli
in un forno a microonde ma questo trattamento può
danneggiare molti prodotti (alimentari, ad esempio) ed
essere incompatibile con altri (oggetti metallici, ad
esempio).
Applicazioni RFID
Diversi i campi di applicazione della tecnologia. In
particolare i campi di adozione principali esistenti sono:
Monetica: Visa, Mastercard e American Express stanno
lanciando nuove carte di credito che per sicurezza,
velocità e flessibilità superano le tradizionali Chip Card.
18
Oltre 10 milioni di Americani, Giapponesi ed Inglesi
stanno usando, su base regionale, tali soluzioni. A New
York è possibile pagare il biglietto della metropolitana
con tali soluzioni.
In Italia si stanno avviando diversi test tra cui: San Paolo
di Torino e ATA Hotel (che già gestisce due dei piu'
importanti villaggi (Tanka Village ed i Giardini di Naxos)
con tale tecnologia) La tecnologia utilizzata è un taqg
13.56 MHz ISO 14443
Biglietteria Elettronica: forse l'ambito di maggiore
applicazione planetaria delle soluzioni contactless RFID. I
sistemi di transito per gli abbonati a Parigi, Londra,
Milano e Brescia utilizzano carte RFID Contactless per
permettere l'accesso ai mezzi di superficie e
metropolitana.
La tecnologia utilizzata è un taqg 13.56 MHz ISO 14443 o
ISO 15693
Logistica Magazzini: identificare ogni contenitore e
ogni scaffale di magazzino con tag riduce gli errori nei
prelievi e fornisce una identificazione certa dell'item (in
funzione del entità controllate si parla di Item Tagging
(oggetto unico) o Box Tagging). Non è necessario aprire
gli imballaggi per verificare il contenuto cercando il
codice a barre, così come non è più necessario effettuare
il conteggio manuale per la verifica dell'inventario fisico.
Con una serie di scansioni a distanza è possibile
identificare e verificare la presenza di specifici oggetti in
magazzino. Infatti la tecnologia permette di leggere
contemporaneamente più etichette (tag) in generale fino
a 100 in contemporanea. La tecnologia permette di
19
conoscere in tempo reale le giacenze di magazzino,
riordinare i capi esauriti (in tempo reale).
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)
I sistemi RFID migliorano gli attuali sistemi di
identificazione del mezzo di trasporto (l'esempio più
comune è il telepass) sia in termini di efficienza sia di
sicurezza della società erogatrice, a spese della sicurezza
(privacy) dell'utente.
Controllo di carico e scarico: è possibile
l'identificazione del carico di un mezzo di trasporto anche
con il mezzo in movimento. Non è necessario che i
prodotti siano visibili rispetto al sistema di identificazione
usato.
Controllo presenze ed accessi: RFID è una valida
alternativa sia alle tecnologie di personal identification
tradizionali (badge, tesserini, ecc.), sia alle tecnologie di
strong authentication basate sul riconoscimento degli
attributi biometrici di un individuo. A differenza di tali
tecnologie non richiede contatto visivo per
20
l'identificazione e permette il riconoscimento anche "a
distanza". L'identificazione tramite RFID oltre a rendere
più agile l'impiego di varchi motorizzati, distinguere gli
ingressi 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.
Sicurezza sul lavoro: sicurezza degli operatori di
macchina (es. una pressa) Una macchina che richiede la
protezione dell'operatore può essere controllata in base
alla presenza dell'operatore autorizzato o arrestare il suo
funzionamento se nell'area si avvicina un operatore
estraneo o non autorizzato.
Tracciamento pratiche: l’applicazione di una etichetta
RFID a ogni pratica consente di automatizzare la loro
ricerca negli archivi cartacei, di effettuare
automaticamente la registrazione del
prelievo/restituzione e di mantenere traccia dei vari
spostamenti tra uffici e depositi.
Assistenza e manutenzione: interessante è
l'applicazione di sistemi RFID nella manutenzione degli
impianti. Un esempio è quello delle aziende
21
petrolchimiche dove si devono effettuare manutenzione
sulle valvole. Con una semplice lettura del tag applicato
direttamente sulle valvole sarà possibile ottenere la storia
delle manutenzioni e riparazioni della specifica valvola.
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;
Dati anagrafici (passaporto) proprietario;
Aziende presso le quali il capo è transitato;
Controlli veterinari a cui l'animale è stato
sottoposto
Trattamenti subiti.
Biblioteche - rilevazione patrimonio librario e
movimento libri: Applicando i tag sui beni delle
biblioteche (libri, video, CD audio, ecc.) è possibile
rilevare a distanza le informazioni in esso contenute (tipo
di bene, descrizione, numero inventario, rappresentazioni
fotografica, ecc.), consentendo di amministrare i libri in
dotazione con estrema facilità ed efficacia. La tecnologia
RFID presenta vantaggi anche nelle operazioni di
22
attivazione di un prestito e restituzione dei libri alla
biblioteca, grazie alla presenza di stazioni self service
estremamente facili da usare. Dopo aver prelevato dagli
scaffali i libri da prendere in prestito, l'utente deve
avvicinarsi alla postazione e appoggiare i libri sul piano di
rilevazione assieme alla tessera della biblioteca. Gli
oggetti vengono rilevati e la transazione viene
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.
Antitaccheggio: il primo aiuto tecnologico, oggi
largamente utilizzato su scala mondiale, è arrivato dalla
EAS (Electronic Article Surveillance). Mediante
l'applicazione di un piccolo tag chipless (senza chip) agli
oggetti in vendita, un negozio può rilevare un eventuale
transito non autorizzato di un articolo attraverso un
varco. Il varco (composta da antenna) e' collegato ad un
dispositivo di segnalazione acustica e visiva.
L'EAS tuttavia non permette di rilevare né la tipologia né
il numero degli oggetti rilevati
Rilevazione dei parametri ambientali: l'ultima
frontiera tecnologica in ambito RFID riguarda
l'introduzione di tag attivi equipaggiati con sensori in
grado di rilevare i parametri climatici (temperatura,
pressione, umidità, ecc.) dell'ambiente in cui sono
immersi. Le grandezze rilevate dai sensori vengono
23
memorizzate in una apposita memoria interna, e lì
permangono fino a quando un operatore, dotato di
apposito lettore, non ne esegue lo scarico su un PC
palmare. Queste caratteristiche si rivelano strategiche
per il monitoraggio dei parametri operativi dei
macchinari in particolari realtà industriali, dove è
necessario garantire regimi operativi controllati. I tag,
grazie alle ridottissime 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.
Esempio nella catena del Catena del freddo Una
applicazione specifica è volta a controllare e mantenere
la temperatura adeguata dei prodotti lungo tutte le fasi
della loro distribuzione (trasporto, immagazzinamento,
allocazione presso i punti vendita), fino al momento della
loro consegna, al fine di garantirne la integrità e
"qualità". Questi tag (13.56 Mhz attivi) incorporano un
sensore di temperatura (sia in picco, ovvero se esce dai
parametri predefiniti, oppure continuo, monitorando
continuamente la temperatura). In questo secondo caso è
possibile programmare gli intervalli di misurazione della
temperatura e memorizzarne i valori, in modo da ottenere
un grafico nel tempo oppure identificare il momento (time
stamp) in cui il collo ha subito condizioni limite rispetto ai
parametri prefissati. La differenza di monitoraggio ha
impatto sul costo del tag che può variare da Euro 3.00 a
euro 5.00 in funzione della memoria necessaria. Essendo
tag ad alto costo, non sono "a perdere", quindi occorre
valutare il costo della logistica di rientro degli stessi.
Grazie all'utilizzo di tali soluzioni si può monitorare lo
stato di conservazione di una sostanza, oppure segnalare
eventuali allarmi quando il parametro temperatura non
24
fosse nei range voluti, senza aprire le confezioni che
proteggono la sostanza conservata in temperatura e
gestendo il dato in via informatica, magari da un sito
centrale, dove poter prendere le decisioni del caso:
eliminare il prodotto oppure accelerare il trattamento di
un processo.
25
C a p i t o l o 4
Rfid e sua capacità di memorizzazione
Rfid non è una tecnologia nuova ma veniva già impiegata
durante la seconda guerra mondiale per distinguere gli
aerei nemici da quella amici.
Un sistema Rfid è composto principalmente da due parti
fondamentali:
1. Trasponder (Tag): contiene i dati;
2. Reader: richiede i dati
3.
Rfid system si occupa di collezionare le informazioni
contenute nella memoria dei tag utilizzando onde radio.
Le informazioni contenuto all’interno di un tag possono
essere:
1. Un numero identificativo;
2. Altre informazioni scelte in base alle esigenze (ad
esempio il codice di un prodotto).
Verrebbe da domandarsi a questo punto: quale è il
vantaggio dell’uso di un sistema Rfid rispetto ai normali
codici a barre? Li ricapitoliamo qui di seguito:
1. Non ha bisogno di un line of sight (normale codice a
barre) per essere letto;
2. I tag possono inizializzare procedura di sicurezza
nel caso fossero rimosse;
26
3. Tag e reader non sono sensibili all’orientamento;
4. Scanning automatico senza bisogno di un
operatore;
5. Ogni tag può gestire altre informazioni oltre ad un
product number;
6. Ogni tag può essere individualmente etichettato;
7. Possono essere letti più tag contemporaneamente;
8. I tag non possono essere solo read only. O meglio le
informazioni possono essere aggiornate;
9. I tag sono difficili da contraffare;
10. Rfid possono essere utilizzati anche in
condizioni metereologiche estreme.
Gli svantaggi dell’Rfid invece sono i seguenti:
1. Un alto costo per il controllo della produzione
utlizzando questa tecnologia;
2. Interferenze radio, ossia alcune onde radio non
riescono a passare alcuni materiali;
3. Alto costo di implementazione delle infrastrutture
di sistema;
4. Non ci sono interferenze internazionali per l’uso di
Rfid.
Precedentemente abbiamo parlato di Tag e Reader.
Andiamo a spiegare brevemente cosa sono. Spieghiamolo
qui di seguito:
27
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:
1. Passivi: antenna + chip. Non hanno batteria. Per
rispondere sfruttano la potenza del campo
magnetico creata da reader;
2. Semi-Passivi: molto simili ai tag passivi. Hanno al
proprio interno una piccola batteria. Sono utilizzati
per per beni di alto valore;
3. Attivi: permettono un lungo raggio di trasmissione
(circa 50 mt). Hanno una più grande memoria
rispetto ai tag passivi e le batterie durano dai 5 ai
10 anni.
Le memorie dei tag possono essere classificate in questo
modo:
1. Read only memory;
2. Read/Write;
La capacità di memorizzazione va da 16 bytes a 256 kb.
Possiamo memorizzare il codice del prodotto o anche
altre informazioni (ad esempio la temperatura di un
oggetto).
Riportiamo qui di seguito una tabella riepilogativa che
mette a confronto le varie bande di frequenze utilizzate
per RFID:
28
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:
1. Condivisione delle informazioni tra compagnie
diverse;
2. Identificazione automatica di oggetti univocamente
individuati.
Questo network è composto da 5 elementi. Prima di
spiegarli riportiamo qui di seguito lo schema che
rappresenta gli elementi:
29
Andiamo a spiegare brevemente gli elementi che la
compongono:
Elettronic Product Code (EPC): come il Universal
Product Number nei codici a barre rappresenta il
fondamentale identificatore per un oggetto fisico in un
EPC network;
ID System (EPC tag e reader): i tag comunicano il
proprio EPC agli EPC reader usando Radio Frequency
Identification. Le comunicazioni avvengono tramite onde
radio. I reader comunicano le informazioni raccolte
all’information system della compagnia per mezzo del
Epc middleware;
EPC middleware: detto anche Savant, permette lo
scambio dei dati fra il sistema fisico degli RFID e le
applicazioni;
Object Name Service (ONS): fornisce la possibilità di
localizzare un server che contiene ulteriori informazioni
su un particolare EPC in qualsiasi posto del mondo. È un
servizio simile al DNS del Web;
Physical Markup Language: il linguaggio comune in
EPCglobal network per definire i dati negli oggetti fisici.
30
I dati RFID possono contenere grandi flussi di dati e
contenere delle ripetizioni. Andiamo ora a vedere come è
possibile osservarli:
1. Compressione dei dati: molti oggetti si muovono
contemporaneamente lungo le stesse locazioni, possono
essere memorizzati anche solo come record;
2. Ogni volta che si esegue una interrogazione non
vengono memorizzati dati ma vengono prese in
considerazioni solamente le informazioni temporanea che
sono EPC, location, time_in; time_out. In questo modo
riusciamo a evitare le ridondanze.
31
32
C a p i t o l o 5
Come avviene l’acquisizioneL’acquisizione avviene in modalità automatica per mezzo
degli RFID reader. Le modalità possono essere due:
1. Sequential Mode: le onde radio del reader
switchano rapidamente, il tag riconosce il gap e
risponde al reader;
2. Inventory mode: se il campo magnetico di un
reader è presente i tag rispondono in broadcast
(interrogazione di più tag alla volta).
I dati devono poi essere trasformati per dar loro un alto
livello semantico.
Dopo l’acquisizione si possono avere tre situazioni:
1. Data filtering: le informazioni ottenute dal reader
possono contenere errori e le informazioni possono
essere duplicate;
2. Location Trasformation: le osservazioni possono
implicare un cambiamento di locazione, queste
devono essere interpretate e rappresentate;
3. Data aggregation: ci possono essere relazioni
semantiche fra gli oggetti e queste devono essere
interpretate in accordo ai pattern utilizzati.
33
Fino ad ora abbiamo parlato sempre di Rfid Middleware,
andiamo ora a vedere come è composto:
1. Rfid Reader;
2. Event Manager:
3. Reader: componente software che comunica con i
reader e li può interrogare;
4. Filter: implementa le funzioni di filtro;
5. Writer: scrivi i dati in PML e inoltra i dati verso
Web services, JMS, pacchetti TCP/IP (più avanti
faremo vedere la web application da noi creata).
6. Rfid Data Server:
7. Data managment: ci sono tre differenti livelli:
8. Semantic data processing: filtro dei dati,
trasformazione automatica dei dati;
9. Query: definisce i metodi per il tracking e il
monitoring degli oggetti;
10. Decision making: business intelligence.
11. Data store: implementa lo schema di
modellazione degli oggetti;
12. Data archive: i dati non attivi sono
memorizzati nella partizione storica del data
archive;
13. Product data store: informazioni statiche
relative agli oggetti;
34
14. Integration interface: integrare il sistema con
le altre applicazioni.
Quando vengono interrogate, ad esempio in una catena di
montaggio, più oggetti sui quali ci sono più tag possono
verificarsi le seguente problematiche:
1. Collisioni dei segnali in arrivo del reader;
2. Protocolli di collision avoidance (che non aumentino
eccessivamente i costi);
E’ possibile interrogare un oggetto da più reader?
Sicuramente si e questo genera una duplicazione delle
informazioni.
Infine definiamo i vantaggi portati dagli Rfid.
I benefici portati da Rfid sono i seguenti:
1. Privacy: associazione Id oggetto – Il cliente può
permettersi di monitorare i comportamenti di tutti
gli oggetti che contengono un tag su di essi;
2. Sicurezza: un sistema basato su RFID è esposto ai
medesimi rischi di sicurezza di qualsiasi rete,
inoltre ci sono rischi di cloning dei tag e di raccolta
di informazioni sensibili.
35
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.
I possibili attacchi che può ricevere un sistema RFID sono
i seguenti:
1. Denial of Service: creare numerosi fake tag che
effettuano numerose richieste ad un reader
rendendolo inutilizzabile;
2. Man in the middle: una terza parte può ascoltare
le comunicazioni fra reader e tag per ottenere
informazioni sensibili;
3. Attacchi fisici ai tag o ai reader: azioni riverse
enginering al fine di creare falsi tag per effettuare
spoofing (Lo spoofing di dati consiste nell'inserire,
modificare o cancellare i dati presenti in un
pacchetto che viaggia sulla rete).
Infine parliamo anche di privacy. L’utilizzo di un unico Id
fa aumentare i rischi di minaccia alla privacy
permettendo una facile associazione ID oggetto – identità
della persona.
Le situazioni che possono verificarsi vengono qui di
seguito elencate:
36
1. Action threat: il comportamento di un individuo
può essere inferito monitorando le azioni di gruppi
di tag;
2. Association threat: al momento dell’acquisto di un
prodotto equipaggiato con un RFID tag, il cliente
può essere associato al numero elettronico seriale
del prodotto;
3. Location threat: l’associazione individuo – id tag
permette di rilevare la posizione dell’individuo se si
monitora quel tag;
4. La posizione di un oggetto con tag è
suscettibile a rilevamenti non autorizzati;
5. Preference threat: il tag in un oggetto identifica
univocamente:
6. Produttore;
7. Tipo di prodotto;
8. Codice identificativo unico;
9. Constellation threat: i tag vicini ad una persona
formano una costellazione e questo rende possibile
tenere traccia di una persona senza conoscerne
l’identità;
10. Transaction threat: quando un oggetto
taggato passa da una costellazione ad un’altra è
facile inferire una transazione fra gli individui
associati a queste costellazioni.
37
38
C a p i t o l o 6
Presentazione del progetto Rfid realizzato
L’idea di Rfid è nata in Bea System insieme a K-Tech.
Queste sono le due società nelle quali ho potuto effettuare
studi e ricerche su questa tecnologia che come già detto,
non risulta essere nuova (perché utilizzata anche nella
seconda guerra mondiale) ma che sicuramente cambierà il
modo di gestire, acquistare merci e di effettuare
transazioni economiche.
Il progetto è durato all’incirca 12 mesi. Per la realizazione
si sono dovuti utilizzare tre software:
39
1.Bea Portal per la realizzazione di un portale dove era
possibile, mediante interrogazione ad un database,
conoscere lo stato delle spedizioni.
2.Bea Rfid Edge Server per l’interfacciamento tra il
software e la parte Hardware;
3.Bea WebLogic 8.1 con il quale creare l’ambiente di
sviluppo in java.
Abbiamo parlato fino adesso della parte software e dei
software utilizzati.
K-Tech nell’utilizzo di questi software ha il miglior staff
presente in Italia proprio perché attraverso lei in Bea
vengono eseguiti corsi sui vari prodotti. K-Tech è
riconosciuto da Bea come patner.
Analizziamo ora la parte hardware utilizzata. Come
spiegato precedentemente nell’introduzione di questa tesi
un sistema Rfid è un sistema piuttosto complesso formato
da Hardware e Software. L’hardware ha un ruolo
importantissimo per il fatto che senza antenne e Tag i
prodotti non possono essere rilevati. Il software invece
permette all’utente di interrogare, caso mai con una
rinnovata e carina interfaccia grafica i dati rilevati dalle
antenne.
L’idea è partita dall’introduzione nel 2006 di un nuovo
prodotto in casa Bea: Bea Rfid Edge Server. Tale
applicativo è stato introdotto per riuscire ad avere un
40
nuovo sbocco nel 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.
Per la realizzazione di questo progetto come si è
proceduto? Prima di tutto, dopo più incontri con il
personale che mi seguiva all’interno delle due aziende
abbiamo steso un roadmap per l’esecuzione del progetto,
utilizzando un progetto pilota che era nato all’interno di
Bea. Proprio in questo periodo infatti all’interno di Bea
System era stato istituito un personaggio che si occupa
solo di Rfid. E proprio grazie alla collaborazione con il
dott. Grabriele Provinciali sono venuto a conoscenza di
nuove tecnologie che riguardavano la materia, ma
soprattutto ho potuto ricevere un minimo di conoscenza
per quello che riguarda lo sviluppo di un progetto Rfid.
A questo punto sono stato inserito all’interno di un
progetto piuttosto ambito: la presentazione del nuovo
prodotto di Bea per L’RFID ai clienti italiani. Le
caratteristiche fondamentali di questa presentazione
dovevano essere le seguenti:
Parte 1:
1.Presentazione del prodotto Rfid Edge Server e di
tutta la famiglia RFID;
2.Cos’è RFID;
41
3.Quali sono le sue caratteristiche più importanti;
4.Perché utilizzare Rfid;
5.Cenni storici su Rfid;
6.Perché cambiare la propria organizzazione e passare
ad un sistema di gestione controllato da Rfid;
Parte 2:
Sicurezza: dimostrazione pratica che Rfid è sicuro e che in
fase di spedizione, se si vuole parlare di anti sabotaggio in
aziende che fanno logistica, nulla sfugge alle antenne che
compongono il sistema. Questa parte è formata più dai
componenti hardware che da componenti software. Ma
soprattutto è la parte fondamentale per il fatto che
dovevano lavorare insieme hardware e software realizzato
precedentemente.
Fino ad ora abbiamo spiegato come era composta la
dimostrazione che dovevamo presentare. Come abbiamo
proceduto per arrivare al nostro obiettivo? Spieghiamo
tutto brevemente qui di seguito.
Abbiamo prima di tutto modificato un ufficio rendendolo
un laboratorio Rfid. Il laboratorio era composto dalle
seguenti componenti:
1. Server Hp con processore Xeon gentilmente offerto
da Hp. Su questo server dovevamo far girare prima
di tutto Edge Server e simulare, insieme
42
all’applicativo di CAEN, le rilevazioni. Forse
verrebbe da domandarsi per quale motivo dovevamo
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;
2. N° 04 antenne con caratteristiche differenti. Le
antenne erano presenti in un N° 02 in ogni portale e
servivano per effettuare le rilevazioni;
3. N° 02 portali in legno realizzati appositamente per
questa presentazione. Le caratteristiche dei portali
verrano portate nella sezione apposita di questa tesi;
4. Varie scatole sui quali erano attaccati dei tag per
effettuare delle rilevazioni;
5. Tag di vario genere in modo da poterli attaccare sui
prodotti che volevamo rilevare.
43
La realizzazione di questa presentazione mi ha permesso
di avere conoscenze in merito a Rfid ma soprattutto ho
potuto conoscere e integrare le funzionalità dei vari
prodotti 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.
44
C a p i t o l o 7
Creazione ambiente di sviluppo
Introduciamo ora l’ambiente di lavoro che è stato
realizzato. Prima di tutto spieghiamo cosa è un tag e poi
analizziamo quello che abbiamo realizzato.
Un tag non è altro che un etichetta che può essere
rilevata da un lettore RFID. Il funzionamento è
semplice, lo spieghiamo brevemente qui di seguito: un
qualunque oggetto (o scatola) con un tag attaccato su di
esso può essere rilevato da un lettore RFID se è passato
vicino ad esso. Il tag, attraverso le onde elettromagnetiche
si alimenta e risponde fornendo un ID che viene rilevato
da un elemento (configurato precedentemente,
normalmente un server con un software di rilevazione
apposito – più avanti spiegheremo il software di
rilevazione utilizzato) capace di fornire caratteristiche e
informazioni sull’elemento rilevato.
La rilevazione può riguardare ogni cosa, o meglio, ogni
cosa su cui è possibile applicare un tag che possa essere
riconosciuto.
45
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.
Figura1
11
2
22
46
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.
47
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.
48
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.
I mini portali realizzato in legno e utilizzati erano i
seguenti:
49
MiniVarco RFIDRealizzato 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).
80 cm
50 c
m
32 cm
Perché utilizzare il legno? È un materiale a basso costo.
I varchi simulano due sezioni fondamentali nella
produzione di elementi in una catena di montaggio:
1. Varco per la preparazione degli ordini;
2. Varco per la spedizione degli ordini.
Sui lati interni dei miniportali abbiamo montato le antenne
di rilevazione.
50
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.
Le prove che abbiamo effettuato vengono catalogate qui di
seguito:
1.Simulazione e creazione di 2 varchi RFID;
2.Studio di differenti collanti per attaccare i TAG;
3.Posizionamento dei tag in vari posti sulle scatole;
4.Utilizzo di scatole di cartone con rivestimenti
differenti;
5.Utilizzo di scatole di materiali diversi dal cartone;
6.Utilizzo di vassoi di plastica utilizzati per simulare
carrelli trasportatori;
7.Utilizzo di vassoi di plastica con rivestimenti laterali.
51
√ Studio di differenti collanti per attaccare i
TAG
I collanti che abbiamo utilizzato sono tre:
Colla (pritt di tipo stick);
Scotch bi-adesivo;
Scotch
Considerazioni Finali
a. Colla Stick
Qui di seguito riportiamo le caratteristiche:
Il barattolino preso in considerazione era da 20
grammi. Non abbiamo riscontrato nessun
problema in quanto è risultata essere molto
leggera e soprattutto, non dava fastidio in alcun
modo al tag.
Nel nostro caso è stata anche molto utile
soprattutto per il fatto che quando dovevamo
52
b. Scotch Bi-Adesivo
La larghezza del nastro utilizzato era di 1 cm e il suo
spessore era di 0.4 mm. E’ risultato il miglior collante per
provare i tag su più scatole e di conseguenza per
effettuare più prove. Anche in questo caso il lettore RFID
non ha avuto nessun problema. E anche per noi è stato
utile perché è stato agevole lo staccare un tag da uno
scatola ad un’altra.
c. Scotch
Per lo scotch tradizionale valgono le stesse considerazioni
fatte per lo scotch bi-adesivo. Abbiamo notato però che se
mettevamo più di una striscia dietro il tag, la rilevazione
avveniva con fatica e non sempre.
Considerazioni Finali
53
Ogni tag di prova ha dietro di se già uno striscia adesiva
che permette di attaccarlo dove vogliano. L’intera
superficie del tag è ricoperta da scotch bi-adesivo. Nel
nostro caso abbiamo fatte le prove con il collante, con lo
scotch tradizionale e bi-adesivo per vedere quale era il
migliore. E soprattutto, abbiamo utilizzato queste
alternative perché il numero di tag a nostra disposizione
era limitato. Di conseguenza, per poter provare i tag su
scatole differenti dovevamo per forza proseguire come
spiegato in questo paragrafo.
Il tag è risultato attaccato in maniera ottimale nel
seguente modo: una sola striscia di scotch, sia esso bi-
adesivo o normale.
54
C a p i t o l o 8
Software utilizzati in Bea
Introduciamo ora i software bea che siamo andati ad
utilizzare. I software Bea sono i seguenti:
1.Bea WebLogic Platform;
2.Bea Portal;
3.Bea Rfid Edge Server
Ora introdurremmo ogni software spiegando le
caratteristiche fondamentali e per quale motivo lo
abbiamo utilizzato.
Introduzione a Bea WebLogic Platform e
Bea Portal
Grazie ad una potente combinazione di piattaforma,
practice e persone, BEA offre la via più sicura per
implementare con successo una SOA (Service-Oriented
Architecture), permettendoti di sfruttare i vantaggi offerti
dalle SOA con maggiore rapidità e sicurezza.
55
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.
56
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.
BEA fornisce una Service Infrastructure di livello
superiore per gestire con successo le SOA e migliorare
l’agilità e l’efficienza di business.
Il ciclo di vita dei Servizi per Bea WebLogic risulta essere
il seguente:
Sfruttando un’infrastruttura servizi condivisa, la famiglia
BEA AquaLogic permette di gestire i servizi per tutto il
ciclo di vita SOA.
57
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).
La 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 per sviluppatori che vogliono abilitare le proprie
applicazioni ai servizi.
58
BEA WebLogic Server
Questa versione più potente e affidabile dell’application
server J2EE leader nel mondo è la base ideale per
costruire le SOA. BEA WebLogic Server 9.0 è conforme
alle specifiche J2EE 1.4 ed estende ulteriormente gli
standard più avanzati per fornire qualità di servizio senza
precedenti attraverso l’intera azienda.
BEA WebLogic Server 9.1 includes a new BEA Smart
Update tool that helps to easily download, apply and
manage maintenance updates, including patches, to your
BEA WebLogic Servers. Other updates can be found in the
areas of securirty (SAML), diagnostics, messaging, web
services and more.
BEA WebLogic Portal
BEA WebLogic Portal 8.1 semplifica la realizzazione e
gestione di portali su misura, permettendoti di sfruttare
un ambiente di servizi condiviso per implementare le
modifiche riducendo al minimo le complessità e gli sforzi.
BEA WebLogic Integration
BEA WebLogic Integration 8.1 permette di far convergere
in una sola soluzione unificata di business integrata due
attività altrimenti disparate, quali l’integrazione e lo
sviluppo applicativo.
59
BEA WebLogic RFID Product Family
BEA's WebLogic RFID edge and enterprise products
deliver the first end-to-end, standards-based RFID
infrastructure platform designed to automate new RFID
enabled business processes. The powerful combination of
leading RFID infrastructure technology and BEA's Service-
Oriented Architecture (SOA) driven platform allow you to
turn RFID data into meaningful information for
competitive advantage and financial improvement through
targeted, cost effective and integrated solutions.
BEA WebLogic Workshop
BEA WebLogic Workshop 8.1 riduce in modo molto
significativo le complessità di migrazione ad una SOA
riducendo, al contempo, i costi di vita complessivi della tua
infrastruttura IT.
BEA JRockit 5.0 JDK
Utilizzando BEA JRockit 5.0 Java Development Kit (JDK),
gli sviluppatori Java possono mettere in esercizio più
velocemente e con maggiore efficienza le applicazioni,
ottenendo prestazioni ottimali con configurazioni minime.
60
Abbiamo parlato di applicazioni SOA, quali sono le
applicazioni SOA e cosa sono? Spieghiamo brevemente qui
di seguito di cosa stiamo parlando.
Gartner [GARTNER] divide i modi in cui si possono integrare le applicazioni in tre casistiche fondamentali:
Data consistency Multistep Process Composite Application
descriviamole brevemente.
Data consistency
L'obiettivo di questa tecnica è quella di tenere allineati i
database di una o più applicazioni sui fatti rilevanti per
l'azienda. La caratteristica principale di questa tecnica è
che le applicazioni sono logicamente e fisicamente
indipendenti perché le sincronizzazioni fra due
applicazioni avvengono in processi separati e in maniera
indipendente da quello che sta facendo l'applicazione.
Questo pattern di integrazione (vedi figura 1) di fatto
viene implementato da processi batch. In genere si parla
poco dei batch, ma nei sistemi informativi enterprise essi
sono tuttora un importante mezzo di integrazione e
rappresentano ancora una parte rilevante delle
elaborazioni.
61
Figura 1 - Data consistency
Multistep Process
Secondo questo pattern (vedi figura 2) una applicazione
scatena un evento che è propagato attraverso le
applicazioni interessate con uno o più step. La
comunicazione è asincrona e monodirezionale. In questo
caso le applicazioni sono fisicamente indipendenti, ma non
lo sono logicamente in quanto l'elaborazione dell'evento
necessita della logica di ogni applicazione che vi
partecipa. Questo pattern si ha ogni volta che si
costruiscono architetture asincrone a messaggi.
Figura 2 - Multistep Process
62
Composite Application
In questo caso una applicazione comunica in maniera
bidirezionale e tipicamente sincrona con una o più
applicazioni. In questo pattern (vedi figura 3) il grado di
accoppiamento delle applicazioni è molto elevato, al punto
che si può sostenere che nell'insieme le applicazioni così
integrate vanno a comporre una nuova applicazione.
Questa è la modalità di integrazione che oggi si incontra
più spesso e che ha permesso a tante aziende di creare
applicazioni di integrazione del loro legacy al fine di
esporre le funzionalità aziendali mediante un nuovo front-
end (tipicamente un'applicazione web).
Figura 3 - Composite Application
63
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.
64
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.
65
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.
66
Figura 4 - Blueprint architettura SOA
67
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.
Quindi per la buona riuscita dell'evoluzione verso SOA da
parte del management è necessario supportare e
sostenere un continuo processo di rinnovo del parco
applicativo mediante acquisizioni di applicazioni a servizi o
conversioni delle applicazioni esistenti.
68
I servizi
Un servizio è una funzionalità di business autoconsistente.
Autoconsistente significa che per usufruire della
funzionalità messa a disposizione dal servizio è sufficiente
chiamarlo senza dovere effettuare altre operazioni. Come
già evidenziato in [PIRACCINI] queste proprietà si
ottengono creando servizi stateless e di granularità
piuttosto grossa.
Mentre dovrebbe essere chiaro a tutti cosa significa
servizio stateless, il discorso sulla granularità fine/grossa è
molto più soggettivo perché il tema è a cavallo fra il piano
architetturale e quello funzionale.
Ad esempio una applicazione di CRM potrebbe esporre tre
servizi come mostrato in figura 6.
Figura 5 - CRM a servizi
69
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
E' abbastanza evidente quindi che i servizi devono essere
disegnati assieme agli esperti funzionali e di dominio.
Anche per queste persone il passaggio ad una architettura
SOA ha degli impatti. Infatti spesso gli analisti funzionali
partono ad eseguire la loro analisi dall'interfaccia grafica
(spesso chiamata mappa) che l'utente si troverà di fronte.
In questa maniera il layer di business (e quindi in questo
caso i servizi) viene modellato in modo da rispondere
perfettamente alle necessità dell'applicazione di front-end,
incernierandosi con le mappe e le navigazioni sulle mappe
previste dagli analisti. Il grado di riusabilità di servizi
ottenuti in questo modo è piuttosto basso, anzi in generale
si può affermare che solo l'applicazione di front-end sarà
in grado di utilizzare i servizi (e per essa andranno
benissimo).
70
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.
L'analista deve partire non più dalle mappe, ma
cominciare a ragionare sull'interfaccia dei servizi, è
importante dunque che esita una interfaccia esplicita e
dichiarata in un documento.
Una società con cui sono in contatto e che vuole
sviluppare applicazioni a servizi ha creato due gruppi uno
per il layer dei servizi ed uno per il front-end e ha adottato
la regola che questi gruppi possono comunicare solo
mediante documenti. Questa situazione che per certi versi
può sembrare estrema e che sicuramente aumenta i costi
di sviluppo dell'applicazioni modella però una situazione
realistica: infatti in futuro sempre più spesso ci sarà la
necessità di integrare applicazioni di due società diverse
che vogliono fare business assieme. In questo caso
abbiamo due sistemi informativi differenti e anche due
gruppi di lavoro remoti per cui è inevitabile che si instauri
un processo di analisi e sviluppo basato sullo scambio di
documenti.
71
Una interfaccia chiara e documentata che rappresenti il
contratto del servizio è quindi il deliverable fondamentale
della fase di analisi di un servizio.
I servizi e il change management
Se stiamo disegnando architetture SOA è perché vogliamo
che i servizi che rendiamo disponibili siano utilizzati da più
utenti possibili, magari anche esterni al nostro sistema
informativo.
Questo pone dei vincoli (anche contrattuali) su come e
quando il comportamento o l'interfaccia del servizio può
essere cambiato, cioè pone dei vincoli sul change
management. Il motivo per cui questo accade è che se si
hanno molti utenti di un servizio e si deve rilasciare una
nuova versione dello stesso non è possibile obbligare tutti
gli utenti a fare gli adeguamenti necessari né è possibile
interrompere la fornitura di servizio a chi non si adegua.
Piuttosto che affrontare il problema di caso in caso è
meglio darsi delle regole generali che valgano per tutti i
servizi realizzando un processo di change management su
cui tutte le parti concordino. In generale il processo di
change management dovrà consentire:
La possibilità del consumer del servizio di scegliere a
quale versione del servizio agganciarsi.
La possibilità al provider del servizio di deprecare e
successivamente dismettere vecchie versioni di un
servizio.
72
Per raggiungere questi obiettivi è sufficiente che il sistema
supporti più versioni in linea del medesimo servizio come
mostrato in figura 6.
Figura 6 - Versionamento dei servizi
73
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.
Management e monitoring del servizio
I servizi nelle architetture SOA dovranno fornire un
servizio (scusate il bisticcio di parole) conforme a certi
standard di qualità (SLA Service Level Agreement) su cui
le parti hanno convenuto. Possono aversi casi in cui gli
SLA sono differenti per tipo di servizio, oppure per
chiamante oppure cambiano a seconda dell'orario del
giorno. In ogni caso deve essere possibile monitorare il
comportamento dei servizi ed eventualmente avere
strumenti per intervenire e quindi gestire il servizio.
L'attenzione si sposta dunque sul servizio e non è più
sull'applicazione che fornisce il servizio, ad esempio una
applicazione potrebbe avere servizi con SLA differenti.
Inoltre dovrebbe essere possibile controllare tutti i servizi
(anche di differenti applicazioni) da un'unica console.
74
Questo naturalmente è fattibile più agevolmente se i
servizi sono disegnati in partenza per essere monitorati e
gestiti.
Inoltre il servizio (e non l'applicazione nel suo complesso)
deve avere un log e deve essere "auditabile" (cioè fornire
un insieme di dati sufficienti alle strutture di audit ad
eseguire i propri controlli). Infatti potrei avere bisogno che
due servizi della medesima applicazione uno di tipo
inquiry ed uno di tipo dispositivo scrivano un log di audit
su due supporti separati.
Infine un servizio potrebbe essere a pagamento, in tal caso
deve essere "accountabile" cioè deve essere possibile
tenere traccia del chiamante e del numero delle chiamate
per potere calcolare i costi.
Il disaccoppiamento
Una pratica su cui insiste SOA è il disaccoppiamento.
Il disaccoppiamento fra il fornitore e il consumatore del
servizio è una caratteristica molto importante in una
architettura di integrazione. Infatti più è alto più
l'architettura è agile e gestibile, e di conseguenza a basso
costo. In teoria se non vi fosse nessun accoppiamento fra
consumatore e fornitore il costo di gestione del sistema
sarebbe dato dalla somma del costo di gestione delle due
applicazioni. Nella realtà i costi invece sono sempre
maggiori perché appunto si aggiunge il costo di
integrazione.
75
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
76
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
77
rappresenta la 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.
Per limitare l'accoppiamento applicativo SOA propone che
le applicazioni mantengano invariata la propria
rappresentazione dei dati senza quindi avere oggetti in
comune. Per fare ciò una possibilità è, come mostrato in
figura 7, che le applicazioni serializzino i dati in un
messaggio in un formato che sia trasformabile facilmente
da un ente intermedio.
78
Figura 7 - Accoppiamento applicativo
79
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.
XML e XSLT sono naturalmente oggi i candidati ideali per
effettuare queste operazioni, ma l'idea del
disaccoppiamento applicativo rimane al di là della scelta di
queste tecnologie. Soluzioni più evolute possono
prevedere la presenza di un dizionario dati che
dinamicamente configuri la trasformazione da effettuare.
Accoppiamento tecnologico
L'accoppiamento tecnologico si ha quando due
applicazioni devono condividere qualche aspetto
tecnologico per funzionare correttamente. Per esempio se
due applicazioni devono essere sviluppate con J2EE o
devono avere il runtime CORBA dello stesso vendor allora
sono accoppiate tecnologicamente.
Nello sviluppo di un sistema informativo SOA non devono
esservi vincoli che generino accoppiamenti tecnologici.
Quindi in teoria SOA ammette la coesistenza di qualunque
tecnologia.
80
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.
Ma anche l'omogeneità tecnologica totale può avere degli
svantaggi: per prima cosa ottenerla su un sistema già
avviato può essere molto costoso; inoltre la possibilità di
ospitare più di una tecnologia in un sistema informativo, in
caso di acquisto di nuove applicazioni consente di
esaminare più candidati e quindi potere scegliere sempre
il prodotto migliore. Infine avere più di una tecnologia
consente di mettere in competizione i fornitori di questa
tecnologia e quindi in generale di abbassare i prezzi delle
licenze (bisogna essere bravi per riuscirci, ma si può fare).
Accoppiamento temporale
81
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.
Figura 8 - Accoppiamento temporale
Layer dell'architettura SOA
82
Come nelle architetture distribuite è possibile distinguere
facilmente alcuni layer (tipicamente dati, business,
presentation) la stessa cosa si può fare per le architetture
SOA.
Figura 9 - Layer architettura SOA
I layer che si possono individuare sono mostrati in figura 9
e sono i seguenti:
1.Layer delle applicazioni SOA
2.Layer tecnologico e di normalizzazione
3.Layer di composizione dei processi
4.User end point layer
83
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).
Layer delle applicazioni SOA
In questo layer ci sono le applicazioni che espongono i
servizi con le caratteristiche di cui si è parlato
precedentemente.
Come già detto le applicazioni possono esporre servizi sia
perché sono state concepite a servizi sia perché sono state
wrappate con qualcosa che le mostra "come se" fossero
state concepite a servizi.
Come si può vedere dalla figura le applicazioni a servizi
non hanno legami esterni se non mediante servizi. Questo
dovrebbe semplificare le operazioni di sostituzione
dell'applicazione dovute a nuovo sviluppo o a un nuovo
acquisto. Infatti in questa architettura sostituire
un'applicazione significa trovare una applicazione che
possa esporre gli stessi servizi della precedente (e migrare
i dati).
Da un punto di vista transazionale tutte le unità di lavoro
devono chiudersi a questo livello; questo consente di
evitare o quantomeno limitare al massimo l'uso di
transazioni distribuite.
Layer tecnologico e di normalizzazione dati
84
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.
Il layer tecnologico e di normalizzazione dati si occupa di
esporre ai layer successivi una sola tecnologia e di
effettuare le dovuta normalizzazioni sui dati.
Il protocollo scelto per i layer successivi deve avere il più
alto grado di accettazione e di interoperabilità possibile; il
pensiero va dunque (ad oggi) ai Web Services, infatti
rispetto a CORBA ed altri sistemi di elaborazione
distribuita i Web Services sembrano avere l'appoggio dei
maggiori vendor e quindi come protocollo sembra il
migliore candidato su cui investire.
Questo layer era stato previsto nel mondo java dalla
specifica JBI (Java Business Integration) [JSR-208] già nel
marzo 2003. Al tempo SOA non era ancora di moda per cui
nella specifica non si fa uso esplicito di tutto il lessico
SOA. Purtroppo come spesso accade nel JCP (Java
Community Process) le cose procedono a rilento e ad oggi
la specifica è in public review, ma non è stata pubblicata. I
vendor di conseguenza non la implementano e stanno
prendendo strade proprietarie come gli ESB (Enterprise
Service BUS) di cui parleremo fra poco.
85
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.
Layer di composizione di processi
Una volta ottenuta l'omogeneità tecnologica e di
rappresentazione dei dati è possibile comporre i servizi in
processi di business.
Questa composizione si può realizzare con servizi ad hoc
oppure mediante un motore di workflow. Va notato
comunque che questo è un layer opzionale di SOA e va
implementato solo se strettamente necessario.
Come linguaggio standard per la definizione di workflow
sembra si stia imponendo è BPEL [BPEL]. Questo
linguaggio consente di definire processi di business
secondo molti dei pattern con cui un workflow può
presentarsi. Per una trattazione completa dei pattern si
veda [WORKFLOWPATTERN]. Il vantaggio di avere
definito un workflow mediante un linguaggio standard è
che in teoria il cambiamento del motore di workflow non
dovrebbe avere ripercussioni sul workflow già sviluppato.
86
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.
Da un punto di vista transazionale, poiché come abbiamo
visto le unità di lavoro si chiudono sul layer delle
applicazioni a servizi, la composizione dei servizi non sarà
transazionale e quindi si dovranno prevedere servizi di
compensazione. BPEL per la verità consente sia questo
tipo di aggregazione sia aggregazioni transazionali.
87
User end-point layer
In questo layer si situano tutti gli utilizzatori dei servizi.
I particolare quindi le applicazioni di front-end e le
applicazioni esterne al sistema informativo che hanno
bisogno di accedere ai servizi.
Può valere la pena sottolineare che le applicazioni di front-
end non perdono la loro importanza nelle architetture
SOA. Infatti queste sono le applicazioni che vede l'utente
ed in fondo è proprio l'utente a determinare il successo o
meno di un progetto software. Quindi nulla vieta che le
applicazioni di front-end siano complesse magari a più
livelli e con dati appoggiati su database. Ciò che consiglia
l'architettura SOA è che la logica di business sia realizzata
mediante chiamate ai servizi. Tutto il resto della logica,
quindi logica di sessione, di navigazione, di sicurezza, di
caching, di logging ecc…, può e deve essere realizzata
nell'applicazione di front-end, in modo che questa sia la
più efficiente possibile.
Come già detto l'implementazione di una architettura SOA
deve essere un processo evolutivo. Quindi ad esempio sarà
possibile in alcune fasi dell'evoluzione che le applicazioni a
servizi abbiano anche un front-end tradizionale (cioè non a
servizi) per esempio per le funzioni di amministrazione,
configurazione o backoffice.
88
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
Il nome che si tende a dare a questo layer software è ESB
(Enterprise Service BUS).
Il ruolo infrastrutturale dell'ESB comprende i seguenti
compiti base:
1.Supporto alla comunicazione asincrona basata su
messaggi. Questa caratteristica consente di
abbassare l'accoppiamento temporale ed è da
applicare ogni volta che sia possibile;
89
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.
Alcune caratteristiche avanzate che un ESB può ospitare
sono:
1.Gestione della sicurezza dei servizi
2.Monitoring e management dei servizi
3.Supporto alla composizione dei processi (in questo
caso l'ESB sconfinerebbe nel layer 3 di SOA)
90
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:
1.ESB batch (per il pattern data consistency);
2.ESB asincrono (per il pattern multistep process);
3.ESB sincrono (per il pattern composite application) ;
Questi tre ESB saranno diversi, ad esempio l'ESB batch
favorirà messaggi di grandi dimensioni, mentre il bus
sincrono avrà priorità maggiore su quello asincrono, ma
avranno anche caratteristiche che si potranno portare a
fattore comune come ad esempio la gestione della
sicurezza e la trasformazione dei dati.
91
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].
92
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).
93
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.
Figura 11: Arcipelaghi di ESB
94
Gartner [GARTNER] chiama questa situazione Arcipelagi
di ESB intendendo per arcipelago un gruppo di
applicazioni a servizi correlate e coordinate da un ESB.
Gli arcipelagi però non sono isolati e come si vede in
figura dovranno comunicare. In qualche modo dunque gli
ESB si dovranno parlare o in altre parole ESB di vendor e
tecnologie differenti dovranno essere interoperabili.
Qualcuno mi ha fatto notare che la figura degli arcipelagi
di ESB assomiglia a figure già viste sull'interoperabilità
degli ORB di CORBA. In quella situazione l'interoperabilità
era piuttosto bassa, nel caso degli ESB i Web Services
dovrebbero dare qualche garanzia in più. Ad oggi in realtà
gli ESB non sono molto interoperabili, questo è dovuto al
fatto che le specifiche dei Web Services sono in continua
evoluzione. L'evoluzione è così rapida e tumultuosa che gli
ESB talvolta non garantiscono neppure la compatibilità
con la versione precedente del medesimo prodotto.
Quando l'evoluzione degli standard dei Web Services si
stabilizzerà ci si potrà attendere qualche cosa di più sul
piano dell'interoperabilità degli 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.
95
In secondo luogo dovrà dotarsi della infrastruttura
organizzativa e tecnologica per gestire i servizi.
Inoltre dovrà effettuare delle software selection per
scegliere un adeguato software di integrazione sapendo
già in partenza in questo momento questa categoria di
prodotti non è ancora matura e stabile.
A mio avviso le architettura SOA danno benefici nelle
condizioni ove vi sia una reale necessità di condividere
servizi. In tal caso conviene implementare una architettura
SOA magari partendo da qualche piccolo, ma significativo
use case.
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'.
Introduzione a Bea Rfid Edge Server
96
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.
97
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.
98
Bea WebLogic RFID Edge Server is the focal point for
operation at the edge, providing a single point of
administration and integration for all RFID devices in a
single remote facility.
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:
99
• EPC and ISO tag protocols
• EPC and US DoD tag data standards
• EPCglobal Application Level Events (ALE)
• EPC Information Services (EPCIS).
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.
100
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.
101
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.
BEA led the development of ALE and created the
industry’s first commercial implementation. ALE is now an
EPCglobal standard, protecting your RFID
investment. BEA WebLogic RFID Edge Server also
includes several enhancements beyond the standard,
including the ability to read non-EPC tags, to program
tags and print labels, and to exploit all features of Gen2
tags including user memory, TID, lock, and kill
functionality.
102
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.
103
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.
If the WAN connection to the data center is not available
at the moment messages are sent, either because of
network problems or system failures, the data is saved on
the edge server and forwarded to the data center once the
connection is restored.
To simplify management of RFID deployments, BEA
WebLogic RFID Edge Server centralizes the
administration, monitoring and management of the entire
infrastructure. The administration console monitors the
performance of readers and other edge devices, supplies
real-time read confirmation, and provides tools to
configure Edge Flows, the ALE API, and devices. To speed
deployment and future expansion, the administration
console enables the import and export the edge server’s
configuration.
The console also provides a quick test feature for rapid
diagnosis of reader functioning, and an authoring tool for
creating ALE event cycle specifications.
104
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.
With the BEA WebLogic RFID Edge Server:
Developers can use popular enterprise application
development tools, leverage important RFID standards,
and rely on interoperability with existing enterprise
applications and middleware.
Operations staff benefit from greater control of the RFID
system with advanced RFID infrastructure management
and monitoring capabilities. The edge server’s superior
scalability ensures that they will be able to easily add and
extend the system as needed;
105
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;
Real production results BEA WebLogic RFID Edge
Server is the right choice for minimizing risk and
maximizing operational efficiencies—from pilot to
production. BEA makes RFID technology a competitive
advantage that optimizes supply chain performance,
lowers operational costs, and maximizes asset utilization.
In a pilot or a large-scale implementation, only the BEA
standards-based, SOA-driven RFID platform offers the first
complete edge-to-enterprise RFID solution that enables
organizations reap the full benefits of RFID.
106
C a p i t o l o 9
Presentazione e Descrizione Apparato Hardware insieme ad
Antenne CAEN
107
108
C a p i t o l o 1 2
Conclusioni
109
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.
Qualunque persona legga questa relazione e voglia
ricreare le prove effettuate e mettere su un piccolo
laboratorio RFID può farlo seguendo le indicazioni che
sono state riportate precedentemente a questo paragrafo.
L’importante è avere a disposizione almeno le antenne con
un software di rilevazione. Tutto il resto lo si può
costruire, proprio come abbiamo fatto noi.
Sicuramente RFID sarà molto utile nelle aziende sia come
risparmio di costi, sia per avere una migliore visione della
produzione, del materiale spedito e molti altri elementi.
Elementi che cambiano nelle aziende in base alle esigenze
di queste ultime e soprattutto a come l’infrastruttura
aziendale è stata organizzata. Sicuramente RFID
permetterà di avere un accurato controllo delle risorse
all’interno di una azienda, non solo in termini di costi ma
anche in termini di ottimizzazione del flusso del materiale
prodotto.
110
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.
Concludendo possiamo dire che in questo primo ambito
abbiamo avuto un primo approccio con l’RFID,
soffermandoci più sulla parte fisica. Verrebbe da
domandarsi perché sulla parte fisica e non sul software. In
questa prima parte abbiamo dovuto realizzare il
laboratorio, metterlo su e realizzare un numero di prove
che ci permettessero di avere un campione da studiare.
Nelle parti a seguire andremo a sviluppare molti altri
elementi per entrare sempre più nel mondo dell’RFID.
111
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.
Sicuramente lavorare in una più vasta area, con una linea
di montaggio vera avrebbe garantito risultati più precisi e
soprattutto più vicini alla realtà.
112
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.
113
114
115
116
117
NOTIZIE VARIE SU RFID
Gli ambiti in cui è possibile applicare Rfid sono
moltissimi. Si spazia dalle carte di credito ai cellulari.
Riportiamo qui di seguito una serie di notizie degli ultimi
giorni in merito a Rfid e ad alcuni campi di applicazioni.
Alcune notizie non sono proprio incoraggianti sull’uso di
Rfid e ad esempio, sulle carte di credito.
Le trovate qui di seguito. Sono tutti appunti ripresi dal
www.punto-informatico.it
…RFID In ogni luogo,in ogni parte…
RFID sta per Radio Frequency IDentification. RFID è
stata definita da molti come la tecnologia del futuro, la
tecnologia capace di sostituire i codici a barre
permettendo di avere un controllo maggiore su tutti
quegli oggetti che avranno un Tag. Il TAG può essere
visto come la carta di identità di un oggetto. Tramite il
TAG possiamo identificare un oggetto, un prodotto e
sapere molte informazioni. Quali informazioni? Le
informazioni sono legate al TAG e siamo noi a decidere
quali informazioni legare all’informazioni che ci viene
fornita. In generale ogni volta che il TAG ci risponde ci
fornisce un ID che opportunamente identificato da sistemi
appositi ci permette di sapere numerose informazioni
dell’oggetto in questione.
118
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.
In molti stabilimenti nel mondo si stanno eseguendo
progetti pilota su RFID per monitorare e identificare
meglio i prodotti che si realizzano. Hp, IBM, Bea Systems
sono solo alcune delle aziende che stanno puntando su
soluzioni RFID da implementare e offrire ai propri cliente.
Perchè è di soluzioni che si parla per migliorare il lavoro
e la propria organizzazione.
In Italia purtroppo siamo indietro su RFID. Soluzioni
minime e soprattutto già sviluppate e provenienti da altri
stati stranieri, specie gli Stati Uniti.
Carte di Credito RFID NON CONVINCONO
Esce proprio oggi la notizia che le carte di credico con
chip RFID non convincono, anzi sono molto molto
pericolose in quanto forniscono una serie di informazioni
sull’identità della persona che la usa.Sostenitore della
tesi sono alcuni ricercatori dell’Università del
Massachusetts, trovate tutte le informazioni al seguente
link: http://prisms.cs.umass.edu/~kevinfu/papers/RFID-
CC-manuscript.pdf e anche dal sito di punto informatico,
al seguente link:http://punto-informatico.it/p.aspx?
id=1715575&r=PI.
119
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.
Ci sono state delle risposte in merito a questo studio e ai
risultati esposti, ma di chi dobbiamo fidarci? Di chi dice
che RFID ancora non è sicuro oppure degli istituti
bancari che affermano che i loro sistemi RFID non
temono intrusioni?
Il discorso sicurezza non riguarda solamente carte
wireless ma anche i nuovi passaporti sui quali sono
presenti chip RFID.
RFID e i chip in questione saranno sempre più presenti
nella nostra vita. Al momento riguardano carte di credito
e passaporti, nel futuro saranno presenti, a mio dire, in
ogni singolo oggetto. RFID rappresenta il futuro, ma
chissà quanto dista da noi per quello che riguarda
sicurezza e privacy.
In Italia ancora non c’è stato tutto questo largo impiego
come negli Stati Uniti. Presto comunque ci imbatteremo
anche noi in queste problematiche. Il problema grande è
che da noi la sperimentazione è molto indietro rispetto
agli altri stati.
Rfid e Cellulari
120
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.
L’obiettivo in questo ambito è quella di integrare le
soluzioni RFID con le tecnologie NFC per permettere, ad
esempio, piccoli pagamenti o scambio di messaggi tra
automobili, antifurti, computer, pagamento di posteggi
per automobili e altro ancora.
Per quello che riguarda il pagamento dei posteggi per le
automobili tramite cellulare qualche piccolo passo ha
cercato di farlo Vodafone Italia creando un borsellino che
era associato al proprio numero di cellulare. Peccato che
il numero di comuni italiani che ha aderito all’offerta è
stato davvero piccolo, rischiando che il servizio
diventasse un flop.
Un terminale mobile con tecnologia NFC potrebbe quindi
trasformarsi in un portafoglio elettronico oppure ad un
ticket per accedere a concerti, cinema e altro ancora.
Facciamo un esempio: vogliamo acquistare il biglietto per
andare ad un concerto. Acquistiamo quindi via internet il
biglietto e scarichiamo il ticket del concerto sul nostro
dispositivo. All’ingresso del concerto un reader leggerà
poi il nostro ticket facendoci accedere all’evento. Queste
e molte altre applicazioni potranno essere associate a
tutti questi dispositivi NFC. Certo è che in un futuro il
cellulare sarà sempre meno cellulare e sempre più
qualcosa che ora come ora possiamo immaginare
lontanamente, oppure, non riusciamo ad immaginare.
121
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à.
Rfid e UHM anche in Italia si parte….
Nei scorsi giorni la Fondazione Ugo Bordoni (risultato
della fusione Federcomin e FITA) hanno presentato il
libro bianco Rfid, ossia il risultato di uno studio effettuato
su Rfid valutando sia gli aspetti tecnici che applicativi.
Rfid in Italia non ha ancora preso piedi più di tanto. Colpa
soprattutto la scarsa conoscenza di questa nuova
tecnologia e il fatto che ancora non ci sono disposizione
precise in merito all’uso delle frequenze UHF a scopo
civile, incluse quelle che occorrono per l’uso in campo
civile.
Alla presentazione ha partecipato anche l’ing. Francesco
Troisi che è il direttore generale per la pianificazione e la
gestione delle spettro radioelettrico del Ministero delle
Comunicazioni. E’ stato inoltre comunicato che l’Unione
Europea e lo stato Italiano hanno finalmente raggiunto un
accordo per fare in modo che l’Italia si adegui alle norme
europee sull’uso delle frequente RFID e UHF. L’Italia ha
ora sei mesi di tempo per recepirla e adeguare il proprio
spettro di radiofrequenza ammettendo la soglia dei 2 watt
di radioemissione UHF per l’RFID.
122
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.
A partire da oggi e per i prossimi 6 mesi sarà possibile
inoltrare al Ministero delle Comunicazioni una richiesta
per la sperimentazione con indicazione del luogo e
dell’applicazione che si intende fare della tecnologia in
questione. Il costo della richiesta di sperimentazione sarà
di poche centinaia di euro.
123
124
C a p i t o l o 7
CREAZIONE AMBIENTE DI LAVORO
125
BIBLIOGRAFIA
Barello, Elio. I pianeti. Londra: 1996.
Doe, Jane. Il Sole. Londra: 1996.
126
INDICE ANALITICO
AAristotele,3
3
4