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)
07 – Supporto a Comunicazione Mobile
(Messaging) e Gestione Eventi
Docente: Paolo Bellavista
[email protected]
http://lia.deis.unibo.it/Courses/sm1011-info/
http://lia.deis.unibo.it/Staff/PaoloBellavista/
Messaging & Eventi - Sistemi Mobili M
1
Comunicazione Disaccoppiata: Messaging
Come già detto più volte, importanza disaccoppiamento
nella comunicazione/interazione fra componenti
distribuiti mobili
Talora si parla in generale di comunicazione middleware
mobile come di scambio di messaggi (vedi S. Tarkoma,
“Mobile Middleware”) a sottolineare l’importanza del
disaccoppiamento
Ogni sistema per mobile messaging deve definire:
Principi e architettura
Sintassi messaggi
Protocollo scambio di messaggi
Locator
Talvolta il termine protocollo tende a includere anche sintassi e
locator…
2
Messaging:
Principi e Architettura
Principio fondamentale: loose coupling (tramite
protocolli/formati standard e aperti)
In sistemi reali, anche estensibilità. Come?

Identificatori di versione nei messaggi (versioni non riconosciute
trattate come errori; compatibilità?)
Formati con extension point
Forward compatibility con possibilità di ignorare parti di
messaggio non riconosciute (principio di robustezza)
Usualmente API middleware per consentire applicazioni di
utilizzare funzionalità comunicazione; talora middleware
con visibilità dei requisiti di scambio dati e loro
semantica
3
Messaging:
Sintassi dei Messaggi
Gestione marshalling/unmarshalling:

Implementato a livello di applicazione
Codice automaticam. generato (tipicamente basato su Interface
Description Language – IDL – considerati a tempo di sviluppo)
Introspezione (più trasparente per sviluppatore ma tipicamente più
costoso a runtime)
Come ci si accorda sul formato dei dati?

Specifica (tipico approccio dei protocolli Internet con messaggi in
formato binario)
Negoziazione
Receiver-makes-right (mittente usa suoi formati nativi ed esprime
metadati per indicare quali sono)
Principali tipologie di formato messaggi:

Binary (ASN.1, …)
Text-based (XML, JSON, …)
4
Messaging:
Protocolli
Oltre alle usuali proprietà dei protocolli per comunicazione in sistemi
distribuiti (header con metadati e payload, metadati anche a livello
applicativo, tipi di messaggi e con che pattern di scambio, …),
particolare rilievo per gestione connessione

Protocolli che “mimano” il livello di trasporto, con connessione
applicativa in rapporto 1:1 con connessione a livello di trasporto
Più spesso protocolli che disaccoppiano i due aspetti
(funzionalità sessione persistente su connessioni di trasporto
temporanee; vedi TCP e cambio di indirizzo IP dinamico)
Vista “pura” end-to-end oppure uso di mediatori fino a
livello applicativo?
Ampio utilizzo di architetture e protocolli store-andforward (disaccoppiamento nel tempo, ottimizzazione
implementazioni con affidabilità, violazione del principio end-to-end)
5
Messaging:
Protocolli
Classici schemi di scambio messaggi: one-way, two-way, requestresponse, subscribe notify, conversation, …
Importante:
ruolo a livello di trasporto (initiator-listener) non
necessariamente lo stesso che a livello
applicativo/messaging
solita distinzione bloccante vs. non bloccante
¾
¾
Metodo polling, usualm. con oggetto (promise o future) dato al
mittente; si può fare inspect o claim bloccante
Callback
Con quale dei due schemi è più semplice e robusto lo sviluppo di
applicazioni?
6
Messaging:
Locator
Siamo abituati a locator strettissimamente legati a indirizzi di rete
Ma anche locator più articolati e complessi, ad es. che includono
numeri di porta (trasporto) o path (URL)
In sistemi mobili molte tipologie di locator, anche non IPbased, specie in passato quando IP parzialmente utilizzato
Comunque, anche oggi, possibilità di:

