Sistemi Mobili M - Università di Bologna

Transcript

Sistemi Mobili M
Università di Bologna
CdS Laurea Magistrale in Ingegneria Informatica
II Ciclo - A.A. 2010/2011
Corso di Sistemi Mobili M (6 cfu)
05 – Principi di Design per Mobile
Middleware e Applicazioni Mobili
Docente: Paolo Bellavista
[email protected]
http://lia.deis.unibo.it/Courses/sm1011-info/
http://lia.deis.unibo.it/Staff/PaoloBellavista/
Principi Mobile Middleware - Sistemi Mobili M
1
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 fino
a 144Kbps
3rd generation (2003-2008)
Piattaforme mobili, cosiddetti servizi di middleware; terminali con
Symbian Series 60, J2ME, Android, iPhone, ...; banda massima
fino a diversi Mbps
4th generation (2008-...)
Servizi adattativi, interfacce utente adattative, protocolli
adattativi; context awareness, connettività continua; banda
massima fino a centinaia di Mbps
2
Evoluzione dei Sistemi e dei Servizi Mobili
revenue
Social sites,
media portals
Stores and
Web pages
SMS
ringtones,
logos
WAP
Ringtones
Java
portals
On-demand
and streaming
video
Advanced
browsers
Full music and
video streaming
Full music streaming
Music downloads
Music clips
Monophonic
Polyphonic
Master tones
time
3
Mobile Middleware
Gestione di tanti aspetti, non strettamente applicationspecific, in particolare della mobilità, è un problema
complesso. Ad esempio, mobilità di:
Reti
Nodi
Connessioni di trasporto
Sessione
Oggetti (passivi, attivi)
Servizi
Utenti
Molte soluzioni necessarie, a livelli multipli (link, rete, trasporto,
applicazione) e cross-layer
Soluzioni 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’ fuzzy
Una 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 timeconsuming
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?
diverse applications
divergence
transport layer (TCP/IP)
Necessità di middleware
Per riduzione tempo di sviluppo e rapid
prototyping
Per semplificare sviluppo di applicazioni e
ridurne i costi
Per supportare ambienti eterogenei,
mascherando in parte differenze a livello
di linguaggio/OS/hardware
convergence
diverse physical layers
hourglass model
6
Chi Beneficia di Mobile Middleware?
Utenti finali
Anche 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 experience
Produttori di dispositivi
Middleware per fornire funzionalità avanzate ed estese che poi si
interfaccino a basso livello con driver di dispositivo
Internet Service Provider
Middleware per monitoraggio e amministrazione di rete
Fornitori di piattaforme middleware
Sviluppo di piattaforme middleware che si integrano con differenti
sistemi operativi
Application Service Provider
Middleware per facilitare sviluppo e deployment di applicazioni in modo
veloce, scalabile e a basso costo
7
Obiettivi ed Elementi Chiave
Accessibilità e Reachability
Risorse 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
operativo
Appropriato 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 affidabili
Storage persistente, buone capacità computazionali, nessun
problema consumo energetico
No mobilità
Ambienti mobili richiedono soluzioni middleware nuove
Middleware 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 middleware
Contesto cambia dinamicamente
Necessità di disaccoppiamento in spazio e tempo
Eventi asincroni, spazi di condivisione dati
Soluzione 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/RMI
In 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 regola o norma tramite
osservazione del soggetto a cui si applicano
Principi hanno caratteristica di minimalità; non possono
ulteriormente essere decomposti
Pattern come schemi di soluzione che hanno dimostrato di
funzionare e lavorare bene in diverse situazioni con
caratteristiche comuni
Classificati in gruppi differenti sulla base del loro livello di
astrazione
Architectural pattern per progetto architettura di soluzione
Design pattern per strategie di progetto languageindependent, tipicamente object-oriented
Idiomi per aspetti di buone soluzioni (best practice) a livello di
utilizzo linguaggio di programmazione
11
Pattern
Info importanti per definizione di pattern:
Nome pattern: nome “informative” che faccia da identificatore
unico per il pattern
Intent: obiettivo del pattern e ragioni per il suo utilizzo
Motivation: presentazione sintetica del problema a cui pattern si
applica, utilizzando uno scenario di esempio
Applicabilità: ambiente operativo e contesto in cui pattern può
essere applicato efficacemente
Struttura: struttura del pattern, rappresentata secondo diverse
modalità e convenzioni grafiche
Collaborazione: come i vari elementi che costituiscono il pattern
(tipicamente classi e oggetti) interagiscono fra loro
Conseguenze: risultati attesi dall’utilizzo del pattern
Implementazione: descrizione di una possibile implentazione
pratica del pattern proposto
Casi 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 componenti
Piattaforma 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-End
Nella sua espressione originale, riferita all’opportunità di
mantenere stato e intelligenza solo sui bordi (edge) della rete
Internet 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 generale
Verso 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 dello
stack TCP/IP sottostante
Semplicità, modularità, decentralizzazione e
robustezza
In particolare, relativamente ad accesso, rappresentazione dati e loro
trasformazione 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 dello
stato per interazioni stateful. Ad es. Representational
State Transfer (REST), basato su URI, HTTP, XML
Client-server, stateless, cacheable, a livelli
Condivisione interfaccia uniforme per trasferimento di stato fra
cliente 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 a
processi 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 standard
Identificazione e categorizzazione di servizi, provisioning e delivery,
monitoraggio e tracking
16
Principi di Sicurezza
(e non solo)
–
–
–
Privacy
Autenticazione
Accountability
- Integrità
- Autorizzazione
- Disponibilità
Principio di Inversion of Control
Principio 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 informate
Choice & Control. Utenti devono avere possibilità di scegliere su raccolta,
utilizzo ed eventuale disclosure di loro info personali
Fairness & 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 per Mobile:
Prospettiva Dispositivo (vedi NoTA)
Esempio di Network on Terminal Architecture (NoTA): architettura
proposta da Nokia per strutturazione interna dispositivi mobili; validità
generale dei principi sotto
System-level loose coupling. Accoppiamento debole/lasco portato fino
all’estremo dei componenti hw che costituiscono il dispositivo
Interconnect-centric. Componente centrale responsabile per
interconnessione di altri componenti e servizi (bus comune), basato su
meccanismi message passing
Basato su servizi, funzionalità realizzate tramite servizi con interfacce ben
definite. Insieme a loose-coupling, porta ad adattabilità
Message & data driven. Message passing come meccanismo privilegiato
per realizzazione applicazioni. Comunicazioni data-driven nel senso di
forwarding richieste basato anche su condizioni correnti del sistema e
dati contenuti nelle richieste. Verso disaccoppiamento
Implementation-wise heterogeneous. Integrazione di sotto-sistemi da
diversi produttori e vendor; una volta note specifiche di interfaccia e formati di
richiesta, componenti sono intercambiabili
18
Esempio di NoTA
Basato su servizi anche per
l’integrazione all’interno di un singolo
device
Possibilità di composizione di
sottosistemi
19
Principi per Mobile:
Prospettiva Mantenimento Sessione (SIP)
Session Initiation Protocol (SIP), alla base di reti
convergenti Next Generation Network (NGN). Ne avete già
parlato in altri corsi, vero ☺?
Utilizzo massiccio di proxy, ad es. per routing
Stato delle chiamate mantenuto presso endpoint
“Endpoint fate sharing”, ovvero fallimento delle
applicazioni quando i loro endpoint hanno guasto
Utilizzo di modello a dialog, e non di modello a chiamata
Architettura basata su componenti logici (ricoprono ruoli
logici, non necessariamente associati a componenti fisici)
Generality over efficiency
Separazione chiara fra piano di segnalazione e piano
di distribuzione media
20
Esempio di SIP
Protocollo, con messaggi tipicamente verbosi
per mantenimento di stato di sessione
, basato su proxy
Modello a dialog, non a chiamata
Alla base, insieme a Diameter, di architettura IP Multimedia Subsystem (IMS)
21
Principio di Cross-Layering
Varie tipologie di interazione per differenti forme di
cross-layering in uno stack protocollare
Flusso info upward, con info propagata da layer più bassi a layer
più alti, contrariamente a principi di architetture a livelli tradizionali
Flusso info downward, con info propagata dai layer alti verso
quelli bassi, tipicamente per fare configurazione di parametri a livello
più basso
Flusso info back-and-forth, con info propagata nei due versi
Merging di layer adiacenti, consente combinazione di differenti
layer adiacenti in un unico super-layer
Accoppiamento senza aggiunta di nuove interfacce. Due o più
layer sono accoppiati a design time in modo definitivo, senza
possibilità di mantenere indipendenza/astrazione da livello
sottostante
Calibrazione verticale fra layer. Per consentire la configurazione
congiunta di parametri fra layer (joint tuning) e ottenere migliori
performance complessive
22
Principio di Cross-Layering
Designed for X
Layer X
Upward information Downward
flow
information flow
Back and forth
flow
Merging of
adjacent layers
Design coupling
Vertical coupling
23
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, strutturati
Cliente-Servitore. Pattern più frequente nel distribuito: clienti
sfruttano risorse e servizi messi a disposizione dal servitore
Peer-to-peer. Ogni nodo può giocare dinamicamente il ruolo sia di
cliente che di servitore; funzionalità più o meno simmetriche
Pipeline (o pipe&filter). Pipeline come catena di elementi di
processamento allineati in modo tale che output di ciascuno sia
input per il successivo
Multitier. Architettura cliente-servitore in cui applicazione eseguita
da una molteplicità di software agent distinti
Blackboard. Una base di conoscenza comune (blackboard) è
aggiornata iterativamente da sorgenti differenti di conoscenza,
partendo da specifica di problema per giungere alla sua soluzione
Publish/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
Applicazione divisa in
tre parti, con
responsabilità
separate e modalità
di interazione ben
specificate
Invocazione di
metodi ed eventi
Ad esempio utilizzato
in Symbian OS
26
Broker
Componente broker che realizza disaccoppiamento fra
clienti e servitori
Server si registrano presso broker, mettendo a
disposizione i loro servizi per i clienti attraverso
interfacce fornite al broker
Clienti accedono le funzionalità dei server inviando
richieste di servizio al broker
Compiti del broker includono:
determinare/localizzare server appropriato
fare forwarding richieste verso server
trasmettere 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 applicazioni
Caratteristiche desiderate sono estensibilità, adattabilità e
interoperabilità
Idea cruciale di piccolo core estensibile tramite componenti che
possano essere plugged-in dinamicamente
Calls Microkernel
External Server
Microkernel calls
Microkernel
Internal Server
Calls
Adapter
Calls
Client
28
Active Object
Supporto per processamento asincrono
Pattern lavora tramite incapsulamento e gestione di richieste
asincrone di servizio e di risposte al completamento del servizio
Cliente notificato al completamento operazione e in grado di
svolgere altre operazioni, anche con stesso server, in modo asincrono
Active Object esegue nello stesso thread dell’applicazione, per
ridurre overhead di context switching fra thread
Active Object deve gestire eventi in modo non-preemptive (un evento
processato per volta; processamenti rapidi)
Decide resumed
object
CActiveScheduler
Status
ActiveObject
AsynchronousServiceProvider
Status flags
CActive
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 sincronizzazione
session token, caching, eager acquisition, lazy acquisition,
synchronization, rendezvous, state transfer
per comunicazione
connection factory, client-initiated connection
30
Distribuzione: Remote Facade
Addresses
Coordinates
Addresses
Coordinates
Remote
Facade
Mobile
Device
Directions
and maps
Routes
Route Segment
Map
Web
Services
Direction
Route Segment
Highlighted map
Last hop
wireless network
Fast fixed-network
Interfaccia coarse-grained verso
singolo o pluralità di oggetti finegrained
Interfaccia fornita tramite remote
gateway
Accetta richieste incoming che
siano conformi all’interfaccia
della facade
Susseguenti interazioni finegrained 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
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 distribuiti
Obiettivo principale del pattern è riduzione del numero
di chiamate a metodo remoto
Singolo 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 rete
By the way ☺, chiara vero la differenza fra proxy e
gateway?
Client
Web
Browser
encoded
request
wireless
encoded
response
Gateway
Server
request
Encoders
Decoders
Protocol
Gateways
HTTP
Server
response
CGI,..
Tutti messaggi/pacchetti (o un loro
sottinsieme selezionato) passano
attraverso proxy, che può valutarli
(anche contenuto) e svolgere
operazioni su di loro
Proxy anche per svolgere operazioni
computazionalm. pesanti al posto del
terminale cliente
Proxy fa da adapter, anche consentendo
l’interazione lato server senza bisogno di
implementare protocolli/soluzioni
terminal-specific
Tipicamente necessità di discovery per
determinare proxy
33
Distribuzione: Observer
Supporta definizione di dipendenza one-to-many fra
oggetti
Tutti gli oggetti considerati ”dipendenti” vengono notificati quando si
verificano modifiche dello stato dell’oggetto ”sotto osservazione”
Disaccoppiamento tramite subject e observer
Supporto a comunicazione di gruppo, ma scalabilità limitata
Adottato 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 server
Token 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/deallocazione
Si ha prima verifica locale in cache di risorse, all’atto di ogni nuova
richiesta di risorse/servizio
Se cache hit, immediata consegna all’applicazione richiedente
Se cache miss, richiesta propagata e nuova entry creata nella cache
Esempi 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 prefetching delle risorse richieste
Come 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 risorse
Resource 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 una
molteplicità di dispositivi, il pattern suggerisce di realizzare
un engine di sincronizzazione
Sync engine traccia le modifiche fatte ai dati utilizzati, scambiando
info modifica trasparent. fra engine differenti (coordinamento), e
aggiornando poi dati quando connessione disponibile
Sync engine responsabile per detection di conflitti e loro
risoluzione durante processo di sincronizzazione
Possibilità accesso a dati obsoleti e conflitti
39
Esempio: SyncML
App A
Sync
Engine
SyncML
Framework
application/vnd.syncml
App B
SyncML SyncML
I/F
Adapter
Sync
Server
Agent
SyncML
XML
Objects
SyncML
Adapter
SyncML
I/F
Sync
Client
Agent
Transport
(e.g. HTTP / OBEX)
40
Sincronizzazione: Rendezvous
Rendezvous come pattern di grande utilizzo per assistere
rete (ma non solo) nella gestione di dispositivi mobili
In 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 poter
rispondere, ad es., su dove un dispositivo mobile è correntemente
posizionato
Esempi: DNS, Mobile IP, HIP, ...
41
Gestione Risorse & Sincronizzazione:
State Transfer
Client
Old AP
New AP
Rendezvous
Correspondent node
Old AP is the
current point
of attachment
Attach to a new AP
Update location
Teardown old attachment
Lookup client
Send message
Forward message
Come sapete, diverse
tipologie di handoff
possibili
Handoff può avere
bisogno di trasferimento
di stato fra AP
Utilizzo di indirection
point (rendezvous) per
garantire raggiungibilità
42
Esempi di Rendezvous & State Transfer:
Mobile
IP, Wireless CORBA, Mobile Web server
Correspondent
host
Foreign agent
Home agent
Home link
Home domain
Foreign
link
Mobile host
Home
Location
Agent
Browser (CoA)
Care-of-Address
Web server
1
2
3
Operator
firewall
Terminal
Bridge
Terminal
domain
GIOP
tunnel
Internet
DNS
Gateway
Access
Bridge
GI
Access
Bridge
Visited domain
OP
Access
Bridge
Host
Access
Bridge
43
Comunicazione: Connection Factory
Suggerisce disaccoppiamento fra applicazione e il
sistema sottostante di comunicazione tramite
introduzione di componente utilizzato per istanziare,
accedere e terminare connessioni
Design pattern factory è di ampio utilizzo; in questo caso, è usato
per consentire gestione e riutilizzo di connessioni in modo
efficiente
Utilizzato ampiamente in architettura Java in generale. API per
comunicazioni in Java ME adottano questo pattern
44
Comunicazione:
Client-initiated Connection
Client
Edge Proxy
Server
Lookup service
Initiate connection
Update client status
Lookup client
Send message
Forward
message
Associate message with connection
In molti casi è impossibile
raggiungere un cliente
mobile a causa di
firewall/NAT lungo cammino
di comunicazione
Questi problemi motivano
l’uso di connessione clientinitiated verso un server
con indirizzo pubblico che
poi possa operare push di
messaggi verso cliente
utilizzando connessione
esistente
Esempi: MS DirectPush,
AJAX
45
Comunicazione:
Multiplexed Connection
Connection 1
Connection 1
Connection N
Connection N
Multiplexer
Demultiplexer
Single connection
Inefficiente creare molte
connessioni che possono
competere per consumo risorse
di rete e sistema
Multiplexed Connection usa
una singola connessione
logica e ne fa multiplexing per
supportare connessioni
multiple a livello di astrazione
più alto
Consente di dare priorità
differenziate ai messaggi di cui
si fa multiplexing sull’unica
connessione di basso livello
Esempio: Stream Control
Transfer Protocol (SCTP)
46

Sistemi Mobili M - Università di Bologna

Transcript

Documenti analoghi

MOBILI NORD SALOTTO srl MOBILI - SALOTTI

ALLEGATO B Percentuali di ammortamento Tipologia di bene

MOBILI I mobili aperti sono

n. 2 IT System Specialist - Application Profilo posizione

PATRIMONIO E BENI CULTURALI

Il mobile learning nella didattica

Nome azienda per inserimento in catalogo: Nome azienda per

Mobili per la Casa - Offerte

Ecco in pratica come dare una nuova vita ai mobili

Vicovaro e la storia della stampa a caratteri mobili