Principi di Design per Mobile Middleware e …lia.deis.unibo.it/Courses/sm1112-info/lucidi/05-MM...Principi Mobile Middleware - Sistemi Mobili M 1 Sistemi Mobili M Università di Bologna

Principi Mobile Middleware - Sistemi Mobili M 11

Sistemi Mobili MSistemi Mobili M

Università di BolognaCdS Laurea Magistrale in Ingegneria Informatica

II Ciclo - A.A. 2011/2012Corso di Sistemi Mobili M (6 cfu)

05 – Principi di Design per Mobile Middleware e Applicazioni Mobili

Docente: Paolo [email protected]

http://lia.deis.unibo.it/Courses/sm1112-info/

http://lia.deis.unibo.it/Staff/PaoloBellavista/

Principi Mobile Middleware - Sistemi Mobili M

Evoluzione dei Sistemi e dei Servizi Mobili

1st generation (1990-1999)Messaggi di testo (SMS) e forme limitate di accesso mobile a dati; banda massima attorno a decine di Kbps

2nd generation (1999-2003)Browser Web limitati, WAP, iMode e MMS; banda massima finoa 144Kbps

3rd generation (2003-2008)Piattaforme mobili, cosiddetti servizi di middleware; terminali conSymbian Series 60, J2ME, Android, iOS, ...; banda massima finoa diversi Mbps

4th generation (2008-...)Servizi adattativi, interfacce utente adattative, protocolliadattativi; context awareness, connettività continua; bandamassima fino a centinaia di Mbps

2


revenue

timeMonophonic Polyphonic

Master tonesMusic clips

Music downloads

Full music andvideo streaming

Full music streaming

On-demand and streaming videoAdvanced browsers

SMS ringtones,

logos

Stores and Web pages

WAPRingtones

Social sites, media portals

Java portals

Evoluzione dei Sistemi e dei Servizi Mobili

3


Mobile Middleware

Gestione di tanti aspetti, non strettamente application-specific, in particolare della mobilità, è un problema complesso. Ad esempio, mobilità di:

RetiNodiConnessioni di trasportoSessioneOggetti (passivi, attivi)ServiziUtenti

Molte soluzioni necessarie, a livelli multipli (link, rete, trasporto, applicazione) e cross-layerSoluzioni di mobile middleware per indicare tutte le soluzioni di supporto tipicam. collocate dal livello 4 OSI in su

4


Middleware

Termine “popolare” e largamente usato, talora anche in maniera parzialmente imprecisa e un po’ fuzzyUna possibile definizione:

“A set of service elements above the operating system and the communications stack”

Una definizione alternativa“Software that provides a programming model above the basic building blocks of processes and message passing”(Colouris, Dollimore, Kindberg, 2001)

Noi useremo definizione di stack software di supporto, tipicamente cross-layer e application-agnostic, che si occupa di problematiche per livelli OSI >= 4

5


Perché Necessità di Middleware?

Sviluppo di applicazioni distribuite come processo complesso e time-consuming

Ogni sviluppatore si deve occupare di fare coding from scratch dei suoi protocolli per servizi di nomi, transazioni, ...?Come gestire inevitabile eterogeneitàdegli ambienti di esecuzione?

Necessità di middlewarePer riduzione tempo di sviluppo e rapid prototypingPer semplificare sviluppo di applicazioni e ridurne i costiPer supportare ambienti eterogenei, mascherando in parte differenze a livello di linguaggio/OS/hardware

divergence

convergence

diverse physical layers

diverse applications

transport layer (TCP/IP)

hourglass model

6


Chi Beneficia di Mobile Middleware?

Utenti finaliAnche se l’obiettivo del middleware non è di interagire direttamente con utenti finali, supporto ad applicazioni e servizi visibili agli utenti. Quindi middleware con API e meccanismi adeguati per gestire differenti tipologie di guasti ed errori runtime, oltre che per supportare enhanced usage experienceProduttori di dispositiviMiddleware per fornire funzionalità avanzate ed estese che poi si interfaccino a basso livello con driver di dispositivoInternet Service ProviderMiddleware per monitoraggio e amministrazione di reteFornitori di piattaforme middlewareSviluppo di piattaforme middleware che si integrano con differenti sistemi operativiApplication Service ProviderMiddleware per facilitare sviluppo e deployment di applicazioni in modo veloce, scalabile e a basso costo

7


Obiettivi ed Elementi Chiave

