Studio e Realizzazione di Architetture Concorrenti per Sistemi ad ...

Architetture Concorrenti in prodotti a larga diffusione - CORBA 23
1. La scelta di un linguaggio unico per specificare le interfacce degli oggetti coinvolti
nell'interazione in rete: in modo che sia il client, sia il server sappiano,
univocamente e senza ambiguità di sorta, quali richieste possono essere invocate
sull'oggetto.
2. La scelta di un protocollo comune per effettuare le comunicazioni vere e proprie
attraverso una generica rete.
CORBA si fonda su IDL (Interface Definition Language) anch'esso definito da OMG
per disciplinare la descrizione delle interfacce (con i loro metodi, parametri, tipi di dati
di ritorno, etc.), e propone IIOP (Internet Inter-ORB Protocol) come protocollo di
comunicazione.
Si deve ricordare che CORBA è unicamente un insieme di specifiche su come deve
operare e quali funzioni deve fornire un ORB che voglia dirsi "CORBA compliant":
non si dice come tali funzionalità debbano essere implementate, ma unicamente
come debbano comportarsi. Nulla di implementativo è stato sviluppato da OMG, ma
diversi produttori di software hanno scelto di fornire applicativi conformi a tale
standard; limitandosi, però, CORBA alle specifiche d'interfaccia, ogni ORB sviluppato
partendo da queste è libero di effettuare le scelte implementative volute, ed è quindi
unico per prestazioni, flessibilità, robustezza, scalabilità, etc [Bibl. 12].
2.3.2 Panoramica sull'architettura
Un programmatore che volesse adoperare CORBA deve definire l'interfaccia di ogni
oggetto facente parte dell'interazione sulla rete usando IDL in modo che non vi siano
ambiguità sulle sue possibilità. La separazione tra definizione ed implementazione
dell'oggetto è il punto di forza di CORBA, poiché lascia liberi di adoperare, in fase di
scrittura dei metodi, qualsiasi linguaggio prescelto dal programmatore: uno specifico
compilatore IDL si occupa, infatti, in una fase successiva, di mappare la definizione
in due oggetti language-specific separati. Gli oggetti sono detti "stub" e "skeleton". Gli
stub servono da proxy per le chiamate da parte di client, mentre gli skeleton
implementano i proxy del lato server. Il progettista, una volta ottenuto lo skeleton
della classe, contenente tutte le definizioni dei metodi precisate in fase di scrittura
IDL, non deve fare altro che estenderlo implementando le chiamate ai metodi: stub e