Invocazioni Remote: i moderni middleware, con la nascita della programmazione a oggetti distribuiti, devono permettere l’invocazione remota di processi e metodi per garantire un’interazione efficiente tra le applicazioni, l’invocatio remote consente cio;
Garanzia della Location Transparency: gli applicativi che costituiscono il sistema distri-buito devono poter comunicare senza preoccuparsi della loro posizione fisica n´e dei loro indirizzi logici, sar`a il Middleware Layer a occuparsi dei dettagli di basso livello;
Totale trasparenza di utilizzo per l’utente finale: l’utente dell’applicazione programma-ta col supporto middleware non deve “accorgersi” della presenza dello stesso e quindi non deve occuparsi di coordinarne il funzionamento dello stesso, in quanto sar`a del tutto integrato nel codice dell’applicazione;
Un Middleware pu`o essere catalogato in base ai servizi offerti, in base a tale principio si ha la seguente classificazione:
RPC-based system: rappresenta la forma pi`u semplice di middleware, prevede le infrastrut-ture necessarie per effettuare le RPC2
in modo trasparente al programma, ed in modo uniforme rispetto ai protocolli sottostanti;
TP Monitor: i middleware di questo tipo sono in grado di supportare transactional RPC cio´e transazioni distribuite con propriet`a ACIDE con dati distribuiti su pi`u sistemi eterogenei;
Object-Broker: estendono il paradigma RPC nel mondo object-oriented, con l’aggiunt`a di nu-merosi servizi che semplificano lo sviluppo di applicazioni distribuite Object-Oriented. In questo modello si ha l’introduzione di concetti come eredit`a e polimorfismo. Uno standard specitico per tale applicazione `e CORBA (Common Object Request Broker Architecture) [1];
Object monitor: nasce dall’unione di due tipi di middleware il TP Monitoe e l’Object Broker, questo prodotto nasce a causa di esigenze di mercato, infatti non si ha l’introduzione di innovazioni;
Message-oriented: (MOM) sono middleware in grado di supportare l’interoperabilit`a message-based, basata su scambio di messaggi. Per messaggio si intende un insieme di dati strut-turati, caratterizzati da un tipo ed un’insieme di parametri del messaggio. Una delle pi`u importati astrazioni generate `e quella di MESSAGE QUEUING. Un esempio di tale implementazione `e il JMS (Java Message Sistem) [3]. La limitazione principale di questo middleware `e l’indirizzamento punto-punto;
Message-brokers: questo middleware supera i limiti del MOM eliminando lo schema di in-dirizzamento punto-punto ma spostando l’inin-dirizzamento al contenuto dei messaggi. Il paradigma pi`u noto `e il Publish/Subscribe;
Nella Fig. 2.2 viene rappresentata la genealogia dei middleware appena descritti.
2
Figura 2.2: Genealogia del Middleware.
2.2 DDS
L’obbiettivo del DDS `e di agevolare la distribuzione efficiente dei dati in sistemi distribuiti, e ha come oggetto i sistemi real-time; per tale motivo `e stata sviluppata un’architettura com-pletamente decentralizzata ed sono state previsto un ricco insieme di qualit`a del servizio che consentono di bilanciare l’efficienza e le prestazioni del software.
Ia specifica del DDS `e basata sull’astrazione di un Global Data Space GDS, in cui i publisher producono dati ed i subscriber consumano dati, tale spazio pu`o 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 servzio fornito. Infatti con le QoS il protocollo spiega “cosa” ci si puo attendere da una applicazione e non il “come” si ottiene. La QoS caratterizza il DDS dagli altri midleware Pub/Sub, in quanto fornisce un’ampia ricchezza di QoS supportate. Per implementare tali caratteristiche il DDS prevede la capacit`a di controllare e limitare l’uso di risorse come la memoria, la banda di rete, e molte propriet`a non funzionali dei topic.
Topic: definisce un tipo di dato che pu`o essere scritto nel GDS. Nello standard attuale devono essere utilizzati dei tipi non ricorsivi e devono essere definiti tramite l’OMG IDL ,Interface Definition Languafe. Il DDS fornisce anche la capacit`a di distinguere topic di uno stesso
2.2. DDS 21
tipo tramite l’uso di semplici chiavi. Ad ogni topic si possono associare specifiche qualit`a del servizio (QoS). Da un punto di vista applicativo i topic sono utilizzati per definire l’Application Information Model, cio´e il tipo di informazioni scambiate nel modello. Il DDS fornisce inoltre le capacit`a per eseguire semplici aggregazioni di topic, ed il content-based filtering;
Publisher: definisce una sorgente dati, pu`o dichiarare l’interesse di generare dati con determi-nate caratteristiche di qualit`a del servizio associate e scrivere il dato nel GDS. Le qualit`a definite devono essere compatibili con quelle dichiarate dal topic di interesse. In figura 2.4 si pu`o notare come il DDS si affidi ad una specifica di topic inglobata in DataWriter, la quale definisce un tipo scritto nel GDS; il publisher incapsula la responsabilit`a legata alla disseminazione dei dati in accordo con le QoS richieste;
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`a associate alla ricezione dei dati in accordo alle QoS richieste.
Subscription: operazione logica che consente di legare insieme un subscriber ai publish inte-ressati. La sottoscrizione deve soddisfare due tipi di condizioni. Un tipo di condizioni sono relative alle caratteristiche concrete del topic, come tipo, nome del contenuto e . 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`u deboli di quelle offerte. Il DDS prevede uno schema di sottoscrizione pi`u generale del tipico Topic-Based Model, lo schema consente una sottoscrizione Content-Based. Per specificare il filtro della sottoscrizione si utilizza un sottoinsieme di Struct Query Language SQL.
Una caratteristica chiave alla base del DDS `e il servizio di discovery. Tale servizio ha il compito di scoprire e comunicare le propriet`a dei partecipanti al GDS. Infatti le informazioni necessarie per stabilire una sottoscrizione sono completamente distribuite e vengono scoperte automaticamente.
2.2.1 QoS
Il DDS implementa un insieme molto ricco di QoS, ora fornir`o una breve panoramica delle QoS pi`u interessanti, tali caratteristiche vengono catalogate in base all’aspetto che permettono di controllare.
Risorse: queste QoS consentono di controllare le risorse usate nella disseminazione dati, le pi`u 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`a di messagi memorizati in una implementazione del DDS. La TIME BASED FILTERED permette alle applicazioni di specificare l’intervallo temporale minimo tra due messagi di dato; i messagi prodotti ad una velocita maggiore non sono consegnati. Questa politica consente di controllare la larghezza di banda utilizata nella connessione, memoria e potenza di calcolo dei subscriber connessi, i quali possono avere una limitat`a capacita di calcolo.
Data Timeliness: il DDS prevede un insieme di politiche che consentono di controllare la propriet`a di timeliness della distribuzione dati. Le QoS supportate sono DEADLINE e LATENCY BUDGET. La DEADLINE permette ad una applicazione di definire il massi-mo 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 comu-nicato. In particolare specifica il massimo ammontare di tempo che dovrebbe trascorrere dall’istante in cui il dato `e scritto, all’istante in cui viene posto nella coda di ricezione del ricevente.
Data Availability: per controllare la data availability posso usare le politiche di , LIFESPAN e HISTORY. La DURABILITY fornisce un controllo sul tempo di vit`a 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 `e considerato valido, il valore di default `e infinito. La HISTORY fornisce un modo per controllare il numero di dati, cio´e 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.
Data Delivery: permette di controllare come il dato `e consegnato, ed a chi `e consentito scri-vere 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 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`o 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 `e posseduto da colui che ha un valore di owneship strength pi`u alto. Un valore di OWNERSHIP STRENGTH `e shared, con questo valore si possono avere pi`u scrittori che sovrascrivono un topic. I vari cambiamenti devono essere ordinati in accordo al valore settato nella politica di DESTINATION ORDER.
Oltre alle politiche appena definite il DDS fornisce alcuni modi per definire e distribuire infor-mazioni di bootstrapping, tramite il significato di USER DATA, TOPIC DATA e GROUP DATA.
La USER DATA permette all’aplicazione di associare informazioni aggiuntive all’oggetto entit`a creato, tale informazione pu`o 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`o essere prelevata da applicazioni remote.
Il GROUP DATA associa informazioni aggiuntive al Publisher e Subscriber creati, tale va-lore `e disponibile alle applicazioni nelle entita DataReader e DataWriter, tale vava-lore viene propagato tramite il topic creato.
Un’altra politica di QoS prevista `e la LIVELINESS, la quale consente di settare i parametri utilizzati nella determinazione di entita considerate “vive”. Questa politica ha molti settaggi per consentire una modellazione pi`u 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`a richiede poco overheard. Il settagio MANUAL consente di determinare fallimenti logici, richiede l’esecuzione dell’operzione di ASSERT-LIVENESS.
2.2. DDS 23
La politica di PARTITION consente l’introduzione di una partizione logica nella partizione fisica indotta dal dominio, questa partizione non crea un vero isolamento tra i partecipanti come un dominio. Questa policy pu`o essere modificata, ci`o causa una modifica delle relazioni esistente tra i DataReader ed i DataWriter del dominio, creando nuove relazioni o rompendo relazioni esistenti.
2.2.2 Architettura
La specifica del DDS definisce due livelli di interface, il DCPS (Data Centric Publish-Subscribe) ed il DLRL (Data Local Reconstruct Layer ).
DCPS: Prevede le funzionalit`a richieste per pubblicare e ricevere data-object, in modo effi-ciente;
DLRL: Livello opzionale che permette una semplice integrazione di servizi al livello applicativo;
Di seguito effettuer`o un analisi del DCPS.
Il DCPS deve essere altamente competivo ed efficiente nell’uso delle risorse. Per tale mo-tivo `e importante che le interfacce siano progettate in modo da consentire al middleware di pre-assegnare le risorse, evitare l’uso di risorse illimitate o difficili da predire, minimizzare la necessit`a di fare copie di dati. Le interfacce definite hanno il vantaggio di essere semplici da usare, sicure ed efficienti.
Le funzionalit`a del DCPS sono:
- Identificazione dei dati che un publisher intende pubblicare e tipi di valori previsti per tali dati;
- Identificazione dei dati di interesse per un subscriber e come accedere a tali dati;
- Applicazioni per definire topic, per associare vari tipi di dato al topic, per creare publisher e subscriber e per associare caratteristiche di QoS a tali entit`a.
Per descrivere un DCPS si usano due specifiche, il PIM Platform Independent Model ed il PSM Platform Specific Model per le piattaforme basate su PIM; Noi ora analizzeremo il PIM. Nel DCPS la comunicazione `e effettuata con l’aiuto delle seguenti entit`a: DomainPar-ticipant, DataWriter, DataReader, Publisher, Subscriber e topic. Lo schema con-cettuale del DCPS viene rappresentato in figure 2.3, nel quale viene rappresentato il flusso dell’informazione tra le varie entit`a.
Il Publisher ed il DataWriter risiedono nel mittente, mentre Subscriber ed Data Rea-der risiedono nel ricevente. Un Publisher `e responsabile della distribuzione dei dati, egli pu`o publicare dati di diverso tipo. Un DataWriter `e l’oggetto dell’applicazione usato dal publi-sher per comunicare l’esistenza di una nuova istanza di dato per uno specifico tipo di dato, ed `e associato ad un singolo tipo di dato. Una volta comunicata l’esistenza di un nuovo dato o un cambiamento con DataWriter(s) `e compito del Publisher determinare quando `e appropriato generare il messagio corrispondente ed eseguire realmente la pubblicazione. Tutto ci`o dovra essere fatto in accordo alle QoS associate al Publisher ed al DataWriter corrispondente.
Un Subscriber `e l’oggetto responsabile della ricezione di dati pubblicati, e della fornitura di tale dato alle applicazioni interessate, si possono ricevere vari tipi di dati, rispettando le QoS richieste. Per accedere ai dati ricevuti l’applicazione usa il modulo DataReader collegato alla sottoscrizione del dato, con tale modulo si esprime l’interesse dell’applicazione nei confronti dei dati relativi al DataReader.
Figura 2.3: Schema concettuale del DCPS.
Il Topic `e un oggetto concettuale che si interpone tra le publicazioni (oggetti DataWriter ) e le sottoscrizioni (oggetti DataReader ), con l’obbiettivo di crere un’associazione tra un nome (unico nel sistema), un tipo di dato e le QoS associate al dato stesso. La definizione del tipo di dato deve fornire le informazioni necessarie per il servizio di gestione dei dati, come serializza-zione e deserializzaserializza-zione del dato in/da uno adatto alla trasmissione. La definiserializza-zione pu`o essere fatta per mezzo di un linguaggio testuale oppure per mezzo di un “plugin” operazionale che fornisce i metodi necessari. Il DCPS pu`o anche supportare sottoscrizioni CONTENT-BASED con l’uso di un filtro, questa `e una caratteristica opzionale, in quanto il filtro pu`o essere com-putazionalmente intensivo e quindi introdurre un ritardo difficile da predire; comunque recenti ricerche hanno dimostrato che esistono efficienti algoritmi per affrontare questo problema. Il DDS differisce dai sistemi publisher/subscriber “enterprise”, come il sistema Rendezvous, nel binding tra topic e tipi di dato, in quanto il topic `e pi`u di una etichetta, ma tale disaccoppia-mento presente nel DDS permette di associare delle aggiuntive QoS, di effettuare ottimizzazioni come la pre-allocazione delle risorse necessarie al topic.
Il modello concettuale del DCPS viene rappresentato in figua 2.4. Nel modello si nota che tutte le classi appena analizzate estendono il DCPSEntity, ogni specializzazione ha una corrispondente specifica Listener ed un insieme di valori di QoS specifici.
Nel modello concettuale troviamo anche le QoSPolicy, Listener, DomainParticipant e StatusCondition.
Le QoSPolicy costituiscono l’insieme delle propriet`a di QoS previste, viene previsto un meccanismo generale che permette alle applicazioni di controllare i servizi e modellarli per le loro necessit`a. Ogni Entity supporta specifici tipi di QoS.
Il Listener prevede un meccanismo generico che consente al middleware di informare l’ap-plicazione dell’accadimento di eventi asincroni importanti, come l’arrivo di un dato o la viola-zione di una specifica propriet`a di QoS. Dalla figura si evince che `e stata effettuata la sceta di
2.2. DDS 25
associare un solo listener ad una entity.
Lo Status Condition prevede un supporto per le comunicazioni tra middleware ed appli-cazione, rispettando le propriet`a di ReadCondition specificate.
Con il concetto di dominio si indica un canale concettuale che collega tutte le applicazioni che possono comunicare tra loro, solo i publisher ed i subscriber associati ad uno stesso do-minio possono comunicare tra loro. Il Domain Participant, rappresenta il membro locale dell’applicazione in un dominio e vi sono associate le entit`a descritte sopra.
Il modello concettuale viene implementato con cinque moduli, che sono: Infrastructure Module, Domain Module, Topic-definition Module, Publication Module, Subscription Module. In fig. 2.5 sono raffigurati i moduli e le loro relazioni.
Figura 2.5: Moduli DCPS.
Infrastructure Module: Definisce le classi astratte e le interfacce che sono poi definite da-gli altri moduli, prevede un supporto per due stili di interazioni con il middleware che sono notification e wait-based. Contiene le classi DCPSEntity, QosPolicy, Listener, Condition, WaitSet;
Domain Module: Contiene la classe Domain Participant, che svolge il ruolo di punto d’ac-cesso al servizio;
Topic Definition Module: Contiene tutte le classi necessarie per definire un Topic, e per associarli delle caratteristiche di QoS; in particolare contiene le classi Topic, TopicLi-stener;
Publication Module: Contiene le classi di Publisher, DataWriter, le interfacce di Publisher-Listener e DataWriterPublisher-Listener, cio´e tutto cio che `e necessario per creare ed usare un publisher;