Analisi e progettazione di servizi web per la cooperazione di reti di sensori eterogenee in base agli emergenti standard di modellazione dei fenomeni

7 
 
Prefazione 
 
 
 
Le reti di sensori costituiscono un notevole passo in avanti rispetto all’impiego di esigue entità di 
rilevamento individuali utilizzate nei contesti di tipo proprietario, fino a decine d’anni fa in diversi campi 
d’applicazione. Le esigenze attuali sono ben diverse e vanno dal monitoraggio ambientale a quello medico, 
dal campo militare a quello industriale e via dicendo. Sono richiesti dispositivi ed impianti estesi 
geograficamente, dotati sempre di maggiori capacità ed elevati livelli di funzionalità. I sensori utilizzati 
all’interno di questi dispositivi vengono in genere impiegati per stimare una o più grandezze fisiche, o per 
monitorare parametri di “controllo di processo” de-localizzati per elaborazioni distribuite (grid computing). 
L’introduzione di una rete di trasduttori porta quindi innegabili vantaggi rispetto all’utilizzo di sensori 
tradizionali in termini di flessibilità, performance, scalabilità, riduzione dei costi d’eventuali sviluppi futuri 
ed attività di manutenzione.  Essenziale è stato l’utilizzo di piattaforme integrative in grado di aggregare e 
gestire sistemi di sensori eterogenei, ma soprattutto colmare il gap tra le svariate tipologie di applicazioni 
richiedenti e il sottostante strato hardware dei sensori. Il successivo passo evolutivo è stato quello di 
rendere ancora più granulare la distribuzione di tali risorse, interfacciando i servizi offerti dalle diverse 
architetture sparse nel mondo su un mezzo accessibile a tutti come internet. 
Fondamentale in tal senso è stato l’apporto avutosi con l’introduzione di architetture distribuite del tipo 
SOA basate sui web services, come nel caso dell’architettura proposta Sensim-Web, orientata alla diffusione 
dei servizi messi a disposizione sulla rete, che offrono un grado di interoperabilità elevato, tralasciando 
però un fattore  molto importante che è quello di una comunicazione standard tra i nodi. Non importa 
quale sistema operativo venga utilizzato e nemmeno con quale linguaggio di programmazione venga 
implementata un’applicazione, ciò che interessa in questo contesto è “come” comunicano due processi in 
esecuzione su due punti diversi di una tale infrastruttura distribuita. Non basta quindi soltanto il solo 
protocollo SOAP, in grado di fornire un middleware come mezzo per la comunicazione, in grado di astrarre i 
sottostanti livelli della pila ISO/OSI mediante opportuno incapsulamento dei messaggi.  C’è bisogno di un 
ulteriore passo a favore dell’integrazione. Occorre stabilire un formalismo standard e un arricchimento 
semantico, in modo da rendere universalmente comprensibili le informazioni veicolate nella rete da e verso 
i sensori.  
In questa discussione valuteremo un modello di dati conforme agli standard OGC (Open Geospatial 
Consortium) orientato alla standardizzazione e all’arricchimento semantico delle informazioni.
8 
 
  
La tesi è strutturata nella seguente maniera: 
 Il primo capitolo illustra le caratteristiche e le problematiche relative alla gestione dei sensori e reti di 
sensori. Vengono introdotti concetti base sulle architetture distribuite e i Web Services; 
 Il secondo capitolo mette in mostra un quadro sulla situazione attuale della modellazione dei dati 
basata su interessanti proposte di altri gruppi di ricerca per affrontare un caso di studio analogo a 
quello affrontato; 
 Il terzo capitolo descrive le componenti, il funzionamento e le limitazioni dell’architettura proprietaria 
SeNsIM-Web (Sensor Networks Integration and Management) realizzata dal SECLAB Group del DIS 
(Dipartimento di Informatica e Sistemistica) presso l’ Università Federico II di Napoli; 
 Il quarto capitolo presenta l’analisi, la progettazione e l’implementazione di un modello di dati standard 
proposto per l’architettura SeNsIM-Web.
9 
 
