download tesi - MobiLab

More documents

Recommendations

Info

Analisi delle prestazioni delle principali soluzioni per servizi publish/subscribe Data Timeliness: il DDS prevede un insieme di politiche che consentono di controllare la proprietà di timeliness della distribuzione dati. Le QoS supportate sono DEADLINE e LATENCY BUDGET. La DEADLINE permette ad una applicazione di definire il massimo intervallo di tempo tra i dati; se trascorre tale intervallo senza l‟arrivo di un messaggio viene effettuata una notifica tramite LISTENER. Il LATENCY BUDGET consente ad una applicazione di fornire al middleware il livello d‟urgenza associato ad un dato comunicato, specifica il massimo ammontare di tempo che dovrebbe trascorrere dall‟istante in cui il dato è scritto, all‟istante in cui viene posto nella coda di ricezione del ricevente [2] [3]. Data Availability: per controllare la data availability posso usare le politiche di, LIFESPAN e HISTORY. La DURABILITY fornisce un controllo sul tempo di vita di un dato scritto nel GDS. Questa caratteristica consente al dato di essere volatile e dall‟altro permette al dato di avere persistenza. E utile notare che dati transienti e persistenti consentono di fare Time Decoupling tra lo scrittore ed il lettore; rendendo il dato disponibile per i successivi lettori inscritti, nel caso di dati transienti oppure dopo che lo scrittore ha lasciato il GDS, nel caso di dati persistenti. Il LIFESPAN permette di controllare l‟intervallo di tempo nel quale il dato è considerato valido, il valore di default è infinito. La HISTORY fornisce un modo per controllare il numero di dati, cioè la sottosequenza scritta nello stesso topic e tenuta disponibile per il lettore; i possibili valori attribuibili sono gli ultimi, gli ultimi N oppure tutti i samples [2] [3]. Data Delivery: permette di controllare come il dato è consegnato, ed a chi è consentito scrivere su uno specifico topic. Le politiche che si possono usare sono la RELIABILITY, DESTINATION ORDER e OWNERSHIP. La RELIABILITY permette di controllare il livello di reliability associato alla diffusione dati, le possibili scelte sono reliable e best-effort. La DESTINATION ORDER consente di definire l‟ordine dei cambiamenti eseguiti dal publisher sulla stessa istanza di un dato topic. Il DDS consente di ordinare i vari cambiamenti in accordo ai time-stamp della 28
Analisi delle prestazioni delle principali soluzioni per servizi publish/subscribe sorgente o della destinazione. La politica di OWNERSHIP consente di controllare il numero di scrittori permessi per un dato topic. Se configurato come esclusivo si indica che il topic può essere posseduto e quindi scritto da un singolo scrittore. E' possibile inoltre associare una nuova politica, detta OWNER-SHIP STRENGTH che consente di associare un valore numerico di forza ad ogni scrittore, in questo caso il topic è posseduto da colui che ha un valore di owneship strength più alto. Un valore di OWNERSHIP STRENGTH è shared, con questo valore si possono avere più scrittori che sovrascrivono un topic. I vari cambiamenti devono essere ordinati in accordo al valore settato nella politica di DESTINATION ORDER [2] [3]. Oltre alle politiche appena definite il DDS fornisce alcuni modi per definire e distribuire informazioni di bootstrapping, tramite il significato di USER DATA, TOPIC DATA e GROUP DATA. La USER DATA permette all‟applicazione di associare informazioni aggiuntive all‟oggetto entità creato, tale informazione può essere utilizzata dalle applicazioni remote per uno scopo apposito, ad esempio attribuire credenziali di sicurezza. Il TOPIC DATA consente di aggiungere informazioni aggiuntive ad un topic creato, tale informazione può essere prelevata da applicazioni remote. Il GROUP DATA associa informazioni aggiuntive al Publisher e Subscriber creati, tale valore è disponibile alle applicazioni nelle entità DataReader e DataWriter, tale valore viene propagato tramite il topic creato. Un‟altra politica di QoS prevista è la LIVELINESS, la quale consente di settare i parametri utilizzati nella determinazione di entità considerate “vive”. Questa politica ha molti settaggi per consentire una modellazione più consona per le possibili situazioni. Il settaggio AUTOMATIC consente di determinare i fallimenti al livello di processo ma non determina i fallimenti a livello logico di processo, questa modalità richiede poco overheard. Il settagio MANUAL consente di determinare fallimenti logici, richiede l‟esecuzione dell‟operazione di ASSERT-LIVENESS. 29
Page 1 and 2: Facoltà di Ingegneria Corso di Stu
Page 3 and 4: Indice Introduzione 8 Capitolo 1. I
Page 5 and 6: Indice delle figure Figura 1.1 Stru
Page 7 and 8: Indice delle tabelle Tabella 2.1 Qo
Page 9 and 10: Analisi delle prestazioni delle pri
Page 23 and 24: eciprocamente. Figura 1.6 Interazio
Page 27: Analisi delle prestazioni delle pri
Page 31 and 32: Figura 2.1 Schema concettuale del D
Page 53 and 54: Figura 2.10 Architettura TAO Analis
Page 65 and 66: Figura 2.16 Semantica AMQP. Analisi
Page 71 and 72: Affidabilità Analisi delle prestaz
Page 77 and 78: VOLATILE Analisi delle prestazioni
Page 79 and 80:
3.2 I Test Figura 3.1 Schema Cluste
Page 81 and 82:
Analisi delle prestazioni delle pri
Page 83 and 84:
Figura 3.3 Architettura decentraliz
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
3.6 Test CORBA TAO Analisi delle pr
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
3.8 Test OpenAMQ Analisi delle pres
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Conclusioni e Sviluppi Futuri Anali
Page 131 and 132:
Ringraziamenti Analisi delle presta
Page 133 and 134:
Page 135 and 136:
Bibliografia Analisi delle prestazi
Page 137 and 138:
show all

download tesi - MobiLab

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?