Osservazioni rilevanti

Nel seguito di questa sezione riassumiamo le principali osservazioni emerse dalla sequenza di esperimenti e dalla implementazione del prototipo di IRL.

Esperimenti. Gli esperimenti dimostrano principalmente la fattibilit`a dell’ap-proccio a tre livelli per la replicazione.

In particolare, l’Esperimento 1 conferma che IRL `e scalabile rispetto al numero di membri dell’object group, visto che la degradazione del throughput dovuta al-l’introduzione di un nuovo membro `e piccola. Questa diminuzione `e dovuta prin-cipalmente al modo in cui l’OGH esegue il multicast dei messaggi verso i membri, che per adesso consiste di un insieme di invocazioni one way eseguite

sequen-zialmente. Questa implementazione pu`o essere ulteriormente migliorata. Inoltre

l’intero prototipo pu`o essere migliorato implementando opportune ottimizzazioni, per cui in generale la latenza, il throughput e la stabilit`a del throughput stesso possono essere sostanzialmente migliorate.

L’Esperimento 2 mostra che la scalabilit`a di IRL rispetto al numero di repliche OGH dipende strettamente dalla scalabilit`a del group toolkit utilizzato per im-plementare il modulo Sequencer del componente OGH. La scalabilit`a e la sta-bilit`a del group toolkit dipendono dal comportamento del sistema sottostante. In questo senso si manifesta l’importanza di distribuire il middle-tier di IRL in un sistema parzialmente sincrono, il cui comportamento sia stabile e predicibile per la maggior parte del tempo.

Per quanto riguarda la scalabilit`a nel numero di client, l’Esperimento 3 mostra che le prestazioni di IRL migliorano se le richieste dei client sono uniformemente distribuite su tutte le repliche OGH disponibili (approccio active), e che l’aumento del numero di repliche OGH permette di scalare nel numero di client.

Considerando le prestazioni globali di IRL, `e facile vedere che la prima con-seguenza della scelta di progettare il sistema “sopra l’ORB” consiste nell’aver legato le prestazioni di IRL alla scalabilit`a e all’efficienza della piattaforma ORB sottostante. Questo potrebbe risultare eccessivamente dispendioso per alcune applicazioni, soprattutto quando si emula un multicast tramite un insieme di in-vocazioni IIOP, come nel caso del prototipo attuale di IRL. Tuttavia questo tipo di design consente di ottenere interoperabilit`a. Notiamo inoltre che eventuali

miglioramenti alla piattaforma ORB sottostante si riflettono trasparentemente in miglioramenti nelle prestazioni di IRL, cos`ı come nuovi servizi standard, come ad esempio il recente Unreliable Multicast Specification [Obj01b], possono essere facilmente inseriti in IRL per ottenere migliori prestazioni.

Sviluppo del prototipo. Lo sviluppo del prototipo ci ha permesso di speri-mentare alcune caratteristiche di CORBA. Prima di tutto, gli esperimenti sul-la replicazione stateless mostrano che i Portable Interceptor rappresentano uno strumento efficiente per emulare la semantica di invocazione di FT-CORBA sen-za impattare sul codice dell’ORB. Una seconda considerazione riguarda le op-erazioni one way e di callback utilizzate nel prototipo attuale per eseguire il multicast delle richieste dall’OGH ai membri dell’object group e per consentire al loro IRGW di restituire un risultato all’OGH. Come detto nella Sezione 5.3.3, le invocazioni one way hanno semplificato la progettazione dell’IRGW e del modulo MemberHandler dell’OGH. Tuttavia, l’uso di invocazioni one way comporta un peggioramento delle prestazioni se confrontato con le invocazioni sincrone. Ci`o `e dovuto al fatto che, usando le interfacce di callback, si hanno due oggetti COR-BA che interagiscono come server CORCOR-BA, per cui tutti i messaggi scambiati devono attraversare lo stack composto dall’ORB, l’object adapter e l’implemen-tazione dell’oggetto (vedi Sezione 5.1.1). Al contrario, quando interagiscono un client ed un oggetto CORBA, solo i messaggi inviati dal client devono attraver-sare questo stack, mentre i risultati ricevuti dall’ORB del client vengono passati subito all’applicazione.

5.5 Discussione

In questa sezione ci concentriamo sulle caratteristiche principali di IRL.

IRL come una architettura a tre livelli per la replicazione software. Come infrastruttura a tre livelli per la replicazione software di oggetti CORBA stateful deterministici, IRL eredita tutti i vantaggi delle architetture a tre liv-elli descritti nella Sezione 3.2, per esempio il disaccoppiamento tra i client e le repliche, il disaccoppiamento tra la disponibilit`a del servizio e l’integrit`a dei dati, l’estendibilt`a del middle-tier, ecc. Inoltre IRL consente di isolare i requisiti di cop-ertura delle assunzioni di sincronia parziale necessari per ottenere alta affidabilit`a di un servizio replicato con garanzie di consistenza forte. Infatti solo i compo-nenti del middle-tier di IRL, ossia OGH, FN e RM, devono essere distribuiti in un sistema parzialmente sincrono. Ci`o consente di distribuire i client e i membri degli object group in WAN.

5.5. DISCUSSIONE 95

Interoperabilit`a e portabilit`a. IRL `e portabile su differenti ORB forniti da diversi vendor. La portabilit`a `e ottenuta sfruttando solo i meccanismi standard di CORBA, come Static e Dynamic Skeleton Interface, Static e Dynamic Invocation Interface, Portable Interceptor, ecc. Questo consente di trasferire il codice di IRL su piattaforme CORBA differenti con uno sforzo minimo.

