Relazione

CORBA ( Common Object Request Broker Architecture )
consiste in un insieme di specifiche promosse e curate da
OMG (Object Management Group).
L’OMG è un consorzio internazionale no-profit di industrie
nel campo dell'Information Technology interamente
dedicato alla produzione di specifiche e di standard.
L’attività di OMG cominciò nel 1989 con soli 8 membri tra
cui Sun Microsystems, Philips, Hewlett-Packard e 3Com.
Le specifiche più conosciute sono UML e CORBA
il consorzio ha definito un framework: Object Management
Architecture (OMA)
OMA
E’ il centro di tutte le attività del consorzio, al suo interno
convivono tutte le tecnologie OMG.
Si “limita” alla definizione dettagliata delle interfacce di
tutti i componenti individuati.
I componenti OMA sono:
•
•
•
•
•
Object Request Broker (ORB)
Object Services (OS)
Common Facilities (CF)
Application Objects (AO)
L’Object Model (OM)
L’ARCHITETTURA CORBA
ORB (Object Request Broker) : Canale di comunicazione.
• ORB Interface : Interfaccia standard per tutte le
implementazioni di ORB.
• OA (Object Adapter) : Componente per la gestione degli
oggetti remoti.
• DII (Dinamic Invocation Interface) : Interfaccia standard per
invocazioni dinamiche lato client.
• DSI (Dinamic Skeleton Interface) : Interfaccia standard per
invocazioni dinamiche lato server.
• SII (Static Invocation Interface) : Interfaccia standard per
invocazioni statiche lato client.
• SSI (Static Skeleton Interface) : Interfaccia standard per
invocazioni statiche lato server.
• Interface Repository : Contenitore per le interfaccie IDL
degli oggetti noti a tempo di esecuzione.
• Implementation Repository : Contenitore per le interfaccie
IDL degli oggetti noti a tempo di esecuzione e loro effettiva
implementazione.
L’ORB
Rappresenta l’infrastruttura di comunicazione degli oggetti
rendendo trasparente la distribuzione nella comunicazione e
garantendo l'interoperabilità e la portabilità delle
applicazioni in un ambiente distribuito eterogeneo.
L’Objects Request Broker (ORB) è una specie di bus
software (Open Software Bus)
La comunicazione tra ORB nella rete avviene tramite i
protocolli GIOP e IIOP che implementano il marshalling,
unmarshalling e la rappresentazione esterna dei dati.
Supporta la Trasparenza di Locazione così da nascondere
al client tutti i dettagli sulla localizzazione degli oggetti
sulla rete e sul loro linguaggio di implementazione.
La trasparenza di Comunicazione così da mascherare le
chiamate remote come semplici invocazioni locali.
GIOP
E’ un protocollo astratto che specifica
• un insieme di tipi di messaggi utilizzabili tra un client e
un server
• una sintassi standard nel trasferimento dati delle
interfacce IDL
• un formato standard per ogni messaggio utilizzabile.
In GIOP sono definiti otto tipi di messaggi (Request,
CancelRequest, LocateRequest, Reply, LocateReply,
CloseConnection, MessageError, Fragment).
Header contiene l’indicatore del tipo del messaggio e la sua
dimensione
Body contiene il messaggio vero e proprio
l’interazione client/server è di tipo senza connessione
GIOP richiede un sistema di trasporto con connessione (es:
TCP/IP)
IIOP
E’ il mapping specifico di GIOP sul protocollo TCP/IP
I messaggi IIOP contengono inoltre informazioni di
servizio (alcuni aspetti del Security Service: codifica)
Interface Definition Language (IDL)
OMG ha definito il mapping dell'IDL su diversi linguaggi
di programmazione, quali C, C++, java, Smalltalk, ADA,
Cobol, Objective-C
Tramite un compilatore IDL si ottengono:
• file contenenti del codice di supporto per l’aggancio
all’ORB
• lo stub (per il client)
• lo skeleton (per il server)
Stub e skeleton realizzano le funzionalità di marshalling e
unmarshalling.
Typedef (tipi definiti dall’utente)
Struct (record)
Enum (tipi enumerati)
Array (tabelle)
Sequences (liste)
Any (tipo universale)
Ereditarietà
Upcasting (automatico)
Downcasting (esplicitato)
No polimorfismo e overloading
Eccezioni (raises)
COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE
Interfacce statiche
Static Invocation Interface (SII)
Interfaccia per inviare una request ad un oggetto remoto
conoscendone la definizione dell’interfaccia IDL descritta
nello stub.
Deve linkare lo stub.
Gli stub sono gestiti dall’ORB
Funzionamento:
• Il client fa una richiesta (Object Reference).
• L’ORB la intercetta, crea proxy object locale sul client.
SII è basato sui pattern:
• Active Object pattern
• Proxy pattern
• Adapter pattern
Static Skeleton Interface (SSI)
Controparte lato server di SII
Funzionamento:
• L’ORB trasporta la richiesta verso un oggetto server
• Lo skeleton la intercettata e la consegna all’oggetto
richiesto.
Si occupa di tradurre la sintassi usata nel linguaggio in cui è
implementato l’oggetto remoto.
Pro e Contro
Il metodo di invocazione statico (SII e SSI) ha dei vantaggi:
• Facilità di programmazione.
• Controllo di tipo più robusto (stub e skeleton sono
specifici).
• Ottime prestazioni (non si richiede l’uso dell’Interface
Repository).
… ha anche dei vantaggi:
• Sono meno flessibili (ricompilazione del client in caso
di modifiche)
• Permettono unicamente il metodo di invocazione
sincrono.
Interfacce dinamiche
Dynamic Invocation Interface (DII)
Funzionamento:
• Ottenere un riferimento all’oggetto
• Ottenere l’interfaccia
• Creare la lista di parametri
• Creare la Request
• Invocare il metodo
o Invoke(). Invocazione sincrona. Il client rimane
bloccato fino all’arrivo della risposta.
o Send_oneway().
Invocazione asincrona senza
risposta (AMI Asynchronous Method Invocation).
Il client prosegue l’elaborazione dopo aver
invocato la richiesta, senza recuperare la risposta
che per questo non viene neanche inviata dal
server.
o Send_deferred(). Invocazione sincrona differita.
Il client non si blocca dopo l’invocazione ma può
reperire successivamente la risposta
Dynamic Skeleton Interface (DSI)
E’ la controparte lato server della DII.
Permette di creare oggetti server non legati ad un
particolare skeleton.
Gli oggetti costruiti attraverso la DSI possono ricevere
richieste da qualsiasi stub.
Pro e Contro
Il metodo di invocazione dinamico (DII e DSI) ha dei
vantaggi:
• Si possono invocare servizi e dati non noti al tempo
della compilazione.
• Offre alta flessibilità al client.
• Facilità di aggiornamento del sistema.
… ha anche dei vantaggi:
• Ci vuole molto lavoro per la ricerca dell’interfaccia
necessaria, la costruzione della richiesta, l’invocazione
della stessa.
Object Adapter (OA)
L’OA è il meccanismo con cui gli oggetti interagiscono con
l’ORB.
La sua principale attività è quella di attivare gli oggetti.
Possiamo riconoscere cinque fasi:
1. Il client attraverso lo stub invoca il metodo all’ORB.
2. L’ORB notifica l’invocazione all’OA che attiva
l’oggetto.
3. L’oggetto si registra e si dichiara pronto.
4. L’OA passa l’invocazione allo skeleton che spacchetta
i parametri e li fornisce all’oggetto.
5. L’implementazione esegue il metodo e restituisce i
risultati o le eccezioni al client.
Metodi di attivazione
Portable Object Adapter (POA)
Ha sostituito a partire dalla versione 2.2 della specifica, il
Basic Object Adapter (BOA).
BOA è risultato lacunoso sotto gli aspetti di portabilità e di
flessibilità.
POA corregge questo problema.
Tutti i server hanno almeno un POA, chiamato RootPOA,
al quale possono esserne aggiunti altri, secondo una
struttura ad albero, il tutto gestito dal POAManager.
Relazione tra RootPOA, POA figli, e POAManager
Relazione tra ORB, POAManager, POA e Servant
Interface Repository
E’ un servizio che rende disponibili a tempo di esecuzione,
alle applicazioni client, le definizioni IDL degli oggetti.
E’ possibile utilizzare oggetti la cui interfaccia non sia nota
a tempo di compilazione.
Con il metodo get_interface_def, è possibile ottenere un
oggetto di tipo InterfaceDef che fornisce tutte le
informazioni sulla struttura di una interfaccia registrata
nell’IR.
Implementation Repository
Contiene informazioni che permettono all’ORB di
localizzare e attivare le implementazioni degli oggetti.
Se non si conosce lo stato di attivazione del server che
implementa l’oggetto usando l’Implementation Repository,
si è in grado di attivare l’oggetto per far sì che riceva la
richiesta.
OBJECT SERVICES
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
Naming Service
Event Service
LifeCycle Service
Persistence Service
Externalization Service
Concurrency Control Service
Transaction Service
Relationship Service
Property Service
Query Service
Licensing Service
Time Service
Security Service
Trader Service
Object Collection Service