Accessibilità e ReachabilityRisorse devono essere comunque disponibili e accessibili per utenti finali in modo non legato alla locazione corrente (di utenti e risorse). Supportate oggi in modo completo? Vogliamo veramente trasparenza completa?AdattativitàServizi mobili e loro utilizzo avvengono in ambiente soggetto a cambiamenti runtime; devono adattarsi dinamicamente all’ambiente operativoAppropriato livello di fiducia (trust)Deve essere gestito un appropriato livello di trust fra le entitàinteragenti in modo tale che operazioni siano svolte in accordo ad aspettative. Contratti? Come ottenere trust decentralizzato?UniversalitàPossibilità di accesso universale a dati come per Web su rete Internet tradizionale

8


Mobile Middleware

Middleware tradizionalmente progettato e implementato per host di rete fissa

Larga banda, bassa latenza, comunicazioni affidabiliStorage persistente, buone capacità computazionali, nessun problema consumo energeticoNo mobilità

Ambienti mobili richiedono soluzioni middleware nuoveMiddleware esistenti non adatti a dispositivi limitati e non sempre scalabili

Obiettivi di mobile middleware:fault-tolerance, adattatività, supporto eterogeneità, scalabilità, condivisione risorse

9


Mobile Middleware

Mobile middlewareContesto cambia dinamicamenteNecessità di disaccoppiamento in spazio e tempo

Eventi asincroni, spazi di condivisione datiSoluzione base in molti casi di wireless computing

Utilizzo di proxy Inoltre, fornitura di un qualche livello di visibilità delle condizioni ai livelli sottostanti (si parla talora di reflective middleware)

Trasparenza alla locazione in RPC/RMIIn ambienti mobili, parziale visibilità di cambio di locazione, modifiche in livelli QoS disponibile, ...

10


Principi e Pattern

Principio come forte convinzione in un certo stato o proprietà di un soggetto

Principi supportano formazione di regole o norme tramiteosservazione del soggetto a cui si applicanoPrincipi hanno caratteristica di minimalità; non possonoulteriormente essere decomposti

Pattern come schemi di soluzione che hanno dimostrato difunzionare e lavorare bene in diverse situazioni con caratteristiche comuni

Classificati in gruppi differenti sulla base del loro livello diastrazione

Architectural pattern per progetto architettura di soluzioneDesign pattern per strategie di progetto language-independent, tipicamente object-orientedIdiomi per aspetti di buone soluzioni (best practice) a livello diutilizzo linguaggio di programmazione

11


Pattern

Info importanti per definizione di pattern:Nome pattern: nome “informative” che faccia da identificatore unico per il patternIntent: obiettivo del pattern e ragioni per il suo utilizzoMotivation: presentazione sintetica del problema a cui pattern si applica, utilizzando uno scenario di esempioApplicabilità: ambiente operativo e contesto in cui pattern può essere applicato efficacementeStruttura: struttura del pattern, rappresentata secondo diverse modalità e convenzioni graficheCollaborazione: come i vari elementi che costituiscono il pattern (tipicamente classi e oggetti) interagiscono fra loroConseguenze: risultati attesi dall’utilizzo del patternImplementazione: descrizione di una possibile implentazione pratica del pattern propostoCasi di utilizzo noti e altri pattern correlati: esempi pratici di come pattern sia stato applicato in sistemi reali

12


Definizioni di Architettura e Piattaforma

Una architettura è guidata da principi e fondata su scelte di design derivanti da pattern architetturali; ècostituita da componenti, e dalle regole/vincoli che governano relazioni fra componentiPiattaforma come realizzazione concreta di una architettura middleware

Un protocol stack è una realizzazione concreta di un insieme di protocolli e di un’architettura per il loro utilizzo (tipicamente strutturata a livelli, come nello stack OSI)

13


Principi Internet

Principio End-to-EndNella sua espressione originale, riferita all’opportunità di mantenere stato e intelligenza solo sui bordi (edge) della reteInternet connette tali bordi senza mantenere stato, per avere massima efficienza e semplicitàOggi nel mondo reale: firewall, NAT, cache per contenuto Web. Modifiche rilevanti a questo principio generaleVerso Trust-to-Trust principle (logica applicativa eseguita sempre su nodi fidati)?

Principio di Robustezza“Be conservative in what you do, be liberal in what you accept from others” (attribuito a Jon Postel, RFC 793 Transmission Control Protocol)Sviluppatori di stack Internet dovrebbero attenersi scrupolosamente a quanto specificato in RFC esistenti nella realizzazione loro funzionalità, ma essere pronti a processare in modo lasco e ad accettare input non conforme proveniente da altri (non consistente con RFC esistenti)

14


Principi Web

Principi alla base del Web seguono le linee guida di quelli alla base dellostack TCP/IP sottostanteSemplicità, modularità, decentralizzazione e robustezza

In particolare, relativamente ad accesso, rappresentazione dati e lorotrasformazione per risorse Web: Principio dell’applicazione di least powerful language per realizzazione di ogni funzionalità (massima accessibilità e meccanismo URL)

