DDS 
DDS (Distributed Data Service for Real-Time Systems) è un'architettura standard per sistemi ad oggetti distribuiti basata sul paradigma di comunicazione publish - and - subscribe. DDS fornisce uno spazio dati globale che è accessibile a tutte le applicazioni interessate. In questo spazio le subscriptions sono disaccoppiate dalle publications; i contratti sono stabiliti tramite QoS (politiche Quality of Service); la scoperta e la configurazione sono automatiche.
Vediamo le
caratteristiche principali di DDS: si basa, come detto, su un semplice paradigma di comunicazione
publish - and - subscribe che è un paradigma dello scambio di messaggi asincrono in cui i mittenti (publishers) non sono programmati per inviare messaggi aspecifici destinatari (subscribers), ma i messaggi sono caratterizzati da classi e i subscribers esprimono interesse per una o più di queste classi e ricevono solo i messaggi di loro interesse senza sapere chi sono i publishers; utilizza la banda in un modo efficiente con basso overhead; supporta comunicazioni uno - a - uno; uno - a - molti; molti a - uno; molti - a - molti; è un'architettura flessibile e adattabile che supporta l' "auto - discovery" di nuove applicazioni; è scalabile dinamicamente; ha un grande numero di parametri di configurazione che consentono un controllo completo di ogni messaggio nel sistema e del livello di comunicazione.
La base del middleware DDS è
DCPS (Data Centric Publish - and - Subscribe) che consente ad un'applicazione di scambiare dati con altre applicazioni DDS - enabled in accordo alle politiche di QoS designate. Sopra ad esso, nell'architettura, troviamo
DLRL (Data Local Reconstruction Layer) che definisce come creare un oggetto locale in modo tale che le applicazioni possano accedere ai dati come se essi fossero in locale. DDS specifica solo le interfacce tra le applicazioni e i suoi servizi; non indirizza protocolli e tecniche per differenti attori implementano i suoi servizi e non indirizza alla gestione delle sue risorse interne.
Figura 1
Domini e partecipanti ai domini: il dominio è il costrutto di base usato per legare applicazioni individuali insieme sulla base dei tipi di dati scambiati. Un partecipante ad un dominio può simultaneamente effettuare il publishing e il subscribing di flussi di dati.
Figura 2: ci sono 4 nodi, ognuno dei quali comprende uno o due partecipanti ai due domini indicati
Un'applicazione publisher ha un access point chiamato data writer, mentre un'applicazione subscriber ha un access point chiamato data reader. Un
data writer è il principale access point che un applicazioni utilizzate per effettuare il publishing di dati in un dominio DDS; un publisher è infatti un contenitore che raggruppa insieme più singoli data writers. Un'applicazione utente deve associare i data writers ai topics, configurare QoS e fornire i dati ai data writers. Un
data reader è il principale access point che un'applicazione utilizza per accedere ai dati ricevuti. Un subscriber è infatti usato come contenitore per raggruppare insieme più singoli data readers. Un'applicazione utente deve associare i data readers ai topics; configurare QoS e ricevere i dati dai data readers.
Figura 3
Pagine totali: 3 - 1 2 3
Inserisci un commento
(solo il nome è obbligatorio; tutti gli altri campi sono facoltativi)
Pagine di commenti: 0