1 Capitolo                            
Introduzione alle Reti di Sensori  
 
 
Le reti di sensori costituiscono particolari sistemi distribuiti per il rilevamento e l’analisi dei dati utili al 
monitoraggio di un qualsiasi fenomeno o processo. L’evoluzione sempre maggiore di questa tecnologia in 
vari ambiti, ha generato la necessità di sviluppare dispositivi ed impianti distribuiti dotati di capacità e 
funzionalità sempre maggiori. Il sensore stesso non può essere visto più come un singolo trasduttore di 
grandezze fisiche in quanto, implementato in un’infrastruttura di rete, è necessario che sia dotato di una 
certa indipendenza d’elaborazione, di memorizzazione e ovviamente di un’interfaccia di comunicazione col 
resto del sistema. Persino il mezzo fisico di comunicazione incide notevolmente sulle prestazioni globali. 
Una tale architettura di rilevamento può essere costituita da un numero elevato di nodi collegati tra loro 
mediante cavi multipli e in tal caso viene denominata rete cablata. In tal caso ogni sensore è collegato al 
resto della rete mediante interfacce proprietarie. Una struttura del genere ha il vantaggio di non avere 
limitazioni riguardo a potenza di calcolo, in quanto è possibile stabilire una connessione fisica(cablata) 
utilizzando una o anche più linee di alimentazione e/o dati (elaborazione parallela). Garantisce inoltre un 
elevato tasso di sicurezza, dato che l’accesso ai dati è possibile solo collegandosi fisicamente al cavo. 
Tuttavia una tale rete è da scartare per il monitoraggio di ambienti inospitali all’uomo, un fattore che rende 
ardui svariati compiti come l’installazione, la manutenzione e l’aggiornamento degli impianti incidendo 
molto sul costo di riparazioni e di gestione di una configurazione rigida del genere. Ricapitoliamo i pro e i 
contro di una rete cablata: 
 Grande affidabilità, essendo sempre alimentate. 
 L’assenza di limitazioni in potenza garantisce una rete di sensori potente e precisa, capace di 
elaborazioni anche molto complesse senza risentirne particolarmente. 
 Elevate garanzie per ciò che riguarda la sicurezza, in quanto l’accesso ai dati è possibile solo attraverso 
un collegamento fisico alla rete. 
 Impossibilità di stanziare una rete di sensori cablata in un ambiente inospitale. 
 Mancanza di flessibilità per quanto riguarda l’inserimento di un nuovo nodo o la riconfigurazione 
spaziale della rete stessa. 
 Elevati costi di installazione. 
La risposta a queste problematiche viene fornita dall’emergente tecnologia delle Reti di Sensori Wireless 
(WSN), che come vedremo offrono soluzioni ottimali in merito a flessibilità e versatilità dei componenti
10 
 
rispetto ad una rete rigida, ma che soffrrono di problemi di propagazione del segnale, interferenze, 
sicurezza, consumi energetici, norme legislative ed altro ancora. Inoltre, la crescente popolarità di questa 
tecnologia nonché l’elevatissimo numero di applicazioni che la utilizzano, provoca una smisurata diversità 
nelle caratteristiche e nelle tecniche di gestione/comunicazione dei nodi al punto che diventa quasi 
impossibile far interagire due diverse piattaforme di rilevamento per uno scopo comune. Per questo motivo 
sono attualmente oggetto di studio in numerosi campi di ricerca, la progettazione di protocolli e di 
tecnologie standard che consentano una gestione ottimizzata delle risorse e dei dati rilevati dai sensori e in 
modo che queste informazioni possano essere scambiate tra  diverse reti di sensori per una cooperazione 
globale, sulla base del concetto di interoperabilità.  
 