Problema essenziale e riconosciuto del mantenimento dellostato per interazioni stateful. Ad es. Representational State Transfer (REST- ne parleremo più avanti), basato su URI, HTTP, XML

Client-server, stateless, cacheable, a livelliCondivisione interfaccia uniforme per trasferimento di stato fracliente e risorsa (insieme limitato di operazioni ben definite, eventualmente con code on demand)

15


Principi SOA

Service Oriented Architecture (SOA) come architettura software dove funzionalità sono strutturate attorno aprocessi di business e realizzate tramite servizi interoperabili loosely-coupled. Fortemente basato su comunicazioni message-oriented Riutilizzo, granularità, modularità, possibilità di composizione dinamica, organizzazione a componenti, interoperabilitàConformità a standardIdentificazione e categorizzazione di servizi, provisioning e delivery, monitoraggio e tracking

16


Principi di Sicurezza(e non solo)

– Privacy - Integrità– Autenticazione - Autorizzazione– Accountability - Disponibilità

Principio di Inversion of ControlPrincipio di least privilege: solo info e risorse strettamente necessarie per fini legittimi di quell’entità a quel livello

Il gruppo di lavoro W3C Platform for Privacy Protections (P3P) ha stabilito i seguenti principi guida ai fini di privacy:

Notice & Communication. Service provider devono fornire notizie fresche ed efficaci su politiche e pratiche di mantenimento dati; user agent devono offrire strumenti efficaci per accedere a queste notizie e permettere a utenti finali di prendere decisioni informateChoice & Control. Utenti devono avere possibilità di scegliere su raccolta, utilizzo ed eventuale disclosure di loro info personaliFairness & Integrity. Utenti devono mantenere controllo sulle loro informazioni personali e la loro integritàConfidentiality. Info personali devono sempre essere protette con misure di sicurezza ragionevoli che considerino sensibilità delle info e livello di privacy richiesto (livelli differenziati)

17


Principi Specifici per Mobile: Prospettiva Dispositivo (vedi NoTA)

Esempio di Network on Terminal Architecture (NoTA): architetturaproposta da Nokia per strutturazione interna dispositivi mobili; validitàgenerale dei principi sotto

System-level loose coupling. Accoppiamento debole/lasco portato finoall’estremo dei componenti hw che costituiscono il dispositivoInterconnect-centric. Componente centrale responsabile per interconnessione di altri componenti e servizi (bus comune), basato sumeccanismi message passingBasato su servizi, funzionalità realizzate tramite servizi con interfacce bendefinite. Insieme a loose-coupling, porta ad adattabilitàMessage & data driven. Message passing come meccanismo privilegiatoper realizzazione applicazioni. Comunicazioni data-driven nel senso diforwarding richieste basato anche su condizioni correnti del sistema e dati contenuti nelle richieste. Verso disaccoppiamentoImplementation-wise heterogeneous. Integrazione di sotto-sistemi dadiversi produttori e vendor; una volta note specifiche di interfaccia e formati dirichiesta, componenti sono intercambiabili

18


Esempio di NoTAEsempio di NoTA

19

Basato su servizi anche per l’integrazione all’interno di un singolo device

Possibilità di composizione di sottosistemi


Session Initiation Protocol (SIP), alla base di reticonvergenti Next Generation Network (NGN). Ne avete giàparlato in altri corsi, vero ☺?

Utilizzo massiccio di proxy, ad es. per routingStato delle chiamate mantenuto presso endpoint“Endpoint fate sharing”, ovvero fallimento delleapplicazioni quando i loro endpoint hanno guastoUtilizzo di modello a dialog, e non di modello a chiamataArchitettura basata su componenti logici (ricoprono ruolilogici, non necessariamente associati a componenti fisici)

Generality over efficiencySeparazione chiara fra piano di segnalazione e piano di distribuzione media

20

Principi Specifici per Mobile: Prospettiva Mantenimento Sessione (SIP)


Esempio di SIPEsempio di SIP

21

Protocollo, con messaggi tipicamente verbosi , basato su proxyper mantenimento di stato di sessione

Modello a dialog, non a chiamata

Alla base, insieme a Diameter, di architettura IP Multimedia Sub-system (IMS)


Principi Specifici per Mobile:Cross-Layering

Varie tipologie di interazione per differenti forme di cross-layering in uno stack protocollareFlusso info upward, con info propagata da layer più bassi a layerpiù alti, contrariamente a principi di architetture a livelli tradizionaliFlusso info downward, con info propagata dai layer alti verso quelli bassi, tipicamente per fare configurazione di parametri a livellopiù bassoFlusso info back-and-forth, con info propagata nei due versiMerging di layer adiacenti, consente combinazione di differentilayer adiacenti in un unico super-layerAccoppiamento senza aggiunta di nuove interfacce. Due o piùlayer sono accoppiati a design time in modo definitivo, senzapossibilità di mantenere indipendenza/astrazione da livellosottostanteCalibrazione verticale fra layer. Per consentire la configurazionecongiunta di parametri fra layer (joint tuning) e ottenere miglioriperformance complessive

