Indice

Home
Su

 

 

 

OMG Corba


 

CORBA

Common Object Request Broker Architecture

Introduzione:

Da alcuni anni a questa parte si stanno diffondendo enormemente middleware orientati agli oggetti, capaci di interfacciarsi con applicativi e linguaggi di programmazione basati su oggetti oltre che con i classici linguaggi procedurali. CORBA consiste in un insieme di specifiche promosse e curate dal OMG (Object Management Group), che si pose l'obiettivo di rendere interoperabili applicativi software orientati ad oggetti, anche progettati per ambienti e piattaforme diversi; quest'ultima è la potenzialità fondamentale del nuovo standard: l'obiettivo fondamentale dell'architettura è infatti quello di facilitare l'integrazione ed il riuso di componenti software eterogenei , creati per ambienti diversi in un' architettura tipo Client/Server su reti comunque estese.

Si può dire che l'architettura si propone come strato Middleware che nasconda le diversità esistenti tra sistemi operativi diversi, linguaggi di implementazione, ambienti di sviluppo, protocolli di rete. Al di sopra di CORBA tutte le applicazioni possono usufruire degli stessi servizi con le stesse potenzialità.

Modelli Object Oriented

CORBA è stato progettato e si rivolge a modelli Object Oriented ma mantiene la compatibilità con i modelli di tipo procedurale. Si basa dunque sui seguenti concetti:

  • Oggetto: una entità incapsulata, in generale non accessibile dall'esterno se non tramite i servizi prevesti e presentati tramite l'interfaccia; l'utente di un servizio è tenuto a conoscere solo le informazioni strettamente necessarie per usufruire del servizio ( information hiding); ogni altra informazione può confondere l'utente se non mettere a rischio l'integrità dell'oggetto. Pertanto si distingue tra informazioni 'pubbliche' e 'private' per l'oggetto. L'interfaccia è ciò con cui interagisce l'utente ed è quanto è presentato all'esterno dell'oggetto.
  • Richiesta: azione creata dal cliente verso un oggetto con cui esso specifica una operazione da svolgere ed i parametri necessari alla sua esecuzione.
  • Interfaccia: modulo di descrizione e implementazione della richiesta; è la parte dell'oggetto 'visibile' dall'esterno e tramite cui si scambiano dati e servizi. Se nascondo tutte le parti dell'oggetto non strettamente necessarie a svolgere il servizio, facilito il riuso di questo, ne preservo lo stato da modifiche inadatte e non volute, ne posso fare manutenzione.
  • Metodi: le operazioni previste per l'oggetto sono implementate tramite i suoi 'metodi' ( potremmo considerarli dei sottoprogrammi interni). essi possono modificare lo stato di un oggetto o leggerne semplicemente il contenuto.

Le specifiche CORBA descrivono, in particolare, come gli oggetti:

  • siano definiti,
  • siano creati,
  • siano invocati

Il Broker: un mediatore

Il cuore di un middleware compatibile CORBA è l' ORB (Object Request Broker), un intermediario nella comunicazione tra i due attori ( cliente, servente) che si fa carico di reperire e restituire all'uno quanto offerto dal secondo indipendentemente dalla locazione di questo, dallo stato, dalle caratteristiche specifiche della implementazione.

Tecnicamente la cosa avviene in maniera simile a quanto accade con le richieste di procedura remota RPC: la richiesta del cliente è intercettata viene inoltrata verso il servente remoto viene ad esso 'presentata' , risolta, e successivamente, per un percorso contrario si restituiscono al cliente i risultati della richiesta.

L'IDL linguaggio per la descrizione delle interfacce:

Come in quel caso si usa un interfaccia per scambiare dati, valori, parametri descritta tramite un linguaggio evoluto: IDL (Interface Definition Language).

L'IDL di CORBA, indipendente dalle due parti, è utilizzabile in ambienti e per linguaggi di programmazione differenti perchè compilabile nel voluto linguaggio nativo ed è adatto soprattuto a descrivere interfacce per oggetti.

 

Interfacce statiche e dinamiche:

Interfacce SII, DII

Come fa un client ad accedere ogli oggetti del server? CORBA stabilisce due tecniche a disposizione del client: statica e dinamica.

La tecnica statica prevede che l'oggette cliente possegga una rappresentazione locale del servizio remoto fornita da ORB; tale rappresentazione è il codice Stub ottenuto dalla compilazione, nel linguaggio nativo del client, della IDL interface. In tal caso il link con l'oggetto server è già presente in fase di compilazione ed il collegamento non è modificabile se non con la ricompilazione del client