1.1 Wireless sensor network (WSN) 
Recenti sviluppi nell’ambito delle comunicazioni wireless e della microelettronica hanno favorito la nascita 
di nodi sensori wireless di ridotte dimensioni, a basso costo e a basso consumo. Sono in grado inoltre di 
misurare grandezze fisiche (sensori di posizione, temperatura, umidità ecc.), elaborare dati di misura, 
trasmettere a brevi distanze via onde radio (fino a circa 300 metri) e in grado di attuare periferiche e 
dispositivi. Generalmente un sensore è definito come un particolare trasduttore che si trova in diretta 
interazione con il sistema misurato. I sistemi basati su tali nodi sensori, noti come reti di sensori wireless 
(WSN), sono dei veri e propri sistemi di misurazione distribuiti le cui unità di rilevamento sono in grado di 
acquisire informazioni dall’ambiente circostante e di elaborarle e di trasmetterle ad altri nodi entro il 
proprio range di trasmissione, secondo i protocolli tipici delle reti mobili ad hoc (MANET (1)). La 
comunicazione, è realizzata infatti tramite tecnologia wireless a corto raggio, di tipo asimmetrico in quanto 
i nodi comuni inviano le informazioni raccolte ad uno o più nodi speciali della rete, detti nodi sink, i quali 
hanno lo scopo di raccogliere i dati e trasmetterli tipicamente ad un server o ad un calcolatore. Una 
comunicazione può avvenire autonomamente da parte del nodo quando si verifica un dato evento, o può 
venire indotta dal nodo sink tramite l'invio di una query verso i nodi interessati.
11 
 
 
Figura 1.1 Tipico scenario di utilizzo di una WSN 
I protocolli  sulla  trasmissione sono stati progettati appositamente per gestire comunicazioni bidirezionali a 
basso consumo e per la creazione di reti multi-hop (come Internet). Sfruttando le comunicazioni peer-to-
peer tra i dispositivi o nodi, l’insieme dei protocolli implementa potenti funzioni come la bi-direzionalità, 
l’autoconfigurazione, l’autoriparazione, la propagazione dei messaggi con  particolare attenzione alla 
gestione del consumo delle batterie dei nodi. Per facilitare la configurazione della rete ed aumentare 
l’affidabilità delle comunicazioni, vengono inoltre implementati collegamenti ridondanti. È importante 
notare che la rete deve essere realizzata in modo da garantirne l'integrità per un periodo di tempo che sia il 
più lungo possibile, allo scopo di ottenere informazioni accurate anche in caso di attacco alla rete da parte 
di terzi, in caso di guasti o di esaurimento delle batterie. Il fatto che un singolo sensore sia dotato di una 
piccola quantità di energia non deve impedirgli di inviare le informazioni elaborate, che verranno raccolte e 
unite alle informazioni provenienti dagli altri sensori. E’ anche questo Il ruolo del gateway (o nodo sink) più 
vicino, ossia prendersi carico,  per trasmissioni su lunghe tratte, di tutte le informazioni rilevate  dai nodi 
limitrofi, che altrimenti dovrebbero impiegare una maggiore potenza in trasmissione.  
Questi sono solo alcuni dei tanti aspetti che portano a scegliere, una WSN rispetto ad una rete cablata. La 
notevole versatilità e libertà di utilizzo porta ad utilizzarli in svariate applicazioni, ma d’altro canto ciò 
comporta delle difficoltà nella progettazione sia hardware che software, per l’integrazione di diversi sistemi 
non è cosa banale dato che i requisiti richiesti sono fortemente legati allo specifico utilizzo. I principali 
scenari applicativi delle WSN si possono riassumere in quattro categorie (2): 
 applicazioni militari, prevenzione di crimini o disastri: diversi sensori possono essere utilizzati per 
individuare deformazioni o problemi strutturali di edifici, oppure sensori di radiazioni possono essere 
dislocati in ambienti urbani per rilevare attacchi terroristici riguardanti sostanze radioattive; la loro
12 
 
tolleranza ai guasti e la capacità di auto-organizzarsi li rendono inoltre particolarmente adatti agli 
impieghi militari. Per esempio WSN possono essere usate per sorvegliare una zona,rilevare 
informazioni riguardo lo spostamento di nemici, o la posizione in cui è avvenuta un’ esplosione; 
 applicazioni ambientali: WSN possono essere utilizzate per rilevare o monitorare incendi forestali, 
condizioni in cui crescono le colture o gli allevamenti, stato degli oceani, livello delle maree, 
spostamenti di animali protetti, livelli d’inquinamento, ecc. ; 
 applicazioni in campo medico: nella sanità le reti di sensori possono essere impiegate per realizzare 
interfacce per disabili, tele-monitoraggio di dati fisiologici umani nella prevenzione di situazioni vitali 
critiche, tracking e monitoraggio di pazienti e dottori all’interno di un ospedale; 
 spazi intelligenti: un ambiente in grado di riconoscere l’utente presente al suo interno può predisporre 