22


Layer X

Designed for X

Upward information flow

Downward information flow

Back and forth flow

Merging of adjacent layers

Design coupling Vertical coupling

23

Principio di Cross-Layering


Pattern Architetturali

Diversi pattern architetturali di utilizzo e applicabilità generali, non solo nel distribuito:A livelli. Architettura software multi-livello con responsabilitàdifferenti allocate “rigidamente” a differenti livelli, strutturatiCliente-Servitore. Pattern più frequente nel distribuito: clienti sfruttano risorse e servizi messi a disposizione dal servitorePeer-to-peer. Ogni nodo può giocare dinamicamente il ruolo sia di cliente che di servitore; funzionalità più o meno simmetrichePipeline (o pipe&filter). Pipeline come catena di elementi di processamento allineati in modo tale che output di ciascuno sia input per il successivoMultitier. Architettura cliente-servitore in cui applicazione eseguita da una molteplicità di software agent distintiBlackboard. Una base di conoscenza comune (blackboard) èaggiornata iterativamente da sorgenti differenti di conoscenza, partendo da specifica di problema per giungere alla sua soluzionePublish/Subscribe. 1) Canale per gli eventi e 2) Notifier (astrazione da locazione/distribuzione di broker)

24


Pattern Architetturali per Mobile Computing

Non solo utilizzabili in applicazioni mobili, ma particolarmente utili in questi scenari:

Model-View-Control (MVC) sia come pattern architetturale che di design, vedi applicazioni Web

Broker, per introdurre disaccoppiamento fra clienti e servitori

Microkernel. Funzionalità centrali e ridotte di un sistema (microkernel), separate da funzionalità complete e più estese, che possono essere plugged-in mediante specifiche interfacce

Active Object. Semplifica supporto a processamento asincrono mediante incapsulamento di richiesta servizio e risposta al completamento del servizio

25


Model-View-Control

26

Applicazione divisa in tre parti, con responsabilitàseparate e modalitàdi interazione ben specificateInvocazione di metodi ed eventi

Ad esempio utilizzato in Symbian OS


Broker

Componente broker che realizza disaccoppiamento fra clienti e servitoriServer si registrano presso broker, mettendo a disposizione i loro servizi per i clienti attraverso interfacce fornite al brokerClienti accedono le funzionalità dei server inviando richieste di servizio al brokerCompiti del broker includono:

determinare/localizzare server appropriatofare forwarding richieste verso servertrasmettere risultati ed eccezioni indietro al cliente

Esempio classico: CORBA Object Request Broker

27


MicroKernel

Pattern tipicamente applicato in scenari con sistemi software complessi che svolgono ruolo di piattaforma per altre applicazioniCaratteristiche desiderate sono estensibilità, adattabilità e interoperabilitàIdea cruciale di piccolo core estensibile tramite componenti che possano essere plugged-in dinamicamente

Internal ServerMicrokernelExternal Server

Adapter Client

Calls Microkernel Microkernel calls

Calls

Calls

28


Active Object

Supporto per processamento asincronoPattern lavora tramite incapsulamento e gestione di richieste asincrone di servizio e di risposte al completamento del servizioCliente notificato al completamento operazione e in grado di svolgere altre operazioni, anche con stesso server, in modo asincronoActive Object esegue nello stesso thread dell’applicazione, per ridurre overhead di context switching fra threadActive Object deve gestire eventi in modo non-preemptive (un evento processato per volta; processamenti rapidi)

CActiveScheduler ActiveObject

CActive

AsynchronousServiceProvider

Status flags

StatusDecide resumed

object

29


Pattern for Mobile Computing

Tre categorie di pattern per middleware e applicazioni mobili:

per distribuzione (come risorse sono distribuite ed accedute nell’ambiente di esecuzione)

remote facade, data transfer object, remote proxy, observer

per gestione risorse e sincronizzazionesession token, caching, eager acquisition, lazy acquisition, synchronization, rendezvous, state transfer

per comunicazioneconnection factory, client-initiated connection

30


Distribuzione: Remote Facade

Interfaccia coarse-grained verso singolo o pluralità di oggetti fine-grainedInterfaccia fornita tramite remote gateway

Accetta richieste incoming che siano conformi all’interfaccia della facadeSusseguenti interazioni fine-grained fra remote facade (gateway) e interfacce oggetti