Locator “trasparenti”, tipicamente pensati come URI e
codificati XML (alza livello di astrazione+disaccoppiamento)
Locator “opachi”, come in CORBA. Necessità di
middleware per generare e utilizzare locator opachi
Gestione mobilità è un problema network-layer? Ovviamente, per
quanto ci siamo già detti nel corso, NON SOLO…
Si dice anche che host mobili sono gestiti come second-class citizen;
verso locator indipendenti da network layer…
7
Messaging:
Progettare per la Mobilità
Usuali considerazioni generali su:
Utilità proxy ad es. per spezzare in due parti connessioni di
trasporto (rottura principio end-to-end)
Problemi Network Address Translation (NAT) quando nodi mobili
vogliono fornire servizi (ma si veda anche FTP e IRC…)
Inoltre:
Capacità di completare lo schema di scambio messaggi anche
se entità in comunicazione si muovono
Utilizzo di classiche connessioni a livello di trasporto è usualmente
preferito
Sintassi snella e contenuto messaggi ridotto, anche
compressione
Sicurezza a livello di messaggio: con approcci tipo SSL (sicurezza a
livello connessione) che tipo di problemi se rompiamo principio end-to-end?
Message-level security con sicurezza applicata a (parti di) payload,
non a header; ovviamente anche combinazione di connection e message
8
Messaging:
Reliability
Come al solito:

Distinzione fra end-to-end e hop-by-hop
Tecnica di base con acknowledgement e
ritrasmissioni (anche a livello applicativo)
Tipi di ACK:
Normali
Cumulativi
Negativi
Piggy-backed
In-order delivery? Qualche volta sacrificata per motivi di
efficienza
D’altronde, riduzione di affidabilità per motivi di performance è un
concetto ben noto (DNS, NTP, SIP, … tipicamente utilizzano UDP)
9
Esempi di Messaging:
Java Message Service (JMS)

Possibilità di chiedere semantica only once per
consegna messaggi (precisamente once-and-only-once per
uso persistente, at-most-once per uso non persistente)

Disaccoppiamento nel tempo dato da destination
(queue o topic) durature

Parziale accoppiamento temporale per topic: ridotto tramite durable
subscription
Possibilità di ricezione non bloccante tramite listener
Uso di ConnectionFactory
Messaggi inviati all’interno di una sessione (tramite un determinato
oggetto Session) verso la stessa destinazione godono proprietà di
in-order delivery
Tre tipologie di ACK (lazy, automatic, client-side)

10
Obiettivi di Design di JMS
JMS è parte della piattaforma J2EE. Obiettivi:

Consistenza con le API dei sistemi di messaging esistenti

Indipendenza dal vendor del sistema di messaging

Copertura della maggior parte delle funzionalità comuni nei
sistemi di messaging

Promuovere la tecnologia Java
Java™ Application
JMS API
JMS
JMS
Provider Provider
IBM
MQSeries
Progress
SonicMq
JMS
JMS
Provider Provider
Fiorano
BEA
JMS
Provider
SUN MQ
11
Riassunto “Grafico” delle API JMS
12
Reliability tramite ACK:
ad es., ACK Automatici

Prospettiva lato
produttore e
consumatore
Differenze fra caso
persistent e nonpersistent
Quando ci possono
essere messaggi
duplicati?
Quando ci può essere
perdita di messaggi?
Inoltre, tre casi di ack
differenziati
13
Persistenza:
2 Modalità di Consegna

PERSISTENT
¾
¾

Default
Specifica al provider JMS di garantire che il messaggio non
sia perso quando in transito, ad esempio a causa di un
guasto del provider JMS
NON_PERSISTENT
¾
¾
NON richiede la memorizzazione dei messaggi lato JMS
provider
Migliori risultati di performance
Metodo SetDeliveryMode() nell’interfaccia MessageProducer
¾
¾
producer.setDeliveryMode(DeliveryMode.NON_PERSIS
TENT);
forma estesa: producer.send(message,
DeliveryMode.NON_PERSISTENT, 3,10000);
14
Priorità e Expiration
nella Consegna dei Messaggi

10 livelli di priorità
da 0 (più basso) a 9 (più alto)
default = 4
¾
¾

Uso del metodo setPriority() dell’interfaccia
MessageProducer, ad esempio producer.setPriority(7);
o la forma estesa producer.send(message, DeliveryMode.
NON_PERSISTENT, 7, 10000);