tutta una serie di servizi personalizzati differenti a seconda di chi è l’ospite; 
 applicazioni commerciali: controllo di robot nei processi industriali, controllo del traffico stradale; 
 domotica: monitoraggio degli elettrodomestici e rilevamento di intrusi. La realizzazione di queste 
applicazioni richiede l’uso di tecniche utilizzate nelle reti wireless ad-hoc. 
A contribuire a tutti i vantaggi apportati da una rete di sensori wireless, vi è una accurata gestione che si 
basa su supporto fornito da architetture multifunzionali ben progettate per l’integrazione e la gestione 
delle risorse. 
 
1.1.1 Architettura di una rete Wireless 
Tutti i nodi della rete vengono collocati in maniera opportuna all’interno dell’area da monitorare o 
comunque nelle immediate vicinanze. Tra le modalità di comunicazione possibili quella più utilizzata per 
una rete di questo tipo è di certo il Convergecast. E’ una tecnica basata sul rispetto di una certa gerarchia 
tra gli elementi connessi, e ciò è fondamentale per mettere ordine in una struttura così dinamica che è per 
certi versi imprevedibile in termini di estenzione, topologia e numero di nodi. Infatti, il flusso dei dati 
provenienti da ciascun sensore viene convogliato verso un nodo principale detto Base Station (o nodo Sink), 
il quale si comporta da interfaccia tra la rete di sensori e il mondo esterno, che sia un singolo utente, 
un’interfaccia Web Services, un sistema complesso o la rete internet.  La Figura, mostra come un messaggio 
può attraversare la rete con la tecnica del routing-multihop, in quanto ogni nodo funziona appunto da 
router, e fa da intermediario (o gateway) tra il nodo che vuole trasmettere e il nodo sink. Ciò porta molti 
vantaggi come la riconfigurabilità della rete in caso di guasti, dato che ci sono numerose possibilità di 
instradamento. Al contrario delle reti di sensori cablate, la chiave del successo sta proprio sulla flessibilità 
nel posizionamento dei sensori che non richiede particolari accorgimenti. Ma tale caratteristica allo stesso 
tempo comporta che la rete sia auto-organizzante, e cioè che i sensori siano dotati di una buona
13 
 
autonomia, dato che la manutenzione a volte può essere impraticabile ad esempio quando il sito è 
praticamente irraggiungibile. 
1.1.2 Struttura di un Mote 
I recenti progressi tecnologici nell’ambito soprattutto delle telecomunicazioni wireless e dell’elettronica 
digitale, hanno permesso lo sviluppo di nodi wireless (motes) sempre più piccoli ed economici, a basso 
consumo di energia e multifunzionali. Ogni mote è costituito da un certo numero di sensori o trasduttori 
(Sensing Unit), un rice-trasmettitore per la comunicazione (Transceiver), da un’unità di elaborazione 
(processing Unit) e da un sistema di alimentazione autonomo (Power Unit). In particolare un mote viene 
descritto dallo schema a blocchi in Figura. 
 
Figura 1.3 Struttura di un Mote 
 La Sensing Unit è tipicamente costituita da un insieme di trasduttori che trasformano la grandezza fisica 
da misurare (temperatura, pressione atmosferica, umidità, accelerazione, intensità luminosa, ecc.) in 
un segnale elettrico, e da convertitori analogico-digitale (Analog-Digital Converter, ADC), che 
convertono il segnale analogico proveniente dall’uscita dei trasduttori in un segnale numerico, per 
 
Figura 1.2  Struttura di una rete Wireless
14 
 
consentirne l’elaborazione software. Ogni nodo ha un numero massimo di trasduttori che può 
alloggiare. La tipologia di trasduttori montata dipende dalla specifica applicazione. 
 Il Transceiver consente la comunicazione wireless, solitamente attraverso un modulatore in Radio 
