Stefano Russo » 19.L’architettura CORBA OMA

OMG, CORBA e OMA

CORBA (Common Object Request Broker Architecture) è la specifica di un modello di riferimento per middleware ad oggetti, che fa parte della cosiddetta Object Management Architecture (OMA), definita dall’Object Management Group (OMG).

OMG è un’organizzazione nata nel 1989, oggi formata da molte centinaia di membri tra industrie, consorzi ed università, con l’obiettivo di standardizzare tecnologie e metodologie relative a sistemi orientati agli oggetti, in modo da ridurre la complessità, abbassare i costi e supportare l’interoperabilità e la cooperazione applicativa in ambiente distribuito eterogeneo.

L’architettura OMA

I quattro macro componenti

CORBA OBJECT REQUEST BROKER (ORB)

• Il nucleo della piattaforma.
• Bus software intermediario nella comunicazione cliente-servente.

CORBA Services

• Servizi a livello di sistema.
• Realizzati da collaborazioni di oggetti CORBA.

CORBA Facilities

• Servizi CORBA di tipo orizzontale per le applicazioni.

CORBA Domains

• Servizi CORBA specializzati per particolari domini applicativi.

L’architettura OMA

Livelli di astrazione dei componenti OMA

L’architettura OMA

L’ORB

È il nucleo dell’architettura OMA.

Fornisce servizi per l’invocazione di metodi su oggetti.

Intermediario nelle interazioni tra oggetti:

• garantisce la trasparenza dei sistemi operativi, dei protocolli, dei linguaggi, della posizione, della migrazione;
• è uno standard –> favorisce la trasparenza delle implementazioni commerciali:
  • portabilità delle applicazioni su ORB di produttori diversi, conformi allo standard;
• un ulteriore standard (Interoperability Architecture) garantisce la possibilità di costruire applicazioni con oggetti su più ORB di produttori diversi.

I servizi CORBA

Naming
Per la ricerca di oggetti a partire dal nome.
Pagine Bianche (White Pages) per gli oggetti distribuiti: nomi degli oggetti organizzati gerarchicamente:

• entry: nome dell’oggetto;
• output: riferimento all’oggetto.

Trading
Per la ricerca di oggetti a partire da specificate caratteristiche.
Pagine Gialle (Yellow Pages) per gli oggetti distribuiti: servizi degli oggetti organizzate in directory:

• entry: tipo servizio;
• output : riferimento agli oggetti.

I servizi CORBA

Events
Supporto allo scambio di eventi: modello produttori-consumatori.

Per la comunicazione: uno a molti o molti a molti: tramite intermediario (Event channel).

Security
Per disciplinare l’accesso alle risorse: politiche differenziabili per cliente:

• a livello di subset di oggetti o di subset di operazioni delle operazioni.

Tramite Autenticazione dei clienti: firme digitali.

I servizi CORBA

Transaction
Supporto alle transazioni che coinvolgono oggetti distribuiti: meccanismi di commit e roll back.

Relationship
Arricchimento dell’IDL con il meccanismo dell’associazione:

• IDL definisce solo subtyping;
• Associazione tra oggetti esplicitata a livello di interfaccia IDL.

I servizi CORBA

Lifecycle
Gestione del ciclo di vita degli oggetti (supporto alla creazione, copia, distruzione di oggetti distribuiti “complessi”).

Persistence
Supporto alla persistenza degli oggetti: interfaccia standard per qualsiasi tipo di DBMS.

Concurrency
Supporto alla concorrenza risorse condivise: accesso atomico agli oggetti condivisi:

• sincronizzazione, lock, unlock.

Il modello a oggetti CORBA

Nei linguaggi a oggetti non fortemente tipizzati (es.: Smalltalk):

• Oggetto: accorpamento di struttura dati e operazioni possibili su di essa.

Nei linguaggi a oggetti tipizzati (es.: C++, Java):

• Oggetto: istanza di una classe;
• Classe: costrutto linguistico per definire tipi di dati astratti.

In entrambi i casi un oggetto ha natura temporanea e locale all’applicazione in cui viene creato.