Expiration: possibilità di configurare TTL tramite
setTimeToLive() dell’interfaccia MessageProducer
¾
¾
producer.setTimeToLive(60000);
o forma estesa, producer.send(message,
DeliveryMode.NON_PERSISTENT, 3, 60000);
15
CORBA Messaging
CORBA Messaging specification include:
Asynchronous Messaging Interface (AMI)

Sia possibilità di polling che di callback (callback passato come
oggetto CORBA, quindi anche non nello stesso spazio di indirizzamento
del cliente)

Time Independent Invocation (TII) per specificare oggetti
CORBA che svolgano ruolo di router per messaggio

Razionale: mittente e destinatario possono essere disconnessi
temporaneamente
Formano una rete di store-and-forward
CORBA locator = Interoperable Object Reference (IOR), con profili
differenti a seconda del protocollo di binding
Messaggi in binary format = Common Data Representation (CDR)
Estrema flessibilità nella scelta protocollo
16
CORBA AMI:
Modalità Callback
Callback: cliente fornisce metodo di callback richiamato dal
supporto al completamento attraverso una specifica fireand-forget (invocata automaticamente)
Anziché: int
somma (in int i, in int j, out int somma)
void
sendcallback_somma (in int i, in int j)
void
callback_somma (in int success, in int somma)
Usiamo due metodi
cambiando solo
implementazione
cliente e non
parte di servizio
Cliente chiama sendsomma
ORB invoca callbacksomma
CORBA DII e AMI 17
17
CORBA AMI:
Modalità Polling
Asincrona polling: cliente decide quando e se interrogare
metodo di verifica del completamento operazione remota
(ottenendo risultati), creato dal supporto
Anziché: int
somma (in int i, in int j, out int somma)
void
sendpoll_somma (in int i, in int j)
void
pollsomma (out int success, out int somma)
Si recupera su richiesta
invocando l’operazione
pollsomma generata
automaticamente
dal supporto CORBA
CORBA DII e AMI 18
18
Esempi di Messaging: Extensible
Messaging and Presence Protocol (XMPP)
Progettato essenzialmente per instant messaging
RFC 3920 basata sull’implementazione esistente del protocollo Jabber;
buona popolarità per utilizzo da parte di Google, Twitter, Facebook, …
Include meccanismi publish/subscribe, per
aggiornamento presenza e stato, per service
discovery
Modello client-server: cliente invia un flusso dati XMPP a server, dopo
negoziazione parametri
Modello peer-to-peer: server si coordinano per consegna al destinatario
Uso di cosiddette stanza, di tre tipologie:

Message stanza – comunicazione uno-uno, simile email
Presence stanza – semplice meccanismo pub/sub, comunicazione
trasferita a tutti subscriber
Info/Query stanza – meccanismo request-response
19
Messaggi XMPP sono stream codificati in XML
Data la larga adozione, buon candidato come supporto per messaging in
sistemi mobili, ANCHE SE:
Non specificatamente progettato per sistemi mobili
Costoso processamento XML, costosa gestione connessioni in termini
energetici
Costose riconnessioni a XMPP server (necessario ristabilire una
nuova sessione di interazione per ogni nuova connessione di
trasporto, invio di dati XML non trascurabile a ogni inizio di sessione)
Android ne implementa una variante, con protocollo non basato su XML
e NO creazione di nuova sessione per ogni nuova connessione
20
21
Web Services
SOAP è costruito su modello di interazione basato
sullo scambio di messaggi

Architettura basata su sender, receiver e intermedi
Locator = HTTP URI
Document-style SOAP: messaggi come documenti XML-based
che devono essere processati

Possibilità di differenti protocol binding, ma
decisamente il più utilizzato è HTTP, uso di metodo POST
(usato più come protocollo di trasporto, ignorando sua
semantica applicativa)

In ambienti mobili, dove HTTP è talora unico protocollo
praticamente utilizzabile a causa di firewall e NAT, questo
uso/abuso di HTTP potrebbe essere considerato legittimo e
prendere piede…
Anche specifica per binding su email e su XMPP

