CORBA;2.ppt Object Management Group’s Object Management Architecture CORBA Fabiano Cattaneo - CEFRIEL Via Fucini, 2 - 20133 Milano Tel. (02) 23954 270.

Presentazione sul tema: "CORBA;2.ppt Object Management Group’s Object Management Architecture CORBA Fabiano Cattaneo - CEFRIEL Via Fucini, 2 - 20133 Milano Tel. (02) 23954 270."— Transcript della presentazione:

1 CORBA;2.ppt Object Management Group’s Object Management Architecture CORBA Fabiano Cattaneo - CEFRIEL Via Fucini, 2 - 20133 Milano Tel. (02) 23954 270 FAX (02) 23954 254 E-mail: cattaneo@cefriel.it

2 CEFRIEL Fabiano Cattaneo - CORBA 2 Indice del corso e prerequisiti l Indice n Il contesto e le motivazioni n L’architettura concettuale di riferimento n Il modello ad oggetti n Common Object Request Broker Architecture n Un esempio l Prerequisiti n Concetti base dei sistemi object-oriented n Linguaggio Java (per l’esempio)

3 CEFRIEL Fabiano Cattaneo - CORBA 3 Il contesto l La disponibilità di PC e reti locali ha causato un mutamento rivoluzionarlo nelle architetture dei sistemi: da mainframe a client/server. n il client è in grado di effettuare elaborazioni locali (es. interfaccia grafica) n il server mantiene funzioni centrali (es. DB) n la comunicazione tra client e server è resa possibile da LAN economiche ed efficienti l Così come il modello C/S ha rotto la monoliticità del mainframe, così gli oggetti tendono a frammentare sia il lato client che il lato server. n i nuovi elementi del modello sono i “componenti”

4 CEFRIEL Fabiano Cattaneo - CORBA 4 Il contesto l Nuovo hardware ha reso possibile la comunicazione a distanza (WAN) in modo efficiente e diffuso. n alta velocità n basso costo n grande copertura l Le applicazioni stanno assumendo dimensioni planetarie n es. Internet e relative applicazioni l I moderni PC sono equipaggiati di hardware e software che li mettono in grado di funzionare sia come client che come server.

5 CEFRIEL Fabiano Cattaneo - CORBA 5 Lo scenario l Ci saranno milioni di potenziali clienti dei più disparati servizi. l È chiaro che la massa di richieste generate da questi client dovrà essere gestita non da un unico server, ma da una rete di server, che a loro volta dovranno essere in grado di accedere a servizi offerti da altri server, ecc. l Lo scenario futuro prevede una rete di componenti: n oggetti autocontenuti, con uno stato e una “intelligenza” propria, in grado di interoperare con masse eterogenee di altri oggetti l Una volta tanto gli standard (OLE/COM, CORBA) sono presenti da subito.

6 CEFRIEL Fabiano Cattaneo - CORBA 6 Il problema l Ci si trova a dover realizzare: n sistemi distribuiti su vasta scala n sistemi eterogenei, costituiti da piattaforme hardware e software estremamente diverse n è necessario che i componenti del sistema distribuito possano interoperare l L’approccio OMG n Definire un’architettura di riferimento object oriented, basata sul concetto di “interfaccia” di un componente n La conformità con l’architettura di riferimento dovrebbe garantire l’interoperabilità

7 CEFRIEL Fabiano Cattaneo - CORBA 7 Perché object oriented? l Dal punto di vista dell’utente n Facilità d’uso delle interfacce utenti object-oriented n Integrabilità di componenti sviluppati indipendentemente n Condivisione di oggetti che svolgono funzioni comuni n Wrapping di applicazioni legacy (anche non object oriented) l Dal punto di vista dello sviluppatore: n Modularizzazione delle applicazioni, separazione delle interfacce, costruzione incrementale n Riuso

8 CEFRIEL Fabiano Cattaneo - CORBA 8 Costruire applicazioni con i componenti l L’oggetto o componente sarà l’unità di produzione, distribuzione e manutenzione. l L’oggetto starà su un bus software (come CORBA o COM) e attraverso questo bus riceverà richieste di servizio e invierà le sue richieste e suoi risultati. l Quindi il componente è anche l’unità di deployment. l Le architetture software cambieranno in accordo con questo nuovo scenario... l … e così pure le modalità di packaging, le licenze e la manutenzione