Modello a oggetti in CORBA

Concetti essenziali dell’orientamento agli oggetti in CORBA:

• Incapsulamento;
• Oggetti CORBA;
• Ereditarietà;
• Polimorfismo;
• Instanziazione.

Modello a oggetti in CORBA

Le proprietà (attributi in IDL) di un oggetto CORBA non sono da riguardare come la struttura dati incapsulata.

• A un attributo specificato nell’interfaccia può corrispondere effettivamente una variabile, ovvero esso può essere calcolato a partire da dati interni all’oggetto, non specificati in IDL.
• A un attributo corrispondono operazioni di lettura (get) e assegnazione (set) del valore.

Modello a oggetti in CORBA

Ereditarietà

• Consente di definire nuovi oggetti per specializzazione o estensione di oggetti preesistenti.
• Questo concetto tipico delle tecniche O-O è definito ereditarietà di implementazione (implementation inheritance).

Ereditarietà in CORBA
Ereditarietà tra interfacce (interface inheritance)

• CORBA non è un linguaggio di programmazione, ma un middleware di connettività, quindi non tratta meccanismi linguistici per definire (gerarchie di) tipi di oggetti, ma la definizione delle interfacce tra oggetti distribuiti.

Modello a oggetti in CORBA

Polimorfismo

• Proprietà di un oggetto di assumere varie forme.
• Supporta la proprietà di estensibilità di un sistema software.

In CORBA il concetto di polimorfismo è

• Intrinsecamente connesso alla definizione di oggetto CORBA: ogni istanza è libera di implementare alla propria maniera i servizi definiti nell’interfaccia.
• Non legato alla creazione di gerarchie di (interfacce di) oggetti.

Modello a oggetti in CORBA

Instanziazione

• Creazione di oggetti di un’applicazione distribuita CORBA.
• A ciascun oggetto l’ORB assegna un riferimento univoco sulla rete (Object Reference, OR).

Interoperability Architecture

Dominio ORB (ORB domain)

• Insieme di ORB tecnologicamente omogenei.

La IA definisce:

• un formato universale per la rappresentazione degli object reference (Interoperable Object Reference, IOR);
• un formato comune per la rappresentazione dei dati, neutro rispetto a piattaforme hardware e protocolli impiegati nei domini ORB (Common Data Representation, CDR).

Interoperability Architecture

Due tipi di protocolli per le interazioni tra ORB

• General Inter-ORB Protocol (GIOP): implementazione obbligatoria per tutti gli ORB standard;
• Environment-Specific Inter-ORB Protocol (ESIOP): implementazione opzionale; riguarda reti su protocolli proprietari, o per l’interoperabilità con altri middleware.

Attualmente sono definiti:

• Internet Inter-ORB Protocol (IIOP): implementazione di GIOP su TCP/IP;
• DCE-CIOP: implementazione di ESIOP su middleware OSF-DCE.

Interoperability Architecture

Il modello a componenti CORBA

(CORBA Component Model, CCM)

È una delle principali innovazioni della specifica CORBA3.
Modello di sviluppo a componenti per la programmazione lato servente.
Volutamente simile al modello EJB di J2EE: EJB basato su Java, CCM pensato per la trasparenza del linguaggio.
Attori coinvolti nella produzione e utilizzo di componenti:

• progettista (component designer);
• cliente (component client);
• sviluppatore (component implementer);
• confezionatore (component packager);
• assemblatore (component assembler);
• distributore/installatore (component deployer).

Il modello a componenti CORBA

Aspetti principali del CCM

Specifica di un ambiente contenitore per l’esecuzione dei componenti.

Specifica di un linguaggio di descrizione per la persistenza dei componenti (Persistent State Definition Language, PSDL).

Specifica di un linguaggio di descrizione dei componenti (Component Implementation Definition Language, CIDL).

Specifica di un formato di distribuzione e di strumenti di configurazione per la produzione di componenti software riusabili.

Integrazione con EJB.

CCM

Modello di container

CCM

Ciclo di sviluppo

CCM

Assemblaggio, confezionamento e rilascio