Frequenza (RF), ossia un segnale ad alta frequenza che si propaga nell’etere o in un dispositivo ottico. 
La trasmissione è di tipo broadcast, quindi i messaggi inviati arrivano a tutti i nodi entro il raggio di 
trasmissione. Inoltre poiché la frequenza di trasmissione è la stessa per tutti i nodi della rete, possono 
verificarsi interferenze. Il trasmettitore radio è il componente del nodo a più elevato consumo 
energetico (in generale il consumo in trasmissione è tre ordini di grandezza superiore al consumo per 
l’elaborazione). 
 La Processing Unit è l’unità computazionale del nodo sensore ed è costituita da un Processore 
(Processor), di solito un microcontrollore (μC) a basso consumo oppure anche un FPGA (Field 
Programmable Gate Array) o un DSP (Digital Signal Processing) o un ASIC (Application Specific 
Integrated Circuit), che realizza tutte le funzionalità di calcolo e controllo del nodo, ed una Memoria 
(Storage) che memorizza un sistema operativo e un programma applicativo. 
 La  Power Unit fornisce energia a tutte le unità funzionali del nodo. Solitamente quindi i sensori sono 
alimentati da fonti energetiche limitate (batterie) e solo raramente possono disporre di fonti 
energetiche rinnovabili (ad es. celle fotovoltaiche), essendo le fonti di alimentazione diverse dalle 
batterie difficilmente integrabili in sensori di ridotte dimensioni.  
Un microsistema del genere necessita di un’accurata gestione di tutte le risorse disponibili al fine di rendere 
ottimale il processo di rilevamento .Nasce quindi l’esigenza di un sistema operativo per nodi sensor. 
 
1.1.3 Sistema Operativo: TinyOS 
La scelta di un sistema operativo per le WSN va effettuata tenendo conto delle particolari caratteristiche 
dei mote. La dimensione della piattaforma hardware in questione e le limitazioni sul consumo di energia 
rendono necessario innanzitutto l’utilizzo di un OS leggero e dotato di bassi consumi durante 
l’elaborazione. In una rete di sensori inoltre lo scambio di informazioni tra i nodi è continuo, sia per il 
trasferimento di dati che per le comunicazioni sullo stato della rete: il sistema operativo deve quindi 
implementare protocolli di rete che siano poco dispendiosi in termini di energia e fornire uno strumento 
per la gestione della concorrenza. Infine deve fornire interfacce per astrarre i dispositivi hardware (sensori 
e attuatori). 
Un sistema operativo con queste peculiarità è TinyOS (3): si tratta di un’applicazione open source 
sviluppata dalla Berkeley University appositamente per la gestione di reti di sensori wireless. E’ scritto in 
nesC, una variante del linguaggio C per la programmazione dei nodi di una rete di sensori, ed offre, in
15 
 
accordo con la politica di risparmio energetico del sensore, un modello basato su eventi (i componenti 
dell’applicazione vengono avviati solo al verificarsi di un particolare evento). L’unico componente che è 
presente in ogni applicazione è lo scheduler, che manda in esecuzione i task dei diversi componenti 
secondo una politica FIFO run to completion (un task non ne può interrompere un altro). I componenti 
comunicano tra di loro invocando comandi e sollevando eventi, entrambi gestiti da handlers appositi. 
Possiamo distinguere tre tipologie di componenti: Hardware Abstractions, che permettono di astrarre i 
moduli hardware; Synthetic Hardware, che simulano la presenza di hardware più sofisticato di quello 
presente sul sensore; High Level Software Component, che eseguono algoritmi che prescindono dalla 
particolare configurazione hardware.  
In TinyOS la chiamata alle funzioni e l’operazione di “roll-back” sono separate (split-phase operation). Un 
tipico esempio è l’invio di un pacchetto sulla rete: ogni componente implementa o il comando o l’evento. 
La tecnologia di rete di TinyOS prende il nome di Active Messages. Questo sistema permette di inviare 
messaggi ad un singolo nodo o a tutti, tra i nodi vicini, senza specificare meccanismi connection oriented: in 
questo modo ogni pacchetto è visto come un’entità indipendente e ciò rende la tecnologia molto più 
leggera. Ogni pacchetto contiene l’identificatore dell’handler da richiamare sulla macchina di destinazione 
e il payload del pacchetto. Ovviamente ciò comporta che i nodi debbano avere lo stesso software o almeno 
implementare un componente che definisca lo stesso handler per garantire la comunicazione. 
 
