Università degli studi di TrentoFacoltà di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea in Informatica

Anno Accademico 2004 - 2005

Un client Symbian per WS-Notification

relatore

prof. Marco Aiello

tesi di laurea di

Michele Iannotta

1

Contenuti

ACRONIMI E ABBREVIAZIONI..........................................................................................31 INTRODUZIONE.........................................................................................................4

1.1 Introduzione delle nuove tecnologie in ambito assistenziale........41.2 Problemi di integrazione in Ambito domotico......................................61.3 Contributi della tesi.........................................................................................61.4 Organizzazione della Tesi.............................................................................7

2 WEB SERVICES............................................................................................................82.1 Web service architecture...............................................................................82.2 XML......................................................................................................................... 92.3 SOAP.....................................................................................................................102.4 Web services e devices mobili...................................................................12

3 SYMBIAN OS..............................................................................................................133.1 Linguaggi di programmazione....................................................................13

3.1.1 Limitazioni rispetto ad ANSI C++......................................................143.1.2 Caratteristiche proprie di Symbian OS...........................................143.3.1 Active Objects............................................................................................15

4 BLUETOOTH...............................................................................................................174.1 Confronto con altri standard wireless.....................................................184.3 Bluetooth Protocol Stack..............................................................................19

5 ARCHITETTURA DEL SISTEMA.............................................................................205.1 SOA........................................................................................................................205.2 Distributed objects.........................................................................................22

5.2.1 Eventi e notifiche.....................................................................................225.3 WS-Notification................................................................................................235.4 Il modello client-server.................................................................................255.5 La messaggistica standard di WS-Notification....................................265.6 Architettura dell’applicazione....................................................................305.7 Design e implementazione..........................................................................33

5.7.1 Costruzione.................................................................................................345.7.2 Connessione...............................................................................................365.7.3 Lettura dati da socket............................................................................385.7.4 Scrittura dati su socket.........................................................................39

6 ESEMPIO DI ESECUZIONE.....................................................................................407 CONCLUSIONI............................................................................................................43

7.1 Evoluzione dei sistemi di Home Automation........................................437.2 Conclusioni.........................................................................................................437.3 Sviluppi futuri...................................................................................................44

APPENDICE A – I TOOLS UTILIZZATI PER LO SVILUPPO................................45APPENDICE B - SYMBIAN CODE NAMING CONVENTIONS.............................46Bibliografia.......................................................................................................................47

ACRONIMI E ABBREVIAZIONIAO Active Object

