Middleware e CORBA 1 Corso di Architetture Distribuite e Servizi di Rete Antonio Corradi & Paolo Bellavista Università degli Studi di Bologna MASTER integratori di Sistema MIDDLEWARE e CORBA Middleware e CORBA 2 Definizione di MIDDLEWARE Insieme degli strumenti che permettono la integrazione di diverse applicazioni e servizi da utilizzare in ambienti aperti Middleware comprendono strumenti per lo sviluppo fino al livello di applicazione RPC middleware Chiamate di Procedura Remote come strumento di invocazione di livello applicativo tra ambienti diversi MIDDLEWARE MIDDLEWARE
58
Embed
MIDDLEWARE e CORBA - unibo.itCORBA.pdf · 2005-05-09 · Middleware e CORBA 19 OMG- Object Management Group CORBA creato nel 1989 con 440 aziendeMicrosoft, Digital, HP, NCR, SUN,
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Middleware e CORBA 1
Corso diArchitetture Distribuite e Servizi di Rete
Antonio Corradi & Paolo Bellavista
Università degli Studi di BolognaMASTER integratori di Sistema
MIDDLEWARE e CORBA
Middleware e CORBA 2
Definizione di MIDDLEWAREInsieme degli strumenti che permettono la integrazione di diverse applicazioni e servizi da utilizzare in ambienti apertiMiddleware comprendono strumenti per lo sviluppo fino al livello di applicazione
RPC middlewareChiamate di Procedura Remote come strumento di invocazione di livello applicativo tra ambienti diversi
MIDDLEWAREMIDDLEWARE
Middleware e CORBA 3
Lo Strato di software che risiede tra la applicazione e i componenti di rete, di sistema operativo locale, di hardware eterogeneo, di aree di applicazioni diverse, ecc.
MIDDLEWAREMIDDLEWARE
Lo strato di disaccoppiamento tra i livelli di sistema consente la semplificazione del progetto sia della parte applicativa sia del supporto
Middleware e CORBA 4
Il Middleware viene spesso invocato in modo trasparente e fornisce l’accesso uniforme a funzioni locali eterogenee• Spesso viene usato per integrare sistemi legacy
preesistenti e necessari alla logica aziendale• Spesso si propone come uno standard (di fatto o
di comitato) per una comunità specifica
MIDDLEWAREMIDDLEWARE
Middleware e CORBA 5
MIDDLEWARE forniscono servizi differenziati In senso esteso per molte aree diverse
mail, electronic data interchange…)Control (thread manager, scheduler,
transaction manager, …) System Management (accounting, configuration, security,
performance, fault management, …event handling)
SERVIZI di un MIDDLEWARESERVIZI di un MIDDLEWARE
Middleware e CORBA 6
MIDDLEWARE tra Applicazione e Sistema Operativo
Applicazione
Domain-specific Middleware Service
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
Sistema Operativo
Hardware
MIDDLEWARE come livelli di sistemaMIDDLEWARE come livelli di sistema
Middleware e CORBA 7
Host Infrastructure Middleware
Livello che incapsula e prepara i servizi locali per la distribuzione e per facilitare la comunicazione
Esempi: JVM, .NET, altri modelli locali
MIDDLEWARE come livelli di sistemaMIDDLEWARE come livelli di sistema
Applet e Applicazioni Java
Classi Base Estensione di Classi di Java
Java Virtual Machine
Interfaccia di portabilità
Adattatore
Browser
S.O.
Hw
Adattatore
Browser
S.O.
Hw
Adattatore
Browser
S.O.
Hw
Adattatore
Browser
S.O.
Hw
Interconnessione via Rete
Si forniscono delle API che permettono di avere un supporto locale unificato per i diversi sistemi
Middleware e CORBA 8
Distribution Middleware
Livello che fornisce i modelli della programmazione distribuita e facilita le applicazioni distribuite configurando e gestendo le risorse distribuite
Esempi: RMI, CORBA, DCOM, SOAP, …
Sistemi che permettono una più facile comunicazione e coordinamento dei diversi nodi che partecipano al sistema introducendo un modello delle risorse e
• API di comunicazione secondo un modello concettuale
• altre funzionalità accessorie per la comunicazionesupporto di nomi, di discovery, …
MIDDLEWARE come livelli di sistemaMIDDLEWARE come livelli di sistema
Middleware e CORBA 9
Common Middleware Services
Servizi aggiuntivi di più alto livello per facilitare la vita del progettista applicativo e per consentire una programma-zione orientata ai componenti fornendo supporto
Esempi: CORBAServices, J2EE, .NET Web services
Alcune funzioni addizionali per consentire operazioni facilitatespesso ispirate ad una architettura comune ed a un modello di supporto
MIDDLEWARE come livelli di sistemaMIDDLEWARE come livelli di sistema
Middleware e CORBA 10
Domain-specific Middleware Service
Insieme di livelli applicativi dedicati a domini diversi
Esempi: Alcuni gruppi di lavoro stanno definendo funzionalitàad-hoc per settori diversi con obiettivi anche molto differenziati di standardizzazione Task Force di lavoro in ambito OMG
Electronic Commerce TF, Finance (banking and insurance) TF, Life Science Research Domain TF,
Syngo Siemens Medical Engineering Group,
Boeing Bold Stroke basato su CORBA
MIDDLEWARE come livelli di sistemaMIDDLEWARE come livelli di sistema
Wide Area Distributed Middleware (Web)Middleware che permette l’accesso in lettura e anche scrittura ad un insieme globale di informazioni Le operazioni avvengono per un sistema globale• Moltissimi domini amministrativi di gestione • Moltissimi utenti• Moltissimi host partecipanti e • Molta eterogeneità di banda, interconnessione, …
Questi non sono veri e propri middleware ma forse solo sistemi di accesso e messa in linea di informazioniWeb come esempio principe
MIDDLEWARE !?MIDDLEWARE !?
Middleware e CORBA 13
RPC come strumenti per il C/S• Interface Definition Language (IDL) per l’accordo• Sincronicità: il cliente bloccato in modo sincrono bloccante in
attesa della risposta dal Server• Gestione eterogeneità dei dati• Uso di Stub per la Trasparenza• Binding spesso statico (o poco dinamico)
Modello un po’ rigido, poco scalabile e replicabile con QoS Il server deve essere presente e prevedere i processi necessari in modo esplicito Non si tiene conto di eventuali ottimizzazioni nell’uso delle risorse
RPC MIDDLEWARERPC MIDDLEWARE
Middleware e CORBA 14
Message Oriented Middleware (MOM)La distribuzione dei dati e codice avviene attraverso lo scambio di messaggi
Scambio messaggi tipati e non tipati sia sincrono sia asincrono con strumenti ad-hoc
• ampia autonomia tra i componenti• asincronicità e persistenza delle azioni• gestori (broker) con politiche diverse e QoS diverso• facilità nel multicast, broadcast, publish / subscribe
Esempio: Middleware basati su messaggi, code e gestori MQSeries IBM, MSMQ Microsoft, JMS SUN
MOM MIDDLEWAREMOM MIDDLEWARE
Middleware e CORBA 15
Distributed Object Computing (DOC) MiddlewareLa distribuzione dei dati e codice avviene attraverso richieste di operazioni tra clienti e servitori remoti
Uso di oggetti come framework e di un broker come intermediario nella gestione delle operazioni
• il modello ad oggetti semplifica il progetto• il broker fornisce i servizi base e molti servizi addizionali• alcune operazioni si possono fare in modo automatico• la integrazione di sistemi è facilitata e incentivata• la tecnologia open source è favorita
Esempi: CORBA, .NET e COM, Java
OO e DOC MIDDLEWAREOO e DOC MIDDLEWARE
Middleware e CORBA 16
Adaptive & Reflective MiddlewareIn alcuni casi la visibilità dei livelli sottostanti può diventare fondamentale per raggiungere ottimizzazione
Uso di middleware che si possono adattare allaapplicazione specifica anche in modo
dinamico, reattivo e radicale• variazioni statiche dipendenti dal componente• variazioni dinamiche dipendenti dal sistemaCon la Riflessività, le politiche di azione sono espresse e visibili nel middleware stesso e si possono cambiare comecomponenti del sistemaSi raggiunge adattamento e flessibilità durante l’esecuzioneEsempi: ancora non molti diffusi
MIDDLEWAREMIDDLEWARE
Middleware e CORBA 17
Sistemi ad oggetti APERTI Object-Oriented
Relazioni cliente/servitore nel distribuito vincolata nell’ambito di sistemi ad oggetti
Obiettivo: tutte le risorse (oggetti o meno) devono essere a disposizione di tutti gli utilizzatori, comunque siano stati specificate e da chiunque siano rese disponibili
Sistema multi-linguaggio e di integrazionecon componenti legacy anche non ad oggetti
MOLTI PROGETTI simili in questa direzione
Open Software Foundation Distributed Computing Environment DCE - RPC
Ansa Ansaware - Ambiente distribuito e standardBBN CHRONUS - Ambiente di servizi con ereditarietà
MIDDLEWARE: AD OGGETTI MIDDLEWARE: AD OGGETTI -- DOCDOC
Middleware e CORBA 18
Possibile infrastruttura per la interazione tra ambienti diversi supera i problemi introdotti da approcci ad-hoc
• funzioni di conversione custom• conversione in formato generico• wrapper• protocollo comune
MIDDLEWARE: ETEROGENEITMIDDLEWARE: ETEROGENEITÀÀ
Cliente ServitoreMiddleware
GUI
DSOM
Sist. Operativo
Oggetti
Sist. Operativo
Groupware
DBMS
DSOM
ServiziSQL Mail ORB
DSOMsnmp CMIP DME
NOSDirectory SecurityRPC Messaggi
TrasportoTCP/IP SNA
DSOM
NetBIOS IPX/SPX
Middleware e CORBA 19
OMG- Object Management Group
CORBA creato nel 1989 con 440 aziende Microsoft, Digital, HP, NCR, SUN, OSF, etc. con l'obiettivo di creare un sistema di gestione di una architettura distribuita
Common Object Request Broker Architecture
CORBA standard v1 1991, v1.2 1992v2 1996, v3 2000
Orbix SunOS Solaris, Iris, Windows NT, HP/UX, AIX, OSF/1, UnixWare
DSOM IBM
MIDDLEWARE: CORBAMIDDLEWARE: CORBA
Middleware e CORBA 20
STANDARD SISTEMI APERTI AD OGGETTI
modelli ad oggetti diversi con possibilità di integrazione e interazione reciproca completa anche provenendo da linguaggi ed ambienti diversi
• definizione di una interfaccia per oggetto
• definizione della interazione tra oggetti
• bus per integrazione di oggetti progettati in linguaggi diversi
• definizione della interazione anche tra sistemi diversi con diversi gestori
MIDDLEWARE: CORBAMIDDLEWARE: CORBA
Middleware e CORBA 21
ENTITÀ da mettere in relazione:
cliente e implementazione di un oggetto per il servizio
oggetto entità che fornisce servizi
richiesta meccanismo per manifestare esigenza di un servizio
tipo entità per classificare gli oggetti
interfaccia descrizione delle operazioni possibili per un insieme di oggetti
operazione servizio con nome che può essere richiesto ad un oggetto
MIDDLEWARE: CORBAMIDDLEWARE: CORBA
Middleware e CORBA 22
Common Object Request Broker ArchitectureCORBA come ambiente comune ancheObject Management Architecture
Il cuore è il gestore dei nomi (broker) che consente i collegamenti in modo statico e dinamico tra le entitàObject Request Broker (ORB)
• controllo allocazione e visibilità di oggetti
• controllo dei metodi e della comunicazione
• controllo di servizi accessori disponibili automaticamente nella OMA
• gestione facilitata dei servizi
MIDDLEWARE: CORBAMIDDLEWARE: CORBA
Middleware e CORBA 23
Struttura ORBAORB come un bus di interconnessione
CORBA come BUSCORBA come BUS
Applications Object
Tutti gli oggetti applicativi gestitipossono appartenere ad ambienti diversi e devono potere comunicare senza un riprogetto
Middleware e CORBA 24
ORB per la comunicazione degli oggetti locali ed anche per la comunicazione tra ORB diversi
In un solo sistema CORBA o in più sistemi OMA coordinando broker diversi tra loro
CORBA come BUSCORBA come BUS
Oggetti Applicativi
ORB 1
Cliente Servitore
ORB 2
logico
dinamico
Oggetti Applicativi
Cliente Servitorelogico
dinamico
Object Request Broker
Middleware e CORBA 25
Ogni componente può legarsi agli altri, anche non noti, usando il servizio di uno o più ORB (anche non noti a priori)
Insieme di componenti addizionali di ambiente
Object Services o CORBA Services
Operazioni fondamentali per oggetti
• naming e trading service
• event e notification service
Oltre ad operazioni ulteriori (o servizi)
Per la gestione del tempo di vita, relazionali, transazioni, controllo concorrenza, sicurezza
Common Facilities CF (orizzontali)Insieme di funzionalità specificheInterfaccia utente (client-site), Management Sistema, Informazioni, Task (server-site)
Domain Interfaces (verticali)funzionalità dedicate ad aree applicative, ad es.manifacturing, telecommunications, electroniccommerce, transportation, business objects, healthcare, finance, life science, …
Application InterfacesNon standardizzate in alcun modo e dipendenti dalla applicazione
Identica interfaccia per tutte le implementazioni di ORB
Possibili adattatori d'oggetto multipli
Una stub ed uno scheletro per ogni tipo d'oggetto
Interfaccia ORB-dipendente
interfaccia di chiamata verso l'alto
interfaccia di chiamata normale
Scheletrostatico
Adattatore d'oggetto
Nuovo, introdotto con CORBA 2.0
Middleware e CORBA 32
Interface Definition Language (CORBA IDL) deve coordinare la identificazione dei servizi statici richiesti e offerti in diversi linguaggi
//OMG IDL
interface Factory
{ Object create();
};
Questa interfaccia consente di riferire un oggetto di tipo factory e di chiedere la operazione create (senza parametri di in e out) di un oggetto riconosciuto
Con IDL si devono definire nuove interfacce e nuovi tipi secondo necessità e farli riconoscere e registrare
CORBA IDL per MULTILINGUAGGIOCORBA IDL per MULTILINGUAGGIO
Middleware e CORBA 33
Interface Definition Language (CORBA IDL) permette di generare nei diversi linguaggi componenti automatiche di appoggio (stub e skeleton) per la funzionalità dei clienti e servitori
Lo stub permette di lavorare sul messaggio dalla parte del cliente (marshalling) agendo come proxy del cliente
Lo skeleton collabora con l’ORB per prendere la richiesta e adattarla al server (unmarshalling) girandogli la richiesta
In questo modo lavoriamo producendo un legame statico tra interfaccia e cliente e servitore. Entrambi sono legati alla interfaccia dallo stub e skeleton creati prima della esecuzione
CORBA IDL CORBA IDL --> STUB E SKELETON> STUB E SKELETON
Middleware e CORBA 34
Adattatore (Object Adapter) permette di superare disomogeneità e differenze tra la interfaccia assunta dal chiamante e quella attesa dal servitore
Ha compiti tipici:
• funzionalità di registrazione dell’oggetto
• generazione dei riferimenti esterni all’oggetto
• attivazione dei processi interni server e dell’oggetto stesso
• demultiplexing delle richieste in modo da disaccoppiarle
• invio delle richieste (upcall) agli oggetti registrati
I primi adattatori erano BOA (Basic), poi POA (Portable)
CORBA ADAPTERCORBA ADAPTER
Middleware e CORBA 35
Interface Repository consente di accedere a tutti i tipi di dati IDL e di accedere alle interfacce esportate dagli oggetti presenti e disponibili durante la esecuzione
Le interfacce sono traslate nei linguaggi di programmazione diversi in cui i componenti sono progettati e compilati (binding statico)
Ci sono casi in cui l’approccio statico non è attuabile: ungateway che permette di accedere alle interfacce CORBA di un ambiente che non può essere ricompilato ogni volta che si aggiunge una nuova interfaccia
IR permette di avere le interfacce presenti dinamicamente e di decidere al momento della esecuzione (binding dinamico)
OBJECT REPOSITORY in CORBAOBJECT REPOSITORY in CORBA
Middleware e CORBA 36
Definizione (dalla versione 2) di Protocolli InterORB per stabilire come fare interagire diversi sistemi CORBA
protocollo per interoperabilità ORB-to-ORB
General Inter-ORB Protocol (GIOP)
Molto diffuso per la interoperabilità per Internet su TCP/IP
Internet Inter-ORB Protocol (IIOP)
SISTEMI CORBA DIVERSISISTEMI CORBA DIVERSI
Oggetti Applicativi
ORB 1
Cliente Servitore
ORB 2
protocolli GIOP / IIOP
Middleware e CORBA 37
Visione di insieme della architettura
CORBA ARCHITETTURACORBA ARCHITETTURA
Middleware e CORBA 38
ORB coordina le richieste degli oggetti clienti di competenza, in modo trasparente da:
• posizione e implementazione dell’oggetto remoto
(indipendenza dal linguaggio)
• comunicazione specifica usata e disponibile
Uso di riferimenti ad oggetti esistenti (non creati da CORBA) ottenuti attraverso:
• creazione esplicita esterna di oggetto
• utilizzo di directory di oggetti
• conversione di riferimenti in stringhe e viceversa (oggetti riferiti e traslati in stringhe, poi riottenuti)
Necessità di servizi di nome (Trading e Naming service)
ORB funzioni CoreORB funzioni Core
Middleware e CORBA 39
CORBA IDL
interfacce come insiemi di metodi ed attributi
distinzione tra definizione e implementazione
ereditarietà multipla delle interfacce
definizione eccezioni
gestione automatica degli attributi
mappaggi per linguaggi diversi ed ambienti diversi
Il compilatore può ottenere automaticamente stub per clienti/servitori anche usando linguaggi diversi
CORBACORBA-- IDLIDL
Middleware e CORBA 40
INTERFACE DEFINITION LANGUAGE (OMG IDL) introdotti per garantire flessibilità nella distribuzione su piattaforme eterogenee
Sono linguaggi dichiarativi per interfacce e dati
Molti IDL diffusi sono procedurali
* OSI ASN.1 / GMDO
* ONC XDR (SUN RPC)
* Microsoft ODL
CORBA IDL è un linguaggio object-oriented (derivato dal C++)
Ovviamente i diversi IDL sono non compatibili tra di loro, anche se spesso sono diversi solo per questioni di sintassi e di sistemi di identificazione e nomi delle entità
CORBACORBA-- IDLIDL
Middleware e CORBA 41
Static Invocation Interface (SII)
Il compilatore e gli strumenti risolvono le chiamate prima della esecuzioneTutte le invocazioni sono controllate in anticipo e sicure
nessun controllo dinamico nei confronti della interfaccia
Il cliente si lega allo stub e fa la richiesta dopo essersi collegato all’ORB (invocazione sincrona)
Il servitore si è legato allo skeleton e viene attivato dall’objectadaptor (POA) per rispondere alla richiesta
In caso il (un) servitore non sia attivo, il POA lo attiva e gli passa la richiesta
BINDING STATICO in CORBABINDING STATICO in CORBA
Middleware e CORBA 42
Dynamic Invocation Interface (DII) e
Dynamic Skeleton Interface (DSI)
necessari per inviare le richieste e per fornire operazioni senza prevedere staticamente legame con una interfaccia
cioè per legarsi ad oggetti che non esistono al momento della compilazionecomportamento DINAMICOIl cliente si appoggia a run-time sull’interface repositoryper la conoscenza dell’interfaccia d’oggetto di interesse
In questo caso si possono assumere invocazioni meno sincronizzate e più varie tra il cliente e il servitore (forme diverse di asincronicità)
BINDING DINAMICO in CORBABINDING DINAMICO in CORBA
Middleware e CORBA 43
API per comporre la richiesta e pseudo oggetto Requestpseudo interface Request {// Pseudo IDL
Status add_arg (in Identifier name, in TypeCode arg_type,in void *value, in long len, in Flag arg_flag );
Status invoke (in Flags invoke_flags // flag invocazione);
Status delete ();
Status send (in Flags invoke_flags // flag invocazione);
Status get_response (in Flags response_flags //flag risposta);
}
La richiesta viene preparata e la chiamata dinamica comporta un costo più elevato rispetto alla statica
Anche modalità oltre la sincrona, Deferred SynchronousInvocation e Oneway Invocation
BINDING DINAMICO in CORBA (DII)BINDING DINAMICO in CORBA (DII)
Middleware e CORBA 44
Per potere invocare la richiesta Request in modo dinamico
un metodo (invoke) permette la invocazione dinamicapseudo interface ServerRequest {// Pseudo IDL
L’oggetto server deve implementare una interfaccia che prevede la invoke da parte dell’ORB
Controllo dinamico della correttezza dei parametri
BINDING DINAMICO in CORBA (DSI)BINDING DINAMICO in CORBA (DSI)
Middleware e CORBA 45
La normale modalità è la sincrona bloccante
In caso di guasti o problemi, il cliente riceve una eccezione diquelle previste dalla interfaccia
Semantica at-most-onceLa invocazione sincrona statica costa meno della dinamicacorrispondente
Altre modalità per la sola invocazione dinamica:
Oneway Invocation nessuna risposta (semantica best effort)
Deferred Synchronous risposta da ritrovare in tempi successivi con attesa solo quando necessario (at-most-once)
SEMANTICA INVOCAZIONI in CORBASEMANTICA INVOCAZIONI in CORBA
Middleware e CORBA 46
Gli Adattatori sono i componenti responsabili della flessibilità di CORBAI molteplici adattatori devono arrivare alla implementazione dei diversi oggetti servitori e comandare la esecuzione concreta
Si parla di servant per le attività che lavorano sugli oggetti concreti per fornire le funzioni del server
Registra Attiva Invoca Accedeimplementazione l'oggetto il metodo ai servizi
del BOA
Implementazione dell'Oggetto
ORB
Basic Object AdapterScheletro
Attivaimplementazione
Middleware e CORBA 47
Gli Adattatori controllano la esecuzione del server astratto attraverso i servant concreti che lavorano sul codice del servizioMOLTI MODI DI ATTIVAZIONE NEL SERVERattivazione per ogni richiesta (thread_per_request)
un processo viene creato nell'oggetto per servizio
attivazione iniziale di un pool (pool di thread)
ogni oggetto riceve il suo processo da un pool creato inizialmentesenza il costo della creazione
attivazione per sessione (thread_per_session)
ogni cliente ha un processo dedicato alla interazione
Anche altre modalità: un thread per ogni servantuna sola attivazione per più oggetti server
Gli Adattatori controllano la esecuzione delle operazioni nei server attraverso il concetto di servantUSO di SERVANT
Un servant è la parte di oggetto che mette a disposizione il codice da eseguire su richiesta di un cliente (entità fortemente dipendenti dal linguaggio di programmazione e dalla specifica implementazione del servitore)
Il POA ha il compito di comporre la immagine dell’oggetto CORBA server. Potrebbe essere presente:
• un unico servant
• anche molti diversi da fornire alle diverse richieste
Un POA decide i propri servant e la politica di gestione
Funzioni di ADATTATOREFunzioni di ADATTATORE
Middleware e CORBA 53
Necessità di identificatori da passare tra ambienti diversi
CORBA 1.2 non prevedeva nomi unici
CORBA 2 supporto per nomi unici
Object Reference come nomi non unici associati ad un servizio
ObjectRef al passaggio viene convertito da un sistema di nomi in un proxy nell'ambiente del ricevente per potere essere utilizzato
ObjectRef possono essere passati da un ambiente ad un altro ed essere utilizzati dovunque ma non necessariamente per lo stesso oggetto
In un ambiente ricevente il riferimento potrebbe essere per un oggetto diverso con la stessa interfaccia
in caso di stato sul server, problemi
RIFERIMENTI AD OGGETTI in CORBARIFERIMENTI AD OGGETTI in CORBA
Middleware e CORBA 54
I middleware più usati devono prevedere risposte anche ad esigenze spicciole e a dettagli ulteriori
I programmatori di CORBA si aspettano di potere:
- progettare velocemente nuovi componenti
- integrare vecchi componenti legacy
- potere utilizzare strumenti esistenti e componenti di ausilio pronti
- potere integrare le applicazioni con facility disponibili
MiddlewareMiddleware
Middleware e CORBA 55
ARCHITETTURA CORBAARCHITETTURA CORBA
Middleware e CORBA 56
I componenti essenziali di CORBA
* Object Request Broker (ORB)
* Interface Definition Language (IDL)
* Basic (e altri) Object Adapter (BOA)
* Static Invocation Interface (SII)
* Dynamic Invocation Interface (DII)
* Interface Repository (IR)
* Protocolli per Integrazione (GIOP)
COMPONENTI DI CORBACOMPONENTI DI CORBA
Middleware e CORBA 57
CORBA mantiene i componenti essenziali anche nella sua evoluzione ma si arricchisce di strumenti e di componentiper ovviare ai problemi man mano delineatiper fornire un migliore supportoComponenti essenziali sempre gli stessi
• Interazione tra ambienti di linguaggi diversi
• Aiuti per l’uso di ambienti di linguaggi diversi
• Strumenti per ottenere QoS in ambienti di linguaggi diversi
• Nuove utilità generali e per domini specifici
• Nuove realizzazioni ed integrazione con diversi ambienti di sviluppo esistenti
CORBA 3
CORBA VERSIONICORBA VERSIONI
Middleware e CORBA 58
Visione di insieme della architettura base di supporto al servizio
CORBA ARCHITETTURACORBA ARCHITETTURA
Middleware e CORBA 59
Visione di insieme della architettura base di supporto al servizio
CORBA ARCHITETTURACORBA ARCHITETTURA
Middleware e CORBA 60
Definizione (dalla versione 2) di Protocolli InterORB per stabilire come fare interagire diversi sistemi CORBAprotocollo di interoperabilità tra ORBGeneral Inter-ORB Protocol (GIOP)
Specifica comune della rappresentazione dei dati, del formato dei messaggi, dell’interazione con messaggi di trasporto (assunzioni semantiche: reliable, connection, …)
per Internet su TCP/IP Internet Inter-ORB Protocol (IIOP)
SISTEMI CORBA DIVERSISISTEMI CORBA DIVERSI
Middleware e CORBA 61
Linguaggio per definire le interfacce in CORBA indipendente dai singoli linguaggi concreti di programmazione
CORBA IDLCORBA IDL
Middleware e CORBA 62
CORBA è un ambiente in cui usiamo riferimenti remoti e non muoviamo oggetti (oggetti fissi) vista la eterogeneitàdei singoli ambienti concreti di deploymentI riferimenti remoti sono il modo di richiedere operazioni ad altri componenti con interfaccia CORBA
Le interfacce prevedono: attributi, operazioni, eccezioni(attributi acceduti attraverso operazioni di get e di set)(operazioni con argomenti di in o/e out)Le interfacce in ereditarietà multipla
Le interfacce sono anche racchiuse in moduli(per aggregazioni logiche)
CORBA IDLCORBA IDL
Middleware e CORBA 63
module ContoCorrente {
struct movimento { string data; float importo;};
exception RossoException {string message;};
typedef sequence <movimento> lista_op;
interface Conto {attribute string cognome;
float saldo (in string cc);
lista_op estratto (in string cc);
void prelievo (in string cc, in float importo,
out float saldo) raises RossoException;
};
};
CORBA IDLCORBA IDL
Middleware e CORBA 64
Tipi in CORBA
Object Reference (oggetti) vs. Value (copia di valori)
Any come tipo generico valido a tempo di esecuzione
Object by value (CORBA 3)
Oggetti che non possono essere acceduti da remoto e possono passare da un ambiente ad un altro solo per copia superando le eterogeneità dei diversi ambienti (nessun IOR)
void one_way set_quote(in string stock_name, in long value); long get_quote(in string stock_name) raises (Invalid_Stock); };
interface SpecialQuoter: Quoter {attribute float quotehistory [length];readonly int index [length];
long get_next (in string stock_name) raises (Invalid_Index); long get_first(in string stock_name) raises (Invalid_Index);
}; }
CORBACORBA-- IDLIDL
Middleware e CORBA 68
Per ogni attributo si mettono a disposizione automaticamente funzioni di accesso adatte alle operazioni consentite (_getper letture e _set per scritture)attribute float quote;float _get_quote ();void _set_quote (in float q);readonly attribute ind index;float _get_index ();
Per ogni eccezione, lo stato (completion_status) fornisce informazioni semantiche sul completamentoCOMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE
CORBACORBA-- IDLIDL
Middleware e CORBA 69
Si devono specificare le interfacce comuni a server e clienti
Dopo avere generato gli stub e skeleton
Si implementano le classi server
Il server deve registrarsi
Si implementano le classi client
Si va alla esecuzione
Necessità di riferimenti remoti del cliente per ritrovare
il server, i componenti, … , e in generale la intera infrastruttura di supporto
PROGETTO PROGRAMMI CORBAPROGETTO PROGRAMMI CORBA
Middleware e CORBA 70
COMPONENTI DI CORBACOMPONENTI DI CORBA
Middleware e CORBA 71
Gli Object Reference permettono di ritrovare una istanza di un servizio remoto (uno stub): sono opachi e non sono manipolabili dai clienti ma solo dall’ORB(eventualmente integrati con la gestione della persistenza)
Gli Object Reference sono riferimenti ad istanze di ObjectInterface
Operazioni di Object Interface sono molte per consentire di lavorare in modo trasparente e visibile
ORB si può intendere come l’insieme di classi che permettono un buon supporto ad oggetti remoti
Funzioni di conversioni varie
funzioni helper per lavorare e trasformare gli Object InterfaceInterface ORB {
string object_to_string (in Object obj);
Object string_to_object (in string str);
}
possiamo così passare da una forma all’altra anche tra ambienti diversi
Anche funzioni per inizializzare i vari OA, per ritrovare servizi necessari, funzioni di base, ecc. ecc.
ORB INTERFACE in CORBAORB INTERFACE in CORBA
Middleware e CORBA 73
ORB Funzioni varie
ORB Initialize per il bootORB ORB_init(inout arg_list arguments,
in ORBid ORB_identifier)
per il collegamento iniziale all’ORB da parte dei clientiAnche object_to_string e string_to_object
anche funzioni per ritrovare il contesto di default e interrogare IRtypedef string ObjectID;
typedef sequence <ObjectID> ObjectIDList;
ObjectIDList list_initial_services ();
Object resolve_initial_references (in ObjectID id);
ORB INTERFACE in CORBAORB INTERFACE in CORBA
Middleware e CORBA 74
Necessità di identificatori da passare tra ambienti diversi
CORBA 2 supporto sia per nomi unici e non unici
Object Reference come nomi non unici associati ad un servizio
ObjectRef al passaggio viene convertito da un sistema di nomi in un proxy nell'ambiente del ricevente per potere essere utilizzato
ObjectRef possono essere passati da un ambiente ad un altro ed essere utilizzati dovunque ma non necessariamente per lo stesso oggetto (all’interno di ORB diversi anche forme diverse)
Possono contenere informazioni di:
indirizzonome del POA di creazioneobject ID
RIFERIMENTI AD OGGETTI in CORBARIFERIMENTI AD OGGETTI in CORBA
Middleware e CORBA 75
Necessità di identificatori unici tra ambienti diversiInteroperable Object Reference come nomi unici associati ad un servizio (IOR) che possono essere portati tra ORB diversi (passando anche attraverso stringhe)
In genere, prima di passare da un ORB ad un altro IOR
Inserimento in un Repository (appena depositato la prima volta) Repository Identifier
Tagged Profile informazioni complete per la ricerca dell’oggetto
IIOP, nome host, porta, chiave identificativa, info. aggiuntiveSi usano queste informazioni per decidere cosa passare al cliente che richiede una operazione (poi gli viene fornito il proxy locale per l’oggetto stesso)
Legame diretto (direct binding) se IOR riferisce direttamentel’oggetto relativo
Legame indiretto (indirect binding) se IOR riferisce al repository e solo indirettamente attraverso questo all’oggetto finale
IOR in CORBAIOR in CORBA
Middleware e CORBA 78
Legame diretto e Legame indiretto (direct e indirect binding)
Implementation Repository localizzato a n’_porta: ip’_address
Op() [OA_1, Obj_2]
Location-forward ( N_porta_1: IP_Address_1)
(1)
(4)
(5)
(7)
Vbj /applicazioni /server:(2)
Restituisce:
IP_Address_1
(3)
Comando per attivareil servizio
Servitore
Implementation Repository
N_porta_1:
Middleware e CORBA 79
Object Adapter come agenti intermedi per consentire di superare i problemi della eterogeneità dei diversi ambienti
BOA (Basic Object Adapter) come la entità di base
Permette la attivazione dei server con politiche semplici
Shared server un unico thread per tutti gli oggettiUnshared server un processo per ogni oggettoPer Method server un processo per ogni invocazionePersistent server un processo unico fatto partire
alla inizializzazione
OBJECT ADAPTER in CORBAOBJECT ADAPTER in CORBA
Middleware e CORBA 80
POA come agente portabile interoperabile che permette di passare da un object reference al codice concreto che deve servire la richiesta stessa
Un POA può gestire molti oggetti diversi e seleziona su quali dirigere le operazioniIn ambienti diversi, il POA è diverso (classi, variabili, metodi, attività) ma deve potere realizzare le politiche di base necessarie alla varietà delle interazioni possibili
In un ambiente specifico, in genere esiste una classe base da cui derivano tutti i POA e che contiene i meccanismi per la gestione della richiesta e dei servant
Il POA non eredita le politiche definite caso per caso
POA può consentire politiche molto differenziate per la gestione degli oggetti servant
Politiche a default POA:
Explicit Object ActivationUn servant specifico è collegato ad un ObjectID con molto controllo della esecuzione
Single Servant (per tutti gli oggetti) Un solo servant per ogni richiesta (anche oggetti di tipo diverso)
On-Demand activation (per un singolo metodo) senza stato
On-Demand activation (per durata indefinita)il servant si attiva su richiesta e si mantiene per ogni richiesta successiva
Si possono anche combinare
POLITICHE PER I POAPOLITICHE PER I POA
Middleware e CORBA 88
Interface Repository si occupa di registrare tutte le interfacce e di gestirne la memorizzazione e la ricerca
Distingue tra contenitore e contenuti
INTERFACE REPOSITORY in CORBAINTERFACE REPOSITORY in CORBA
Middleware e CORBA 89
Interface Repository ad accesso
direttamente o attraverso utilità proprietarie
Ogni entità viene anche etichettata da un RepositoryIDSi raccomandano formati diversiIDL IDL:/Vai/Servizi/Interfaccia:1.0RMI hashed RMI: nome … /hashcodeDCE format DCE: UUIDLocal format LOCAL: libero
Si fanno operazioni di accessoContained lookup_id (in RepositoryID searchid);
InterfaceDef get_interface();
INTERFACE REPOSITORY in CORBAINTERFACE REPOSITORY in CORBA
Middleware e CORBA 90
Ad ogni interfaccia definita e compilata
Si generano delle trascrizioni delle informazioni nell’IR
in base ai tipi che possono essere riconosciuti
INTERFACE REPOSITORY in CORBAINTERFACE REPOSITORY in CORBA
Middleware e CORBA 91
Struttura più completa dei tipi in un IR
INTERFACE REPOSITORY in CORBAINTERFACE REPOSITORY in CORBA
Repository
CostantDef
TypeDef
ModuleDef ExceptionDef InterfaceDef
AttributeDef OperationDef
ParameterDef
ModuleDef
TypeDef
TypeDef
CostantDef
CostantDef
ExceptionDef InterfaceDef
ExceptionDef
ExceptionDef
Contiene
Contiene
Contiene
Contiene
Middleware e CORBA 92
CORBA 3 introduce alcune significative aree di estensione / completamento
Internet
nomi come URL, firewall proxy per GIOP, …
QoS
nuove forme di invocazione con maggiore controllo QoS Asynchronous calls (AMI) & Time-independent (TII)
livello più astratto per lavorare in modo trasparente
CORBA 3CORBA 3
Middleware e CORBA 93
In CORBA le invocazione sono sincrone
Il cliente deve attendere il completamento della operazione da parte della infrastruttura
Operazioni statiche sempre sincrone (at-most-once)
Operazioni dinamiche anche asincrone
one-way (best-effort per l’arrivo al server)
nessuna risposta prevista staticamente
deferred-synchronous (at-most-once)
il cliente può successivamente aspettare la risposta
SEMANTICA di INVOCAZIONESEMANTICA di INVOCAZIONE
Middleware e CORBA 94
Le invocazioni di CORBA non sono persistenti
CORBAMessaging per trattare metodi di invocazione non possibile nello standard di base CORBA
Callback il cliente fornisce un metodo di callback richiamato dal supporto al completamento attraverso una specifica fire-and-forget (invocata automaticamente)
(cambiando solo la implementazione cliente e non la parte di servizio)
il cliente decide quando e se interrogare un metodo di verifica del completamento della operazione remota
Si usa la specifica automatica di due metodi separati derivati dalla interfaccia
Per trattare
metodi asincroni
a polling
Recupero su richiesta
ASYNCHRONOUS INVOCATIONASYNCHRONOUS INVOCATION
Middleware e CORBA 96
ARCHITETTURA CORBAARCHITETTURA CORBA
Middleware e CORBA 97
CORBA richiede anche molte altre parti
I CORBA Services permettono di fornire funzioni di appoggio per ottenere servizi più o meno essenzialiCollection service per raggruppare oggetti
Query service per query per interrogare oggetti
Concurrency (control) serviceper servizi pronti di lock
Event service per usare eventi asincroni
La presenza di questi servizi qualifica CORBA come un ambiente di integrazione di componenti
CORBA SERVICESCORBA SERVICES
Middleware e CORBA 98
CORBA SERVICESCORBA SERVICES
Provides the current time within specified error marginsTime
Mechanisms for secure channels, authorization, and auditingSecurity
Facilities for expressing relationships between objectsRelationship
Facilities for persistently storing objectsPersistence
Facilities to publish and find the services on object has to offerTrading
Facilities for associating (attribute, value) pairs with objectsProperty
Facilities for systemwide name of objectsNaming
Facilities for attaching a license to an objectLicensing
Facilities for creation, deletion, copying, and moving of objectsLife cycle
Facilities for marshaling and unmarshaling of objectsExternalization
Advanced facilities for event-based asynchronous communicationNotification
Facilities for asynchronous communication through eventsEvent
Flat and nested transactions on method calls over multiple objectsTransaction
Facilities to allow concurrent access to shared objectsConcurrency
Facilities for querying collections of objects in a declarative mannerQuery
Facilities for grouping objects into lists, queue, sets, etc.Collection
DescriptionService
Middleware e CORBA 99
OMG ha standardizzato molti altri componenti per facilitare la programmazione ed il supporto
NAMING SERVICEPer consentire di trattare ObjectReference in modo facile e per avere sempre alcuni sistemi di nomi noti
Name binding come associazione tra oggetto e nome
Name context come insieme di binding in cui ognuno dei nomi (delle coppie) è unico
I binding sono per definizione relativi ad un contesto specifico e da specificarsi
CORBA SERVICESCORBA SERVICES
Middleware e CORBA 100
I nomi possono anche fare riferimento a contesti federati con server diversi di gestione
e connessi tra loro
NAMING SERVICENAMING SERVICEUn nome come una sequenza di componenti di nome
Nomi diversi possono fare riferimento a oggetti diversi o allo stesso oggetto ritrovandolo con un processo di risoluzione
Middleware e CORBA 101
NAMING SERVICENAMING SERVICESi determinano dei grafi di contesti e di riferimenti agli oggetti da relazioni di contenimento di contesti (attraverso Object Reference)
Middleware e CORBA 102
NAMING SERVICENAMING SERVICEUn nome come semplice o composto da una sequenza di componenti di nome
Ogni componente costituito di due parti o attributi
[Identifier , Kind ]
Identifier
Kind di tipo descrittivo, ad esempio executable, postscript
struct NameComponent {string id; string kind;};
typedef sequence <NameComponent> Name;
La idea è che il servizio fornisca solo meccanismi e non politiche di nessun tipo
Middleware e CORBA 103
NAMING CONTEXTNAMING CONTEXTLe operazioni che si possono considerare su un contesto di namigderivano dalla Interfaccia NamingContext che richiede le tipiche operazioni prevedibili per un sistema di nomi
interface NamingContext{
void bind(in Name n; in Object obj) raises …;
void rebind(in Name n; in Object obj) raises …;
void unbind(in Name n) …;
void bind_new_context(in Name n)…;
object resolve(in Name n)…;
void list(in unsigned long how_many, out BindingList bl, out BindingIterator bi);
}
Middleware e CORBA 104
TRADING SERVICETRADING SERVICEIl TRADING Service ha l’obiettivo di facilitare la ricerca di servizi che implementano una certa interfaccia
con funzionalità simili alle pagine gialle
Il Trader è un oggetto che permette di diffondere la conoscenzadei servizi che si possono richiedere
Il trader permette di esporre serviziexport da parte di chi li fornisce
Il trader permette di importare serviziimport da parte di chi li vuole conoscere
Ovviamente avremo anche
Trader federati
Middleware e CORBA 105
TRADING SERVICETRADING SERVICECORBA non specifica niente sulla implementazione del TRADING Service
Si possono avere database o anche tabelle in memoria
Ogni trader è caratterizzato da
un’interfaccia che definisce le funzionalità esposte dal servizio,
alcune proprietà per rappresentare gli aspetti comportamentali e non-funzionali non espressi dall’interfaccia del servizio
Ogni proprietà è identificata da un attributo PropertyMode
PropertyMode associata alla tripla <name, type, mode>
TRADING SERVICETRADING SERVICEInterfaccia di un Servizio
Middleware e CORBA 108
TRADING SERVICETRADING SERVICELa ricerca avviene fornendo dei vincoli per orientare la ricerca sul servizio di trading che devono operare su grafi di trading
N1 servizi di tutti i trader
N2 servizi conformitàin interfaccia
N3 servizi che rispettanoi vincoli richiesti
N4 servizi ordinati
N5 servizi ridotti ulteriormente
Esistono problemi di cicli nella ricerca nel grafo di interconnessione dei diversi trader
Middleware e CORBA 109
Se CORBA prevede solo comunicazione sincrona e strettamente uno-a-uno, EVENT SERVICE permette di renderla più lasca e flessibile
Si considerano produttori (supplier) e consumatori (consumer) di eventi con diverse alternative per la comunicazione e si considerano eventqueue per gli eventi (che non sono oggetti)
Modelli di comunicazione
Modalità push i produttori inviano ai consumatori
Modalità pull i consumatori inviano ai produttori
Le informazioni comunicate possono essere
generiche o tipate (untyped & typed events)
EVENT & NOTIFICATION SERVICEEVENT & NOTIFICATION SERVICE
Middleware e CORBA 110
In modalità push i consumatori e produttori si conoscono tramite le interfacceinterface PushConsumer {
void push (in any data) raises(Disconnected);void disconnect_push_consumer(); };
Event Channel oggetto che permette e agevola la comunicazione molti-a-molti
Il Channel ha la capacità di coordinare anche più possibili eventi di supplier prima di scatenare eventi multipli di diversi consumer, introducendo anche filtraggio sui destinatari
Inoltre, come oggetto a parte, può anche occuparsi di una eventuale qualità di servizio nella comunicazione delle informazioni (mantenute stabilmente, permanentemente, …)
Il Notification service estende il servizio degli eventi con molteplici nuove funzionalità
descrizione degli eventi e informazioni, filtri e repository di filtri
EVENT & NOTIFICATION SERVICEEVENT & NOTIFICATION SERVICE
Middleware e CORBA 113
Event Channel oggetto che permette e agevola la comunicazione molti-a-molti
EVENT & NOTIFICATION SERVICEEVENT & NOTIFICATION SERVICE
Middleware e CORBA 114
Gli eventi possono essere caratterizzati da proprietà che ne permettono la ricerca (Header e Body su cui si possono filtrare)