9 CEFRIEL Fabiano Cattaneo - CORBA 9 Costruire applicazioni con i componenti: l’infrastruttura l Già oggi i bus software offrono servizi che i componenti possono ereditare (addirittura a run-time) per ottenere alti livelli di cooperazione con gli altri componenti. l L’infrastruttura intelligente favorisce lo sviluppo dei componenti: n aspetti come l’interoperabilità, la sicurezza, l’accesso concorrente, ecc. sono gestiti direttamente dall’infrastruttura l Costruire componenti diventa facile e alla portata di piccoli sviluppatori: non è infatti più necessario preoccuparsi dell’intera infrastruttura

10 CEFRIEL Fabiano Cattaneo - CORBA 10 L’infrastrutturaL’infrastruttura l Fornisce un’architettura predefinita. l Abbasserà i costi di produzione. l Abbasserà i costi per gli utenti finali n potranno decidere quali componenti servono n potranno anche decidere quando fare gli upgrade l Scalabilità: è indifferente che un componente si trovi su un PC stand-alone o su una rete planetaria, dal suo punto di vista non cambia nulla, se ne occupa l’infrastruttura l Saranno possibili “applicazioni” una-tantum: l’applicazione sarà semplicemente l’insieme di componenti coinvolti in una transazione, variabile di volta in volta

11 CEFRIEL Fabiano Cattaneo - CORBA 11 Primo: gli standard l OMG (Object Management Group), attivo dal 1989 nella definizione del bus software n uno dei primi esempi di middleware ad oggetti n ORB (Object Request Broker), permette di invocare metodi appartenenti ad oggetti remoti, in modo statico o dinamico n CORBA 2.0 (1994), architettura inter-ORB basata su TCP/IP (e opzionalmente su DCE) n il bus è estensibile con servizi modulari (es. comunicazione ad eventi, transazioni, licenze, ecc.) n contatti con altre organizzazioni di standardizzazione e produttori di software assicurano un’ampia accettazione dello standard

12 CEFRIEL Fabiano Cattaneo - CORBA 12 Object Request Broker (ORB) Object Services Application InterfacesDomain InterfacesCommon Facilities L’architettura di riferimento (OMA)

13 CEFRIEL Fabiano Cattaneo - CORBA 13 l Object Request Broker (ORB): permette la comunicazione in un ambiente distribuito (software bus) l Object Services (OS): servizi di applicabilità generale, utilizzabili per la costruzione di sistemi distribuiti l Common Facilities (CF): interfacce per funzionalità comuni a molti domini applicativi (mercati “orizzontali”: compound document, user interface, system management,...) l Domain Interfaces (DI): interfacce per funzionalità specifiche di un dominio (mercati “verticali”: business objects, healthcare, telecommunication, finance,...) l Application Interfaces (AI): interfacce non standardizzate, dipendenti dall’applicazione (specificate ed utilizzate da un singolo produttore) L’architettura di riferimento Componenti

14 CEFRIEL Fabiano Cattaneo - CORBA 14 l CORBA è l’architettura di riferimento per la costruzione di ORB (software bus) l Gli oggetti che si affacciano sul bus descrivono i servizi che mettono a disposizione definendone le interfacce mediante un Interface Definition Language (IDL) l Le interfacce descritte con IDL costituiscono delle specifiche; le implementazioni possono essere realizzate con un linguaggio qualsiasi (per cui esista un mapping IDL) l Oggetti con implementazioni scritte in linguaggi diversi possono interoperare (richiamare reciprocamente i metodi) l Oggetti collegati ad ORB diversi (anche di venditori diversi) possono interoperare (CORBA 2.0) L’architettura di riferimento ORB e CORBA

15 CEFRIEL Fabiano Cattaneo - CORBA 15 l Sono i “blocchi base” che consentono di costruire applicazioni distribuite l La specifica di un Object Service è costituita da un insieme di interfacce (IDL) e dalla descrizione della loro semantica (inglese) L’architettura di riferimento ORB e CORBA

16 CEFRIEL Fabiano Cattaneo - CORBA 16 Il modello ad oggetti l OMA definisce un modello parziale della computazione che include le caratteristiche principali della tecnologia ad oggetti l Un sistema ad oggetti è visto come un insieme di oggetti in cui i client possono richiedere un servizio agli oggetti server senza sapere in che modo il server realizza il servizio (qual è il codice da eseguire, qual è il formato dei dati) l Un client è schermato da un’interfaccia rispetto al modo in cui un server è realizzato

17 CEFRIEL Fabiano Cattaneo - CORBA 17 l Un oggetto in OMA è una entità che: n incapsula dati e operazioni n ha un’interfaccia ben definita n è univocamente identificabile n è in grado di eseguire i servizi richiesti da un client n può rappresentare un oggetto del mondo reale l Nota: nella visione OMA i client non devono necessariamente essere oggetti, anche se nelle situazioni più comuni un’entità si può comportare sia da client che da server Il modello ad oggetti Concetti base: oggetti