1.1.4 Middleware: TinyDB 
Il sistema operativo dei sensori non fornisce comunque gli strumenti adatti per far si che la rete si possa 
interfacciare in modo adeguato con applicazioni esterne, che rappresentano poi i reali utilizzatori delle 
informazioni ed elaborazioni generate da una WSN. Si rende necessaria quindi un’infrastruttura software, 
chiamata middleware, capace di offrire all’utente finale una serie di interfacce che, oltre a permettere 
l’acquisizione di dati, offrano un’astrazione di determinate caratteristiche della rete. Le reti di sensori sono 
infatti molto eterogenee tra loro : il sistema operativo utilizzato, i protocolli di comunicazione e la 
piattaforma hardware sono spesso differenti, anche perché la configurazione di una rete dipende in modo 
imprescindibile dal tipo di analisi e controllo a cui è dedicata. I nodi di una WSN sono inoltre facilmente 
soggetti a malfunzionamenti: interferenze di trasmissione, guasti, mancanza di energia possono rendere il 
nodo inutilizzabile, modificando quindi la topologia della rete. Un middleware che sia efficiente deve essere 
quindi in grado di mascherare all’utente queste caratteristiche, fornendo una serie di servizi e API 
(Application Programming Interface) che permettano di interagire con la rete prescindendo dalla rete 
stessa.
16 
 
Il TinyDB è un esempio di middleware basato sulla gestione dei dati rilevati di tipo database, che utilizza un 
sistema di query per estrapolare le informazioni dalla rete, utilizzando il SO TinyOS. Questo software è in 
grado di semplificare notevolmente l’utilizzo della rete WSN in quanto virtualizza le risorse distribuite come 
se fossero elementi di un  database in un’unica tabella chiamata SENSOR contenente tutte le informazioni 
riguardo ai sensori. Questa tabella viene popolata grazie ai dati forniti dalle query che l’utente di tinyDB, 
invia verso la rete connessa localmente: a questo scopo viene messa a disposizione un’interfaccia per la 
gestione delle interrogazioni. Le query vengono inviate attraverso la rete tramite un meccanismo di 
inondazione (flooding): ogni nodo possiede un processore per l’elaborazione delle query ricevute, che 
permette  di processare e aggregare i risultati, nonché di memorizzare le informazioni relative al routing 
della rete. Questa operazione è ripetuta in un periodo che viene dichiarato all’interno della richiesta. 
TinyDB gestisce in modo trasparente la topologia della rete: grazie ad una tabella di routing, è in grado 
di definire una struttura ad albero ad ogni query, la cui radice è rappresentata da un nodo collegato 
all’utente, permettendo l’invio dei dati da tutti i sensori interessati. E’ possibile inoltre eseguire più query 
contemporaneamente e in modo del tutto indipendente tra loro, coinvolgendo anche diversi sottoinsiemi 
di sensori.  
Possiamo scomporre questo middleware in due componenti: la prima è eseguita sul sensore 
ed è sviluppata in nesC; la seconda rappresenta l’interfaccia utente ed è scritta in Java. Nel software 
presente sul sensore possiamo individuare tre componenti fondamentali per la trasmissione dei dati e la 
collaborazione tra i nodi della rete: 
 Sensor Catalog. Questa componente si occupa della memorizzazione di alcuni dati riguardanti il 
sensore, tra cui il set di misure disponibili e il sensore padre nella struttura ad albero. 
 Query processor. Si occupa di ricevere i dati dai sensori figli, aggregarli ai propri, filtrarli e inviarli al 
sensore padre a intervalli di tempo stabiliti dalla query. 
 Network topology manager. Fornisce i comandi per l’invio di query e gli eventi per ricevere query e 
risultati. 
TinyDB rappresenta una buona soluzione per gestire l’accesso ad una rete WSN, ma comporta parecchie 
limitazioni: 
 L’albero per il routing non può cambiare configurazione durante una query se non nel caso di aggiunta 
di nuovi sensori. La struttura quindi è di per sé molto statica. 
 I nodi più vicini alla radice, poiché trasferiscono molti più dati, hanno un consumo di energia maggiore, 