Applicazione che usa pattern non ha necessità di conoscere quali particolari server o funzioni remote sono usati per implementare operazioni richieste

RemoteFacade

MapWeb

Services

Addresses

Coordinates

Coordinates

Routes

Route Segment

Direction

Route Segment

Highlighted map

Fast fixed-networkLast hopwireless network

Addresses

Directionsand maps

MobileDevice

31


Distribuzione: Data Transfer Object (DTO)

Pattern Data Transfer Object (DTO) per fornire un contenitore serializzabile per trasferimento di elementi multipli di dati fra processi distribuitiObiettivo principale del pattern è riduzione del numero di chiamate a metodo remotoSingolo DTO che contiene tutti i dati che devono essere trasferiti perché di interesse complessivo per una applicazione

Usualmente implementato come semplice oggetto serializzabile che contiene un insieme di campi con corrispondenti metodi ”getter & setter”

32


Distribuzione: Remote Proxy

Proxy (o gateway) interposto fra terminale e reteBy the way ☺, chiara vero la differenza fra proxy e gateway?

Tutti messaggi/pacchetti (o un loro sottinsieme selezionato) passano attraverso proxy, che può valutarli (anche contenuto) e svolgere operazioni su di loroProxy anche per svolgere operazioni computazionalm. pesanti al posto del terminale clienteProxy fa da adapter, anche consentendo l’interazione lato server senza bisogno di implementare protocolli/soluzioni terminal-specificTipicamente necessità di discovery per determinare proxy

Client

WebBrowser

Server

HTTPServer

CGI,..

Gateway

EncodersDecoders

encodedrequest

encodedresponse

request

responseProtocol

Gateways

wireless

33


Distribuzione: Observer

Supporta definizione di dipendenza one-to-many fra oggettiTutti gli oggetti considerati ”dipendenti” vengono notificati quando si verificano modifiche dello stato dell’oggetto ”sotto osservazione”Disaccoppiamento tramite subject e observerSupporto a comunicazione di gruppo, ma scalabilità limitataAdottato in modelli ad eventi Java e Jini

34


Gestione Risorse: Session Token

Rende più semplici e leggeri l’onere e i requisiti di gestione dello stato lato serverToken emesso da server e inviato a cliente (contiene dati che si riferiscono alla sessione attiva che il cliente ha in corso con il server)

Token contiene identificatore di sessione (talora anche informazioni di sicurezza correlate e time-to-live per evitare attacchi replay)

Quando cliente ri-presenta token al server, il server è in grado di associare correttamente il cliente alla sessione (stato, …) opportuna

By the way, in quali tecnologie avete già visto applicato questo pattern di soluzione?

35


Gestione Risorse: Caching

Suggerisce memorizzazione temporanea di risorse in local storage dopo il loro utilizzo, piuttosto che la loro immediata distruzione/deallocazioneSi ha prima verifica locale in cache di risorse, all’atto di ogni nuova richiesta di risorse/servizio Se cache hit, immediata consegna all’applicazione richiedenteSe cache miss, richiesta propagata e nuova entry creata nella cacheEsempi di file system Coda e Aura framework per pervasive computing

36


Gestione Risorse: Eager Acquisition

Se risorse necessarie a un’applicazione sono note fin dall’inizio, possibilità di utilizzare questa info per fare pre-fetching delle risorse richiesteCome risultato, risorse già disponibili localmente al momento del bisogno; nessuna necessità di richiesta remota

Esempi di risorse come memoria, connessioni di rete, file handler, thread e sessioni

37


Gestione Risorse: Lazy Acquisition

Ai fini di ottimizzazione dell’uso delle risorse di sistema, si suggerisce di differire acquisizione risorse fino all’ultimo(latest possible time)Resource Proxy responsabile per intercettazione di tutte richieste utente a risorseResource Proxy NON acquisisce risorse, trasparentemente, fino a che l’utente non vi accede esplicitamente

38


Sincronizzazione

Ai fini di gestire efficacemente istanze multiple di dati per unamolteplicità di dispositivi, il pattern suggerisce di realizzareun engine di sincronizzazioneSync engine traccia le modifiche fatte ai dati utilizzati, scambiandoinfo modifica trasparent. fra engine differenti (coordinamento), e aggiornando poi dati quando connessione disponibileSync engine responsabile per detection di conflitti e lororisoluzione durante processo di sincronizzazionePossibilità accesso a dati obsoleti e conflitti

39

Ora piccola parentesi su

sincronizzazione e SyncML


Sincronizzazione e SyncML:Scenario del Commesso Viaggiatore

Customer A Customer B Customer C

Company

Central DB

itinerario clientida visitare

Mobile DeviceLocal DB replicate

Mobile DeviceLocal DBupdate

