download tesi - MobiLab

More documents

Recommendations

Info

Analisi delle prestazioni delle principali soluzioni per servizi publish/subscribe Capitolo 2 - Le principali architetture Publish/Subscribe 2.1 Middleware Publish/Subscribe DDS L‟OMG (Object Management Service) ha redatto uno standard per la comunicazione publish/subscribe che contenga un forte supporto alla qualità del servizio. Tale standard prende il nome di Data Distribution Service for Real Time System (DDS). Lo standard OMG non prevede specifiche riguardanti l‟integrazione tra i diversi prodotti software, quindi non è possibile attualmente avere interoperabilità tra le varie implementazioni del DDS. Per sopperire a tale mancanza si sta lavorando per redigere uno standard di interoperabilità tra diverse implementazioni. L‟obbiettivo del DDS è di agevolare la distribuzione efficiente dei dati in sistemi distribuiti, ed ha come oggetto i sistemi real- time; per tale motivo è stata sviluppata un‟architettura completamente decentralizzata e sono state previste un ricco insieme di qualità del servizio che consentono di bilanciare l‟efficienza e le prestazioni del software. La specifica del DDS è basata sull‟astrazione di un Global Data Space GDS, in cui i publisher producono dati ed i subscriber consumano dati, tale spazio può essere caratterizzato dal concetto di topic, Publisher, Subscriber, Subscription e Quality of Service; Quality of Service: con le QoS si indica un concetto generale, utilizzato per specificare il comportamento del servizio fornito. Con le QoS il protocollo spiega “cosa” ci si può attendere da una applicazione e non il “come” si ottiene [2] [3]. Topic: definisce un tipo di dato che può essere scritto nel GDS. Il DDS fornisce anche la capacità di distinguere topic di uno stesso tipo tramite l‟uso di semplici chiavi. Ad ogni topic si possono associare specifiche qualità del servizio (QoS). Da un punto di vista applicativo i topic sono utilizzati per definire l‟Application Information Model, cioè il tipo di informazioni scambiate nel modello. Il DDS fornisce inoltre le capacità per eseguire semplici aggregazioni di topic, ed il content- based filtering [2] [3]; 26
Analisi delle prestazioni delle principali soluzioni per servizi publish/subscribe Publisher: definisce una sorgente dati, può dichiarare l‟interesse di generare dati con determinate caratteristiche di qualità del servizio associate e scrivere il dato nel GDS. Le qualità definite devono essere compatibili con quelle dichiarate dal topic di interesse [2] [3] Subscriber: leggono topic in GDS, per i quali esiste una sottoscrizione correlata. Il DDS conta su uno specifico DataReade che serve come tipo letto dal GDS. Il Subscriber incapsula la responsabilità associate alla ricezione dei dati in accordo alle QoS richieste [2] [3]. Subscription: operazione logica che consente di legare insieme un subscriber ai publish interessati. La sottoscrizione deve soddisfare due tipi di condizioni. Un tipo di condizioni sono relative alle caratteristiche concrete del topic, come tipo, nome del contenuto. L‟altro insieme di condizioni sono relative alle QoS. Per le QoS si segue un modello di richiesta/offerta, nel quale le QoS richieste devono essere le stesse o più deboli di quelle offerte [2] [3]. Una caratteristica chiave alla base del DDS è il servizio di discovery. Tale servizio ha il compito di scoprire e comunicare le proprietà dei partecipanti al GDS. Infatti le informazioni necessarie per stabilire una sottoscrizione sono completamente distribuite e vengono scoperte automaticamente. 2.2 Qualità del servizio nei Middleware DDS Il DDS implementa un insieme molto ricco di Quality Of Service. Risorse: queste QoS consentono di controllare le risorse usate nella disseminazione dati, le più rilevanti politiche che consentono di controllare le risorse di calcolo e le risorse di rete sono la RESOURCE LIMITY e la TIME BASED FILTERED. La RESOURCE LIMITY permette di controllare la quantità di messaggi memorizzati in una implementazione del DDS. La TIME BASED FILTERED permette alle applicazioni di specificare l‟intervallo temporale minimo tra due messaggi di dato; i messaggi prodotti ad una velocità maggiore non sono consegnati [2] [3]. 27
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 25: 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?