18 CEFRIEL Fabiano Cattaneo - CORBA 18 Il modello ad oggetti Scambio di messaggi l Attenzione: questo è un concetto generale, non di OMA l La comunicazione fra oggetti in un sistema ad oggetti avviene (logicamente) mediante scambio di messaggi l L’oggetto client invia un messaggio all’oggetto server l Il messaggio identifica, oltre al destinatario (server), anche l’operazione (servizio) che viene richiesta e porta con sé i parametri necessari al server per svolgerla l L’oggetto server che riceve il messaggio sceglie di eseguire un particolare metodo (cioè codice) in base all’operazione richiesta

19 CEFRIEL Fabiano Cattaneo - CORBA 19 l Nella terminologia OMA, una richiesta (request) viene inviata da un client ad un oggetto per richiedere un servizio l Una richiesta è costituita dal nome di una operazione, dall’identificazione dell’oggetto server, dai parametri dell’operazione, se necessari, e dal contesto in cui svolgere l’operazione, se necessario l Ricevuta una richiesta, un oggetto esegue il servizio relativo nel contesto specificato ed eventualmente restituisce i risultati prodotti o segnala che si è verificata una condizione anomala Il modello ad oggetti Richieste

20 CEFRIEL Fabiano Cattaneo - CORBA 20 l I parametri di una richiesta possono essere trasmessi dal client all’oggetto (ingresso), dall’oggetto al client (uscita) o in entrambi i sensi (ingresso-uscita) l Una richiesta può anche specificare un unico valore restituito come risultato della stessa (in stile funzionale) Il modello ad oggetti Parametri delle richieste

21 CEFRIEL Fabiano Cattaneo - CORBA 21 l Un modulo di richiesta (request form) è uno “schema” che può essere utilizzato più volte per inviare una richiesta l Un modulo di richiesta può essere definito mediante costrutti linguistici di uno pseudo-linguaggio di programmazione (IDL) o costruito programmaticamente (invocando le opportune funzioni) Il modello ad oggetti Moduli di richiesta

22 CEFRIEL Fabiano Cattaneo - CORBA 22 l I parametri di una richiesta sono costituiti dai valori appartenenti ai tipi definiti dal linguaggio IDL l Un particolare valore può identificare un oggetto, ed in questo caso costituisce il nome dell’oggetto (object name) l Se il nome di un oggetto identifica affidabilmente, ogni volta che viene utilizzato, un unico oggetto, viene anche detto riferimento dell’oggetto (object reference) Il modello ad oggetti Valori e oggetti

23 CEFRIEL Fabiano Cattaneo - CORBA 23 l Gli oggetti possono essere creati e distrutti, ma ciò non risulta direttamente visibile ai client l I client non hanno a disposizione meccanismi per richiedere la creazione o la distruzione di oggetti l Nuovi oggetti possono essere creati come effetto dell’emissione di richieste e si manifestano ai client nella forma di riferimenti trasmessi come parametri in uscita o risultati della richiesta Il modello ad oggetti Creazione e distruzione

24 CEFRIEL Fabiano Cattaneo - CORBA 24 l Un tipo è un’entità identificabile mediante un nome l Ogni tipo ha associato un predicato che permette di stabilire se un valore appartiene o no al tipo l I tipi vengono utilizzati per restringere l’insieme di valori utilizzabili come parametri o risultato delle richieste l Se tutti i valori che soddisfano il predicato di un tipo sono oggetti, allora quel tipo viene chiamato object tipe l OMA definisce un insieme di tipi base (numeri interi e in virgola mobile, caratteri, boolean, …) ed un insieme di costruttori di tipo (record, sequenze, array, …) Il modello ad oggetti Tipi

25 CEFRIEL Fabiano Cattaneo - CORBA 25 l Un’interfaccia è un’insieme di operazioni che un client può richiedere ad un oggetto l Un oggetto soddisfa un’interfaccia se è in grado di eseguire tutte le operazioni appartenenti all’interfaccia l Un oggetto può soddisfare più di una interfaccia l Un’interfaccia può specificare anche degli attributi che corrispondono ad un’operazione di lettura e ad una di scrittura (se l’attributo non è read-only) l Le interfacce sono descritte utilizzando il linguaggio IDL Il modello ad oggetti Interfacce

26 CEFRIEL Fabiano Cattaneo - CORBA 26 l Un’operazione è una entità con un nome che identifica un particolare servizio che un client può richiedere ad un oggetto l Il nome dell’operazione è chiamato operation identifier l Un’operazione è caratterizzata dalla propria signature: n l’elenco dei (tipi dei) parametri dell’operazione n il (tipo del) risultato n le eccezioni che l’operazione può sollevare n il contesto in cui può essere eseguita n la semantica dell’esecuzione Il modello ad oggetti Operazioni