possibilità anchedi temporanea disconnessione

Mobile DeviceLocal DB

synchronize

40


Sincronizzazione a livellodi processo

Sincronizzazione a livellodi dati

Data item 1

Process A Process B

Process A

Process B

Data item 1

Data item 1

System BSystem A

Main? System

Process Process

Data Item 1 Data Item 1

Data Item 1

time

time

sincroniz.

modifica

modifica

modifica

modifica modifica

41

Due MacroDue Macro--TipologieTipologiedi Sincronizzazione Possibilidi Sincronizzazione Possibili

detection

sincroniz.sincroniz.


Qualche Volta è Possibile Merging di Dati durante Sincronizzazione

System A

Main? System

Stock: 100

Ordine 50 unità

Stock Product A: 100

System BOrdine 25

unità

Stock Product A: 100

System A

Main? System

Stock: 25

Stock Product A: 50

System B

Stock Product A: 75

Ordine: 50 Ordine : 25

Applicare modifiche in fase di sincroniz.Operazioni

disconnesse

Inserire ordine,ridurre stock

Inserire ordine,ridurre stock

Nessun conflitto in questo caso; sempre vero?42


Sincronizzazione:Modelli ed Elementi di Base

Fino a che non sarà disponibile in modo seamless e a costo limitato una realizzazione efficace dell’ideale di cloud computing, importanza di operazioni disconnesse e di sincronizzazione in secondo step

Joking a parte ☺, costo (economico, energetico, …) e lentezza connettività + connettività discontinua spingono verso operazioni disconnesse e gestione copie

Gradi di libertà nella sincronizzazione:Quando lanciare operazioni di sincronizzazione

Trigger manualeTrigger automatico

Vedi anche problemi analoghi per replicazione nel distribuitoCome sincronizzare (stili di sincronizzazione)

Pessimistico – permettere unica copia modificabile; sincronizzazione come copia dell’unica istanza modificataOttimistico – consentire che copie multiple possano essere modificate; tentare poi di riconciliare modifiche avvenute in secondo step

Con quali costi?43


Sincronizzazione:Modelli ed Elementi di Base

Meccanismo di base spesso utilizzato: versioningDiverse soluzioni possibili; in generale problema aperto su come fare

versioning per migliorare processo sincronizzazione in approccio ottimistico

Usualmente semplici meccanismi versioning soddisfano proprietà:Se versione B deriva da modifica A, allora versione di B maggiore di ASe due copie sono state modificate concorrentem. in locazioni diverse, allora i numeri di versione non sono comparabili

⇒ Sequenza lineare di versioni ad ogni locazione singola; comunque possibilità di fare detection di modifiche concorrenti

Due fasi (oltre a propagazione update):Detection di modifica (copie clean o dirty, anche approccio conservativo)Reconciliation (necessariamente bisogna considerare sintassi e semantica dei dati)

Log di operazioni di modifica – riconciliazione come calcolo di log complessivo che comincia dall’ultima versione comune prima di modificaComparazione di stato – opera direttamente su dati modificati

44


Architetture per Sincronizzazione

In casi realistici, sempre sincronizzazione come processo solamente fra due nodi che detengono copieArchitettura centralizzata con nodo con ruolo di master per ogni istanza di datoArchitettura ad albero (sincronizzazione fra nodo e suo singolo parent)Architettura più generale come grafo ciclico connesso (maggiore flessibilità ma gestione più complessa: ad esempio, quali versioni precedenti considerare per comparazione di stato?)Raramente utilizzata in sistemi di sincronizzazione attuali

Algoritmi di riconciliazione possono beneficiare di conoscere la natura (ad es. struttura) delle info condivise

Capacità di riconciliazione crescenti passando da info opache, con struttura nota, con identificatore unico anche per parti, con semantica nota, con soluzioni application-specific

45


Un Paio di Esempi Notevoli

File system (ad es. Coda per citare uno degli esempi più vecchi):

Conoscete la differenza fra Networked File System (NFS) e DistributedFile System (DFS), vero?Tipicamente DFS si occupano di consistenza nell’albero dei direttori, non a livello di singolo contenuto di file (delegato a plug-in synchronizer esterno); spesso richiesta di intervento esplicito dell’utenteAnalogia con mantenimento consistenza albero XML

Conoscete gli strumenti antenati diff e patch in Unix?Oppure esempio di strumento più raffinato come rsync?

46


Un Paio di Esempi Notevoli

Concurrent Versions System (CVS) per lavoro collaborativo su sviluppo software:

Prime versioni banali con server centralizzato che rilasciava lock a un solo partecipante per volta; nessun bisogno di riconciliazioneOra generalmente approccio ottimistico e architettura centralizzata: algoritmo 3-way merge; detection di conflitti e richiesta intervento dell’utenteAnche primi approcci non centralizzati, con utilizzo di change set (ciascuno dei quali atomico e con id unico): sincronizzazione come applicazione ordinata e completa di tutti change set