Questa tecnica è poco onerosa per il programmatore del client ma non sempre attuabile: se il client non possiede alcuno stub che si interfacci con lo specifico servizio remoto, bisogna definirlo successivamente alla compilazione, mentre il client è attivo, cioè run - time . I questo caso il compito del programmatore è più gravoso poichè si tratta di creare una interfaccia client una sul server (Skeleton) e i relativi link col codice dell'oggetto tutto run - time.

 

Architettura di CORBA

.

Una caratteristica importante è il fatto che, definendo l'interfaccia in IDL, non dobbiamo specificare come implementare l'interfaccia perchè qualunque prodotto CORBA (CORBA Compliant) sarà in grado di farlo per voi: l'ORB può eseguire una compilazione della IDL interface in diversi linguaggi.

 

La Repository delle interfacce:

Inoltre, tutte le definizioni così fatte con IDL possono essere immagazzinate in un archivio comune, la Interface Repository , per poter essere usate quando servono.

 

Le CORBA service

Per meglio gestire questa interessante struttura, le specifiche CORBA definiscono anche una serie di potenti servizi di base con cui, per esempio, navigare nella Repository o cotrollare gli oggetti. Tali servizi sono fondamentali per gestire stati critici e per migliorare la polivalenza della architettura; ricordiamone alcuni.  

  • Naming: si può richiamare un interfaccia usando il nome simbolico ad essa associato (white pages).
  • Events: intermediario che interviene nel modello user - producer di un servizio.
  • Concurrency control: facilita l'accesso a più clienti a risorse condivise.
  • Life cycle: specifiche per cotrollare vita, creazione, cancellazione, spostamento e duplicazione di oggetti.
  • Security: per proteggere specifiche applicazioni distribuite.
  • Object trader: ricerca di un interfaccia conoscendone le specifiche ed i servizi (yellow pages).

I cinque componenti di CORBA

Riassumendo, i fondamentali componenti di Corba sono dunque 5 :

  1. l'ORB (Object Request Broker) intermediario di richieste ad oggetti, è un componente software, un bus software ( Open Software Bus ) utilizzando il quale applicazioni ad oggetti eterogenee possono interoperare attraverso la rete: l'ORB implementa il meccanismo tramite cui l’oggetto chiede e riceve un servizio. Detto così si può ribattere che anche un linguaggio come Java è capoce di fare ciò, però, nel caso di CORBA la cosa si espande a qualunque linguaggio con cui l'applicazione è scritta: un programma scritto in C++ può richiamare i metodi di un oggetto ( anche remoto ) scritto in Java, in Smalltalk o anche in Cobol ! Secondo CORBA tutte le comunicazioni client – server avvengono a carico del ORB sicché il client vede l’operazione come se fosse locale in completa trasparenza, sarà ORB a risolverla su qualche server nella architettura distribuita. Le specifiche CORBA comunque lasciano libero arbitrio circa l’implementazione pratica di ORB.
  2. L'IDL (Interface Definition Language), linguaggio descrittivo per definire l’interfaccia, con istruzioni indipendenti da qualsiasi linguaggio di programmazione e ambiente operativo.
  3. La Interface Repository il cui scopo è quello di contenere descrizione di tutte le interfacce, i tipi, le eccezioni, usate dal sistema e la Implementation Repository che contiene i percorsi degli eseguibili deputati a stanziare gli oggetti di cui si cerchi un servizio.
  4. Le interfacce client, ve ne sono di due tipi: una statica (SII) e l’altra dinamica. SII (Static Invocation Interface ), richiede uno stub sul client; DII (Dtatic Invocation Interface ), effettua un collegamento run-time.
  5. Le interfacce server, anche qui troviamo una interfaccia statica (Skeleton statico) ed una dinamica (Skeleton dinamico). Sono la parte server di una SII e di una DII. La BOA (Basic Object Adapter) capace di cercare l'eseguibile che istanzia l'oggetto sul server quando questo non è attivo.

In altre parole, tramite IDL un progettista di sistemi distribuiti descrive le interfacce "pubbliche" presenti sul sistema: operazioni ed attributi specificati da tali interfacce potranno essere invocati dal client. E'CORBA che si prende cura di rimappare le richieste del client su quelle IDL.

In tutto il mondo esistono innumerevoli applicativi e linguaggi di vecchia e nuova generazione, procedurali o ad oggetti ciascuno sul suo sistema operativo o protocollo di rete; tutti possono avvalersi del "mapping" per portarsi su CORBA. Si riesce cosi a stabilire una tecnica evoluta di comunicazione tra qualunque client ne faccia richiesta.

Man mano che le interfacce vengono descritte e attivate sul sistema distribuito, esse vengono 'archiviate' nella Interface Repository e messe a disposizione del sistema affinchè, ogni qual volta un applicazione faccia una richiesta ad un oggetto, sia possibile avvalersi di quanto già creato per le richieste precedenti. In essa troviamo interfacce, tipi astratti, eccezioni che di volta in volta arricchiscono le potenzialità del sistema man mano che esso cresce.

L'ORB mette a disposizione del client la SII per quelle invocazioni ad oggetti che sono effettuabili all'atto della compilazione, note quindi in quel momento. Si tratta in pratica del fatto che il client se conosce una interfaccia, ne può linkare lo stub sul server remoto. Gli stub sono gestiti dall'ORB: se il client fa una richiesta di un servizio disponibile su di un server remoto, l'ORB la intercetta, crea un oggetto sul terminale locale che simuli quello remoto, (proxy object), dando così al client la possibilità di inoltrare la richiesta che ad esso parrà risolta in ambito locale. Tale rappresentazione locale è il codice stub ottenuto dalla compilazione dell'interfaccia IDL.

 

L'altro modo con cui il client può richiedere servizi ad un server è quello dinamico: si possono invocare servizi e dati non noti al tempo della compilazione ma successivamente disponibili. Non serve collegarsi allo stub-server, ma ci vuole molto lavoro per la preliminare ricerca dell'interfaccia necessaria, la costruzione della richiesta, l'invocazione della stessa. Il meccanismo DII è certamente molto oneroso ma offre alta flessibilità al client e la possibilità di aggiornarsi di volta in volta su quanto oferto dal sistema. Tipicamente è quanto fatto dai Browser.

Vi sono alcuni interessanti servizi disponibili allo scopo: la interface repository, il naming, il trader. tutte le interfacce realizzate e disponibili, i relativi stub, ed altro è immagazzinato nella interface repository in cui il client può navigare per scoprire i servizi che interessano. La navigazione viene facilitata dall'uso di un identificatore associato a ciascun interfaccia, un reference cioè, assegnato preliminarmente, con cui individuare la stessa. Il naming ed il trader servono appunto per la navigazione in questa sorta di yellow pages.

La richiesta del cliente Cliente viene intercettata da ORB.

 

 Le interfacce per il Server: S.Skeleton, D.Skeleton, OA, ORB.

 

Invocazione del metodo sul servente

Skeleton statico.

E' cio che corrisponde sul lato server alla richiesta di servizio effettuata dal client tramite SII. Lo skeleton è infatti il lato server del codice ottenuto per la compilazione dell'interfaccia IDL. Esso è noto già durante la fase di compilazione dell'interfaccia ed è collegato all'applicativo server. La cosa funziona così: quando il broker trasporta la richiesta del client sulla rete, verso un oggetto server, questa viene intercettata dallo skeleton linkato con l'oggetto in questione ed instradata verso l'oggetto stesso. Si deve anche tradurre la sintassi usata in una compatibile col codice con cui l'oggetto è stato descritto: per esempio se il server è un oggetto Java allora richiedere il servizio significherà invocare un metodo.

Skeleton dinamico

E' quanto corrisponde sul lato server nella implementazione della DII e si occupa di selezionare l'oggetto server e di invocarne il metodo a partire dalla request sempre compatibilmente con la sintassi con cui l'oggetto server è stato descritto.

Adattatore ad oggetti, Broker Object Adapter (BOA).

L' Object Adapter fornisce un servizio caratteristico del CORBA perchè non presente in tecnologie simili: il lancio automatico del server contente il servizio richiesto dal client. In questo modo è possibile accedere al servizio pubblicato indipendentemente dallo stato del server. L'OA lavora basandosi sulla Implementation Repository da cui legge i percorsi degli eseguibili che istanziano gli oggetti server relativi alle interfacce pubblicate nella I.R. Il BOA (Broker Object Adapter) nel recepire una richesta indirizzata ad un oggetto server non attivo, legge il percorso dell'eseguibile nella I.R., lo segue e lo manda così in esecuzione.

Vediamo come le applicazioni possano portarsi su CORBA e comunicare con altre. CORBA mette a disposizione una serie di interfacce dedicate ai client ed altre dedicate ai server; infine c'è una interfaccia comune utile ad entrambi, l'ORB appunto.

 

Autore: Vasco Antonio

riferimenti:

Schede tecniche da www.omg.org

 

 


Telefono: 081-8244146
Indirizzo postale: via Roma, 100 83022 Baiano (AV)
Posta elettronica: vascoant@libero.it
Inviare a vascoant@libero.it un messaggio di posta elettronica contenente domande o commenti su questo sito Web.
Aggiornato il: 02 novembre 2000