Il middleware CORBA per sistemi distribuiti

Il middleware CORBA per sistemi distribuiti

Common Object Request Broker Architecture (CORBA) è la specifica tecnica pubblica per lo scambio di messaggi tra oggetti in una rete di sistemi eterogenei, promossa da Object Management Group (OMG), associazione che all’inizio del 1998 contava circa 780 membri tra produttori, sviluppatori ed utenti.

Questo standard si inserisce nel contesto architetturale ad oggetti, mostrato nella figura seguente e chiamato Object Management Architecture (OMA), basato sui seguenti componenti principali:

  • l’Object Request Broker (ORB), che assicura i meccanismi di base necessari per la registrazione dei servizi offerti dai diversi oggetti e per la loro invocazione ed esecuzione; è un bus software che consente agli oggetti di fare richieste e ricevere risposte in modo trasparente in un ambiente distribuito;
  • i Servizi di base (Common Object Services, COS), che assicurano le funzionalità necessarie per l’attivazione e la gestione operativa dei sistemi applicativi ad oggetti;
  • i Servizi Orizzontali, ovvero servizi per risolvere problematiche ricorrenti e generali nelle applicazioni (ad esempio l’interfaccia utente);
  • i Servizi Verticali, che facilitano lo sviluppo in particolari domini.

Il middleware CORBA per sistemi distribuiti - Architettura
Il middleware CORBA per sistemi distribuiti – Architettura

Spesso, per questo tipo di specifiche, il termine “standard” è utilizzato in modo improprio. Nel mondo dei sistemi aperti è più corretto infatti distinguere:

  • specifiche proprietarie, cioè definite da un singolo fornitore;
  • specifiche tecniche pubbliche, cioè preparate e diffuse da organizzazioni internazionali, non a scopo di lucro (ad esempio OMG, X/OPEN, OSF);
  • norme de iure, ovvero e messe dagli organismi internazionali autorizzati (quali IEEE, ISO).

Il middleware CORBA rientra più propriamente nel secondo insieme; DCOM invece appartiene alla prima categoria e per esso si parla di standard “de facto” a causa della larga diffusione della piattaforma Windows, su cui è attualmente basato.

L’architettura mostrata è disponibile su piattaforme hardware e software diverse. Gli oggetti possono essere realizzati con diversi linguaggi di sviluppo e dialogano fra loro e con il broker mediante interfacce definite nel linguaggio dichiarativo IDL (Interface Definition Language). Il protocollo di interazione tra oggetti IIOP (Internet Inter Object Protocol) permette il dialogo fra broker diversi. Attualmente esistono sul mercato una decina di prodotti che implementano CORBA; inoltre recentemente (nel 1997) porzioni client di questa tecnologia, sotto forma di un ORB realizzato in Java, sono state inserite nel browser Netscape Communicator.

Lo standard CORBA, che mira all’indipendenza da specifiche piattaforme e si basa sul concetto di broker come intermediario nel dialogo fra oggetti, si propone come soluzione nei casi in cui si debbano federare sistemi informatici di organizzazioni diverse, chiamati a cooperare mantenendo ognuno elevati livelli di autonomia.

I suoi punti di forza sono un’architettura stabile e completamente definita, sia per quanto riguarda l’ORB che, più in generale, per i servizi complementari, la sostanziale indipendenza dalle piattaforme e la sua disponibilità commerciale per molte piattaforme hardware/software e la piena aderenza ai concetti dell’object orientation, sia per il progetto delle applicazioni che per i linguaggi di programmazione supportati. CORBA gode inoltre di un vasto supporto da parte dei numerosi produttori che aderiscono all’OMG.

Gli attuali punti deboli di CORBA sono la carenza di strumenti di supporto al progetto  ed alla realizzazione delle applicazioni e la mancanza di una vera interoperabilità tra ORB di produttori differenti.

L’Object Model

Il paradigma di sviluppo implicitamente definito da CORBA è quello Plug&Play: un oggetto, una volta connesso al bus (plug) è in grado di vedere ed interoperare (play) con qualunque altro oggetto CORBA. Il modello ad oggetti enfatizza quindi il ruolo di un’entità (il client) in grado di richiedere servizi ad un oggetto (il server).

L’object implementation è l’insieme di codice e dati che effettivamente realizza il comportamento dell’oggetto server.

Al concetto di request, richiesta di servizio, sono associate due informazioni fondamentali per denotare, rispettivamente, l’oggetto target (object reference) e il servizio richiesto (operazione). L’operazione è identificata da un operation identifier ed è descritta da un’operation signature che specifica i parametri richiesti, i risultati restituiti al client, le eccezioni nei casi di terminazione anomala. Una specifica implementazione viene chiamata metodo.