27 CEFRIEL Fabiano Cattaneo - CORBA 27 l Un’operazione può avere una semantica di esecuzione di tipo: n at-most-once: se viene restituito un risultato, l’operazione richiesta è stata eseguita esattamente una sola volta; se viene restituita un’eccezione, l’operazione non è stata eseguita o è stata eseguita al più una volta n best-effort (one-way): può essere caratteristica solo di operazioni che non restituiscono risultato; il client invia la richiesta e poi prosegue, senza poter verificare se l’operazione è stata o meno completata con successo Il modello ad oggetti Semantica delle operazioni

28 CEFRIEL Fabiano Cattaneo - CORBA 28 l Un oggetto server deve poter eseguire le attività corrispondenti alle richieste che riceve dai client l È l’implementazione di un oggetto (object implementation) che esegue tali attività l Durante l’esecuzione delle operazioni l’implementazione di un oggetto può eseguire delle computazioni, può modificare il proprio stato interno e può inviare richieste ad altri oggetti Il modello ad oggetti Oggetti server

29 CEFRIEL Fabiano Cattaneo - CORBA 29 l Il servizio richiesto ad un oggetto viene svolto mediante l’esecuzione di codice (metodo) da parte dell’implementazione dell’oggetto l L’attivazione di un metodo è una particolare esecuzione di un metodo l Se l’oggetto (lo stato dell’oggetto) non è disponibile per una data attivazione di metodo, è innanzi tutto necessario ripristinare questo stato (attivazione dell’oggetto) l Il processo inverso si chiama disattivazione Il modello ad oggetti Esecuzione dei servizi

30 CEFRIEL Fabiano Cattaneo - CORBA 30 l Un object implementation è ciò che consente di definire: n lo stato di un oggetto n i metodi di un oggetto n le modalità con cui si seleziona un metodo in base al nome di un’operazione n come si rende disponibile lo stato di un oggetto ai metodi che vengono eseguiti n cosa accade dopo la creazione di un oggetto (quali metodi vengono resi disponibili?) Il modello ad oggetti Costruzione

31 CEFRIEL Fabiano Cattaneo - CORBA 31 Object Request Broker (ORB) Object Services Application InterfacesDomain InterfacesCommon Facilities L’architettura di riferimento (OMA)

32 CEFRIEL Fabiano Cattaneo - CORBA 32 CORBACORBA l Common Object Request Broker Architecture (CORBA): definisce l’interfaccia programmatica dell’ORB l Interface Definition Language (IDL): è il linguaggio con cui si descrivono le interfacce degli oggetti che si affacciano sul bus l L’interfaccia IDL nasconde ai client le modalità (linguaggio) con cui sono realizzati i server: separa l’interfaccia dall’implementazione l L’ORB rende trasparente ai client le modalità con cui localizzare, attivare e comunicare con i server

33 CEFRIEL Fabiano Cattaneo - CORBA 33 L’IDLL’IDL l Consente di separare le interfacce dalle implementazioni degli oggetti: n supporta l’ereditarietà multipla ed il controllo statico dei tipi n è indipendente dal linguaggio di programmazione utilizzato per implementare gli oggetti (mapping per linguaggi diversi: C, C++, SmallTalk, Java,...) n non è un linguaggio di programmazione, ma un linguaggio per la specifica di interfacce l È definito in modo da consentire un utilizzo sia statico che dinamico l È uno dei fattori che consentono l’interoperabilità