47


Middleware per Synchronization

Sempre più rilevante in sistemi e servizi mobili, supporto a livello middleware per sincronizzazione applicazioni

API di sincronizzazione a disposizione di sviluppatori

Operazioni di update detection e di riconciliazione come operazioni tipicamente localiInvece azioni necessarie di propagazione update come operazioni che necessitano di definizione protocolli e connettività anche temporaneaSpesso basate su sistemi di messaging o pub/sub

Esempio di soluzione (parziale) di sincronizzazione oggi molto diffusa: SyncML

48


SyncML

Open Mobile Alliance (OMA) ha adottato Synchronization Markup Language (SyncML) come linguaggio di sincronizzazione per aumentare interoperabilità e contrastare numero crescente di protocolli proprietari

SyncML non è soluzione di sincronizzazione completa: solo protocollo di sinc (propagazione update), nessuna specifica su detection modifiche o riconciliazioneBasato su approccio a log (operazioni tracciate di inserimento, cancellazione, ecc. di oggetti che sono unità atomiche SyncML)Architettura centralizzata; scambio di messaggiSincronizzazione avviata da clienteServer riceve modifiche, le applica alla sua copia principale, determina conflitti, restituisce a cliente altro file SyncML con ulteriori modifiche da applicareUso di diversi protocolli (HTTP, OBEX, …) per trasferimento messaggi SyncML

49


SyncML

50

Sync server deve conoscere tipicam. semantica applicazione (esterno a specifica SyncML) per riconciliazione; uso di numeri di versione

Tecnologia giàutilizzata da numerose applicazioniOMA include Ericsson, Nokia, IBM, Motorola, …


SyncML in Maggiore Dettaglio

Progettato per essere efficiente su reti wireless: encoding di dati e comandi ottimizzato (WAP Binary XML - WBXML) in formato binarioRobusto a caduta di connessione durante scambio di messaggiDiverse soluzioni per trasferimento messaggi: HTTP, Bluetooth OBEX, IrDA, SMTP, WAP Wireless Session ProtocolSupporto a dati qualsiasi, da vCard a email, dati relazionali, documenti HTML/XML, dati binari

La specifica standard definisce:SyncML representation protocol per formato messaggiSyncML synchronization protocol per azioni di sincroniz fra due entità (cliente e servitore in gergo SyncML)

51


SyncML Synchronization Protocol

cliente e servitore devono mantenere log di modifiche (formato non standardizzato); se perso log, slow syncnegoziazione iniziale capability dispositivi (formato dati supportati, …)utilizzo di sync anchor (stringhe) per identificare eventi sinc. Lato cliente, anchor chiamata last rappresenta ultimo evento prima di sinccon server; next quello corrente. Confronto lato server per verificare che guasti non abbiano fatto perdere synch anchor; nel caso slow syncidentificatori unici per dati da tenere sincronizzati. Utilizzo di LocallyUnique ID (LUID) lato cliente e GUID lato server; tabella di mappinglato servermodalità per notificare cliente che conflitto è stato risolto (codici di stato per descrivere conflitto e come è stato risolto). Ad es.<Status> <MsgRef> 1 </MsgRef>

<CmdRef> 2 </CmdRef>

<SourceRef> 2121 </SourceRef>

<Data> 208 </Data> <!– conflitto risolto con data merge --> </Status>

52


Esempio Messaggio Esempio Messaggio SyncMLSyncML: : Cliente Invia ModificheCliente Invia Modifiche

<SyncML> <SyncHdr>

<VerDTD>1.0</VerDTD>

<VerProto>SyncML/1.0</VerProto>

<SessionID>1</SessionID>

<MsgID>2</MsgID>

<Target><LocURI>http://www.syncml.org/sync-server</LocURI>

</Target>

<Source><LocURI>IMEI:493005100592800</LocURI></Source>

</SyncHdr>

<SyncBody> <Status>

<MsgRef>1</MsgRef><CmdRef>0</CmdRef> <Cmd>SyncHdr</Cmd>

<TargetRef>IMEI:493005100592800</TargetRef>

<SourceRef> http://www.syncml.org/sync-server

</SourceRef>

<Data>212</Data>  </Status>

53



<Status>

<MsgRef>1</MsgRef><CmdRef>1</CmdRef> <Cmd>Alert</Cmd>

<TargetRef>./dev-contacts</TargetRef>

<SourceRef>./contacts/james_bond</SourceRef>

<Data>200</Data> 

<Item> <Data>

<Anchor xmlns='syncml:metinf'><Next>200005022T093223Z