Per quanto riguarda l’interoperabilit`a, `e importante notare che in IRL le co-municazioni tra i client, i componenti del middle-tier e i membri degli object group avvengono tramite invocazioni CORBA standard. Solo le repliche dei com-ponenti che appartengono al middle-tier di IRL sono accoppiate da invocazioni non-CORBA. Di conseguenza, IRL supporta object group distribuiti su ORB eterogenei, rimediando alla limitazione di FT-CORBA.

Il prezzo da pagare per l’interoperabilit`a `e legato alle prestazioni, che risultano estremamente ridotte se confrontate con altri sistemi che sfruttano tecniche pi`u efficienti. D’altra parte, se l’interesse principale riguarda l’integrazione, l’inter-operabilit`a pu`o semplificare il compito di integrare oggetti distribuiti in ambienti eterogenei, rendendoli altamente affidabili [MVB03, MVBM01].

Supporto per legacy ORB. L’Outgoing Request GateWay consente ai client distribuiti su ORB non conformi alla specifica FT-CORBA di beneficiare della trasparenza alla replicazione e ai guasti durante l’interazione con object group stateful gestiti da una infrastruttura FT-CORBA. Quindi IRL supera la limi-tazione imposta dalla specifica FT-CORBA relativa ai legacy ORB.

Capitolo 6

Conclusioni

Questo capitolo riassume il contributo di questa dissertazione e mette in luce alcuni aspetti che saranno oggetto di ulteriore ricerca in futuro.

6.1 Contributi

I principali contributi di questa dissertazione riguardano la classificazione e l’anal-isi delle prestazioni di alcuni group toolkit rispetto al servizio di total order mul-ticast da essi offerto, finalizzata all’implementazione e all’analisi prestazionale dell’infrastruttura software Interoperable Replication Logic per la replicazione trasparente di oggetti CORBA.

Il total order multicast nei group toolkit. La specifica del servizio di to-tal order multicast pu`o essere data in vari modi, ciascuno dei quali pu`o dare adito al verificarsi di un certo insieme di problemi. Una stessa specifica pu`o in-oltre essere implementata utilizzando protocolli diversi, ciascuno dei quali pu`o presentare prestazioni diverse a seconda del contesto in cui viene utilizzato. Gli sviluppatori di group toolkit spesso non forniscono una descrizione dettagliata in termini di specifica e implementazione dei servizi offerti. Ci`o vale in particolare per il servizio di total order multicast. Tuttavia conoscere questi aspetti `e molto importante per coloro che intendono utilizzare il group toolkit per lo sviluppo delle proprie applicazioni, poich´e l’adozione di una specifica piuttosto che un’al-tra pu`o violare alcuni dei requisiti di consistenza su cui si basa l’applicazione. Allo stesso modo, una specifica troppo forte o un protocollo poco adatto possono influire negativamente sulle prestazioni. In questa dissertazione abbiamo chiarito gli aspetti legati alla specifica del total order multicast, fornendo una gerarchia di specifiche e mostrando l’insieme dei problemi legati a ciascuna di esse. Inoltre abbiamo effettuato una classificazione di alcuni group toolkit sulla base delle loro

caratteristiche architetturali e del servizio di total order multicast offerto. Sulla base di questa classificazione, `e stata poi effettuata una analisi delle prestazioni di questi group toolkit. Questa classificazione e analisi rappresentano un vali-do supporto a coloro che intenvali-dono utilizzare un group toolkit per lo sviluppo delle proprie applicazioni, facilitando la scelta del sistema pi`u appropriato per soddisfare i propri requisiti.

Interoperable Replication Logic (IRL). IRL `e una infrastruttura software che sfrutta la replicazione attiva a tre livelli per fornire replicazione trasparente di oggetti CORBA deterministici. Inoltre IRL `e conforme allo standard Fault Toler-ant CORBA, e ne supera alcune limitazioni. In particolare, IRL `e interoperabile, in quanto consente l’interazione tra oggetti replicati distribuiti su piattaforme eterogenee. Inoltre, sfruttando i Portable Interceptor, IRL consente ai client “legacy” di interagire con gli oggetti replicati beneficiando della trasparenza di replicazione e dei guasti. Per ottenere questi vantaggi, IRL evita di modificare l’ORB, sfruttando solo gli interceptor per ottenere trasparenza di replicazione per i client, e utilizza solo meccanismi CORBA standard, come DII/DSI e Interface Repository, per implementare l’infrastruttura, basando l’interazione tra i client, gli object group e il middle-tier solo sul protocollo IIOP. Nella dissertazione `e sta-to presentasta-to un prosta-totipo di IRL che implementa il prosta-tocollo per la replicazione attiva a tre livelli definito in [Mar02], ed `e stata presentata inoltre una accurata analisi delle sue prestazioni. I risultati sperimentali mostrano che l’approccio a tre livelli per la replicazione software `e realizzabile e conferma le propriet`a di scalabilit`a del protocollo analizzato.

6.2 Sviluppi futuri

Gli scenari adottati per gli esperimenti dei group toolkit non contemplano la presenza di guasti. Inoltre pu`o essere importante valutare l’efficienza dei group toolkit anche rispetto ad altri servizi come il fifo e il causal multicast. Per questo motivo abbiamo pianificato ulteriori test per studiare il comportamento dei group toolkit anche rispetto a questi servizi e scenari.

Per quanto concerne il prototipo di IRL, esso manca attualmente delle seguenti funzionalit`a.

• Supporto per membership controllata dall’infrastruttura. Il

pro-totipo non `e in grado di mantenere un numero minimo di repliche dell’OGH e di membri di un object group. In altre parole, l’infrastruttura non gestisce