e ciò va in contrasto con la politica di risparmio energetico delle WSN. 
 Non è possibile cambiare la radice della query durante l’esecuzione della stessa.
17 
 
La piattaforma software appena vista, non può quindi da sola soddisfare le molteplici esigenze che 
caratterizzano una qualsiasi applicazione che si propone di far interagire reti di sensori eterogenee. Inoltre, 
negli ultimi anni ha suscitato notevole interesse lo sviluppo di una nuova tecnologia che permette di 
integrare il mondo dei sensori e internet. Si parla in tal caso di Sensor Web, una soluzione dalle grandi 
potenzialità che mira a rendere le reti di sensori, o anche i singoli sensori, ricercabili, accessibili e 
controllabili tramite il World Wide Web. La diffusione sempre crescente di questo tipo globale di 
interazione con le svariate reti di sensori esistenti nel mondo, ha reso necessaria la definizione di ulteriori 
standard orientati a smussare le diversità tra innumerevoli e sempre più eterogenei sistemi di rilevamento 
che si affacciano sul Web.  
 
1.2  I web Services e le architetture SOA  
La tecnologia dei Web Services, costituisce un notevole passo in avanti verso l’evoluzione del Web  di tipo 
“Transazionale”. Non vi è più solo il classico scenario dell’utente che accede ad un servizio distribuito, ma 
anche la possibilità che un’applicazione o un servizio possa accedere ad un insieme di altri servizi o 
applicazioni. I Web Services costituiscono appunto un nuovo tipo di applicazioni condivise sul Web in grado 
di fornire un modello standard per l’intercomunicazione tra le stesse, basato su standard ampiamente 
diffusi, nati soprattutto per superare i problemi di interoperabilità tra piattaforme software eterogenee (in 
termini di Sistemi operativi e linguaggi utilizzati). Ciò consente ad applicazioni auto-descrittive 
opportunamente pubblicate, di interagire in maniera autonoma sul web all’interno di processi ben distinti. I 
servizi web consentono lo svolgimento di funzioni di ogni genere, dalle più semplici richieste ai più 
complessi processi aziendali e scientifici. ”In breve i Web Services, promettono di fornire un meccanismo 
standard per l'integrazione e l'interoperabilità tra i sistemi più disparati, il punto chiave dell’utilità viene 
fornito dal grado di standardizzazione introdotto” (4). Costituiscono perciò un tipo di applicazione dei 
servizi che presentano una serie di caratteristiche standard.  
In linea di massima i web services presentano le seguenti caratteristiche: 
 sono ricercabili e pubblici, in quanto vengono memorizzati in un Registro comune disponibile sul Web; 
 sono auto-contenuti, cioè ogni servizio è ben definito, completo ed indipendente dagli altri; 
 forniscono un'interfaccia indipendente dall'implementazione, in quanto munite di relative  descrizioni 
in WSDL, molto accurate, con cui si è in grado di conoscere tutti i parametri di scambio, e i dati 
necessari per un qualsiasi linguaggio di programmazione; 
 sono Loosley coupled, cioè un client di un WS non è strettamente vincolato ad esso, nel senso che 
l'interfaccia WS può cambiare nel tempo senza preavviso e senza però compromettere la capacità del
18 
 
cliente di interagire con il servizio. Un sistema strettamente accoppiato implica invece che il cliente e 
server siano allineati l'uno all'altro,e quindi se l'interfaccia cambia, anche l'altro deve essere aggiornato. 
Un’architettura loosely coupled tende quindi a rendere i sistemi software più maneggevoli e permette 
di semplificare l'integrazione tra diversi sistemi. 
 sono a “grana grossa”, cioè mettono a disposizione poche funzionalità ma complete, in modo da ridurre 
la complessità per gli sviluppatori. Caratteristica importante da contrapporre al problema dei moduli a 
grana fine nella programmazione ad oggetti, come in java, dove realizzare un programma partendo da 
zero è un compito molto difficile. 
 permettono  l'integrazione con altri servizi (composizione di servizi). 