(http://www.symbian.com/developer/techlib/papers/tp_active_objects/active.htm)API Application Programming Interface

2

BEEP Blocks Extensible Exchange ProtocolBPEL4WS Business Process Execution Language for Web Service

(http://www106.ibm.com/developerworks/library/ws-bpel)BT Bluetooth

(http://www.bluetooth.com)CPU Central Processing UnitCGI Common Gateway InterfaceDLL Dynamic Link LibraryFIFO First-In First-Out FTP File Transfer ProtocolHTTP HyperText Transfer ProtocolIEEE Institute of Electrical and Electronics EngineersIR Infra-RedISM Industrial Scientific Medical J2ME Java 2 Micro EditionMMU Memory Management UnitOS Operating SystemPAM Personal Area NetworkPDA Personal Digital Assistant QoS Quality of ServiceRAM Random Access MemoryRFCOMM Radio Frequency COMMunications ROM Read-Only MemorySDP Service Discovery ProtocolSMS Short Message ServiceSMTP Simple Mail Transfer ProtocolSOA Service Oriented ArchitecturesSOAP Simple Object Access Protocol

(www.w3.org/TR/soap)SOC Service Oriented ComputingUDDI Universal Description Discovery and Integration

(www.uddi.org)VM Virtual MachineWSDL Web Service Description Language

(www.w3.org/TR/wsdl)XML eXtensible Markup Language

(http://www.w3.org/XML)XML-RPC XML Remote Procedure Calls

1 INTRODUZIONENel corso degli ultimi cinquanta anni, i miglioramenti della scienza e della medicina hanno indotto un notevole innalzamento dell’età media. Questo fenomeno positivo, ha portato però con sé anche aspetti a valenza negativa, quali il massiccio e progressivo aumento delle persone in età geriatrica rispetto ai giovani. Numerose ricerche hanno messo in evidenza l’acuirsi del problema, aggravato da bassi tassi di natalità. Uno studio del CNR [1] stima infatti che nel 2025 gli ultraottantenni rappresenteranno quasi il 7% della popolazione italiana

3

Figura 1.1: Popolazione ultraottantenne nei Paesi Industrializzati ed in Italia.

Queste cifre rendono l’idea dell’espansione del fenomeno, che colpisce in egual misura tutti i paesi industrializzati. Le soluzioni fino ad ora adottate, basate principalmente sull’assistenza informale (ovvero quella resa da membri della famiglia, amici o lavoratori volontari, anche chiamati caregiver), sembrano non sostenerne più la portata. Ad esempio, in un approfondito articolo di Bianchetti et al. [2] si mostra che

“mentre da un lato la crescita della popolazione anziana indica chela domanda di assistenza informale crescerà nel futuro, gli altri modellisocio-economici e demografici indicano che la disponibilità dipersonale che fornisca assistenza a livello informale si sta abbassando“.

Da più parti nasce allora la richiesta di trovare nuovi strumenti per risolvere un problema che, sempre più, affligge sia economicamente che eticamente la nostra società.

“Vi è oggi un notevole spazio che deve essere riempito da studi e ricercheper inventare nuove risposte, tenendo conto degli scenari in profondamodifica“ [2].

1.1 Introduzione delle nuove tecnologie in ambito assistenziale

L’introduzione delle nuove tecnologie in ambito medico ha permesso la realizzazione di sistemi di assistenza che, pur non sostituendo la figura professionale dell’infermiere e dell’assistente sanitario, possono affiancarlo nelle attività quotidiane [4] [5].I deficit di un paziente possono essere sia di tipo fisico che cognitivo. E’ dunque necessario tener conto di entrambi gli aspetti per lo sviluppo di una soluzione adeguata ed efficiente che risponda alle esigenze dei pazienti e delle loro famiglie.La robotica in questo senso viene introdotta per ridare al paziente il controllo della dimensione fisica dell’ambiente in cui vive, aspetto fondamentale anche dal punto di vista psicologico. Nelle patologie a lungo termine, infatti

“la maggior parte degli individui disabili preferisce rimanere nelle propriecase invece di trasferirsi in una struttura istituzionale per riceverel’assistenza di cui ha bisogno“ [3].

L’autonomia concessa al paziente da questo tipo di tecnologia produce inoltre una notevole riduzione del tempo di assistenza richiesto ai caregiver o agli assistenti specializzati.L’altra tecnologia utilizzata in questo ambito è la domotica, che oltre a sopperire ai deficit fisici, può assicurare servizi essenziali nell’assistenza a pazienti con deficit cognitivi.In primo luogo la domotica consente una vasta automatizzazione dell’ambiente, che va dall’apertura di porte e finestre, all’accensione e al controllo remoto dell’impianto di illuminazione e di riscaldamento di tutta la casa. Applicando gli stessi concetti già visti per la robotica, si capisce l’utilità di questi servizi ricordando che nel caso di pazienti disabili anche le operazioni più semplici possono risultare impossibili.

4

Inoltre la domotizzazione dell’ambiente consente un continuo ed affidabile controllo delle attività quotidiane. È stato rilevato infatti che

“una notevole percentuale del tempo a disposizione di una persona chefornisce assistenza viene trascorsa a controllare il paziente nelle suediverse attività, al fine di poter conoscere e curare i disturbi comportamentalie sorvegliarlo per evitare eventuali situazioni di pericolo, comeil contatto con l’acqua bollente, il fuoco, ecc..“ [3].

Questo servizio di controllo, assolutamente trasparente al disabile, apporta numerosi vantaggi, tra cui i più importanti sono i seguenti:• Sicurezza: il grado di sicurezza è elevato perché il paziente è sottoposto ad una sorveglianza continua, cosa che un caregiver, per quanto attento, non potrà mai fornire.• Prevenzione: se il sistema ravvisa una possibile situazione di pericolo, attua le regole a sua disposizione per evitare conseguenze.• Emergenza: nel caso in cui l’emergenza non possa comunque essere evitata, un sistema di allarme avverte tempestivamente gli addetti responsabili.• Personalizzazione: tutti i comportamenti possono essere registrati ed opportunamente analizzati, per disegnare un profilo il più personalizzato possibile della malattia del paziente. Così lo spazio e l’ambiente in cui vive possono essere adattati alle sue esigenze.

Per chiarire questi concetti si consideri un anziano con perdita di capacità cognitiva che durante la notte si alza da letto. In assenza di un sistema di sorveglianza automatizzato, l’anziano può trovarsi in difficoltà e richiedere la presenza di un assistente che lo guidi, accendendo le luci e aprendo le porte al suo passaggio. In un ambiente pervasivamente domotizzato invece, i movimenti del paziente sono continuamente sorvegliati. Un sensore può ad esempio rilevare che il paziente non è più sdraiato, ma si sta alzando da letto. In questo caso viene tempestivamente accesa la luce e la porta scorrevole della camera viene aperta. In questo nuovo scenario, la presenza dell’assistente o del caregiver viene richiesta solo in caso di emergenza. La comunicazione gioca un ruolo fondamentale nella realizzazione di uno scenario di questo tipo. Infatti, alla mobilità del paziente deve corrispondere un mobilità di comunicazioni. Un sistema wireless a basso consumo di potenza e dimensioni ridotte che può seguire il paziente in tutti i suoi movimenti, affiancato da un elevato numero di embedded device distribuiti nello spazio in cui il paziente stesso si muove, può rappresentare la migliore risposta al requisito di mobilità.Riguardo a questo requisito, possiamo dire che il mercato punta proprio in questa direzione offrendo in continuazione nuovi dispositivi e standars di comunicazione. L’esplosiva crescita di device mobile che abbiamo assistito nei precedenti anni, infatti, è destinata a continuare nel futuro dato che la richiesta dei consumatori è sempre più orientata verso dispositivi sempre più piccoli con capacità di calcolo superiori.Gli smart-phone, una combinazione di un (PDA) e un telefonino, si trovano in cima a questo mercato, offrendo dispositivi di piccole dimensioni e la flessibilità di un software di un sistema operativo come ad esempio Symbian OS.

1.2 Problemi di integrazione in Ambito domotico Il problema dell’assistenza agli anziani (o in generale ai disabili) può essere risolto o almeno coadiuvato dalla robotica e dalla domotica. All’interno della casa intelligente (non necessariamente destinata all’assistenza ai disabili) possono esserci molti dispositivi “intelligenti” che aiutano, o come nel caso dei disabili compiono loro stessi, delle attività domestiche. Tuttavia, oltre alla diffidenza di molti utenti, esiste un altro ostacolo allo sviluppo di queste tecnologie: la standardizzazione. Ad esempio Zolet afferma

5

“Questi prodotti spesso sono in grado di rilevare, comunicare, ed offrire servizi soltanto ad altri della propria linea di produzione.[7]”

Molti lavori sono stati eseguiti con l’obbiettivo di abbattere queste barriere, sia dal punto di vista software che hardware. In quest’ottica possiamo inserire lo sviluppo dei Web Services (o in generale dell’architettura SOA) e dello standard Bluetooth, entrambi utilizzati all’interno del progetto sviluppato per questa tesi.I WS sono nati con l’obbiettivo principale quello della interoperabilità delle applicazioni aziendali. Proprio per questa natura, sono stati successivamente adottati anche all’esterno di ambienti circoscritti come quelli aziendali. Infatti come afferma Leoni

“L’approccio Web Service fornisce lo strumento per unificare la modalità di interazione rispetto a tutti gli “attori domotici”, utilizzando quegli strumenti friendly che man mano stanno diffondendosi nell’uso quotidiano (telefoni, computer palmari, …)[8].

Per gli sviluppatori l’introduzione dei Web Services rappresentano un nuovo modo in cui le applicazioni nascono e vengono sviluppate.L’interoperabilità, anche con il mondo esterno, è un fattore essenziale a cui pensare sin dalle prime fasi dello sviluppo, non solo un problema da verificare alla fine della programmazione . Per quanto riguarda il Bluetooth, la creazione di uno standard di comunicazione condiviso da più dispositivi, è stato il principio del suo sviluppo, come riportato nella sezione 4.

1.3 Contributi della tesi

Questa tesi si inserisce nel progetto, in corso presso il DIT (Dipartimento di Informatica e Telecomunicazioni) dell’Università degli Studi di Trento e in collaborazione con l’ITC-irst e il CNR-IMM di Lecce, per la realizzazione di un sistema domotico di assistenza ad anziani e disabili.L’obbiettivo di questo progetto, avviato con l’ITEA (Istituto Trentino Edilizia Abitativa) è la realizzazione di appartamenti domotici per persone con disabilità di varia entità.In particolare questo sistema è stato realizzato per rilevare attraverso l’utilizzo di sensori e telecamere, appositamente installati all’interno dell’abitazione, gli eventi di caduta. La segnalazione può giungere attraverso segnali acustici, video, oppure a dispositivi portatili, come palmari o telefoni cellulari.Scopo di questa tesi è la realizzazione di un’applicazione client , per device mobili che permetta l’invocazione del web service reso disponibile dal server. Come ambiente di sviluppo è stato scelto il sistema operativo Symbian e come sistema di comunicazione wireless lo standard Bluetooth. In particolare, in questa prima fase di progetto, il client contatta il server per sottoscriversi alla notifica dell’evento caduta.L’obiettivo perseguito è quello di realizzare uno strumento che sia il più possibile standard, aperto e scalabile. A tal fine, per quanto riguarda il web service, abbiamo utilizzato un particolare stack di protocolli che contiene ad alto livello WS-Notification. WS-Notification è una famiglia di specifiche che definiscono un approccio standard, di tipo Web Service, alle problema delle notifiche, utilizzando un modello topic-based publish/subscribe.Allo scopo di ottenere un buon livello di scalabilità è stato utilizzato a livello di codifica un protocollo (SOAP), basato su XML, che oltre a godere delle proprietà di estensibilità, leggibilità e portabilità derivanti dall’uso della tecnologia XML, presenta caratteristiche di astrazione in grado di risultare indipendenti dal protocollo di trasporto sottostante.

6

1.4 Organizzazione della Tesi La tesi è organizzata come segue.Il secondo capitolo introduce, nella prima, parte i concetti di base dei Web services; successivamente il capitolo affronta lo sviluppo dei web services all’interno di devices mobili.Il terzo capitolo introduce il sistema operativo Symbian OS. Symbian è stato utilizzato come piattaforma per lo sviluppo dell’applicazione oggetto di questa tesi. Il capitolo comprende anche un confronto tra il linguaggio di programmazione C++ e Symbian C++ per mettere in evidenza alcune differenze che si incontrano nella programmazione per questo particolare sistema operativo.Il quarto capitolo pone l’attenzione sul sistema di comunicazione adottato per far interagire i componenti del sistema, ovvero il Bluetooth. Dopo aver introdotto brevemente questa tecnologia ed aver presentato lo stack di protocolli si descrive un particolare protocollo utilizzato a livello implementativo, ovvero il protocollo RFCOMM, che simula una comunicazione seriale. Il quinto capitolo è dedicato alla descrizione del sistema realizzato, sia dal punto di vista software che da quello hardware, con particolare attenzione alla sinergia tra dispositivi utilizzati e funzioni implementate.Il sesto capitolo descrive, attraverso una serie di screenshot, un esempio di esecuzione del prototipo Home Security. Il settimo capitolo infine riassume i risultati ottenuti e indica possibili sviluppi futuri.

2 WEB SERVICES

Un web service è un qualsiasi servizio reso disponibile su Internet, che usi un sistema di messaggistica che rispetti gli standard XML e inoltre non sia legato a qualche particolare sistema operativo o linguaggio di programmazione. Ci sono diverse alternative, allo scambio di puri messaggi XML. Per esempio si possono invocare remotamente delle procedure ( XML-RPC ) oppure si possono utilizzare messaggi SOAP. Alternativamente si può usare il protocollo HTTP GET/POST e scambiarsi documenti XML. Anche se non richiesto un web service dovrebbe avere altre due proprietà:

7

o essere “self-describing” cioè dovrebbe essere resa disponibile un’interfaccia pubblica al servizio.

o un web service dovrebbe essere localizzabile,dovrebbe esserci un qualche semplice meccanismo attraverso il quale le parti interessate al servizio possano localizzare la sua interfaccia pubblica.

I web services non introducono niente di nuovo a livello implementativo [11], infatti con essi si passa da un modello cosiddetto human-centric Web (dove sono persone fisiche che avviano molte web requests) a uno scenario che possiamo chiamare application–centric Web nel quale subentra un nuovo attore, rappresentato da una applicazione. Questo esiste già, infatti programmi CGI e servelets Java sono stati realizzate principalmente per essere utilizzate da altre applicazioni, ma il problema è che questi sistemi esistenti (come per esempio search system, news retrieval system) rappresentano una soluzione ad hoc. Ed ecco dove entrano in gioco i web services, che si propongono di abbattere le barrire che impediscono l’integrazione delle applicazioni, attraverso una standardizzazione delle soluzioni. Per la prima volta, un telefono, un palmare, un Pc e un mainframe si possono scambiare informazioni utilizzando il medesimo protocollo e le stesse semantiche. E lo possono fare oggi, utilizzando le attuali reti e gli strumenti e i software di produzione già disponibili e ben conosciuti dagli sviluppatori.

2.1 Web service architecture

Ci sono tre attori all’interno dell’architettura web service:

1.SERVICE PROVIDER : il provider del web service. Il service provider implementa il servizio e lo rende disponibile su Internet. 2.SERVICE REQUESTOR : è rappresentato da qualsiasi fruitore del web service. Il requestor utilizza un web service esistente creando una connesione di rete e spedendo un richiesta XML.3.SERVICE REGISTRY : rappresenta una directory centralizzata di servizi. Il service registry fornisce un posto centrale dove gli svilippatori possono pubblicare nuovi servizi o trovare quelli esistenti.

Un’altro punto di vista attraverso il quale si può analizzare l’architettura web service è esaminare lo stack di protocolli.

SERVICE TRANSPORT: questo livello è responsabile di trasportare messaggi tra applicazioni. Al momento include HTTP, SMTP, FTP, BEEP(Blocks Extensible Exchange Protocol).

XML MESSAGING: questo livello è responsabile di codificare i messaggi in formato XML. Attualmente questo livello include XML-RPC e SOAP.SERVICE DESCRIPTION: questo livello è responsabile di descrivere l’interfaccia pubblica di uno specifico web service. Al momento questo servizio è gestito attraverso WSDL(Web Service Description Language).

SERVICE DISCOVERY: questo livello è responsabile di centralizzare servizi in un comune registro, e di fornire una facile funzionalità di pubblicazione/ricerca. Attualmente questo livello è gestito con UDDI ( Universal Description,Discovery, and Integration).

Discovery UDDI

8

Description WSDL

XML messaging XML-RPC, SOAP, XML

Transport HTTP, SMTP, FTP, BEEP2.2 XML

Questo linguaggio è stato definito dal W3C (World Wide Web Consortium) poiché si sentiva la necessità di un formato uniforme e indipendente dalla piattaforma per descrivere dati che potessero essere anche strutturati. Il tutto doveva essere pensato in modo che un’applicazione potesse poi usare facilmente questo formato. Da queste specifiche è nato XML : eXtensible Markup Language. Le caratteristiche principali sono :

i dati sono strutturati ad albero un documento XML, essendo nient’altro che una sequenza di caratteri, può essere

facilmente spedito su una rete

La “X” di XML indica che un’altra delle caratteristiche fondamentali di XML è l’estensibilità: infatti, molti linguaggi di descrizione dei dati – ed in particolare WSDL e SOAP – sono basati su XML. Banalmente si può paragonare XML all’HTML (derivano entrambi dallo standard SGML che fornisce una notazione formale per la definizione dei linguaggi di markup) con la differenza che mentre in HTML i tag servono per esprimere come un dato deve essere visualizzato (font, dimensione, colore, ecc.) in XML i tag rappresentano il significato del dato, quindi non è affatto necessario che esistano dei parser che rendano il contenuto dei file XML uman-readable, come invece accade con HTML.Vediamo ora brevemente un esempio di documento XML:

<?xml version="1.0" encoding="iso-8859-1" ?> <magazzino><libro>  <IDLibro>111</IDLibro>   <Titolo>Divina Commedia</Titolo>   <Prezzo>40</Prezzo>   <Autori>Dante Alighieri</Autori> </libro><libro>  <IDLibro>222</IDLibro>   <Titolo>Promessi Sposi</Titolo>   <Prezzo>30</Prezzo>   <Autori>Alessandro Manzoni</Autori> </libro></magazzino>

9

Grazie alla strutturazione ad albero del documento, si intuisce facilmente che rappresenta un ipotetico magazzino contenente due libri, il primo, la “Divina Commedia” di Dante Alighieri, che ha codice 111 e costa 40 euro, il secondo, i “Promessi Sposi” di Alessandro Manzoni, che ha codice 222 e costa 30 euro.

Il documento inizia con una riga di intestazione che informa il parser sulle caratteristiche del documento, dopo la quale inizia il documento vero e proprio nel quale i vari tag, che devono seguire regole ben precise perché il documento sia accettato, “spiegano” il contenuto dei dati.Dal documento si nota inoltre come sia possibile definire nuovi tag a piacere e come le informazioni vengano descritte creando una struttura gerarchica ad albero.Per rendere possibile una validazione da parte del ricevente ogni documento XML può contenere la descrizione della sua struttura (DTD), cosicché il parser ricevente possa controllare se il documento è “well formed” (ben formato), cioè rispetta la sintassi XML e “well formed” e “valid” (valido), cioè rispetta le regole presenti nel DTD.In sintesi XML non è nient’altro che un sistema per dare un significato al contenuto di un documento. Per questo trova grande applicazione, nell'ambito dello scambio di dati tra strutture non omogenee come possono essere diverse aziende.

2.3 SOAP

SOAP (Simple Object Access Protocol) è il protocollo che fornisce un semplice meccanismo per lo scambio di informazioni strutturate (scritte sfruttando le potenzialità di XML) in un sistema distribuito decentralizzato.Definendo solo la struttura del messaggio e alcune regole per elaborarlo, SOAP risulta completamente indipendente, dal protocollo di trasporto sottostante e così implementabile da qualsiasi linguaggio di programmazione e su qualsiasi sistema operativo.Un’altra caratteristica chiave di SOAP è la sua semplicità (“Simple”) che gli ha permesso di affermarsi tra i protocolli di comunicazione e che lo rende estensibile a seconda delle esigenze e degli sviluppi futuri.Inoltre con SOAP è possibile usare un qualsiasi modello di programmazione e non solo l’RPC al quale è spesso associato.SOAP è diviso in tre parti: 

1. L’envelope (busta), che è una struttura globale per la definizione di cosa sta nel messaggio e di chi se ne deve occupare.

2. Un insieme di regole di encoding, che sono il meccanismo con il quale poter ottenere lo scambio di informazioni.

3. Una rappresentazione RPC, che fornisce la convenzione usata per le eventuali chiamate e risposte a procedure remote.

Mostriamo ora un messaggio SOAP e analizziamone la struttura, come protocollo di trasporto per il messaggio è stato scelto l’HTTP.Tale messaggio rappresenta la richiesta al web service dell’esecuzione del metodo GetLastTradePrice e passa come parametro una stringa, racchiusa tra i tag <symbol></symbol> che rappresenta il prodotto del quale si vuole conoscere il prezzo.

POST /StockQuote HTTP/1.1Host: www.stockquoteserver.com

10

Content-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "Some-URI"

<SOAP-ENV:Envelope  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>   <SOAP-ENV:Header>       <t:Transaction           xmlns:t="some-URI"           SOAP-ENV:mustUnderstand="1">               5       </t:Transaction>   </SOAP-ENV:Header>   <SOAP-ENV:Body>       <m:GetLastTradePrice xmlns:m="Some-URI">           <symbol>DEF</symbol>       </m:GetLastTradePrice>   </SOAP-ENV:Body></SOAP-ENV:Envelope>

Si nota subito come l’envelope del messaggio sia divisa in due parti:

1. L’header: una parte opzionale del messaggio che consente l’aggiunta di caratteristiche al messaggio SOAP stesso ed è sfruttato spesso per l’estensibilità del protocollo, vi possono essere infatti entries riguardati l’autenticazione, la gestione della transazione, ecc.

2. Il Body: parte obbligatoria che contiene le informazioni da spedire al destinatario, quali possono essere il marshalling di una chiamata RPC, comprensivo dell’invio di tutti i parametri necessari alla stessa.

L’applicazione che riceverà il messaggio deve:

1. Identificare le parti del messaggio SOAP destinate ad essa.

2. Verificare che tutte queste parti siano supportate e in tal caso elaborarle.

3. Nel caso in cui l’applicazione non sia il destinatario finale del messaggio, essa deve rimuovere tutte le parti identificate nel punto 1. e inoltrare il messaggio.

Nel caso subentrino degli errori l’applicazione risponderà al mittente con degli speciali messaggi d’errore che specificano il tipo e le cause dell’errore stesso, tali messaggi sono detti SOAP Fault.

2.4 Web services e devices mobili

L’evoluzione e la diffusione dei devices mobili hanno suscitato notevole interesse; ad esempio nelle principali aziende i cui dipendenti debbano accedere ad applicazioni back office dall’esterno dell’azienda stessa.I WS offrono inoltre alla Pubblica Amministrazione l'opportunità di aprire le porte ai propri cittadini, offrendo in maniera conveniente ed economica servizi accessibili 24 ore su 24, nell'ottica del riuso di quanto già sviluppato.I web services, dal canto loro, per la loro indipendenza alla piattaforma che li utilizza, sono considerati un’ottima soluzione per portare applicazioni sui devices mobili.

11

Appare quindi abbastanza naturale come queste due tecnologie si stiano sempre più avvicinando l’una all’altra, cosicché gli utenti finali possano fruire contemporaneamente dei benefici derivati dalla loro unione.A tale scopo tutti i più importanti software vendors hanno operato per realizzare piattaforme destinate a questo tipo di dispositivi. Oltre alla già nota J2ME della Sun infatti, sono tuttora disponibili anche piattaforme sviluppate da IBM e da Microsoft (che ha realizzato .Net Compact Framework, una versione ridotta della piattaforma .Net). Palm, dal canto suo, ha sviluppato partnership con BEA Systems e IBM per veicolare Web Services attraverso gli application server di tali produttori.Sfruttare i web services comporta, oltre agli enormi benefici in termini di standardizzazione e apertura, lo spostamento del calcolo su un’altra macchina e quindi non soffrire per le basse risorse a disposizione.

Il Nokia Web Services Framework.

Il Nokia Web Services Framework è un’insieme di APIs e una SDK che permette di costruire applicazioni service-oriented progettate in Java o C++ e un metodo di astrazione che permette ai sviluppatori di concentrarsi più sull’aspetto logico dell’applicazione che sulle chiamate di sistema. Inoltre include il supporto per standards come HTTP, XML, SOAP e un framework per identity management, sicurezza, service discovery e session managment. In poche parole questo framework facilita lo sviluppo e l’impiego di nuovi servizi che sono sia offerti che utilizzati dai telefonini.Questa struttura device-to-server è basata su una specifica “open” del World Wide Web Consortium (W3C) e del Liberty Alliance Project. L’uso di queste specifiche consente la creazione di soluzioni che sono in grado di interagire con varie implementazioni basate su Web service. Il Nokia Web Services Framework è implementato nelle piattaforme smartphone di Nokia. Al momento il framework è disponibile, attraverso un insieme di Symbian OS APIs, nei modelli Nokia 9500 Communicator e Nokia 9300 smartphone. In un prossimo futuro verrà inglobato nella terza edizione della piattaforma Series 60.

3 SYMBIAN OSSymbian OS – precedentemente conosciuto come EPOC – è un open smart-phone OS prodotto da Symbian. Symbian è una software licensing company, fondata nel 1998 di proprietà di Ericsson, Nokia, Panasonic, Psion, Samsung Electronics, Siemens e Sony Ericsson. Posseggono una licenza di Symbian Arima, BenQ, Fujitsu, Panasonic, LG Electronics, Motorola, Nokia, Samsung, Sanyo, Sendo, Siemens, and Sony Ericsson. (Symbian 2004)Questo sistema operativo è stato progettato specificatamente per device mobili. Questo ha significato la creazione di un OS che è in grado di gestire aspetti quali capacita di calcolo limitato e vincoli di memoria, fornendo inoltre una ricca Application Programming Interface ( API ) per gli sviluppatori. Symbian OS ha una struttura layered, uno scheduler preemptivo a livello di thread, e uno non preemptivo a livello di active objects. Inoltre è un sistema aperto che consente di installare software altrui direttamente da parte dell’utente. Le applicazioni per Symbian possono essere in Java installando la Java Micro Edition o in C++. Tutti questi fattori, in aggiunta all’espansione dei

12

telefoni basati su Symbian, rende lo sviluppo su Symbian un allettante opzione, ma al momento, è relativamente sconosciuto in termini di performance e facilità di sviluppo.

3.1 Linguaggi di programmazione

Il linguaggio scelto per lo sviluppo è il C++ che consente maggiore flessibilità. Sviluppando in C++ permette performance più veloci e da accesso a ogni dispositivo in modo simile ad un’ambiente di sviluppo basato su PC. Queste risorse/dispositivi includono alcuni elementi come schermo, tastiera, camera, speaker e anche Bluetooth, GSM, GPRS, SD/ CompactFlash, messaggi (MMS/Text), oltre alla suite di protocolli di rete come TCP/IP e anche quelli di più alto livello come HTTP e vari metodi di invio/ricezione e-mail.In aggiunta al C++, lo sviluppo su dispositivi Symbian può essere realizzato usando il linguaggio di programmazione Java. Questo è particolarmente indicato per giochi e piccole applicazioni, dato che lo sviluppo in Java è più veloce che quello in C++ dovuto alla presenza del garbage collector e alla sua natura come linguaggio object oriented. Uno svantaggio principale di Java è la velocità di esecuzione delle applicazioni Java. Questo è dovuto al fatto che i programmi Java i quali sono compilati usando le Micro Edition class libraries, Mobile Information Device Profile (MIDP) sono poi eseguite in un Connected Limited Device Configuration (CLDC) virtual machine sul dispositivo Symbian.Qui arriviamo al secondo svantaggio, il quale consiste nel limitato accesso alle native API e dispositivi da parte della VM. Questo potrebbe non influire in alcune applicazioni ma potrebbe essere un fattore limitante all’accesso ad esempio al Bluetooth e al pieno controllo del dispositivo se necessario.

3.1.1 Limitazioni rispetto ad ANSI C++.

1. Static Writeable Data :Symbian OS non permette static writeable data [22] ( ogni dato dichiarato fuori da una funzione ) in DLLs. Dato che tutte le applicazioni standards sono DLLs, questo vuol dire che le applicazioni non possono avere static writeable data.

2. TemplatesSymbian OS limita l'utilizzo di templates solo per "thin templates". Thin templates non richiedono duplicazione di codice oggetto, ma sono comunque type-safe.

3.1.2 Caratteristiche proprie di Symbian OS.

1. Regole di nomenclaturaI nomi delle classi sono formattati con le lettere C, T, R, o M come prefisso, secondo particolari regole dettate dall'allocazione, gestione risorse, interfacce ...

13

2. Regole di eraditarietàereditarietà dalla classe CBase e ereditarietà multipla.

3. EccezioniI comandi per gestire le eccezioni, try-catch-throw, tipiche dell'ANSI C++, non sono supportate in Symbian OS. Questo per ragioni sia storiche che di efficienza. Symbian OS introduce il concetto di leaves. Le macro TRAP e TRAPD vengono utilizzate in analogia a try-catch del C++. In aggiunta alla gestione delle eccezioni attraverso leave e trap in Symbian OS esiste anche il concetto di panics.

4. Cleanup StackIl cleanup stack è di solito usato per memorizzare puntatori a classi derivate da CBase. Quando si verifica una leave il cleanup stack è svuotato e la funzione delete è invocata su ogni puntatore CBase* sullo stack.

5. Costruttore a due fasiIl cleanup stack non fornisce una soluzione per leaves che si verificano all’interno dei costruttori delle classi derivate da CBase. La soluzione è il costruttore a due fasi. All’interno del normale costruttore, che non può generale una leave, si invoca un altro “costruttore” che può contenere codice che genera una leave. Prima di invocare il secondo costruttore, però, si inserisce il puntatore all’oggetto che si sta creando sul cleanup stack.

6. Active Objects e Active scheduler

Active objects sono una parte fondamentale di Symbian OS. Gli active objects sono utilizzati per semplificare la programmazione asincrona, attraverso essi si può emettere una richiesta asincrona, gestire il ritorno dell’evento e processare i risultati. Sono adatti per una programmazione basata sugli eventi, non pesante dal punto di vista del consumo di risorse, eccetto per operazioni real-time. Questo perché, una volta che un active object sta gestendo un evento, non può essere interrotto per gestire un evento in un altro active object ( poiché Symbian OS utilizza uno scheduler non preemptivo a livello di active objects).L’active scheduler è responsabile della schedulazione degli eventi verso gli appropriati active object.3.3 Event HandlingSymbian OS è ottimizzato per un efficiente gestione eventi. Ogni applicazione Symbian OS o server è un singolo event-handling thread, nel quale una serie di active objects vengono utilizzati per gestire degli eventi in modo non nonpre-emptive.Questo vuol dire che dal punto di vista del consumo energetico la CPU ha bisogno di risorse solo quando sta eseguendo qualcosa. C’è consumo di energia nella gestione di un interruzione, mentre non c’è consumo quando non ci sono threads da sincronizzare.La gestione degli eventi si verifica nei therads con un unico active scheduler per therad il quale coopera con uno o più active objects per gestire gli eventi generarti da devices o altri programmi.Ogni active object ha una funzione virtuale RunL(), la quale è chiamata quando un evento si verifica, per il quale l’AO è responsabile.

Multitasking

Per permettere l’esecuzione di più applicazioni e severs simultaneamente, Symbian OS implementa preemptive multithreading. Dall’altro lato, active objects sono usati per implementare non-preemptive multitasking all’interno del contesto di un singolo thread, dato che RunL() deve gestire l’evento prima che il prossimo event handling possa verificarsi sul thread.

14

Come i therads, gli AOs hanno priorità che influenzano la loro schedulazione, ma in modo differente.Mentre il thread con priorità più alta viene sempre eseguito, la selezione di un active object viene eseguita solo quando la gestione della notifica del precedente AO è terminata.Dato che alcuni eventi sono più importanti di altri, è molto più vantaggioso gestirli in base alla priorità piuttosto che in modalità FIFO. La gestione degli eventi deve essere relativamente veloce, poiché non possono essere chiamate altre RunL() finchè quella corrente non termina, nonostante la loro priorità.Oltre all’efficacia d’esecuzione, il vantaggio del multitasking basato sugli active objects è che il programmatore non ha bisogno di utilizzare mutexes, semafori, sezioni critiche, o altri metodi di sincronizzazione per proteggere dalle attività di altri active objects nello stesso thread.

3.3.1 Active ObjectsCome menzionato in precedenza, quasi tutti i threads in Symbian OS utilizzano un active scheduler, il quale si comporta come un mini-kernel, e uno o più active objects, i quali si comportano come dei non-pre-emptively scheduled minithreads.Quindi quasi tutto il codice Symbian OS viene eseguito sotto il controllo delle funzioni membro RunL() degli active objects.Sistemi event-handling sono basati su programmi che richiedono qualche servizio che verrà completato in seguito ad un certo istante. Tali servizi sono perciò forniti in modo asincrono. Chi richiede il servizio deve quindi gestire l’evento, quando il servizio asincrono è pronto per la notifica. In Symbian OS è tipico avere un therad che possiede simultaneamente più di una richiesta ad un servizio asincrono.Quando una richiesta asincrona viene notificata al richiedente, deve essere identificata, così la particolare richiesta può essere gestita.Gli active objects incapsulano la richiesta di un servizio e la gestione dell’evento nel momento della notifica, in modo tale che ogni active object è responsabile di emettere la richiesta e gestire la ricezione della notifica per una sola richiesta alla volta.

Richiesta di servizi asincroni

In Symbian OS, ogni funzione asincrona – cioè una service request – ha come parametro un riferimento a un oggetto TRequestStatus. Quando la funzione è invocata, TRequestStatus è impostato a KRequestPending.Quando il servizio notifica il richiedente, TRequestStatus contiene un codice d’errore - KErrNone, se nessun errore si è verificato.Un service requester (chi invoca il servizio asincrono) deve usare o la funzione User::WaitForRequest() o User::WaitForAnyRequest() per attendere il completamento della richiesta. Inoltre deve fare attenzione a non usare lo stesso TRequestStatus per altre richieste finchè la richiestà è stata completata e gestita e generalmente non emettere più di una richiesta per un particolare provider.Siccome le richieste possono essere cancellate dopo che sono state emesse, il service provider deve fornire una funzione Cancel() nella API. Quando la funzione Cancel() è chiamata, il provider deve completare la richiesta immediatamente con codice di ritorno KErrCancel, o permettere che la richiesta termini normalmente se è garantito che ciò richiede pochissimo tempo, o non fare niente, se la richiesta è già stata completata prima della chiamata a Cancel().

15

Encapsulating Request Handling

Normalmente, un singolo thread emette più rechieste asincrone simultaneamente, le quali possono “ritornare” in qualsiasi momento. Per assicurare che il therad gestisca correttamente questi ritorni, può essere utilizzato il seguente protocollo :

per attendere che una richiesta venga completata usare User::WaitForAnyRequest(), il thread verrà riesumato quando la prima richiesta verrà completata. In quel momento si procede alla ricerca tra i vari TRequestStatus, associati con le richieste, quello non settato a KRequestPending. Quindi si procederà alla sua gestione. Ricomincia il ciclo rimanendo in attesa del prossimo ritorno di una richiesta.

Symbian OS incapsula il ciclo descritto sopra in un CActiveScheduler - l’active scheduler – che ogni therad possiede, uno al massimo. Il comportamento di un event requester (colui che richiede un service request) è incapsulato in una classe base astratta, CActive – la super classe degli active objects. Una classe che deriva da CActive aggiunge un oggetto che rappresenta un service provider asincrono, alcune funzioni di richiesta disponibili ai clients, una funzione RunL() per gestire il ritorno della richiesta, una funzione DoCancel() per cancellare la richiesta, e spesso, alcuni puntatori ad altri oggetti nel programma e alcune variabili interne. Le variabili di stato sono contenute nella classe base.Il costruttore di un AO imposta la sua priorità, la quale determina la sequenza con la quale l’active scheduler ricerca la prossima richiesta che è completata.La funzione che richiede un service request usa un built-in TRequestStatus appartenente alla classe base CActive nella sua richiesta e subito dopo chiama SetActive() per settare l’active flag. Altrimenti l’active scheduler non troverebbe l’AO responsabile per la gestione dell’evento, nel qual caso provocherebbe la generazione di un stray signal. Stray signals provocano “to panic” il therad da parte dell’active scheduler.

4 BLUETOOTHCome standard di comunicazione per far interagire i componenti del sistema è stato scelto il Bluetooth (IEEE 802.15.1). Questa scelta rappresenta una conseguenza dettata da un requisito di sistema: l’applicazione deve essere implementata su sistema operativo Symbian OS. Questo vincolo e stato imposto sia per permette agli smart-phone di partecipare come nuovi attori nel sistema, sia per risolvere alcuni problemi di architettura incontrati nello sviluppo di questo client su device con JVM. Quindi analizzando gli standard di comunicazione disponibili sui device basati su Symbian OS, la scelta è ricaduta sul Bluetooth poiché escludendo a priori la comunicazione basata su SMS, essendo troppo costosa, e IR, poca banda a disposizione e limiti dovuti alla necessità di una comunicazione visiva, gli smart-phone che al momento permettono la comunicazione Wi-Fi sono pochi e costosi.Bluetooth [23] è uno standard de facto per connessioni radio di ristretto raggio e di poca potenza, che può collegare PDA, telefonini e portatili, e dare accesso ad Internet attraverso hot spots.Questa tecnologia è stata ideata nel 1994 dalla ditta svedese Ericsson, come metodo di comunicazione a corto raggio (circa 10 metri) tra dispositivi mobili per rispondere ad una precisa esigenza di mercato. Infatti, con l’aumento dei dispositivi elettronici di uso quotidiano, sono aumentati anche i metodi di connessione, sempre più specifici e proprietari. Ad esempio, un cavo VGA connette il computer al monitor ed uno USB alla stampante. Una connessione dati veloce richiede Ethernet (ovvero un cavo RJ-45) oppure, accontentandosi di una velocità ridotta, un doppino telefonico con presa RJ-11. A questi vanno poi aggiunte tutte le connessioni a breve

16

termine, come quelle che si realizzano temporaneamente per sincronizzare i dati tra computer e palmare, o per scaricare le foto dalla macchina digitale, quelle via radio che permettono l’uso di telefoni senza fili, e infine quelle ad infrarossi per il controllo remoto del televisore o dello stereo.Questa breve panoramica degli standard utilizzati quotidianamente mette in evidenza la necessità di un denominatore comune, per sollevare l’utente dai limiti introdotti dall’hardware proprietario.Nel 1998 questi concetti si concretizzano nel consorzio SIG (Special Interest Group) Bluetooth, formato da Ericsson, IBM, Intel, Nokia e Toshiba per sviluppare specifiche open-source e indipendenti dalle grandi case costruttrici. Da allora, più di 2000 società hanno partecipato al SIG Bluetooth, compresi virtualmente tutti i produttori di telefonia, computer e palmari. Anche se inizialmente è stato utilizzato quasi esclusivamente come sostitutivo delle comunicazioni via cavo e via raggi infrarossi, il Bluetooth offre effettivamente molti altri vantaggi. Questi vanno dalla sincronizzazione di dispositivi al controllo sull’accesso di edifici basato sul riconoscimento degli utenti provvisti di tecnologia Bluetooth. Le opportunità di sviluppo create da questo standard sono poi rese particolarmente interessanti da tre elementi:

• Il costo ridotto necessario per la realizzazione di dispositivi con Bluetooth integrato.• La possibilità di riassumere in un unico telecomando tutti i dispositivi eterogenei che ognuno di noi porta sempre con se, come carte magnetiche e di credito, chiavi di casa, della macchina, dell’ufficio, telecomandi per il cancello e il garage.• La facilità di installazione e di utilizzo, resa possibile dal riconoscimento automatico di altri dispositivi Bluetooth adiacenti. Questa trasparenza permette all’utente di aprire cancelli e porte senza azionare nessun comando, oppure telefonare con il semplice uso di auricolari, pur tenendo il cellulare in tasca.

Si comprende quindi come questa tecnologia (che al pari di altri standard usa la banda Industrial-Scientific-Medical (ISM) dei 2.4 GHz), sia molto più che un metodo di sostituzione di cavi e rappresenti piuttosto un metodo di comunicazione completamente nuovo tra dispositivi elettronici a breve distanza.

4.1 Confronto con altri standard wirelessPer mettere in evidenza i punti di forza ed i limiti di questa tecnologia, risulta utile un breve confronto con due noti standard di comunicazione wireless i cui ambiti vengono spesso ad intersecarsi con quelli del Bluetooth: l’infrarosso e l’802.11b (Wi-Fi™).Generalmente i dispositivi domestici come i TV o i videoregistratori (anche indicati come black devices, in contrasto con gli elettrodomestici come la lavatrice e la lavastoviglie chiamati white devices) vengono controllati con telecomandi a fasci di luce infrarossa. Questo tipo di comunicazione, pur beneficiando di costi ridotti ed estrema facilità di utilizzo, è però limitata per quel che riguarda il raggio di azione. Inoltre, dato che ricevitore e trasmettitore devono vedersi reciprocamente, la comunicazione può avvenire solo posizionandosi di fronte all’apparecchio a cui si vuole inviare il segnale.Per quel che riguarda il confronto con lo standard 802.11g, l’aspetto comune più evidente riguarda la banda: entrambi questi protocolli di comunicazione wireless operano nella banda dei 2.4 GHz. Tuttavia è importante non considerare Bluetooth come un sostitutivo dello standard 802.11g nell’ambito, ad esempio, di LAN realizzate senza cavi, perché effettivamente sono stati pensati e realizzati come tecnologie complementari.Il protocollo 802.11g è stato progettato per connettere dispositivi di dimensioni piuttosto grandi e con elevata disponibilità di potenza e di banda, come computer desktop e portatili. Questi possono comunicare ad una velocità massima di 54 Mbit/sec e raggiungere distanze di 100 metri.

17

Dall’altra parte Bluetooth è stato realizzato per dispositivi di dimensioni ridotte come palmari e telefoni cellulari, in grado di comunicare ad una velocità massima di 1 Mbit/sec, in un raggio di 10 metri. È quindi ovvio che questo protocollo può operare a potenza molto ridotta.I miglioramenti delle versioni 1.1 e 2.0 dello standard Bluetooth hanno consentito l’introduzione di nuove classi di potenza, che permettono di raggiungere fino a 100 metri di raggio mantenendo un consumo abbastanza limitato.Un’altra importante differenza con lo standard 802.11b è relativa al fatto che questo non è stato creato per le comunicazione vocali, mentre ogni connessione Bluetooth supporta sia i dati che la voce.Riassumento i maggiori vantaggi della tecnologia Bluetooth.• È wireless ed opera in modo automatico: non servono cavi, connettori e connessioni. Inoltre la connessione viene iniziata automaticamente, perché i dispositivi, posti in prossimità, si trovano reciprocamente e cominciano autonomamente a comunicare (eccetto nel caso in cui sia richiesta un’autenticazione).• È a consumo ridotto: questa caratteristica che ne lo strumento più adatto per essere integrato all’interno di apparecchi compatti, in cui non è previsto lo spazio per voluminose batterie.• È a basso costo: attualmente la spesa sostenuta da un’azienda per introdurre questa tecnologia all’interno di prodotti di dimensioni ridotte è di circa 15 euro, ma nel giro di alcuni anni dovrebbe scendere sotto i 5 euro per unità.• La banda ISM è regolata ma libera: gli stati si sono accordati su un unico standard per permettere agli utenti di utilizzare lo stesso dispositivo Bluetooth virtualmente in ogni parte del mondo.• Gestisce sia la voce che i dati: la sua capacità di gestire simultaneamente dati e voce rende possibili innovazioni quali auricolari da utilizzare a mani libere con applicazioni integrate per l’invio di fax ed email.• Il segnale è omnidirezionale e può passare attraverso i muri: i dispositivi non hanno bisogno di essere a vista e posso anche essere in stanze diverse.

4.2 Topologia di reteUn altro punto di forza del Bluetooth è la topologia di rete, che permette la creazione di reti ad-hoc particolarmente flessibili. I dispositivi possono interagire secondo due diversi schemi.Lo schema più semplice è costituita da una “personal area network” (PAN) chiamata piconet. In questa configurazione possono essere contemporaneamente presenti 8 dispositivi (poiché lo spazio d’indirizzamento è limitato a 3 bits): 1 solo master e 7 slave. Il master controlla tutto il traffico e se due slave vogliono comunicare tra di loro, il messaggio deve passare attraverso il master. La piconet utilizza un semplice meccanismo di polling: richiede a turno ad ogni slave se ha un messaggio da inviare.La comunicazione è basata su pacchetti. Quando un’unità riceve un pacchetto controlla prima di tutto il destinatario: se non è diretto a quell’unità, il pacchetto viene rilasciato. In questo modo tutti i dispositivi della rete possono condividere un unico canale logico.Il secondo schema (scatternet), è più complesso e permette la sovrapposizione di più piconet, fino ad un massimo di 10. Le piconet formano una scatternet quando hanno un punto in comune, tipicamente realizzato con un dispositivo in comune a diverse piconet.

4.3 Bluetooth Protocol StackTutte le comunicazioni che avvengono tra due dispositivi Bluetooth passano attraverso il Bluetooth Protocol Stack.

18

Lo stack del Bluetooth, rappresentato in Figura 4.1 è diviso in due parti: il controllore, tipicamente hardware, e l’host software con cui le applicazione ed i servizi interagiscono. Il sistema realizzato in questa tesi interagisce in modo esplicito solo con i livelli più alti dello stack, analizzati di seguito:• HCI: è il livello software più basso, che si interfaccia direttamente con l’hardware.• L2CAP: gestisce la segmentazione e il raggruppamento dei pacchetti, il protocollo di multiplexing e fornisce informazioni sulla qualità del servizio.• SDP: le applicazioni utilizzano questo livello per identificare servizi Bluetooth disponibili.• RFCOMM: questo livello opera per emulare una connessione seriale via Bluetooth.

Figura 4.1: Bluetooth Protocol Stack.5 ARCHITETTURA DEL SISTEMA

Riprendiamo per il momento l’architettura su cui si basa un web service, analizzando la pila di protocolli. Questo ci servirà poi per introdurre il particolare stack di protocolli che verrà utilizzato in ambiente domotico.

5.1 SOA

I web services sono un esempio di service-oriented architecture (SOA). Architetture service-oriented sono sistemi distribuiti che promuovono il concetto di servizi autonomi, accessibili e disponibili a un gran numero di applicazioni.Il Service-Oriented Computing (SOC) [20] e il paradigma computazionale che utilizza servizi come elementi fondamentali per lo sviluppo di applicazioni. Per costruire il “modello a servizi”, SOC utilizza come base l’architettura SOA, in questo modo e possibile riorganizzare applicazioni software e infrastrutture in un insieme di servizi che interagiscono tra loro. Comunque la base su cui appoggia SOC, ovvero l’architettura SOA, non affronta aspetti quali gestione, coordinazione, sicurezza ed altri problemi che si verificano nella gestione dei servizi in un’architettura orientata ai servizi.Quindi e necessario estendere quest’architettura per supportare la composizione di servizi. Papazoglou ha introdotto a tale scopo un Extended Service Oriented Architecture (ESOA) che fornisce ulteriori livelli per la composizione e coordinazione di servizi.

19

Per supportare la realizzazione del paradigma SOC [17], i Web services devono basarsi su standars a livello di protocollo di comunicazione, di meccanismi di descrizione dei servizi, scoperta, composizione e QoS. Gli aspetti nuovi, rispetto al framework base sono rappresentati proprio dai livelli QoS e composizione. Di seguito viene riportato una versione ampliata dello stack di protocolli per web service utilizzato per supportare la composizione robusta di servizi.

Figura 5.1: Lo stack di protocolli per web service [17].

Il protocollo SOAP e il linguaggio XML sono stati già affrontati nel capitolo 2. Passiamo quindi in rassegna gli altri componenti. WSDL è una specifica che definisce come descrivere web services in una comune grammatica XML. WSDL è indipendente dalla piattaforma e dal linguaggio utilizzato ed è utilizzato principalmente (non esclusivamente) per descrivere servizi SOAP. WSDL descrive 4 importanti parti di codice del web service:

o Informazioni sull’interfaccia, descrivendo tutte le funzioni pubbliche o Informazioni sui tipi di dato scambiati nei messaggi di richiesta e rispostao Informazioni sul binding, cioè riguardo al protocollo di trasporto utilizzatoo Informazioni sull’indirizzo dove localizzare il servizio specifico

Utilizzando WSDL [11], un client può localizzare un web service ed invocare le sue funzioni pubbliche. Inoltre utilizzando dei WSDL invocation tools, come IBM Web Services Invocation Framework (WSIF), SOAP::Lite o la piattaforma Mind Electric’s GLUE è possibile automatizzare questo processo permettendo di integrare facilmente nuovi servizi con poche righe di codice.WSDL è lo standard per la descrizione di un singolo web service, per rendere possibile la descrizione di aggregati di servizi esiste un altro sistema, BPEL (Business Process Execution Language) .BPEL (Business Process Execution Language) è un linguaggio in grado di specificare il comportamento di un processo di business, e quindi di descrivere le caratteristiche di un aggregato di web services.L’introduzione di tale linguaggio permette un ulteriore grado di astrazione nella pila dei servizi web, infatti grazie al suo utilizzo si è in grado di mascherare all’utente finale non solo il funzionamento interno di ogni singolo servizio (cosa che era già possibile con WSDL) ma anche le modalità di interazione con ogni singolo servizio, mostrando all’utente finale l’aggregato di servizi come un’entità unica.BPEL esprime le specifiche degli aggregati di servizi tramite un file XML per struttura molto simile ai file WSDL. Per rendere l’interazione tra tra servizi robusta vengono utilizzati Web service coordination (WS-Coordination) e Web service transactions (WS-Transaction). WS-Security

20

garantisce controllo d’accesso e riservatezza dei messaggi mentre per problematiche relative all’affidabilità WS-ReliableMessaging.Le capacità descrittive di WSDL possono essere migliorate dal framework WS-Policy, il quale estende WSDL per codificare ed allegare informazioni di QoS ai servizi nella forma di “politiche del servizio” che possono essere riutilizzate.Questo stack di protocolli Web service rappresenta una soluzione generale, progettato in modo modulare, permettendo cioè di modificare secondo le necessita i componenti utilizzati ad ogni livello. Questa premessa introduce il prossimo paragrafo nel quel viene presentato un framework specifico per ambiente domotico.

L’ambiente domotico si presenta come un insieme di web services. Ciascun componente, infatti, offre dei servizi, che possono essere integrati per offrire servizi di livello superiore. Quindi l’architettura presentata nel precedente paragrafo offre una soluzione adeguata al contesto.Per il caso specifico di progetto di assistenza agli anziani, in [Aiello et al] [17] è stato proposto una versione rivisitata dello stack di protocolli. Di seguito viene riportato il framework proposto.

Figura 5.2: Lo stack di protocolli per web service in ambiente domotico [17].

Due considerazioni importanti emergono da questa nuova proposta. Prima di tutto ad alto livello è stato inserito WS-Notification per la coordinazione dei processi tramite il sistema di pubblicazione e sottoscrizione offerto da questo recente standard. Secondo a livello di QoS è stato considerato rilevante solo l’utilizzo di WS-Security.

5.2 Distributed objects

Il concetto di oggetti distribuiti ricade all’interno dei modelli di programmazione per applicazioni distribuite – cioè, quelle applicazioni che sono composte da programmi che cooperano tra di loro e si trovano all’interno di diversi processi spesso situati su altri computer. Per ottenere ciò, alcuni familiari modelli di programmazione sono stati estesi per applicarli a programmi distribuiti. Il primo ad essere stato esteso è stato il concetto di procedure call per ottenere il modello remote procedure call. Con l’avvento del modello di programmazione object-oriented il concetto di chiamata di procedura è stato esteso per permettere ad oggetti in differenti processi di comunicare con altri per mezzo di Remote Method Invocation (RMI).Il modello di programmazione basato sugli eventi, che permette agli oggetti di ricevere notifiche di eventi di altri oggetti ai quali hanno precedentemente registrato il loro interesse è stato esteso per scrivere programmi distribuiti basati sugli eventi.

5.2.1 Eventi e notifiche

21

Dietro l’uso degli eventi c’è l’idea che un oggetto possa reagire ai cambiamenti che si verificano in un altro oggetto. I sistemi distribuiti basati sugli eventi estendono il modello locale, cioè non distribuito, permettendo a molti oggetti situati su differenti siti di essere notificati quando si verificano degli eventi sugli altri oggetti.Questi oggetti usano il paradigma publish-subscribe, nel quale un oggetto che genera eventi “pubblica” i tipi di eventi che renderà disponibile agli oggetti “osservatori”.Gli oggetti che desiderano ricevere notifiche da parte di altri oggetti che hanno pubblicato i loro eventi, si sottoscrivono ai tipi di eventi di loro interesse.I sistemi distribuiti basati sugli eventi possiedono due caratteristiche principali:

eterogeneo : l’uso delle notifiche degli eventi può essere utilizzato come mezzo di comunicazione per creare un sistema distribuito, che permetta di far comunicare dei componenti che in realtà non erano stati progettati per lavorare in questa modalità.Quello che bisogna fare è che gli oggetti che generano eventi pubblichino i loro tipi di eventi, e altri oggetti si sottoscrivano a questi eventi e dispongano di un’interfaccia per ricevere le notifiche.

asincrono : le notifiche sono spedite in modo asincrono dall’oggetto che genera eventi a tutti gli oggetti che si sono sottoscritti . Questo per prevenire che chi pubblica gli eventi ( publisher ) sia sincronizzato con chi sia sottoscritto ( subscribe ) – publishers e subscribers devono essere dissociati.

Queste due caratteristiche rappresentano, appunto, due peculiarità del sistema implementato. Infatti, all’interno di un ambiente domotico, in generale, sussistono una serie di device eterogenei. Inoltre gli eventi che alcuni dispositivi generano sono per loro natura asincroni. Nel nostro caso, per esempio, l’evento di caduta è un evento che può addirittura non verificarsi.

5.3 WS-Notification

Il termine WS-Notification è usato per riferirsi ad una famiglia di specifiche [16]. Questa famiglia consiste dei seguenti documenti:

Publish-Subscribe Notification per Web Services : questo documento introduce il modello di programmazione basato sugli eventi e notifiche, includendo un insieme di termini e concetti usati negli altri documenti.I principali termini utilizzati in queste specifiche sono:

NotificationProducer : è un Web service che implementa lo scambio di messaggi con l’interfaccia NotificationProducer e supporta uno o più Topics. Questo Web service può essere un Publisher (cioè crea da solo i messaggi) oppure un NotificationBroker, che distribuisce i messaggi che sono prodotti da delle entità Publisher separate.

NotificationConsumer : è un Web service che riceve NotificationMessage da parte di un NotificationProducer.

Subscriber : è un entità (spesso un Web Service) che richiede dei servizi, spedendo dei messaggi di richiesta ad un NotificationProducer. Il Subscribe può essere un’entità diversa dal NotificationConsumer il quale effettivamente riceve il NotificationMessage.

22

NotificationBroker : è un intermediario Web service che dissocia NotificationConsumers da Publishers. Implementa entrambe le interfacce NotificationProducer e NotificationConsumer.

Publisher : è un’entità che crea NotificationMessages.

Vediamo con l’utilizzo di due diagrammi due scenari, rispettivamente senza e con NotificationBroker.

Figura 5.3: Le interazioni tra Subscriber e NotificationProducer, senza NotificationBroker.

Come possiamo vedere dal diagramma Subscriber e NotificationConsumer possono essere due entità distinte.

Figura 5.4: Le interazioni tra Subscriber, NotificationBroker e un Publisher.

WS-BaseNotification : definisce le interfaccie dei web services per i NotificationProducers e NotificationConsumers. Attraverso questo documento è possibile creare una semplice

23

comunicazione punto-a-punto. Per gli altri tipi di scenari è necessario la conoscenza degli altri documenti.

WS-Topics : la specifica WS-Topics definisce un meccanismo per organizzare e catalogare gli elementi di interesse per le sottoscrizioni conosciuti come “topics” in una struttura ad albero.

WS-BrokeredNotification : la specifica WS-Brokered Notification definisce l’interfaccia web services per il NotificationBroker. Un NotificationBroker è un intermediario il quale, fra le altre cose, permette la pubblicazione di messaggi da parte di entità che in realtà non sono fornitori di servizi. Questo è il cuore del servizio di notifica.

WS-Notification permette di costruire sistemi scalabili indipendenti dalle piattaforme costituiti da entità autonome. Inoltre la comunicazione tra queste entità può avvenire tramite l’invio di messaggi asincroni. Questo scenario è proprio quello di un ambiente domotico.

All’interno del nostro progetto il ruolo di NotificationBroker è ricoperto dal server che accetta tutte le sottoscrizioni da parte dei device mobili che ricoprono il ruolo dei Subscriber e anche dei NotificationConsumers. Mentre il ruolo dei Publisher è ricoperto dai rilevatori di caduta.

5.4 Il modello client-server

Nello scenario domotico relativo ad un sistema di sensori di caduta possono essere integrati devices mobili e device non-mobili, in tale contesto viene utilizzato il termine di spontaneous networking per sottolineare questa coesistenza. Esempi di device-mobili sono i computers portatili, PDA e smartphone in contrapposizione a PCs, sensori, telecamere ed altri dispositivi per il rilevamento.La caratteristica che contraddistingue i devices mobili, oltre utilizzare la comunicazione wireless, è la loro presenza temporanea all’interno del sistema. Non possiamo sapere a priori quanti e quali devices ci saranno nel sistema.In tale scenario dinamico esiste comunque un componente che è sempre presente e ricopre un ruolo di gestione, il server degli eventi. Se nella concezione comune del modello clint-server il server è colui che fornisce un servizio e il client usufruisce di esso, allora nell’implementazione adottata il server ricopre entrambi i ruoli. Questo perché mette a disposizione una serie di servizi ai clients, per esempio il rilevamento di caduta, ma allo stesso tempo per fornire questi servizi usufruisce di altri servizi come quelli resi dai sensori e telecamere. Questo doppio ruolo sarà ben chiaro quando introdurremo il funzionamento del server.Il modello client-server è stato preferito al modello peer-to-peer (P2P) per due motivi principali:

o C’era l’esigenza di un componente che utilizzasse tutti i servizi messi a disposizione dai diversi dispositivi di rilevamento e li elaborasse per produrre servizi di più alto livello. Questo è il motivo per cui il server rappresenta il NotificationBroker ricoprendo il ruolo di

24

intermediario tra clients che richiedono un servizio e clients e i sistemi di rilevamento che offrono un servizio.

o Per motivi di scalabilità: il sistema realizzato permette infatti a qualsiasi client, in grado di spedire e ricevere messaggi secondo una precisa sintassi, di usufruire dei servizi. I clients non devono essere a conoscenza di come questi servizi vengono forniti. Basta implementare opportunamente WS-Notification per accedere al sistema .

Figura 5.5: Il modello client-server.

5.5 La messaggistica standard di WS-Notification

Consideriamo tutti i messaggi che il server e il client si scambiano. Intanto incominciamo a descrivere la struttura di questi messaggi.Nell’immagine sottostante mostriamo una rappresentazione di questa struttura.

Figura 5.6: Struttura di un messaggio SOAP+WS-Notification.

25

La struttura del messaggio SOAP è già stata descritta nel paragrafo 2.3, quindi adesso poniamo l’attenzione sui messaggi WS-Notification, quindi riporteremo solo le porzioni di codice inserite nel body del messaggio SOAP.Prima di poter sottoscriversi ad un evento, il client contatta il server per ricevere l’albero degli eventi. Infatti il server memorizza tutti gli eventi che mette a disposizione in una struttura gerarchica ad albero. Di sotto viene riportato un esempio.

Figura 2.7: Un esempio di albero degli eventi.

La struttura gerarchica di questo albero comporta, per esempio, che la sottoscrizione all’evento Evento/Perdita/Acqua implica la ricezione di notifiche di eventuali eventi Evento/Perdita/Lavatrice e Evento/Perdita/Doccia. L’evento padre rappresenta una generalizzazione.L’albero degli eventi (quello gestito dal server) rappresenta una struttura dinamica, in quanto gli eventi possono essere aggiunti e cancellati in qualsiasi momento. L’eliminazione di un evento comporta la cancellazione di tutte le sottoscrizioni registrate dal broker (cioè nel nostro caso il server) stesso per quell’evento, nonché del suo sottoalbero. Comunque come scelta di progetto è stato concordato che due eventi sono sempre disponibili sul server, Event/Topics e Event/MysubscribedEvents. Questi due eventi rappresentano l'insieme degli eventi gestiti dal server e l'insieme delle sottoscrizioni inviate dal client presso quel server.Ecco il frammento di codice che il client spedisce per chiedere al server di spedirgli l’albero degli eventi :

1. <s12:Body>2. <wsrp:GetResourceProperty>3. "tns:Event/Topic"4. </wsrp:GetResourceProperty>5. </s12:Body>

Questo frammento di codice rispetta la sintassi definita in WS-ResourceProperties. In generale GetResourceProperty viene utilizzato per richiedere una particolare risorsa specificando un qualche identificativo della risorsa di cui si desidera conoscerne il valore.Un’altra risorsa è rappresentata dall’insieme delle sottoscrizione registrate con un particolare broker. Questa risorsa può essere molte utile per risincronizzare il server con il client, per esempio dopo un crash improvviso di quest’ultimo. Viene riportato il codice di questa richiesta:

1. <s12:Body>2. <wsrp:GetResourceProperty>3. "tns:Event/MySubscribedEvents"4. </wsrp:GetResourceProperty>5. </s12:Body>

Il cuore dello standard di comunicazione è costituito da due tipologie di messaggi: sottoscrizioni e notifiche (Subscribe message e Notify message).

26

Le sottscrizioni vengono generate dai clients ed inviate verso il server. Ogni sottoscrizione ha come oggetto un evento. Tramite le sottoscrizioni agli eventi - e soltanto in questo modo - è possibile ricevere messaggi di notifica generati in seguito al verificarsi di quegli stessi eventi.Ecco il frammento di codice che il client spedisce al server per sottoscriversi all’evento Event/Health:

1. <s12:Body>2. <wsnt:Subscribe>3. <wsnt:ConsumerReference>4. <wsa:Address> MY_URL:MY_PORT </wsa:Address>5. </wsnt:ConsumerReference>6. <wsnt:TopicExpression dialect="miourl+dialect.ebnf">7. tns:Event/Health8. </wsnt:TopicExpression>9. <wsnt:UseNotify> true </wsnt:UseNotify>10. <wsnt:InitialTerminationTime>EX_DATE</wsnt:InitialTerminationTime>11. </wsnt:Subscribe>12.</s12:Body>

Passiamo ad analizzare questo frammento di codice. Prima di tutto, è richiesto di esplicitare l’indirizzo del client (linea 4) a cui devono essere spedite le notifiche dell’evento di cui sta avvenendo la sottoscrizione. L’indirizzo viene espresso nel modo che segue, dove MY_URL è la stringa che identifica il proprio host, mentre MY_PORT è la porta su cui il proprio client è in attesa di notifiche.Quindi, è necessario specificare l’evento che è oggetto della sottoscrizione corrente (linea 7). L’identificativo dell’evento è espresso secondo la grammatica definita nella dialettica degli eventi. Nello spezzone precedente, l’evento è identificato da Event/Health.In aggiunta (linea 10), è possibile specificare la data e l’ora relative alla scadenza della sottoscrizione; qualora si desideri mantenere per sempre attiva una sottoscrizione, è sufficiente non indicare alcuna data. Talvolta, dato che le sottoscrizioni possono durare un tempo indeterminato, un consumer potrebbe desiderare di eliminare una sua specifica sottoscrizione. Purtroppo, lo standard non fornisce alcun tipo di messaggio per rispondere a questa necessità. Quindi è stato proposto di introdurre un nuovo messaggio appositamente strutturato per eliminare una sottoscrizione, denominato Unsubscribe message. Viene riportato di seguito il frammento di codice.

1. <s12:Body>2. <esns:Unsubscribe>3. <wsnt:TopicExpression dialect="miourl+dialect.ebnf">4. esns:Event/Health5. </wsnt:TopicExpression>6. <esns:Id>7. 110200143278171758. </esns:Id>9. </esns:Unsubscribe>10.</s12:Body>

Passiamo ad analizzare il codice. Prima di tutto, è necessario esplicitare l’evento che è oggetto della revoca della sottoscrizione (linea 4). L’identificativo dell’evento è espresso secondo la grammatica definita nella dialettica degli eventi. Nello spezzone precedente, l’evento è identificato da Event/Health. Quindi, è necessario specificare un identificativo alfanumerico unico (linea 7) per quella determinata sottoscrizione. Questo identificativo è stato assegnato dal broker e restituito nel precedente messaggio di conferma dell’avvenuta sottoscrizione.

27

A questo punto bisogna puntualizzare un aspetto importante riguardo alle tipologie di messaggi che il client può ricevere da parte del server. Esistono infatti messaggi reply e messaggi asincroni.I messaggi simmetrici sono tutte le risposte a particolari richieste, come per esempio una risposta ad una richiesta di sottoscrizione, mentre i messaggi asimmetrici sono le notifiche di evento (a cui si è sottoscritti) e i messaggi che avvertono delle modifiche dell’albero degli eventi.

simmetrici (risposte) asimmetrici (notifiche)ad una richiesta di sottoscrizione notifica di un eventoad una richiesta di revoca di una sottoscrizione modifica albero degli eventiad una richiesta di invio albero degli eventi sottoscrizioni scadutead una richiesta lista delle sottoscrizioni

Passiamo in rassegna i messaggi più importanti, partendo prima dalle risposte per poi analizzare le notifiche.Una sottoscrizione, come si può intuire, può ricevere una conferma o un diniego da parte del broker o da parte del publisher, a seconda della tipologia di sistema. Qualora il messaggio sia formattato correttamente, ed i termini della sottoscrizione vengano accettati, il broker o il publisher, restituiscono un messaggio di conferma, altrimenti restituiscono un messaggio di errore.Se il messaggio di richiesta è formattato correttamente ecco cosa otteniamo:

1. <s12:Body>2. <wsnt:SubscribeResponse>3. <wsnt:SubscriptionReference>4. <wsa:Address>5. SERV_URL6. </wsa:Address>7. <wsa:ReferenceProperties>8. <esns:SubscriptionId>9. 1102001432781717510. </esns:SubscriptionId>11. </wsa:ReferenceProperties>12. </wsnt:SubscriptionReference>13. </wsnt:SubscribeResponse>14.</s12:Body>

Nel caso che la sottoscrizione sia andata a buon fine, il messaggio restituito al consumer è un messaggio di SubscribeResponse, definito dagli standard di WS-BaseNotification. Un messaggio di SubscribeResponse contiene, tra i diversi campi, un identificativo alfanumerico unico (linea 9) per quella determinata sottoscrizione, assegnato dall’agente di sottoscrizione stesso. Nel caso che la sottoscrizione non sia stata completata per qualche motivo, l’agente di sottoscrizione restituisce al consumer un messaggio d’errore (fault) contenente una motivazione della generazione dell’errore.Ecco la struttura di un messaggio d’errore.

1. <s12:Body>2. <wsnt: <!-- The error occurred--> > 3. <Timestamp>4. <!-- An xsd:date timestamp -->5. <Timestamp>6. <Description>8. <!-- A string that describes the error occurred -->7. </Description> 8. </wsnt: <!-- The error occurred-->>

28

9. </s12:Body>

Nel messaggio viene riportata la data e l’ora dell’invio da parte del server (linea 4) , oltre a una breve descrizione dell’errore verificatosi (linea 8). Similmente ai Subscribe message, anche i Notify message possiedono una struttura predefinita.

1. <s12:Body>2. <wsnt:Notify> 3. <wsnt:NotificationMessage>4. <wsnt:Topic dialect="+Property.topicExpressionDialect+">5. <!-- The topic of the generated event-->6. </wsnt:Topic> 7. <wsnt:Message>8. <!-- The message to comunicate-->9. </wsnt:Message>10. </wsnt:NotificationMessage>11. </wsnt:Notify>12. </s12:Body>

Al loro interno, sono presenti innanzitutto uno o più NotificationMessage (da linea 3 a linea 10), ossia i messaggi di notifica veri e propri. Ciascuno di essi possiede due campi fondamentali: un identificativo (TopicExpression) che rappresenta l’evento per cui si è ricevuta la notifica (linea 5), ed un messaggio personalizzabile (Message) che contiene ciò che si vuole comunicare con la notifica (linea 8).

5.6 Architettura dell’applicazione

Una tipica applicazione in Symbian OS, come l’applicazione sviluppata per questo progetto, consiste di quattro principali componenti.

1. Application. Questo componente deriva da CAknApplication ed e istanziata dal framework. Una volta creato ha la responsabilita di inizializzare il resto del codice.

2. Il Document. Questo componenete deriva da CAknDocument. Crea l’interfaccia utente attraverso la funzione CreateAppUiL().

3. App UI. L’interfaccia utente dell’applicazione deriva da CAknAppUi. Questa classe fornisce utili funzioni, come la gestione degli eventi e l’accesso a molte chiamate di sistema.

4. View. Questo componnete rappresenta quello che l’utente vede sullo schermo.

Nello schema sottostante abbiamo una rappresentazione visuale delle relazioni che incorrono tra questi componenti.

29

Application AppUiDocument11

Model

View

1..n1..n

Figura 5.8: Anatomia di un'applicazione.

Nel caso specifico dell’applicazione Secure Home, App UI contiene una sola View. Nella Figura 5.8 è presente anche un componente Model, il quale non si riferisce ad una specifica classe Symbian OS o Serie 60, ma include i dati dell’applicazione e i suoi algoritmi. Numerose classi possiedono un riferimento al modello- questa è una dimostrazione visibile della sua importanza.Nel diagramma UML sottostante mostra 4 livelli di classi presenti nella progettazione di un’applicazione basata su Avkon. Avkon è il nome del UI-specific application framework utilizzato per l’applicazione Secure Home. Si riferisce quindi a una specifica UI: la Series 60.

Figura 5.9: Il framework classes di un'applicazione Symbian OS Control-Based UI.

CONE è l’acronimo di “CONtrol Environment”, è rappresenta un component di Symbian OS. Le classi in questo componente forniscono dei meccanismi per gestire user input e per creare la user interface.

30

Il secondo livello di classi rientra nel componente Symbian OS Uikon. Questa è una generica implementazione indipendente dal device, di classi di alto livello. Inoltre fornisce una libreria UI comune a tutte le piattaforme Symbian OS.Il terzo livello consiste delle classi Avkon che forniscono le funzionalità delle user interface Series 60. Questo livello rappresenta un’implementazione specifica per questa particolare UI.Il quarto livello, quello relativo dell’applicazione Home Security, dimostra come questa applicazione deriva dalle classi specifiche della Series 60.

Inizializzazione dell’applicazione

La Figura 5.10 mostra il ruolo del framework nella fase di inizializzazione dell’applicazione.Tutte le applicazioni Series 60 UI [21] implementano una funzione globale, E32Dll(), che è invocata dal framework quando l’applicazione è lanciata. Questa funzione viene riferita come il DLL entry point e deve essere presente in ogni applicazione.

Figura 5.10: Inizializzazione di un'applicazione.

31

Il secondo passo nell’inizializzazione dell’applicazione è l’invocazione, sempre da parte del framework, della funzione NewApplication(). Questo crea un’istanza della classe CSecureHApp (passo 3). L’invocazione della funzione AppDllUid(), da parte del framework, ritorna l’UID dell’applicazione. Attraverso questo processo di inizializzazione il framework ottiene dei puntatori alle classi Document e AppUi appena create. Con i passi 5/6 ottiene un puntatore alla classe astratta CApaDocument attraverso la chiamata CSecureHApp::CreateDocumentL(). Con i passi 7/8 riceve un puntatore alla classe base CEikAppUi invocando la funzione CSecureHDocument::CreateAppUiL().

5.7 Design e implementazione

In Symbian OS, la libreria socket utilizza l’architettura Symabin OS client/server, questo implica che tutte le richieste devono essere inoltrate al socket server, previa connessione ad esso. Molte richieste al socket server sono asincrone e richiedono una particolare architettura per supportarle. In Symbian OS questo è facilitato dal’uso di active objects. L’applicazione Home Security utilizza due classi Symbian OS della libreria socket.

RSocketServ - è utilizzata per creare una sessione con il socket server, così da fornire un canale di comunicazione con il socket server.

RSocket - è implementata come una sotto-sessione di RSocketServ e quindi richiede una previa sessione socket server. Ogni distinta connessione ad un socket remoto richiede una sotto-sessione RSocket.

Il diagramma delle classi sottostante mostra le relazioni tra le classi più importanti dell’applicazione e le classi di sistema RSocketServ e RSocket.

32

CHomeSAppView

MTimeoutNotifier MEngineNotifier

MUNotifier

CSocketsReader<< active >>

RSocket

CSocketsWriter<< active >>

RSocketServ

CHomeSEngine<< active >>

CHomeSEventParserCETreeCSubscription CNode0..n0..n

Figura 5.11: Relazioni tra le classi di sistema e le classi più importanti dell’applicazione.

Il cuore dell’applicazione è rappresentato dalle seguenti classi “attive” (cioè degli active objects):

CHomeSEngine – questa classe :o Crea la sessione con il socket server.o Crea e connette il socket che verrà utilizzato per la comunicazione con il server.o Gestisce i feedback dal socket reader (CSocketsReader) e writer

(CSocketsWriter).o Riporta i cambiamenti di stato alla UI per visualizzarli.

CSocketsReader – questa classe :o Emette delle richieste asincrone di lettura al socket server.o Riporta tutti i dati ricevuti o errori all’oggetto CHomeSEngine attraverso

l’interfaccia MEngineNotifier.

33

CSocketsWriter – questa classe :o Emette delle richieste asincrone di scrittura al socket server.o Riporta gli errori all’oggetto CHomeSEngine attraverso l’interfaccia

MEngineNotifier.

5.7.1 Costruzione

La classe CHomeSEngine fornisce il cuore dell’applicazione. Il suo compito è di creare un socket locale, stabilire una connessione con un socket remoto, creare l’oggetto CTree in verranno memorizzato l’albero degli eventi. Inoltre crea un’istanza degli active objects CSocketsReader CSocketWriter, che gestiscono rispettivamente la ricezione asincrona e la trasmissione di dati. La sequenza di costruzione è mostrata nel sequence diagram di Figura 5.12 (pagina seguente):

34

Figura 5.12: La sequenza di costruzione degli oggetti.

35

Messaggi Descrizione1 - 3 L'oggetto CHomeSAppUi invoca CHomeSEngine::NewL per creare l'oggetto

CHomeSEngine. Viene utilizzato il costruttore standard a due fasi di Symbian OS.4 Lo stato di CHomeSEngine viene inizializzato a ENotConnected.5 Viene creato un timer che verrà utilizzato per assicurare che le richieste non

completate in un determinato intervallo di tempo verranno cancellate.6 L’active object CHomeSEngine è aggiunto all’Active Scheduler7 Utilizzando RSocketServ::Connect si crea una connessione al SocketServer.

Questo stabilisce un canale IPC verso il socket server per essere utilizzato in seguito da RSocket.

8 - 10 La funzione CSocketsReader::NewL viene invocata per creare l’oggetto CSocketsReader. Viene utilizzato il costruttore standard a due fasi di Symbian OS. L’oggetto creato è un active object che verrà utilizzato per gestire letture asincrone dal socket server.

11 L’active object CSocketsReader è aggiunto all’Active Scheduler.12 - 14 La funzione CSocketsWriter::NewL viene invocata per creare l’oggetto

CSocketsWriter. Viene utilizzato il costruttore standard a due fasi di Symbian OS. L’oggetto creato è un active object che verrà utilizzato per gestire scritture asincrone verso il socket server.

15 L’active object CSocketsWriter è aggiunto all’Active Scheduler.16 Viene creato un timer che verrà utilizzato per assicurare che le operazioni di scrittura

asincrone non completate in un determinato intervallo di tempo verranno cancellate.17 La funzione CETree::NewL viene invocata per creare l’oggetto CETree. Viene

utilizzato il costruttore standard a due fasi di Symbian OS. Questo oggetto verrà utilizzato per memorizzare l’albero degli eventi che il server spedirà, come risposta ad una determinata richiesta, al client.

5.7.2 Connessione

CHomeSAppUi è la classe che rappresenta la user interface dell’applicazione Home Security. Utilizza un’istanza di CHomeSEngine per connettersi al server e spedire messaggi . L’oggetto CHomeSEngine utilizza le classi di Symbian OS, RSocketServ e RSocket per aprire un socket verso il server e spedire messaggi. Prima di poter aprire il socket, l’oggetto CHomeSEngine deve trovare il server, interrogando il suo database SDP per trovare i parametri relativi al Serial Port service. Per trovare il server, utilizza la classe RNotifier di Symbian OS. Questa classe gestisce una sessione con un server di notifiche che fornisce supporto per plug-in notifier, e nel caso specifico, il Device Selection Notifier plug-in. Per invocare il plug-in viene utilizzata la funzione asincrona RNotifier::StartNotifierAndGetResponse.CMessageClient utilizza un’istanza di CMessageServiceSearcher per interrogare il database SDP del device a cui si connette(nel nostro caso il server) ed estrarre il channel number(ovvero il numero di porta) da utilizzare per il servizio Serial Port. Il channel number è inserito all’interno del record memorizzato nel database SDP del device che offre il servizio(nel nostro caso il server che mette a disposizione il servizio Serial Port).

36

La classe CMessageServiceSearcher è derivata da una classe che offre un servizio di ricerca più generico, la classe CBTServiceSearcher, che si connette al database SDP del server. Questa classe utilizza la classe di Symbian OS CSdpAgent la quale emette richieste Bluetooth SDP verso il server. MSdpAgentNotifier gestisce le risposte delle Bluetooth SDP queries. I clients che lancia le queries attraverso CSdpAgent deve implementare questa interfaccia per gestire le risposte e implementare le funzioni callback AttributeRequestComplete( ),AttributeRequestResult( ) e NextRecordRequestComplete( ).

RSocket

RSocketServ

CHomeSAppUi

CMessageServiceSearcher

CHomeSEngine

MSdpAgentNotifier

CSdpAgent

MAttributeValueVisitor

CBTServiceSearcher

RNotifier

CSdpAttributeParser

MSdpAttributeNotifier

Figura 5.13: Diagramma UML delle classi del modulo Bluetooth.

37

5.7.3 Lettura dati da socket

Il Symbian OS Socket Client API implementa le operazioni di lettura come richieste asincrone. L’applicazione Home Security utilizza un active object, CSocketsReader, per eseguire lo scheduling di queste richieste. I dati vengono letti quando dall’altra parte del canale, cioè sul server, sono disponibili dei dati da trasmettere, poi, quando la lettura è terminata si esegue lo scheduling per un’altra lettura. La sequenza richiesta per la lettura dei dati è illustrata nel seguente diagramma:

Figura 5.14: Sequenza di operazioni richieste per la lettura da socket.

Messaggi Descrizione1 La funzione CSocketsReader::Start viene invocata per inizializzare lo

scheduling delle letture. 2 - 4 Viene invocata la funzione CSocketsReader::IssueRead, che spedisce una

richiesta di lettura al socket server attraverso la funzione RSocket::RecvOneOrMore. In seguito viene invocata la funzione (ereditata da CActive) SetActive per indicare all’active scheduler che esiste una richiesta in corso da parte di questo oggetto.

5 La funzione RSocket::RecvOneOrMore “ritorna” quando è disponibile almeno un byte nel buffer passato come parametro, questo “ritorno” provoca la chiamata a CSocketsReader::RunL().

6 Si inserisce il contenuto appena letto in un buffer, gestito attraverso un oggetto CString. Questa bufferizzazione è necessaria in quanto si possono ricevere messaggi incompleti.

7 Si procede ad un’altra lettura.

38

5.7.4 Scrittura dati su socket

Il Symbian OS Socket Client API implementa le operazioni di scrittura come richieste asincrone. L’applicazione Home Security utilizza un active object, CSocketsWriter, per eseguire lo scheduling di queste richieste. Nell’applicazione l’interfaccia utente intercetta l’evento generato dalla conferma di una richiesta di sottoscrizione, per esempio, e in risposta viene inserita in coda una richiesta di scrittura. CSocketsWriter utilizza un buffer (iTransferBuffer) per accettare dati dalla UI, mentre il contenuto di un altro buffer (iWriteBuffer) è spedito in modo asincrono, per evitare collisioni. Quando un’operazione di scrittura è terminata, viene invocata la funzione RunL() dal framework, si controlla in contenuto del transfer buffer, se vi sono dati vengono copiati nel write buffer e spediti. Le operazioni che non terminano in un certo tempo sono cancellate. La sequenza richiesta per scrivere dei dati sul socket è illustrata nel seguente diagramma:

Figura 5.15: Sequenza di operazioni richieste per la scrittura su socket.

Messaggi Descrizione1 Quando l’utente conferma una richiesta, per esempio di sottoscrizione, da inviare al

server, la richiesta viene inoltrata all’engine invocando la funzione CHomeSEngine::WriteL().

2 La richiesta è inoltrata alla classe CSocketsWriter attraverso la funzione CSocketsWriter::IssueWriteL.

3 I dati sono prima copiati nel transfer buffer e quindi viene invocata la funzione

39

CSocketsWriter::SendNextPacket.4 CSocketsWriter::SendNextPacket trasferisce i dati verso il write buffer,

libera il transfer buffer e chiede alla funzione RSocket::Write di spedire i dati.5 - 6 Lo stato dell’oggetto CSocketsWriter è impostato a ESending, quindi si avvia

un timer per gestire la situazione in RSocket::Write non “ritorna” in un tempo ragionevole. A questo punto viene invocata la funzione (ereditata da CActive) SetActive per indicare all’active scheduler che esiste una richiesta in corso da parte di questo oggetto.

7 La funzione RSocket::Write termina quando i dati sono stati spediti dal socket server e quindi viene invocata la funzione CSocketWriter::RunL().

8 - 9 Il timer viene “resettato” (poiché l’operazione asincrona è terminata in tempo) e si invoca CSocketsWriter::SendNextPacket per spedire gli altri dati accumulati mentre il precedente pacchetto era spedito. In questo scenario, nessun dato è presente e quindi lo stato di CSocketsWriter ritorna a EWaiting.

6 Esempio di esecuzione

Vediamo ora un esempio di utilizzo del prototipo. Il client software presenta un’interfaccia semplice, da cui è possibile effettuare delle sottoscrizioni, verificarne lo stato, leggere le notifiche ricevute, salvarle o eliminarle. Dopo aver lanciato l’applicazione dal menu principale, l’utente ha a disposizione solo due comandi all’interno del menu Opzioni. Un comando Connect, che avvia la procedura di inquiry e il comando Saved Messages che permette di scorrere tutti gli eventi salvati, se presenti, che l’utente ha ricevuto nelle precedenti sessioni. Con la procedura di inquiry i dispositivi Bluetooth possono trovare altri dispositivi Bluetooth nel range di copertura della loro antenna. In questa fase il device che ha iniziato la ricerca memorizza le informazioni ricevute come risposta che contengono le informazioni necessarie (indirizzo e clock) per una successiva connessione con le unità che hanno risposto, attraverso una procedura che prende il nome di paging. Nella screenshot (Fig. 6.1) viene riportato il risultato di una procedura di inquiry.

Figura 6.1: Risultato di una procedura di inquiry.

La schermata precedente riporta i devices che sono stati trovati. I nomi visualizzati sono quelli assegnati dai proprietari dei devices. Come possiamo vedere dalle icone è stato rilevato un computer Portable e uno smart-phone dal nome Bob’s phone.

40

Selezionando il device, nel nostro caso l’access point attraverso il quale si accede al server, e poi il pulsante Select si avvia la procedura di paging. Come accennato in precedenza questa procedura utilizza le informazioni recuperate durante la fase di inquiry per stabilire una connessioni Bluetooth con il device selezionato.Dopo aver stabilito la connessione, il menu Opzioni contiene un’altra entry, Requests Events. Attraverso questo comando è possibile richiedere l’albero degli eventi che il particolare server dispone. Dopo questa richiesta l’entry Available events è inserita nel menu. Attraverso questo comando è possibile scorrere l’albero degli eventi ed eseguire le operazioni si sottoscrizione e deregistrazione. Come abbiamo accennato in precedenza l’evento Event rappresenta la radice dell’albero, e come tale ogni sottoscrizione ad esso comporta la notifica di ogni evento che il broker può generare. Inoltre in fase di progettazione è stato deciso di rendere sempre disponibili gli eventi Event/Topics (questa formulazione indica che Topics è un sotto-evento di Event) e Event/MySubscribedEvent. Nella screenshot (Fig 6.2) viene riportata come esempio una porzione di albero.

Figura 6.2: Il sotto-albero di Event.

Questa porzione di menu indica che Topics, MySubscribedEvent e Health sono sotto-eventi di dell’evento Event. Il segno di spunta vicino all’evento Topics indica che l’utente si è sottoscritto a questo particolare evento. Utilizzando il pulsante Visit su un particolare nodo si può visitare il sotto-albero che ha per radice quel particolare evento. Naturalmente se si incontrano dei nodi foglia l’utente viene avvertito. Il pulsante Actions permette la sottoscrizione al particolare evento. Nel caso il client abbia eseguito in precedenza anche una sottoscrizione è possibile, sempre attraverso il pulsante Actions, di revocare la registrazione con l’invio di un messaggio Unsubscribe.Quando l’utente decide di sottoscriversi ad un evento, deve specificare la data e l’ora di scadenza della sottoscrizione. Nella screenshot (Fig. 6.3) viene riportata la form che l’utente deve compilare per impostare questi parametri.

41

Figura 6.3: Interfaccia di sottoscrizione.

Con il pulsante Ok si invia la richiesta di sottoscrizione con data e ora di scadenza impostati nella form. Ogni 5 minuti (un frame che può essere comunque reimpostato) il server degli eventi controlla tutte le sottoscrizioni che sono pervenute per controllare quali sono scadute e in tal caso spedisce ai vari clients un messaggio per avvertirli di questa situazione. Nella screenshot (Fig. 6.4) viene riportata questa situazione in cui il client riceve un messaggio per avvertirlo che una particolare sottoscrizione è scaduta.

Figura 6.4: Sottoscrizione scaduta.

Quando il server rileva un particolare evento, come per esempio l’evento di caduta, ricerca all’interno della sua struttura dati tutti i clients le cui sottoscrizioni a questo particolare evento sono ancora valide e spedisce un messaggio di notifica a tutti questi clients. Nella screenshot (Fig. 6.5) viene riportata questa situazione in cui il client riceve un messaggio di notifica.

Figura 6.5: notifica di un evento.

42

7 CONCLUSIONI

7.1 Evoluzione dei sistemi di Home Automation: dall’interfacciamento, all’interoperabilità, al “plug and play”

L’evoluzione del mercato della domotica [6] ha prodotto una concreta aspettativa rispetto a garanzie di libertà e flessibilità nella scelta dei sistemi e delle applicazioni. Il percorso iniziato nella metà degli anni ’80 appare ora chiaramente tracciato nella direzione della cosiddetta “Architettura aperta”.Effettivamente, seguendo quello che è stato il percorso che conduce ai nostri giorni, è possibile distinguere tre momenti storici successivi:

1) fase dell’interfacciamento;2) fase dell’interoperabilità;3) fase ”plug and play”.

Fase dell’interfacciamento – In questa prima fase le diverse aziende hanno realizzato i propri sistemi attraverso la produzione di corrispondenti trasduttori chiamati gateway. Questi trasduttori consentono la condivisione dei messaggi tra i dispositivi a essi collegati.

Fase dell’interoperabilità – L’industria della Home Automation si trova oggi tra la fase dell’interoperabilità, che implica la capacità degli apparati realizzati da differenti produttori di scambiarsi informazioni, e quella susseguente del “plug and play”. In particolare tecnologie come Jini e UPnP rappresentano gia delle realta che dimostrano l’esistenza della fase “plug and play”.

Fase “plug and play” – acronimo PnP, consiste nella capacità di aggiungere nuovi devices senza il bisogno di riconfigurare il sistema. In particolare, significa un alto livello di standardizzazione di reti e protocolli di comunicazione che permette ai dispositivi non solo un’interazione con gli altri apparecchi compresenti, ma, ciò che più conta, una “autoconfigurazione” al momento della loro connessione a un sistema.

7.2 Conclusioni

L’adozione delle tecnologie domotiche apporta un miglioramento immediato della qualità della vita. Tale miglioramento per l’anziano si esplica consentendogli ancora una certa autonomia, grazie agli azionamenti automatici, e una certa sicurezza psicologica in quanto percepisce di vivere in un alloggio “protetto”. Il personale di assistenza, invece, grazie al sistema di monitoraggio, è in grado di intervenire efficacemente e tempestivamente.Il progetto nel quale rientra il lavoro svolto per questa tesi si propone di sviluppare un sistema di telesoccorso per assistenza ad anziani. Questo servizio, comunque, rappresenta una prima fase dello sviluppo in quanto il sistema è in grado di fornire una serie di servizi non necessariamente rivolti solo all’assistenza ad anziani e disabili. In particolare l’applicazione sviluppata in questa tesi implementa un client su sistema operativo Symbian OS, il quale interagisce con il server degli eventi per usufruire dei servizi resi disponibili sotto forma di web service. La scelta di utilizzare come piattaforma Symbian OS ha permesso di risolvere alcuni problemi di architettura incontrati nello sviluppo di questo client su device con JVM, oltre a permette anche agli smart-phone di partecipare come nuovi attori nel sistema. Il client utilizza l’architettura SOA introdotta in [17] per usufruire dei vantaggi di un architettura aperta, in particolare implementa lo stack di protocolli proposto per ambienti domotici. Questo

43

stack utilizza ad alto livello WS-Notification per la coordinazione dei processi tramite il sistema di pubblicazione e sottoscrizione offerto da questo recente standard.La comunicazione tra client e server avviene utilizzando lo standard Bluetooth ed in particolare adottando il protocollo RFCOMM che simula una comunicazione seriale.

7.3 Sviluppi futuri

Alcune estensioni al servizio di telesoccorso riguardano la possibilità di specificare delle condizioni sotto cui la sottoscrizione debba essere accettata e altre condizioni sotto cui le notifiche debbano essere ricevute o meno, ossia implementare le funzionalità di precondition e selector.Inoltre, bisognerà affrontare temi di qualità del servizio (QoS), in altre parole permettere che la comunicazione tra client e server abbia determinate garanzie non funzionali, come sicurezza, tempo di risposta, disponibilità, etc.Infine, l’implementazione del mio client potrà essere migliorata dal punto di vista della sicurezza e gestione dei failure. L’applicazione infatti, non gestisce al meglio la perdita di messaggi e non implementa un sistema di sicurezza per garantire la confidenzialità e l’integrità della messaggistica.

Possibili sviluppi del progetto sono orientati all’eliminazione del server degli eventi. Essendo punto centrale dell’architettura risulta essere critico. Il crash di tale server infatti porta al fallimento dell’architettura domotica; i messaggi che partono dai sensori per avvisare di una possibile situazione critica vengono perduti e le notifiche di eventi non vengono generate per i Client. L’idea è quella di trasformare l’architettura da Client-Server a Peer-To-Peer. Ogni dispositivo dovrà quindi integrare una parte Server, dove verranno registrati ed elaborati i vari eventi provenienti dai sensori, e una parte Client che notifica gli eventi. Mentre la parte client può rimanere sostanzialmente invariata, i compiti della parte Server saranno:

ricevere le registrazioni dei sensori e “pubblicare” il relativo servizio; ricevere le notifiche di eventi dai sensori e generare le relative notifiche; ricevere le registrazioni dei dispositivi vicini ai propri servizi; inoltrare ai dispositivi vicini che sono registrati all’evento le notifiche che gli interessano;

Attraverso l’utilizzo di un’architettura service-oriented è possibile offrire servizi che usufruiscono a pieno delle potenzialita dei device mobili, permettendo a quest’ultimi di diventare sia fruitori di servizi che provider. Lo sviluppo di una libreria da integrare all'interno di un qualsiasi telefono Symbian, che permetta lo sfruttamento efficace e produttivo delle tecnologie Web services senza dover per forza conoscere in dettaglio la struttura ed il funzionamento degli stessi è una linea tecnologica da perseguire.La libreria dovrebbe permette di accedere alle funzionalità di un qualsiasi web service senza che lo sviluppatore si debba far carico del parsing dei file WSDL e della costruzione dei messaggi SOAP. La libreria si occupa infatti di parsare il file WSDL e passare all'applicazione l'alberorappresentante la struttura dati del web service; una volta che i campi della struttura sono stati riempiti dall'applicazione la libreria genera il messaggio SOAP corretto pronto per essere spedito.Naturalmente è possibile utilizzare la libreria per generare direttamente messaggi SOAP da spedire, ma in quel caso sarà necessario definire i namespaces ed eventuali restrizioni da applicare ai campi.

44

APPENDICE A – I Tools utilizzati per lo sviluppoL’applicazione è stata implementata utilizzando come ambiente di svilluppo CodeWarrior™ Development Studio for Symbian OS (disponibile dal sito www.forum.nokia.com). Questo ambiente fornisce strumenti utili sia per la fase di stesura del codice che per la fase di testing attraverso un emulatore. In particolare per testare il software che utilizza i socket per la comunicazione TCP/IP e stato necessario installare un plug-in (PrnESock, disponibile all’indirizzo www.peroon.co.il) per Symbian OS SDKs, che consente all’emulatore di utilizzare le proprietà di networking del PC eseguendo un mapping delle Symbian networking API (RSocket, RHostResolver) su Windows networking API (winsock plug-in).Per testare il codice che utilizza la comunicazione Bluetooth si è utilizzato uno smart-phone che supportasse questo standard e predisposto all’interfaccia Series 60. La scelta e ricaduta sul modello Nokia 6600 che soddisfa questi requisiti ed inoltre ha un costo contenuto (circa 200 €).

Figura A.1: Nokia 6600.

Sistema operativo: Symbian OS v7.0s, Java MIDP 2.0 User Interface: Series 60 Platform 2nd Edition Connettività :Bluetooth® technology, Infrared e SyncML Display: 176 x 208 pixels a 65K colori Memoria: 6MB + 32MB MMC

Per testare l’applicazione si è installando un Bluetooth USB adapter su un PC, sul quale è attivo il server, per permettere la comunicazione Bluetooth tra il Nokia 6600 e il PC. Inoltre dato che il server è stato sviluppato per comunicare con i clients che utilizzano il protocollo TCP/IP, mentre la comunicazione Bluetooth utilizza un servizio che simula una comunicazione seriale, è stato necessario utilizzare un altro componente, l’applicazione TCP-Com (disponibile all’indirizzo www.taltech.com). Questa applicazione si interfaccia tra il Nokia 6600 e il server per eseguire il mapping tra una particolare porta seriale RS232 e un particolare porta TCP/IP. Purtroppo quest’applicazione viene fornita per un periodo di prova di 30 giorni, quindi è stata implementata una applicazione Java che svolgesse questo mapping, dal nome com2TCP. Riportiamo uno schema dell’operazione di mapping.

45

L’interfaccia utente dell’applicazione com2TCP.

Figura A.3: com2TCP.

APPENDICE B - SYMBIAN CODE NAMING CONVENTIONSQui possiamo trovare alcune OS naming conventions utili per comprendere il codice scritto per Symbian OS. (Symbian 2002).Nomi delle classiMolte classi sono formattate con una lettera maiuscola come prefisso. L’eccezioni sono le classi che consistono solo di funzioni statiche – le quali non hanno una lettera come prefisso. Oltre al prefisso, il nome della classe generalmente indica lo scopo della classe.I nomi delle classi allocate sulla heap che derivano dalla classe base CBase iniziano con la lettera ‘C’. Con il prefisso ‘T’ si indica una classe che non contiene alcun oggetto esterno, cioè non vengono utilizzati puntatori, riferimenti, o handles ai dati contenuti.I nomi delle resource classes contenenti handles a risorse gestite esternamente, iniziano con la lettera ‘R’.Le interface classes che definiscono classi astratte implementate da altre classi, hanno come prefisso la lettera ‘M’.Nomi delle variabiliLe variabili private alla classe inizino con la lettera ‘i’, per esempio, iMember. Gli argomenti di una funzione, inizino con la lettera ‘a‘, per esempio, aIndex. I nomi delle variabili locali non hanno un prefisso.Nomi delle funzioniI nomi delle funzioni indicano che cosa eseguono, generalmente sono dei verbi. Un ‘eccezione è rappresentata dalle funzioni che ritornano il valore delle variabili private della classe. Il nome di questa funzione è il nome della variabile senza il prefisso ‘i’.Le funzioni che possono leave – implicitamente o esplicitamente- devono terminare con ‘L’. Il nome di una funzione di allocazione o di costruzione che inserisce dati sul cleanup stack senza provvedere alla relativa funzione di popping deve terminare con ‘LC’.Una funzione che possiede i suoi oggetti e provvede alla sua distruzione, termina con la lettera ‘D’.Nomi delle macroI nomi delle macro sono tutti in maiusolo con underscores che separano le parole.Nomi delle enumerazioniDato che le enumerazioni sono dei tipi, hanno il prefisso ‘T’. I nomi dei membri delle enumerazioni hanno il prefisso ‘E’.Nomi di costantiI nomi delle costanti hanno il prefisso ‘K’.

46

Bibliografia

[1] A. Lori, A. Golini, and B. Cantalini. Atlante dell'invecchiamento della popolazione. Rome: Consiglio Nazionale per le Ricerche.1995, disponibile all’indirizzohttp://www.aging.cnr.it/atlante.htm

[2] A. Bianchetti, C. Geroldi, and M. Trabucchi. La malattia di Alzheimer in Italia: qualità ecosti dell’assistenza. Science Adv, 1995.

[3] B. Jönsson, L. Jönsson, and A. Wimo. I costi della demenza: una review. In Demenza, pages365–393. CIC Edizioni Internazionali, 2004.

[4] J. Abascal and A. Civit, Mobile Communication for Older People: New Opportunities for Autonomous Life, EC/NSF Workshop on Universal Accessibility of Ubiquitous Computing: Providing for the Elderly, Alcácer do Sal, Portugal (2001), disponibile all’indirizzo http://virtual.inesc.pt/wuauc01/procs/pdfs/abascal_final.pdf

[5] M. Berggren. Wireless communication in telemedicine using Bluetooth and IEEE 802.11b.Uppsala Master’s Thesis in Computing Science, 2001. disponibile all’indirizzohttp://www.it.uu.se/research/reports/2001-028/2001-028.pdf

[6] Bellintani S. Manuale della domotica. (2004) Il Sole 24 Ore.

[7] Zolet A. Integrazione di device mobili in un ambiente domotizzato basandosi su web service. Università di Trento, (2005) disponibile all’indirizzo http://dit.unitn.it/˜aiellom/tesi/zolet.doc

[8] Leoni P. A web service based domotic architecture. Università di Trento, (2004) disponibile all’indirizzo http://dit.unitn.it/˜aiellom/tesi /leoni.doc

[9] Zanoni M. Invocazione di Web Services da devices mobili. Università di Trento, (2003) disponibile all’indirizzo http://dit.unitn.it/˜aiellom/tesi/zanoni.doc

[10] George Coulouris, Jean Dollimore, Tim Kindberg. Distributed Systems: Concepts and Design. 2002 Addison-Wesley

[11] Ethan Cerami. Web Services Essentials. (2004) O’Reilly.

[12] Jo Stichbury. Symbian OS Explained. (2005) Wiley

[13] Michael J.Jipping. Symbian OS communication programming. (2005) Wiley

47

[14] Richard Harrison. Symbian OS C++ for mobile phones. (2005) Wiley

[15] Symbian OS: Designing Bluetooth Applications In C++. (2004) disponibile all’indirizzo http://www.forum.nokia .com

[16] Publish-Subscribe Notification for Web services. (2004) disponibile all’indirizzo http://www-106.ibm.com/developerworks/library/specification/ws-notification

[17] M. Aiello, M. Marchese, P. Busetta, and G. Calabrese, Opening the Home: a Web Service Approach to Domotics. (2005), volume I:271-279, In N. Guimaraes and P. Isaias (eds). Applied Computing 2005 IADIS. disponibile all’indirizzohttp://eprints.biblio.unitn.it/archive/00000716/

[18] M. Aiello, M. Zanoni, and A. Zolet, Exploring Web-Service Notification: Building a scalable domotic infrastructure. (2005), 371:48-51, DrDobbs Journal: Software Tools for the Professional Developer CMP. disponibile all’indirizzohttp://www.ddj.com/documents/s=9603/ddj0504g/0504g.html

[19] Curbera F., Khalaf R., Mukhi N., Tai S., and Weerawarana S. (2003). The next step in web services. ACM, 46(10): 29-34, (2003).

[20] M.P. Papazoglou, D. Georgakopoulos (2003). Service-Oriented Computing. ACM, 46(10): 25-28, 2003.

[21] L. Edwards, R.Barker. Developing Series 60 Applications: A Guide for Symbian OS C++ Developers. (2004) . pag.172-201, Addison Wesley Professional.

[22] Symbian OS: From ANSI C/C++ To Symbian C++. (2004) disponibile all’indirizzo http://www.forum.nokia .com

[23] Oraskari J. Bluetooth versus WLAN IEEE 802.11x. disponibile all’indirizzo http://users.tkk.fi/~joraskur/BT2.pdf

48