</Next></Anchor>

</Data> </Item> </Status>

<Sync>

<CmdID>1</CmdID>

<Target><LocURI>./contacts/james_bond</LocURI></Target>

<Source><LocURI>./dev-contacts</LocURI></Source>

<Meta>

<Mem xmlns='syncml:metinf'>

<FreeMem>8100</FreeMem> 

54



<FreeId>81</FreeId> 

</Mem> </Meta>

<Replace> <CmdID>2</CmdID>

<Meta><Type xmlns='syncml:metinf'>text/x-vcard</Type> </Meta>

<Item>

<Source><LocURI>1012</LocURI></Source>

<Data> dati per vCard vanno indicati qui </Data>

</Item> </Replace> </Sync>

</SyncBody>

</SyncML>

55


Ulteriori Info Ulteriori Info e Link Utilie Link Utili

Esistono server, anche open source, che implementano SyncML, ad esempio Sync4j e sua implementazione come modulo di estensione per application server J2EE (vedi Funambol community – http://www.forge.funambol.org/ )

Ulteriori informazioni e link utili:

SyncML -http://www.openmobilealliance.org/tech/affiliates/syncml/syncmlindex.html

JSR230 Data Sync API -http://www.jcp.org/en/jsr/detail?id=230Elenco di dispositivi che supportano SyncML -http://www.weblicon.de/html/mobile_devices.html

56


Sincronizzazione: Rendezvous

Rendezvous come pattern di grande utilizzo per assistererete (ma non solo) nella gestione di dispositivi mobiliIn generale, rendezvous come modalità che consente a due o piùentità di coordinare le loro attivitàRealizzato in sistemi distribuiti tipicamente tramite rendezvous point

Una entità logicamente centralizzata (punto di indirettezza) Accetta messaggi/pacchetti e mantiene stato così da poterrispondere, ad es., su dove un dispositivo mobile è correntementeposizionato

Esempi: DNS, Mobile IP, HIP, ...

57


Gestione Risorse & Sincronizzazione: State Transfer

Come sapete, diversetipologie di handoffpossibiliHandoff può averebisogno di trasferimentodi stato fra AP Utilizzo di indirectionpoint (rendezvous) per garantire raggiungibilità

58

Old AP New AP Rendezvous Correspondent nodeClient

Old AP is thecurrent pointof attachment

Attach to a new AP

Update location

Teardown old attachment

Lookup client

Send message

Forward message


Esempi di Rendezvous & State Transfer: Mobile IP, Wireless CORBA, Mobile Web server

Home agent

Correspondenthost

Foreign agent

Mobile hostHome link Foreign

linkCare-of-Address (CoA)

Home domain

HomeLocation

Agent

Visited domain AccessBridge

AccessBridge

AccessBridge

AccessBridge

TerminalBridge

HostGIOP

GIOPtunnelTerminal

domain

Web server Browser

DNSGateway

Operatorfirewall

1

23Internet

59


Comunicazione: Connection Factory

Suggerisce disaccoppiamento fra applicazione e il sistema sottostante di comunicazione tramiteintroduzione di componente utilizzato per istanziare, accedere e terminare connessioniDesign pattern factory è di ampio utilizzo; in questo caso, è usatoper consentire gestione e riutilizzo di connessioni in modoefficienteUtilizzato ampiamente in architettura Java in generale. API per comunicazioni in Java ME adottano questo pattern

60


Comunicazione: Client-initiated Connection

In molti casi è impossibileraggiungere un clientemobile a causa di firewall/NAT lungo camminodi comunicazioneQuesti problemi motivanol’uso di connessione client-initiated verso un servercon indirizzo pubblico chepoi possa operare push di messaggi verso clienteutilizzando connessioneesistenteEsempi: MS DirectPush, AJAX

Client Edge Proxy Server

Initiate connection

Send message

Forward message

Lookup service

Update client status

Lookup client

Associate message with connection

61


Comunicazione: Multiplexed Connection

Inefficiente creare molteconnessioni che possonocompetere per consumo risorsedi rete e sistemaMultiplexed Connection usauna singola connessionelogica e ne fa multiplexing per supportare connessionimultiple a livello di astrazionepiù altoConsente di dare prioritàdifferenziate ai messaggi di cuisi fa multiplexing sull’unicaconnessione di basso livelloEsempio: Stream ControlTransfer Protocol (SCTP)

Multiplexer Demultiplexer

Connection N

Connection 1

Connection N

Connection 1

Single connection

62

Documents

Principi di Design per Mobile Middleware e …lia.deis.unibo.it/Courses/sm1112-info/lucidi/05-MM...Principi Mobile Middleware - Sistemi Mobili M 1 Sistemi Mobili M Università di Bologna