Tali proprietà hanno reso i servizi web i soggetti ideali per lo sviluppo di un nuovo tipo di paradigma 
architetturale: il Service Oriented Architecture (SOA). Una SOA è un modello architetturale composto da 
più applicazioni distribuite (non necessariamente appartenenti al web), opportunamente connesse in modo 
da interagire e cooperare per un obiettivo comune, ottenendo maggiore potenza di calcolo e una maggiore 
disponibilità di funzioni. Un sistema realizzato seguendo tale principio, è perciò costituito da una serie di 
applicazioni, denominate servizi, ben definite e ben distinte funzionalmente l’una dall'altra: ognuna di esse 
mette a disposizione un particolare dato o funzionalità e, potenzialmente, può sfruttare quelle messe a 
disposizione dagli altri, realizzando così applicazioni di maggiore complessità. Il concetto di servizio sta alla 
base della definizione di SOA, ed è da non confondere col termine Web Service. Infatti, un servizio è un 
modulo software autonomo, in grado di realizzare un determinato task in maniera indipendente dal 
contesto e dallo stato degli altri servizi e può essere implementato senza alcun vincolo sulla scelta delle 
tecnologie sottostanti. Con il termine Web Service, invece, ci si riferisce alle tecnologie che permettono di 
effettuare il collegamento tra servizi che collaborano in modo distribuito sul web. I servizi sono definiti 
anche per composizione, e quindi li si ottiene connettendo altri servizi distribuiti mediante Web Services. 
Quindi, un servizio necessita di un tipo di sistema informatico base connesso a internet per sfruttare tale 
tecnologia. La combinazione di servizi interni ed esterni relativi ad un'organizzazione, compongono una 
architettura orientata ai servizi di tipo SOA. Ricapitolando: 
 Un’architettura SOA, è un particolare sistema composto da un insieme di servizi distribuiti sul web (ma 
anche no); 
 Un servizio è un’applicazione autonoma, che realizza un compito in modo autonomo, e indipendente 
dagli altri servizi contigui. 
 Un Web Service è una particolare tecnologia che permette la connessione tra differenti servizi esistenti, 
disponibili in diversi punti del Web, che intendono collaborare per un medesimo obiettivo.
19 
 
1.2.1 I protocolli utilizzati 
Diverse tecnologie sono state introdotte per lo sviluppo dei servizi web (WSs) e molti altri ancora 
potrebbero essere sviluppate nei prossimi anni. In realtà, il paradigma dei Web Services è cresciuto così 
rapidamente da far si che diversi approcci concorrenti stiano cercando di fornire le stesse proprietà. 
Tuttavia, il punto di vista dei Web Servicess  relativo ad un’ integrazione ottimale dei servizi nel mondo del 
business non è fattibile senza una tecnologia di base standard, supportata dai maggiori produttori di 
software esistenti. Negli ultimi anni, tre principali standard sono emersi e utilizzati in tutto il mondo, 
costituendo di fatto il nucleo dei protocolli su cui si basano gli attuali Web Services. Tali tecnologie sono: 
 Simple Object Access Protocol (SOAP)  
Il SOAP è un protocollo leggero per il trasporto di documenti XML, mediante particolari messaggi, tra le 
diverse componenti software. La parola object manifesta appunto che il suo utilizzo rispecchia il paradigma 
della programmazione ad oggetti. Il protocollo SOAP è una struttura operativa estensibile e decentralizzata 
in grado di operare al di sopra le varie pile protocollari delle reti di calcolatori, astraendo in questo modo i 
protocolli e le altre tecnologie dei livelli sottostanti. I richiami a procedure remote (RPC) e i relativi 
standard, vengono modellati come interazione di numerosi messaggi SOAP. Può operare su 
differenti protocolli di reti (SMTP, HTTP e FTP), ma l’http è quello più comunemente utilizzato tra quelli 
della W3c. Il SOAP si basa sul metalinguaggio XML e la sua struttura segue la configurazione Head-Body, 
analogamente  a quanto succede nell’html (vedi Figura 1.4). Il segmento opzionale Header contiene meta-
dati riguardanti il routing, la sicurezza e le transazioni. Il segmento obbligatorio Body trasporta il contenuto 
informativo e talora viene detto carico utile, o payload. Essendo basato sull’XML, deve quindi seguire uno 
schema di riferimento definito dal linguaggio XML Schema (5).  
 
 
Figura 1.4 Struttura di un messaggio SOAP