L’insieme di tutte le possibili operazioni che un client può richiedere su un oggetto si chiama interfaccia che, in CORBA, deve essere descritta nel linguaggio dichiarativo IDL.

Object Request Broker

L’Object Request Broker (ORB) è il bus di interconnessione tra gli oggetti. Esso fa sì che gli oggetti possano inviare richieste e ricevere risposte da altri oggetti locali o remoti senza che si abbia la necessità di conoscere i meccanismi effettivamente utilizzati per comunicare.

L’ORB mette a disposizione un insieme molto ricco di servizi distribuiti fra i quali:

  • invocazione statica o dinamica: l’ORB permette di definire l’invocazione dei metodi da parte del client sia in modo statico, cioè al momento della compilazione, sia in modo dinamico; in questo caso il client può identificare ed invocare, durante l’esecuzione, i metodi offerti dai server; l’identificazione avviene consultando l’Interface Repository  che descrive le funzioni che un server mette a disposizione  ed i loro parametri;
  • binding per linguaggi di alto livello: l’ORB permette ai client di invocare i metodi

dei server usando linguaggi di alto livello (C, C++, Java, Smalltalk e qualunque altro linguaggio in grado di chiamare routine scritte in questi linguaggi); non ha importanza quale sia il linguaggio utilizzato per realizzare il server, in quanto CORBA separa l’interfaccia dalla realizzazione e rende possibile l’interoperabilità tra linguaggi e sistemi operativi differenti;

  • trasparenza di accesso locale/remoto; un ORB può funzionare su un singolo calcolatore o essere interconnesso con altri ORB; nello sviluppo delle applicazioni non ci si deve preoccupare delle problematiche di trasporto, di locazione dei server, dell’attivazione degli oggetti, di differenze nel formato dei pacchetti tra piattaforme diverse o dei sistemi operativi;
  • messaggi polimorfici; un ORB non invoca semplicemente una funzione remota, ma invoca una funzione su un certo oggetto: la stessa invocazione può avere effetti diversi a seconda dell’oggetto che la riceve; ad esempio il messaggio AutoConfigurati() otterrà un effetto differente a seconda del dispositivo cui viene

Un Object Request Broker del middleware CORBA è quindi ancora un middleware che stabilisce le relazioni cliente/servente tra gli oggetti. I suoi componenti sono descritti meglio nel paragrafo successivo.

Componenti CORBA dal lato client

Gli stub IDL sono generati automaticamente compilando le definizioni IDL dei servizi e costituiscono le interfacce statiche verso tali servizi, ovvero il modo in cui il client invoca il corrispondente servizio sul server; dal punto di vista del client lo stub è equivalente ad una chiamata locale.

L’interfaccia per l’invocazione dinamica (Dynamic Invocation Interface – DII) permette di identificare ed invocare i servizi durante l’esecuzione. Permette di individuare i metadati che definiscono le interfacce dei server e che sono contenuti, generare i parametri, fare l’invocazione del metodo remoto e ricevere i valori di ritorno. L’Interface Repository è popolato a seguito della compilazione delle interfacce definite in IDL.

L’ORB Interface è composta da poche API verso servizi locali utili alle applicazioni.

Componenti CORBA dal lato server

Gli stub IDL dalla parte server (chiamati skeleton) mettono a disposizione interfacce statiche verso i servizi esportati. Questi, come quelli creati per il client, sono generati utilizzando il compilatore IDL.

L’interfaccia dinamica dal lato server (Dynamic Skeleton Interface) consente la risoluzione delle richieste a quei server che non hanno stub compilati tramite IDL. Diversamente da quanto avviene con gli stub compilati, che sono definiti per la specifica classe di un oggetto e prevedono un’implementazione per ciascun metodo definito in IDL, l’interfaccia dinamica utilizza i parametri di un messaggio in ingresso per risolvere sia l’oggetto che il metodo che dovrà rispondere al messaggio.

L’Object Adapter fa da mediatore tra l’ORB e gli oggetti che effettivamente implementano i servizi; mette a disposizione l’ambiente di esecuzione per attivare le istanze degli oggetti e trasferisce le richieste a tali istanze.

L’Implementation Repository contiene le informazioni sui server e sugli oggetti correntemente attivi. Può servire anche da contenitore per varie informazioni di amministrazione (informazioni di trace, audit, security, etc.).

L’ORB Interface, come quello fornito del client, consiste di un insieme di API verso i servizi locali.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *