Indice
Home Su
| |
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 :
- 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.
- L'IDL
(Interface Definition Language),
linguaggio descrittivo per definire
l’interfaccia, con istruzioni indipendenti da qualsiasi linguaggio
di programmazione e ambiente operativo.
- 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.
- 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.
- 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
|
|