2. l’approccio di intercettazione (Interception Approach) consiste nell’in-tercettare i messaggi diretti all’ORB e nel multiplexarli verso gli oggetti di un gruppo facendo solitamente uso di un group communication toolkit proprietario;
3. l’approccio di servizio (Service Approach) consiste nel fornire la comuni-cazione di gruppo definendo un nuovo CORBA service.
2.5.1 Integration Approach
L’approccio di integrazione (Figura 2.4) estende le funzionalit`a dell’ORB con l’inserimento di un toolkit per la comunicazione di gruppo. L’ORB si occupa direttamente degli object groups e dei riferimenti agli object groups. Le richi-este CORBA sono passate ad un toolkit per la comunicazione di gruppo (group communication toolkit [18]) che effettua il multicast verso i server replicati, uti-lizzando un meccanismo proprietario.
Modi fied ORB
Multicast Group Toolkit
Client Object Object
Replica Object Replica G r o u p
Figura 2.4: Approccio di integrazione per la tolleranza ai guasti in CORBA.
L’approccio `e chiamato di “integrazione” poich´e il gruppo toolkit `e integrato nel-l’ORB. I sistemi che attualmente sfruttano questo approccio sono Orbix+Isis ed Electra ([36]).
2.5.2 Interception Approach
L’approccio ad intercettazione (Figura 2.5) presuppone che l’ORB non abbia cog-nizione della replicazione. Le richieste ORB sono intercettate in maniera traspar-ente sia lato client che lato server, usando meccanismi di intercettazione di basso livello. A questo punto, la richiesta intercettata viene passata a un group com-munication toolkit che effettua il multicast verso il gruppo di interesse.
Unmodi fied ORB
Multicast Group Toolkit
Client Object Object
Replica Object Replica G r o u p Interceptionlayer
Figura 2.5: Approccio di intercettazione per la tolleranza ai guasti in CORBA. Tale approccio non richiede la modifica dell’ORB come il precedente approccio di integrazione, ma per intercettare le richieste fa affidamento su meccanismi specifici del sistema operativo. Un esempio di tale approccio `e il sistema Eternal ([41]), sviluppato nell’Universit`a della California a Santa Barbara, che si basa sul-l’intercettazione dei messaggi prima che questi raggiungano il livello di trasporto TCP/IP.
2.5.3 Service Approach
L’approccio di servizio (Figura 2.6) fornisce un supporto esplicito all’astrazione di gruppo mediante la realizzazione di un nuovo CORBA service. A differenza del-l’approccio di integrazione che estende l’ORB con meccanismi di comunicazione proprietari, in questo caso va semplicemente specificato un nuovo servizio COR-BA mediante interfacce IDL, per cui non c’`e nessuna dipendenza da un particolare ORB o da un particolare linguaggio implementativi. L’ORB rimane ignaro della nozione di gruppo e il servizio pu`o essere utilizzato con qualsiasi implementazione
2.6. L’ARCHITETTURA FT-CORBA 21
CORBA compliant.
ORB
Client Object Object
Replica Object Replica G r o u p Trans action Notificati on Group Communication
Common O bject Ser vic e
Figura 2.6: Approccio di servizio per la tolleranza ai guasti in CORBA. Un esempio importante di sistema basato sull’approccio al servizio l’Object Group Service (OGS), sviluppato dall’`Ecole Polytechnique de Lausanne, Svizzera ([20, 21]) , che si basa su una serie di sottoservizi ciascuno dei quali si configura come un servizio indipendente dall’altro.
La Tabella 2.1 fornisce in sintesi un confronto tra i vari approcci sopra descritti per aumentare CORBA con la nozione di gruppo. Le caselle lasciate in bianco indicano che la relativa propriet`a `e solo parzialmente soddisfatta.
Approcci per la FT
Integration Interception Service
Trasparenza SI SI
Interoperabilit`a SI SI
Portabilit`a NO SI
CORBA compliance NO SI SI
Tabella 2.1: Confronto fra i vari approcci usati per la FT.
2.6 L’architettura FT-CORBA
La specifica FT-CORBA ([43]) raggiunge la tolleranza ai guasti definendo un supporto per la ridondanza di oggetti CORBA, per il rilevamento dei guasti e per
il recovery dai guasti.
Le repliche di oggetti CORBA sono dislocate su diversi host di un dominio di
tolleranza ai guasti2 (FT-domain). Le repliche di un oggetto sono chiamate
membri e sono riunite in un object group, cio`e un elemento logico usato per fa-cilitare l’indirizzamento degli oggetti replicati ([6]) e che permettono ai client di accedere trasparentemente ai membri dell’object group come se quest’ultimo fosse un oggetto singleton, non replicato e ad alta disponibilit`a. Se l’oggetto replicato `e stateful allora deve essere rispettata la strong replica consistency3 dello stato dei membri dell’object group.
Le modifiche e le estensioni pi`u importanti apportate allo standard CORBA riguardano l’indirizzamento degli object group, la definizione di una nuova
se-mantica di failover per il client e nuove tecniche e componenti architetturali per
la gestione della replicazione, gestione dei guasti e la gestione del ripristino dai
guasti.
Indirizzamento degli object group. Per identificare ed indirizzare gli ob-ject group, la specifica FT-CORBA introduce gli Interoperable Obob-ject Group
Ref-erences (IOGRs). Un IOGR `e un Interoperable Object Reference (IOR, [44]) CORBA, composto da profile multipli, ognuno dei quali pu`o indirizzare:
• un membro dell’object group, per esempio nel caso di replicazione passiva
o stateless;
• un gateway che gestisce l’accesso ai membri dell’object group, ad esempio
nel caso di replicazione attiva.
Gli IOGR sono usati dagli ORB dei client per accedere trasparentemente agli object group.
2Un dominio di tolleranza ai guasti `e un insieme di host interconnessi da una rete di computer
non partizionabile.
3Formalmente, la strong replica consistency corrisponde alla linearizzabilit`a delle richieste
2.6. L’ARCHITETTURA FT-CORBA 23
Estensione della semantica di failover di un client CORBA. Per fornire alle applicazioni la trasparenza sulla replicazione e sui guasti, un ORB compliant con la specifica FT-CORBA deve implementare le tecniche della reinvocazione
trasparente e della redirezione:
• quando un ORB riceve una richiesta da un’applicazione client, la
identifi-ca univoidentifi-camente attraverso un FTRequestServiceContext e manda la richi-esta all’object group indirizzato dall’IOGR (o meglio dai profile presenti nell’IOGR);
• quando un ORB riceve una failover condition, ad esempio una TRANSIENT
o NO RESPONSE exception, viene usato un altro profilo dell’IOGR per eseguire di nuovo la richiesta fino a quando non viene ricevuto un risultato oppure scade il request expiration time associato alla richiesta.
Gestione della replicazione. Include meccanismo per la creazione e la ges-tione degli object group e dei membri di un object group: il componente de-nominato ReplicationManager `e responsabile di queste attivit`a. In particolare, quando un’applicazione client richiede la creazione di un object group, il Replica-tionManager sfrutta le local factory (messe a disposizione dagli sviluppatori delle applicazioni) per creare i membri dell’object group, per reperire gli object refer-ence dei nuovi oggetti creati, e restituisce alla fine la referrefer-ence dell’object group. Il ReplicationManager permette di selezionare la tecnica di replicazione per un object group e di scegliere se la consistenza di oggetti stateful deve essere gestita dall’applicazione stessa o dall’infrastruttura.
Gestione dei guasti. Consiste nel rilevamento dei guasti dei membri di un ob-ject group, nella creazione, notifica e analisi dei fault report relativi ai guasti rile-vati. Queste attivit`a devono essere implementate rispettivamente dai componenti denominati FaultDetectors, FaultNotifier e FaultAnalyzer. Un oggetto replicato pu`o essere monitorato da un FaultDetector se implementa l’interfaccia PullMonitorable. Il FaultNotifier `e basato sul paradigma di funzionamento publish-and-subscribe. Il FaultNotifier riceve i fault report dai vari FaultDetector (i publishers) propaga
queste notifiche di guasti al ReplicationManager e ad altri client interessati (i subscribers).
Gestione del ripristino dai guasti. E basata su due attivit`` a, chiamate
log-ging e recovery, che sfruttano due interfacce definite dalla specifica
(Check-pointable and Updateable). Il meccanismo di logging periodicamente memorizza in un log informazioni riguardanti gli oggetti (ad esempio gli update dello sta-to dei membri, le richieste servite, i risultati restituiti, e l’expiration time della richiesta), mentre il meccanismo di recovery recupera queste informazioni dal log quando, ad esempio, si aggiunge un membro ad un object group esistente, ed `e quindi necessario settarne lo stato interno per mantenere la consistenza del gruppo.
Un dominio di tolleranza ai guasti deve contenere una istanza logica del Repli-cationManager e del FaultNotifier. I FaultDetectors invece sono dislocati su tutto il dominio per rilevare i guasti degli oggetti monitorabili4. Questa infrastruttura software `e comunemente denominata infrastruttura tollerante ai guasti.
Lo standard FT-CORBA `e il risultato di ricerche nel campo dei sistemi dis-tribuiti tolleranti ai guasti e nel campo della computazione distribuita ad oggetti (DOC - Distributed Object Computing). I principali contributi sono stati dati dai seguenti sistemi: Isis+Orbix e Electra ([36]), OGS ([20, 21]), AQuA ([14]), DOORS ([12]) e Eternal ([41]).