34 CEFRIEL Fabiano Cattaneo - CORBA 34 l L’IDL ha una sintassi simile a quella del C++ l Il compilatore IDL supporta il pre-processing in stile C++ (#include) l Una specifica scritta in IDL consiste in un insieme di: n dichiarazioni di tipi n dichiarazioni di costanti n dichiarazioni di eccezioni n dichiarazioni di interfacce n dichiarazioni di moduli L’IDLL’IDL

35 CEFRIEL Fabiano Cattaneo - CORBA 35 l Il “modulo” IDL coincide con il costrutto di modularizzazione tipico dei linguaggi di programmazione (scope di nomi) module Global { typedef... interface B... } L’IDL: moduli

36 CEFRIEL Fabiano Cattaneo - CORBA 36 l Un’interfaccia IDL definisce l’insieme di tipi, costanti, eccezioni, attributi ed operazioni messi a disposizione da un oggetto server l Ogni interfaccia ha un nome e può essere definita a partire da una o più interfacce esistenti (ereditarietà multipla) n l’interfaccia derivata può aggiungere nuovi elementi o ridefinire elementi esistenti n non è possibile ereditare da interfacce che definiscono lo stesso attributo o la stessa operazione n le ambiguità si risolvono qualificando l’elemento con il nome dell’interfaccia (::) L’IDL: interfacce

37 CEFRIEL Fabiano Cattaneo - CORBA 37 interface Base { const int N … } interface Derived: Base { const int N … typedef … } L’IDL: interfacce

38 CEFRIEL Fabiano Cattaneo - CORBA 38 l All’interno di un interfaccia o modulo è possibile dichiarare entità con valori costanti (espressioni costanti) const int MAX = MIN + LEN l È possibile associare un nome alla definizione di un nuovo tipo (typedef) l Sono previsti i tipi base ed i costruttori di tipo di derivazione C/C++ (escluse le classi), più qualche estensione (any, union discriminate, sequence, string) typedef sequence > DblSeq typedef string MyString L’IDL: costanti e tipi

39 CEFRIEL Fabiano Cattaneo - CORBA 39 l Le eccezioni possono essere dichiarate come strutture exception NotFound {string what} l Possono essere sollevate da operazioni chiamate e gestite dal chiamante. CORBA definisce un insieme di eccezioni standard l Le operazioni vengono dichiarate in un formato simile alle funzioni C, specificando in più la semantica di invocazione, l’elenco delle eccezioni che possono sollevare ed il contesto che richiedono void search(in Code what, out Item el) raises (NotFound) L’IDL: eccezioni ed operazioni

40 CEFRIEL Fabiano Cattaneo - CORBA 40 l All’interno di una interfaccia è possibile dichiarare attributi, che corrispondono logicamente ad una coppia di operazioni (una per modificare ed una per leggerne il valore) attribute float radius; readonly attribute position_t position; L’IDL: attributi

41 CEFRIEL Fabiano Cattaneo - CORBA 41 Object Request Broker (ORB) COBOLJavaCC++SmalltalkAda IDL IDL e interoperabilità l Attualmente esistono correlazioni (binding) fra IDL e: C, C++, Ada, Smalltalk, Java (COBOL, ObjectiveC) l È possibile specificare in IDL: n attributi e metodi di un oggetto n gerarchie di ereditarietà n eccezioni che un metodo può sollevare

42 CEFRIEL Fabiano Cattaneo - CORBA 42 Il ruolo dell’ORB l Costituisce un punto di contatto locale e ben identificabile attraverso cui i client possono invocare metodi dei server l Smista le richieste fra oggetti distribuiti l “Comprende” l’IDL e mantiene un repository contenente le interfacce e le implementazioni registrate nel sistema l Mantiene le informazioni di cui sopra all’interno di un sistema distribuito l Consente di costruire una “rete di ORB”

43 CEFRIEL Fabiano Cattaneo - CORBA 43 Object Request Broker Core Client IDL stub Client Dynamic Invocation Client IDL stub ORB Interface Static Skeleton Implementation Repository Interface Repository Object implementation Identica per tutti gli ORB Dynamic Invocation Dipende dall’interface del server Object Adapter Molteplici Object Adapter Struttura di un ORB

44 CEFRIEL Fabiano Cattaneo - CORBA 44 l Il client è un’applicazione scritta in un linguaggio per cui sia stato definito un binding con IDL (o che consenta di richiamare procedure scritte in quel linguaggio) l Non deve necessariamente essere un’applicazione object- oriented (es. Visual Basic, 4GL) l Client ed object implementation possono essere localizzati ovunque (il client non deve essere a conoscenza della localizzazione dell’object implementation) l Un oggetto può operare contemporaneamente da client e da server l Un client può invocare un metodo di un oggetto remoto di cui abbia un object reference e di cui conosca l’interfaccia Struttura di un ORB Client

45 CEFRIEL Fabiano Cattaneo - CORBA 45 l Un object reference consente di identificare in modo univoco un oggetto all’interno di un sistema costruito su di un ORB l CORBA non specifica in che modo debba essere realizzato, ma definisce il formato di un Interoperable Object Reference (IOR) l Il binding fra IDL ed un particolare linguaggio di programmazione definisce in modo univoco come mappare un object reference in un concetto del particolare linguaggio (puntatori in C/C++, riferimenti ad oggetti in SmallTalk, …) Struttura di un ORB Object reference

46 CEFRIEL Fabiano Cattaneo - CORBA 46 Struttura di un ORB Client IDL stub l Ogni stub corrisponde ad un’operazione del server che il client può invocare usando i meccanismi tipici del linguaggio di programmazione (chiamata di subroutine) l Lo stub viene costruito automaticamente a partire dall’IDL dell’interfaccia (IDL compiler) nel linguaggio prescelto l Dal punto di vista del client, lo stub è una chiamata di procedura locale l All’interno dello stub, vengono codificati (marshaling) i parametri da inviare al server, vengono decodificati i risultati ricevuti e vengono ri-sollevate le eccezioni sollevate dal server

47 CEFRIEL Fabiano Cattaneo - CORBA 47 Struttura di un ORB Dynamic invocation l Mediante una Dynamic Invocation Interface, in alternativa all’utilizzo di uno stub precompilato, il client può: n venire a conoscenza durante l’esecuzione dell’interfaccia di un oggetto n costruire ed inviare dinamicamente una richiesta per richiedere lo svolgimento di un’operazione qualsiasi l Dal lato server (Dynamic Skeleton Interface) n Permette ad un server di ricevere richieste senza aver dovuto compilare in precedenza l’interfaccia IDL l Un server non può distinguere se una richiesta è stata inviata da uno stub o mediante DII ed un client non può distinguere se un server risponde mediante uno skeleton o DSI

48 CEFRIEL Fabiano Cattaneo - CORBA 48 Struttura di un ORB Interface repository l Contiene la descrizione delle interfacce definite nel sistema l Può essere interrogato (da un oggetto, durante l’esecuzione) per ottenere informazioni sulle interfacce, sui metodi che le compongono, sui parametri l Le informazioni ottenute possono essere utilizzate per costruire dinamicamente le richieste (DII) l Gli oggetti presenti nel sistema possono anche aggiungere e modificare le informazioni memorizzate nel repository l Il repository consente al sistema di “auto-descriversi” l I servizi offerti dall’interface repository sono descritti mediante interfacce specificate in IDL

49 CEFRIEL Fabiano Cattaneo - CORBA 49 Invocazione statica o dinamica? l Gli stub statici: n possono essere utilizzati solo se si conoscono a priori i metodi che si vogliono invocare (compile time) n il loro utilizzo è praticamente trasparente al programmatore n consente controlli statici di correttezza n è efficiente l L’invocazione dinamica: n non richiede di conoscere i metodi (interfacce) prima dell’esecuzione n consente di scrivere codice generico

50 CEFRIEL Fabiano Cattaneo - CORBA 50 Struttura di un ORB ORB Interface l Consiste in un insieme di API di servizi offerti dall’ORB, utili sia per il client che per il server l Fra le API offerte vi sono quelle che operano direttamente su object reference n get_interface per ottenere una descrizione dell’interfaccia dell’oggetto corrispondente n get_implementation per ottenere una descrizione dell’object implementation corrispondente n is_nil per verificare se l’object reference identifica effettivamente un oggetto

51 CEFRIEL Fabiano Cattaneo - CORBA 51 Struttura di un ORB Object implementation l È l’insieme di codice e dati che costituiscono l’implementazione degli oggetti server e che ne definiscono stato e comportamento l Può essere realizzato in modi diversi (vedi i diversi tipi di Basic Object Adapter)

52 CEFRIEL Fabiano Cattaneo - CORBA 52 Struttura di un ORB Static Implementation Skeleton l È uno dei meccanismi con cui un oggetto server riceve le richieste dei client (l’altro è il DSI) l Costituiscono un meccanismo analogo a quello degli stub: n decodificano i parametri e li forniscono al metodo invocato n ricevono il risultato o le eccezioni e li codificano per rispedirli al client l Come gli stub si ottengono come prodotto della compilazione di interfacce descritte in IDL

53 CEFRIEL Fabiano Cattaneo - CORBA 53 Struttura di un ORB Implementation repository l Contiene informazioni sulle object implementation del sistema, gli oggetti istanziati, i loro identificatori, informazioni per la loro gestione

54 CEFRIEL Fabiano Cattaneo - CORBA 54 Struttura di un ORB Object Adapter l È il tramite fra il “mezzo trasmissivo” (ORB) ed object implementation l Supporta le operazioni più comunemente utilizzate da object implementation: n istanziazione di nuovi oggetti n attribuzione e gestione di object reference n ricezione delle richieste ed instradamento n registrazione nell’implementation repository l CORBA definisce un object adapter standard (Basic Object Adapter, BOA)

55 CEFRIEL Fabiano Cattaneo - CORBA 55 Struttura di un ORB Esempi di adapter l Basic Object Adapter (BOA): offre i servizi di base come generazione e gestione di object reference, invocazione di metodi, consegna delle richieste, registrazione, attivazione e disattivazione l Library Object Adapter (LOA): può sostituire il BOA se client e server fanno parte dello stesso processo (ORB = libreria), fornisce pochi servizi ma ottimizzati per il particolare utilizzo (in-process) l Object-Oriented Database Adapter (OODA): realizza una connessione con un database object-oriented e consente di accedere gli oggetti in esso memorizzati l Tutti gli adapter sono definiti specificandone le interfacce in IDL

56 CEFRIEL Fabiano Cattaneo - CORBA 56 Struttura di un ORB Diversi tipi di BOA l Shared server n il BOA attiva un server non appena riceve una richiesta per un oggetto gestito da quel server n un unico server può gestire più oggetti l Unshared server n ogni oggetto viene gestito da un server diverso, attivato dal BOA quando riceve una richiesta per quell’oggetto l Server-per-method n viene creato un server per ogni richiesta ricevuta l Persistente server n il server non viene attivato dal BOA, ma con altri mezzi n si comporta come uno shared server

57 CEFRIEL Fabiano Cattaneo - CORBA 57 Struttura di un ORB Diversi tipi di ORB Client & Implementation Resident Single-Process Library Resident Server or Operating- System Based IDL Client Obj Impl IDL ORB REQUEST IDL Client Obj Impl IDL ORB REQUEST IDL Client ORB IDL ORB Obj Impl REQUEST Fonte: OMG

58 CEFRIEL Fabiano Cattaneo - CORBA 58 Interoperabilità fra ORB l Lo standard CORBA 2.0 affronta il problema dell’interconnessione e dell’interoperabilità fra (sotto)sistemi distribuiti realizzati con ORB di fornitori diversi l Definisce un Internet Inter-ORB Protocol (IIOP), che costituisce un protocollo comune che tutte le implementazioni devono implementare, o verso cui devono fornire “half-bridge” opportuni

59 CEFRIEL Fabiano Cattaneo - CORBA 59 Interoperabilità fra ORB IDL Client Obj Impl IDL ORB IDL Client IDL ORB Obj Impl IDL Client ORB IDL ORB Obj Impl Fonte: OMG

60 CEFRIEL Fabiano Cattaneo - CORBA 60 Semantica delle richieste Formato dei messaggi Livello di trasporto Protocolli e interoperabilità Applicazioni CORBA IDL General Inter- ORB Protocol (GIOP) Internet Inter- ORB Protocol (IIOP) TCP/IP OSI Netware IPX/SPX DCE RPC TCP/IP DCE RPC OSI... Environment Specific Inter- ORB Protocols (ESIOP)

61 CEFRIEL Fabiano Cattaneo - CORBA 61 Protocolli e interoperabilità l General Inter-ORB Protocol (GIOP) n Definisce il formato dei messaggi che ORB di fornitori diversi possono scambiarsi n Definisce un formato comune dei dati (Common Data Representation, CDR) che può essere trasmesso su una rete fra piattaforme diverse l Internet Inter-ORB Protocol (IIOP) n Specifica come i messaggi GIOP vengono trasmessi su una rete TCP/IP n Permette di connettere ORB diversi mediante Internet l Environment Specific Inter-ORB Protocol (ESIOP) n Permette di utilizzare protocolli di trasporto diversi

62 CEFRIEL Fabiano Cattaneo - CORBA 62 Scenari d’uso Server WWW e CORBA WEB Server C G I Programs IIOP (CORBA) TCL HTTP -- HTML -- GIF, JPEG -- AV, WAV Sea of Objects (CORBA) WEB Browser Applications IIOP (CORBA) PROGRAMSPROGRAMS Fonte: OMG

63 CEFRIEL Fabiano Cattaneo - CORBA 63 Scenari d’uso Java e CORBA WEB Server C G I Programs IIOP (CORBA) TCL Sea of Objects (CORBA) IIOP Java Enabled WEB Browser Java Orblet IIOP PROGRAMSPROGRAMS HTTP -- HTML -- GIF, JPEG -- AV, WAV IIOP Fonte: OMG

64 CEFRIEL Fabiano Cattaneo - CORBA 64 Scenari d’uso Browser e CORBA WEB Server C G I Programs IIOP (CORBA) TCL HTTP -- HTML -- GIF, JPEG -- AV, WAV Sea of Objects (CORBA) WEB Browser CORBA Enabled IIOP PROGRAMSPROGRAMS Fonte: OMG

65 CEFRIEL Fabiano Cattaneo - CORBA 65 Windows app COM/CORBA link ORB Uno scenario applicativo ragionevole deve prevedere la presenza di componenti applicativi di tipo diverso ed una infrastruttura in grado di farli interoperare. CORBA server standalone CORBA client ORB JAVA/CORBA client JAVA VM (browser) JAVA ORBlet Fonte: OMG Scenari d’uso

66 CEFRIEL Fabiano Cattaneo - CORBA 66 standalone CORBA client Windows app COM/CORBA link ORB Client CORBA standalone possono essere scritti in molteplici linguaggi ed accedere a server scritti in linguaggi diversi ed operanti sulle piattaforme più disparate in modo trasparente. ORB IIOP CORBA server JAVA/CORBA client JAVA VM (browser) JAVA ORBlet Scenari d’uso

67 CEFRIEL Fabiano Cattaneo - CORBA 67 standalone CORBA client JAVA/CORBA client Windows app JAVA VM (browser) COM/CORBA link ORB CORBA server IIOP JAVA ORBlet Anche i client Java possono operare su piattaforme diverse, ovunque sia disponibile un browser abilitato. Scenari d’uso

68 CEFRIEL Fabiano Cattaneo - CORBA 68 standalone CORBA client Windows app COM/CORBA link ORB Un client scritto in Java può contemporaneamente accedere a server Java mediante RMI. Se il client è un applet può anche sfruttare le funzionalità del browser (multimedialità, audio, video, HTML, …). ORB CORBA server HTTP JAVA/RMI server HTTP server JAVA/CORBA client JAVA VM (browser) JAVA ORBlet Scenari d’uso

69 CEFRIEL Fabiano Cattaneo - CORBA 69 standalone CORBA client Lo standard OMG per l’interoperabilità COM/CORBA consente ad una applicazione Windows di accedere ad un server CORBA mediante IIOP o DCOM. Contemporaneamente, l’applicazione Windows può accedere ad un server DCOM. ORB CORBA server IIOP or DCOM JAVA/CORBA client JAVA VM (browser) JAVA ORBlet DCOM server Windows app COM/CORBA ORB Scenari d’uso

70 CEFRIEL Fabiano Cattaneo - CORBA 70 L’architettura di riferimento (OMA) Object Request Broker (ORB) Object Services Application InterfacesDomain InterfacesCommon Facilities

71 CEFRIEL Fabiano Cattaneo - CORBA 71 Object Services l Naming Service: mantiene i collegamenti fra nomi simbolici e riferimenti programmativi agli oggetti (name server) l Event Service: generazione, trasmissione, registrazione, ricezione di eventi l Life Cycle Service: copia, spostamento e rimozione di grafi di oggetti collegati l Relationship Service: visita di grafi di oggetti collegati (senza attivare i singoli oggetti), gestione della consistenza l Persistent Object Service: supporto alla gestione dello stato persistente degli oggetti

72 CEFRIEL Fabiano Cattaneo - CORBA 72 Object Services l Transaction Service: gestione di transazioni in ambiente distribuito l Concurrency Control Service: accesso coordinato a risorse condivise (lock) in ambiente distribuito l Externalization Service: salvataggio e ripristino dello stato di un oggetto (su supporti di salvataggio “rimovibili”) l Licensing Service: controllo sull’uso di “proprietà intellettuali” l Query Service: interrogazioni su collezioni di oggetti l Property Service: creazione e gestione di insiemi coppie nome-valore (attributi o proprietà)

73 CEFRIEL Fabiano Cattaneo - CORBA 73 Object Services l Security Service: identificazione ed autenticazione, autorizzazione e controllo degli accessi, auditing, sicurezza nella comunicazione, non ripudio l Time Service l Collection Service l Trader Service: offerta di servizi di un service provider

74 CEFRIEL Fabiano Cattaneo - CORBA 74 FrameworksFrameworks l A differenza dei componenti elementari citati, un framework costituisce un componente di livello più alto, che offre funzionalità direttamente utilizzabili dall’utente finale l All’interno di un framework si ritrovano oggetti che implementano le interfacce dei componenti elementari citati

75 CEFRIEL Fabiano Cattaneo - CORBA 75 Object Request Broker (ORB) FrameworksFrameworks AI OS CF DI OS CF DI OS CF OS Object Framework

76 CEFRIEL Fabiano Cattaneo - CORBA 76 BibliografiaBibliografia l IONA Technologies. OrbixWeb Programming Guide. Release 2.0. l OMG. A Discussion of the Object Management Architecture. January 1997. http://www.omg.org l OMG. The Common Request Broker: Architecture and Specification. Revision 2.0, July 1995, Updated July 1996 l R. Orfali, D. Harkey, J. Edwards. The Essential Distributed Objects Survival Guide. John Wiley & Sons, 1996 l Visigenic. VisiBroker for Java. Programmer’s Guide Release 2.5, 1997