22
Representational State Transfer (REST)
REST è sostanzialmente uno stile architetturale di
soluzione, Resource Oriented Architecture (Roy Fielding,
UCI PhD Thesis, 2000)
Promuovere interazione client-server, stateless, che
sfrutti possibilità di caching, anche con possibilità di
code-on-demand verso cliente
Ogni risorsa ha un identificatore persistente; idea di
trasferire non risorse ma loro rappresentazioni
tramite protocollo HTTP
Vincolo: scambio di messaggi self-descriptive (linguaggi per
rappresentazione, negoziazione modalità supportate, …)
23
Locator = HTTP URI
Tre tipi di metadata inclusi in header HTTP:

Resource metadata – dati sulla risorsa, ad es. timestamp di ultima
modifica
Representation metadata – dati sulla rappresentazione trasferita, ad
es. suo media type
Control metadata – dati sul messaggio, ad es. lunghezza e possibilità
caching
Esempio notevole: RESTful Web services
RESTful Web service come semplice Web service implementato usando
HTTP e principi REST, quindi collezione di risorse con 3 aspetti definiti:
base URI per servizio, ad es. http://example.com/resources/
Internet media type dati utilizzati nel servizio (usualm. JSON o XML)
Insieme di operazioni supportate dal servizio tramite metodi HTTP (ad
es., POST, GET, PUT o DELETE)
24
Esempio notevole: RESTful Web services
Risorsa
URI per collezione
di risorse, ad es.,
GET
http://example.com/re
sources/ef7d-xj36p
POST
DELETE
Lista dei membri
della collezione
Sostituisce
intera
collezione
Crea un nuovo
elemento per la
collezione
Rimuove
intera
collezione
Ottiene
rappresentazione
dell’elemento
desiderato, espresso
in Internet media
type appropriato
Sostituisce o
crea un
elemento
della
collezione
Tratta l’elemento
come una
collezione e crea
un nuovo
elemento al suo
interno
Rimuove un
elemento
della
collezione
http://example.com/re
sources/
URI singolo
elemento, ad es.
PUT
Esempi di uso di REST oggi:
Maggioranza di blog Web (scaricamento di file XML in formato
RSS/Atom, che contengono link ad altre risorse
S3 di Amazon.com
OpenStreetMap (interfaccia REST)
25
26
Gestione Eventi e
Sistemi Publish/Subscribe

Consegna eventi da publisher a subscriber
¾ Eventi come messaggi con contenuto
¾ One-to-many, many-to-many (sistemi tradizionali per messaggi
sono queue-based e one-to-one)
Spesso realizzati sulla base di sistemi di messaging e
soluzioni store-and-forward
Paradigma di comunicazione di frequente uso, specie nel mobile
¾ Disaccoppiamento in spazio e tempo
Sistema ad eventi come servizio logicamente centralizzato
¾ Comunicazione anonima
¾ Possibilità di utilizzo di filtri (su header o su totalità messaggio)
¾ Primitive di base: subscribe, unsubscribe, publish, anche con filtri
Varie topologie per routing e semantiche associate all’invio e
notifica di eventi
Operazioni associate tipicamente non bloccanti (polling, callback)
¾

27
Architettura Generale per
Sistema Publish/Subscribe
Pub/Sub Service
Subscriber
Sottoscrizioni
Su
re bs
re que crib
sp st e
on /
se
Publisher
Notifica
istanze di
messaggi
Situation
Notification
Consumer
Notify
Notification
Engine
Subscription
Manager
Riceve
notifiche
Esegue matching
e invia notifiche
ai consumer
appropriati
Sottoscrizioni
Gestisce
sottoscrizioni
su delega
publisher
28
Event Router e Topologie
Event router o broker

Fa da mediatore (disaccoppiamento) fra publisher e subscriber
Uso di tabella di routing (anche con filtri) per dispatching di eventi in
locale o a quale router vicino; router distribuiti per ottenere scalabilità,
affidabilità e alta disponibilità
Filtri anche basati su contenuto e content-based routing
Altri requisiti non-funzionali: notifica entro intervalli di tempo (bounded delivery
time), Quality of Service, fault-tolerance, ordinamento (causal order, total order)
Possibili topologie di router:
Centralizzata
Gerarchica (notifiche sempre inviate a master, radice dell’albero
distribuzione)

Ciclica, aciclica (peer-to-peer, ciclico permette ridondanza ma servono
tecniche di minimum spanning tree per prevenire cicli)
Basato su rendez-vous point (router speciale che fa da rendev-vous,
tipicamente per tipologia pre-determinata di eventi)
Qualcuno vi ha parlato di Distributed Hash Table (DHT)?
29
Propagazione di Interessi e
Sottoscrizioni
Una delle funzioni principali di router è propagare notifiche
a router vicini che hanno interesse in quell’evento
Proprietà da raggiungere: ridotto overhead forwarding, alte
performance, supporto veloce variazioni
Simple routing: ogni router conosce tutte sottoscrizioni del
sistema globale (flooding sottoscrizioni)

Identity-based routing: non fatto forwarding se messaggio
sottoscrizione già circolato

Covering-based routing: forwarding dei soli filtri sottoscrizione
più generali (problemi con unsubscription?)

Merging-based routing: permette di fondere diverse entry
tabella di routing (usualm. combinato con covering, anche qui
problemi di unsubscription)
Notifiche usualmente distribuite su reverse path di subscription
30
Decisione di Routing
Dipendentemente da che cosa viene utilizzato per prendere decisioni di
routing, classificazione in:

Channel/topic-based: sulla base del canale (usualm. con nome)
su cui viene pubblicato l’evento. Accordo fra pub/sub su nome canale,
anche indirizzo multicast associato a canale

Subject-based: sulla base del subject (argomento) dell’evento,
campo singolo di info

Header-based: sulla base di un insieme di campi. Ad es. SOAP
supporta routing header-based dei suoi messaggi

Content-based: sulla base dell’intero contenuto. Maggiore
espressività, maggiori costi
Anche context+content-based routing, particolarmente adatto per
sistemi/servizi mobili, con filtri per eventi dipendenti da contesto
31
OMG Distributed Data Service (DDS)

Specifica OMG (non basata su CORBA né fortemente
interoperabile) per servizio distribuzione dati progettato
per sistemi real-time
Specifica definisce API per comunicazione
publish/subscribe cosiddetta data-centric, ovvero
middleware DDS fornisce astrazione di spazio globale di dati
accessibile a tutte applicazioni interessate

Utilizzo di combinazione di oggetti Topic e chiavi per
identificare in modo unico istanze all’interno di stream
di dati dello stesso topic
Supporto a content filtering e negoziazione qualità
Utilizzabile per propagazione distribuita di segnali, dati ed
eventi
CORBA Event Service (non data-centric e no supporto QoS);
CORBA Notification Service (filtri, QoS, ma obbligo utilizzo CDR e IIOP)
32
Content Subscription:
Partizioni DDS
Partizioni sono spazi di nomi che permettono di dividere logicamente
un dominio DDS
Publisher/Subscriber possono decidere a tempo di esecuzione (e non a
tempo di creazione come per JMS Topic) su quali partizioni
pubblicare/sottoscrivere i dati
Affinché un DataReader possa
ricevere i messaggi di un
DataWriter è necessario
condividere sia lo stesso
Topic sia la stessa partizione
Partizioni considerate come
una policy di QoS
33
Negoziazione QoS in DDS

Perché un Subscriber possa ricevere pubblicazioni di un
Publisher, proprietà di QoS devono essere compatibili
Protocollo di negoziazione Richiesta/Offerta
DataWriter
Publisher
DomainParticipant
Subscriber
Requested
Requested
Requested
Requested
Requested
Offered
QoS
QoS
QoS
QoS
QoS
QoS
Comunicazione non stabilita
QoS:Durability
QoS:Presentation
QoS:Deadline
QoS:Latency_Budget
QoS:Ownership
QoS:Liveliness
QoS:Reliability
QoS incompatibile
DataReader
DDS supporta diverse modalità di invio di messaggi (es. best-effort,
reliable) e consente alle entità di gestire persistenza informazioni
34
Qualità in Termini di Reliability
DDS prevede due politiche di QoS per l’affidabilità dei
messaggi:
BEST_EFFORT – NON garantito tutti messaggi siano ricevuti, né
l’ordine di consegna
RELIABLE – garantito tutti messaggi siano ricevuti e ordine di
consegna. Tramite Publisher che ri-inviano dati a Subscriber se
necessario e Subscriber che danno feedback (ack) alla ricezione

In caso reliable, tutti messaggi inviati sono mantenuti in coda di history
in attesa di essere confermati (lato publisher) e processati
dall’applicazione (lato subscriber); dimensione coda definibile mediante
policy di HISTORY
Possibile definire anche quante risorse (es. memoria, max istanze)
utilizzare per mantenimento dati mediante policy RESOURCE_LIMITS
35
Qualità in Termini di Durability

Mediante policy Durability è possibile definire se e quanti dati
mantenere lato publisher per poter essere richiesti
successivamente
DDS supporta tre tipi di persistenza:
¾ VOLATILE – No Instance History Saved
¾ TRANSIENT – History Saved in Local Memory
¾ PERSISTENT – History Saved in Permanent storage
DataWriter
Publisher
DomainParticipant
Permanent
Storage
Local
Memory
Durability=Persistent
Durability=Transient
36
Qualità DDS: Altre Policy
DDS supporta serie di altre policy per definire:
Ordinamenti ricezione dei messaggi (DESTINATION_ORDER e
PRESENTATION)
Priorità dei messaggi (LATENCY_BUDGED)
Esclusività su alcuni tipi di dato (OWNERSHIP)
Autenticazione e sicurezza dei dati (USER_DATA)
Vincoli temporali su rate invio dei messaggi
(TIME_BASED_FILTER)
Fault detection e heartbeat (LIVELINESS)
Per documentazione dettagliata, riferimenti utili:
¾
¾
Getting Started Guide
www.rti.com/eval/rtidds44d/RTI_DDS_GettingStarted.pdf
RTI DDS User’s Manual
www.dre.vanderbilt.edu/~mxiong/tmp/backup/RTI_DDS_UsersManual.pdf
37
Modello Java per Eventi Distribuiti
Anche Java ha un modello per distribuzione di eventi,
basato su RMI, per es. (soprattutto) utilizzato in Jini
Basato su Remote Event Listener (consumatore registrato
per ricevere certi tipi di eventi da certi oggetti, metodo notify())

Oggetto Remote Event come oggetto restituito in
notifica (dati, riferimento a oggetto sorgente, oggetto handback,
identificatore unico)

Meccanismo di lease
Specifica prevede possibilità di definire Distributed
Event Adaptor che realizzano filtri e politiche QoS
¾
Idea di sfruttare oggetto handback, fornito alla sorgente evento,
per passare stato e comportamento (ad es. per implementare
filtro per eventi)
38
package net.jini.core.event;
public class RemoteEvent {
public long getID();
public long getSequenceNumber();
public java.rmi.MarshalledObject getRegistrationObject();
}
Eventi in componenti locali possono trasferire anche stato oggetto
piuttosto complesso
Non nel distribuito: solo info su come consentire ritrovamento stato
Evento remoto come oggetto serializzabile trasferibile fra listener
Idea, “rubata” da sistemi Xt Intrinsics e Motif: registrare cliente
includendo handback, restituito con ogni evento
Ad es. un tassista Jini registra interesse in prenotazioni taxi mentre passa per
un’area (handback include locazione); quando riceve evento può essere
informato della vecchia locazione al momento della registrazione
Possibilità di registrare altri oggetti per notifica (delega): in questo caso
handback può servire come “reminder” con info di chi ha fatto subscription
(modello stock broker)
39
Registrazione eventi
Jini non specifica come registrare listener presso sorgenti di eventi; solo
specifica di utilizzo di una classe come valore ritorno dalla
sottoscrizione:
package net.jini.core.event;
import net.jini.core.lease.Lease;
public class EventRegistration implements java.io.Serializable {
public EventRegistration(long eventID, Object source,
Lease lease, long seqNum);
public long getID();
public Object getSource();
public Lease getLease();
public long getSequenceNumber();
}
Quindi programmatore della sorgente di eventi deve implementare:
public EventRegistration
addRemoteEventListener(RemoteEventListener listener);
40
Modello eventi Java locali prevede tutti oggetti nelo stesso spazio
indirizzamento
Jini come comunità di oggetti distribuiti e cooperanti tramite proxy
Per eventi remoti, rovesciamento direzione proxy

Ad es. cliente Jini usa proxy per accedere servizio e tramite esso si
registra come listener
¾
Serve un metodo del proxy per aggiungere event listener
Proxy chiamerà il “vero” metodo di aggiunta listener sulla risorsa
scoperta
Chiamata di registrazione evento locale al proxy; chiamata del proxy
di registrazione remota alla risorsa
Come se risorsa reale ottenesse un proxy per cliente da usare nella
catena di notifica

41
General Event
Notification Architecture (GENA)
Come già detto utilizzata
principalmente in UPnP
Control point è listener dei
cambiamenti di stato dispositivo
¾ 0 ottiene indirizzo
¾ 1 scopre dispositivo
¾ 2 trova descrittore XML
ottiene URL per eventing
¾ 4 si registra
Estrema semplicità:
Invio e ricezione notifiche tramite
HTTP su TCP/IP o multicast UDP
UPnP
UPnPvendor
vendor
UPnP
UPnPForum
Forum
UPnP
UPnPDevice
DeviceArchitecture
Architecture
HTTP
HTTP
TCP
TCP
IP
IP
GENA
GENA
GENA: Sottoscrizione
Control point si deve registrare prima di poter ricevere qualsiasi evento
SUBSCRIBE
SUBSCRIBEpublisher
publisherpath
pathHTTP/1.1
HTTP/1.1
HOST:
publisher
host:publisher
HOST: publisher host:publisherport
port
CALLBACK: <delivery URL>
NT: upnp:event
TIMEOUT: Second-requested subscription duration
Dispositivo accetta sottoscrizione: invia immediatamente un evento
speciale (iniziale) a control point con valori di tutte variabili di stato
HTTP/1.1
HTTP/1.1200
200OK
OK
SID:
uuid:subscription-UUID
SID: uuid:subscription-UUID
TIMEOUT:
TIMEOUT:Second-actual
Second-actualsubscription
subscriptionduration
duration
GENA: Notifiche
Quando una variabile di stato cambia valore presso dispositivo:
NOTIFY
NOTIFYdelivery
deliverypath
pathHTTP/1.1
HTTP/1.1
HOST:
delivery
host:delivery
HOST: delivery host:deliveryport
port
CONTENT-TYPE:
CONTENT-TYPE:text/xml
text/xml
NT: upnp:event
NTS: upnp:propchange
SID: uuid:subscription-UUID
SEQ: event key
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<variableName>new value</variableName>
</e:property>
Altri (eventuali) nomi di variabile e valori
</e:propertyset>
Really Simple Syndication (RSS)
e Atom
Anche se in forma molto semplificata, usiamo spesso
sistemi a eventi, tutte le volte che vogliamo rompere
classica interazione sincrona+bloccante clienteservitore
Come sapete, RSS come famiglia di specifiche per
information feed in XML da scambiare su Web.
Ampiamente utilizzato per blog, notizie, risorse audio/video
Anche questo è essenzialmente un sistema pub/sub;
molto semplice, solo si fa polling client-initiated di un
URL noto a priori; informazioni scambiate in XML
Numerosi Web browser supportano RSS; anche diversi
clienti applicativi specifici per RSS

Alternativa: Atom (RFC 4287 e RFC 5023), anche in questo
caso basato su HTTP e XML
45
SIP Event Framework
Notifiche asincrone sono essenziali per realizzare molti
servizi SIP (servizi automatici di callback, liste di amici in linea,
servizi di attesa messaggi, ...)
Per questo esiste SIP Event Framework (RFC 3265),
basato su metodi SUBSCRIBE e NOTIFY
Eventi SIP identificati da tre elementi: Request URI, tipo
evento e corpo messaggio (opzionale)

Esempio notevole di utilizzo: servizio di presenza, con
presentity e watcher
¾
¾
¾
Presence URI nella forma pres:paolo@domain
Problemi di scalabilità della soluzione
Servirebbero organizzazione gerarchica in domini e azioni di
aggregazione di eventi su località per ridurre numero di
notifiche
46
Web Services Event&Notification
Due meccanismi chiave per implementare pub/sub per Web
services: WS-Eventing e WS-Notification
(standardizzazione in 2006)

WS-Eventing come specifica di protocollo con cui Web
service devono effettuare/accettare registrazioni per
notifiche di eventi
¾
¾
¾

Meccanismi per creare/cancellare subscription
Definire expiration time, consentire rinnovo
Supporto a filtri (diversi linguaggi per definizione di filtri possono
essere utilizzati)
WS-Notification come specifica per consentire a Web
service di fare disseminazione di dati verso altri Web
service
¾
¾
Anche possibilità di organizzazioni articolate su interessi
(chiamati topic) e filtri basati su interessi
Topologie distribuite per broker di notifica
47
Web Services Event&Notification
Possibile subscription
di terze parti (diretta,
senza broker)
Più usuale subscription
tramite broker per
disaccoppiamento
48
Esempio di Programmazione
WS-Event&Notification
Ad es., come realizzare WS subscriber utilizzando IBM WebSphere:
Come al solito occorre ottenere WSDL file per servizi notification broker e
subscription manager (NotificationBroker.wsdl e SubscriptionManager.wsdl)
Se non già disponibili lato cliente, eseguire wsimport per generare client stub
Fare look up su notification broker (serve riferimento a servizio notification
broker)
Creare oggetto subscription request e configurare rif. a consumer
Creare oggetto subscribe per includere dettagli su sottoscrizione, come
riferimento a consumer per notifica
import org.oasis_open.docs.wsn.b_2.Subscribe;
import javax.xml.ws.wsaddressing.W3CEndpointReference;
import javax.xml.ws.wsaddressing.W3CEndpointReferenceBuilder;
// Crea oggetto subscription request. DEVE contenere
// ConsumerReference e PUO’ includere filtro, InitialTerminationTime
// e SubscriptionPolicy
Subscribe subscribeRequest = new Subscribe();
W3CEndpointReference consumerReference = new
W3CEndpointReferenceBuilder().address(consumerURI).build();
subscribeRequest.setConsumerReference(consumerReference);
49
Definizione di espressione topic come filtro per la registrazione
Possibile associare un oggetto Filter alla richiesta di registrazione per indicare
quali eventi sono di interesse (filtro basato su topic, contenuto messaggio o
entrambi). Ad es. filtro per topic (con classi helper IBM):
import com.ibm.websphere.sib.wsn.jaxb.base.FilterType;
import com.ibm.websphere.sib.wsn.jaxb.base.TopicExpressionType;
// Preparare espressione topic
topicExpression = topicNamespacePrefix + ":" + topicExpression;
TopicExpressionType topicExpressionType = new TopicExpressionType();
topicExpressionType.setExpression(topicExpression);
// Specificare mapping da prefisso namespace a topic namespace URI
topicExpressionType.addPrefixMapping(topicNamespacePrefix,
topicNamespace);
// Specificare dialect TopicExpression da utilizzare
topicExpressionType.setDialect(topicDialect);
// Creazione filtro
FilterType filter = new FilterType();
// Aggiunta espressione a filtro e configurazione richiesta
// subscribe con filtro
filter.addTopicExpression(topicExpressionType);
subscribeRequest.setFilter(filter);
50
Specifica di durata registrazione e invio richiesta
Due modalità per specificare expiration time di registrazione:
1) namespace URI e oggetti QName
2) factory di ausilio JAXB ObjectFactory
import javax.xml.bind.JAXBElement;
import javax.xml.datatype.DatatypeFactory;
import javax.xml.datatype.Duration;
// Opzione 1: Specifica durata (1 anno “P1Y” a partire da ora)
DatatypeFactory factory = DatatypeFactory.newInstance();
Duration duration = factory.newDuration(”1Y”; JAXBElement<String>
initialTerminationTime = new JAXBElement<String>(
new QName("http://docs.oasis-open.org/wsn/b-2",
"InitialTerminationTime"), String.class, duration.toString());
// Opzione 2:
org.oasis_open.docs.wsn.b_2.ObjectFactory objectFactory = new org.
oasis_open.docs.wsn.b_2.ObjectFactory();
initialTerminationTime = objectFactory.createSubscribeInitialTerminationTime(duration.toString());
subscribeRequest.setInitialTerminationTime(initialTerminationTime);
org.oasis_open.docs.wsn.b_2.SubscribeResponse
subscribeResponse = port.subscribe(subscribeRequest);
51