View
4
Download
0
Category
Preview:
Citation preview
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
Presentation Management (stampa, grafica, GUI, interazione)Computation (procedure comuni, servizi caratteri,
internazionalizzazione, sorting)Information Management (file manager, record manager,
database manager, log Manager, …)Communication (messaging, RPC, message queue,
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
Molti servizi addizionali per componenti
eventi, logging, streaming, sicurezza, fault tolerance, …
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
Middleware e CORBA 11
MIDDLEWARERPC middlewareMessage Oriented Middleware (MOM)Distributed Transaction Processing (TP) MonitorDatabase MiddlewareDistributed Object Computing (DOC) MiddlewareAdaptive & Reflective MiddlewareAltri special purpose:Mobile & QoS Multimedia MiddlewareAgent-based Middleware
CLASSIFICAZIONE MIDDLEWARECLASSIFICAZIONE MIDDLEWARE
Middleware e CORBA 12
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
ObjectObject Management Management ArchitectureArchitecture
Middleware e CORBA 26
Altri componenti addizionali di ambiente
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
ObjectObject Management Management ArchitectureArchitecture
Middleware e CORBA 27
Ambiente Object Framework
ObjectObject Management Management ArchitectureArchitecture OMAOMA
Middleware e CORBA 28
I componenti essenziali della architettura OMA e di CORBA
*Object Request Broker (ORB)
* Interface Definition Language (IDL)
*Basic Object Adapter (e altri) (BOA)
*Static Invocation Interface (SII)
*Dynamic Invocation Interface (DII)
* Interface Repository (IR)
COMPONENTI DI CORBACOMPONENTI DI CORBA
Middleware e CORBA 29
• individuare l’implementazione di un oggetto come servitore ad una richiesta (object location)
• preparare il servitore a ricevere la richiesta
(object creation, activation & management)
• trasferire la richiesta dal cliente al servitore
• restituire la risposta al cliente
COMPONENTI DI CORBACOMPONENTI DI CORBA
Oggetti Applicativi
Servitori
ORB
Clienti
Cl1 Srv1
Object Request Broker (ORB) deve coordinare la invocazione di servizi locali e remoti (dinamico)
Middleware e CORBA 30
Interface Definition Language (CORBA IDL) deve coordinare la identificazione dei servizi richiesti e offerti, locali e remoti (statico)
• Si devono associare le richieste di operazioni e le offerte di servizio
• Sia i servitori sia i clienti devono potere identificarsi e rendersi noti reciprocamente
• Si fa ampio uso della esperienza degli IDL già sviluppati
Purtroppo IDL consente solo una identificazione ed un legame previsto e riconosciuto staticamente. E se volessimo legami dinamici??
COMPONENTI DI CORBACOMPONENTI DI CORBA
Middleware e CORBA 31
Elementi in gioco: visione complessiva
CORBA: VISIONE DINAMICACORBA: VISIONE DINAMICA
Invocazione Stub Interfaccia Scheletrodinamicodinamica IDL ORB
ClienteImplementazione
dell'oggetto
Nucleo dell'ORB
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
readonly attribute Identifier operation_name;
readonly attribute OperationDef operation_definition;
void parameters(inout NVList params);
Context ctx();
void set_result(in Any val);
void set_exception(in Any val);
};
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
COMPONENTI CORBA: ADATTATORECOMPONENTI CORBA: ADATTATORE
Metodi
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
(shared server) contemporaneamente
COMPONENTI CORBA: ADATTATORECOMPONENTI CORBA: ADATTATORE
Middleware e CORBA 48
Ogni richiesta riceve un thread attivato by-need
Costo elevato della attivazione che pesa su ogni operazione
Attivazione THREADAttivazione THREAD--PERPER--REQUESTREQUEST
Più Servant
Client1Client2
ObjectAdapter
generazione di thread
ThreadAThreadB ThreadC
Capacità di Esecuzione
Servitore
Middleware e CORBA 49
Ogni richiesta riceve un thread da un pool di processi creati primaIn caso non ce ne siano, si aspetta il primo libero
Costo inferiore, ma anche elevata attesa in caso di traffico non previsto
Attivazione THREADAttivazione THREAD--POOLPOOL
Più Servant
Client1Client2
ObjectAdapter
generazione di thread
ThreadAThreadB
ThreadC
Capacità di Esecuzione
Servitore
Coda RichiestePool di Thread
Richieste in Coda
Middleware e CORBA 50
Ogni cliente riceve un thread attivato all’inizio della sessione di lavoro
Si limita il parallelismo del servizio
Attivazione THREADAttivazione THREAD--PERPER--SESSIONESESSIONE
Client1Client2
ObjectAdapter
generazione di thread
Thread3Thread1
Thread2
Generazione su richiesta
ServitoreCoda Richieste
Richieste in Coda
Client3
Più Servant
Middleware e CORBA 51
Ogni oggetto viene dotato di un servantche prevede un thread dalla prima attivazione e risponde solo attraverso quello
Si limita il parallelismo in base al numero dei servant
Attivazione THREADAttivazione THREAD--PERPER--SERVANTSERVANT
Client3
Client1Client2
ObjectAdapter
Capacità di Esecuzione
ServantA ServantB ServantC
Middleware e CORBA 52
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)
Exceptions
Value
Basic values short, long, ushort, ulong, float, double, char, string,boolean, octet, enum, Any
Constructed values Struct, Sequence, Union, Array
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)
CORBA IDLCORBA IDL
Middleware e CORBA 65
Tipi in CORBA IDL
CORBA IDLCORBA IDL
Type
Object Reference
Tipi Costruiti
Valori base
Struct
Sequence
Union
Array
ShortLongUshortUlongfloatdoublecharstringbooleanoctetenumany
Eccezioni
Tipo generico ANY
Il tipo generico ANY permette di contenere qualunque tipo di dato e si comporta come il tipo Object dei linguaggi di programmazione ad oggetti
I tipi di CORBA IDL sono poi traslati nei tipi dei diversi linguaggi di programmazione ottenuti per i diversi language mapping
Middleware e CORBA 66
Si usano strumenti per derivare dal CORBA IDL i diversi componenti necessari per la esecuzione
stub e
skeleton
+
file helper
di aiuto
CORBA IDLCORBA IDL
Middleware e CORBA 67
module Stock{exception Invalid_Stock {}; exception Invalid_Index {}; const length = 100; interface Quoter {
attribute float quote;readonly attribute float quotation;
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
get_implementation, get_interface,is_nil, non_existent, is_a, is_equivalent, hash, duplicate, release, create_request, get_domain_manager,get_policy, set_policy_overrides,
ObjectObject ReferenceReference in CORBAin CORBA
Middleware e CORBA 72
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
NOMI UNICI in CORBANOMI UNICI in CORBA
IDL:MyObject:1.0 N_porta: ip_address OA1, Obj_2 Obj_1Obj_2
Obj_3
Object Reference
Cliente
Object Adapter:OA1
Servitore
Op() [OA1, Obj_2]
Risposta
Middleware e CORBA 76
Accordo tra le rappresentazioni dei diversi ORB per i diversi oggetti che esistono al di fuori dell’ORB
Interoperable Object Reference o IOR
IOR come ProfileID (identificatore) e tagged Profile (per determinare completamente)
InteroperableInteroperable ObjectObject ReferenceReference
Middleware e CORBA 77
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)
IOR in CORBAIOR in CORBA
IDL:MyObject:1.0 n’_porta: ip’_address OA1, Obj_2Obj_1Obj_2
Obj_3
Interoperable Object Reference
Cliente
Object Adapter:OA1
N_porta_1: IP_Address_1
Op() [OA1, Obj_2]
Risposta
OA_1
OA_2
OA_3
Vbj \applicazioni\server
Vbj \pub\gestore
N_porta_1: IP_Address_1
N_porta_2: IP_Address_2
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
PORTABLE OBJECT ADAPTER PORTABLE OBJECT ADAPTER -- POAPOA
Middleware e CORBA 81
POA come agente portabile per la interoperabilità
Eredita da altri POA (di default) senza ereditare le politiche che devono essere espresse ad-hoc
Politiche anche diverse e specializzate
PORTABLE OBJECT ADAPTER PORTABLE OBJECT ADAPTER -- POAPOA
Middleware e CORBA 82
Gli Adattatori POA hanno un metodo visibile ai clienti
ObjectID activate_object (in Servant p)
che restituisce un identificatore di oggetto CORBA e può ricevere in ingresso un puntatore ad un servant
Il metodo permette anche la gestione della scelta esplicita tra servant nella Active Object Map
ObjectID permettono la scelta dei servant nel POA
Funzioni di ADATTATOREFunzioni di ADATTATORE
Middleware e CORBA 83
POA viene gestito da un POA Manager che esprime lepolitiche (come mappare servant e object reference) e lerealizza
PORTABLE OBJECT ADAPTERPORTABLE OBJECT ADAPTER
Middleware e CORBA 84
POA Manager capace di fornire operazioni per consentire politiche diverse….
Il POA Manager permette di:
• attivare un POA (per fare partire il lavoro)
• disattivare un POA (per chiudere il lavoro dei POA)
• bloccare le richieste ai POA (il lavoro viene bloccato e non si fa partire nessuna operazione)
• scartare le richieste per i POA (tutte le richieste in arrivo e accodate sono scartate: nessuna operazione)
PORTABLE OBJECT ADAPTERPORTABLE OBJECT ADAPTER
Middleware e CORBA 85
POA come agente portabile per la gestione degli oggetti e dei servant
RESPONSABILITÀ di
Creazione object reference
Identificazione degli ObjectID
Gestire i servant relativi
Oggetti CORBA transientiche non sopravvivono alla applicazione che li ha generati
Oggetti CORBA persistentiche sopravvivono alla applicazione che li ha generati e rimangono disponibili anche per altre successive applicazioni
OBJECT ADAPTER in CORBAOBJECT ADAPTER in CORBA
Middleware e CORBA 86
POA come agente portabile per la interoperabilità
le politiche derivano da proprietà specificate ad-hoc:
Thread (ORB_CTRL_MODEL, SINGLE_THREAD_MODEL)
Lifespan (TRANSIENT, PERSISTENT)
Object ID Uniqueness (UNIQUE_ID, MULTIPLE_ID)
ID Assignment (USER_ID, SYSTEM_ID)
Servant Retention (RETAIN, NON_RETAIN)
Requests (USE_ACTIVE_OBJECT_MAP_ONLY,USE_DEFAULT_SERVANT, USE_SERVANT_MANAGER)
Implicit Activation (IMPLICIT_ACTIVATION, NO_IMPLICIT_ACTIVATION)
OBJECT ADAPTER in CORBAOBJECT ADAPTER in CORBA
Middleware e CORBA 87
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)
CORBA Real-time, CORBA ridotto, CORBA fault-tolerant
Componenti
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)
ASYNCHRONOUS INVOCATION ASYNCHRONOUS INVOCATION -- AMIAMI
Middleware e CORBA 95
invocazione asincrona polling
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>
mode di tipo
enum PropertyMode {PROP_NORMAL, PROP_READONLY, PROP_MANDATORY, PROP_MANDATORY_READONLY}
Middleware e CORBA 106
TRADING SERVICETRADING SERVICEInterfaccia di un Servizio
Con ereditarietà tra servizi
service <ServiceTypeName>
[:<BaseServiceTypeName> [,<BaseServiceTypeName>]*]
{interface <InterfaceTypeName>;
[[mandatory] [readonly] property <IDLType>
<PropertyName>;]*
};
Ogni proprietà è fatta di <nome, valore>
La pubblicazione avviene fornendo
il nome del servizio, nessuna o più proprietà
un riferimento alla interfaccia che implementa
Middleware e CORBA 107
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(); };
interface PushSupplier {void disconnect_push_supplier(); };
Possono anche terminare la operatività con le disconnect per bloccare la comunicazione
EVENT SERVICE: ModalitEVENT SERVICE: Modalitàà pushpush
Middleware e CORBA 111
In modalità pull i consumatori e produttori si conoscono tramite le interfacceinterface PullSupplier {
void pull () raises(Disconnected);void try_pull (out boolean event)
raises(Disconnected);void disconnect_pull_supplier(); };
interface PullConsumer {
void disconnect_pull_consumer(); };
Possono anche terminare la operatività con le disconnect
EVENT SERVICE: ModalitEVENT SERVICE: Modalitàà pullpull
Middleware e CORBA 112
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)
Reliability (best-effort, persistent), Priority, StartTime, Stoptime, Timeout
Si prevede anche un repository di Event type per la descrizione degli stessi
NOTIFICATION SERVICENOTIFICATION SERVICE
Middleware e CORBA 115
Molto ampia ed in crescitaObject Broker DEC
ORB HP
DSOM IBM
Orbix IONA
Visibroker Borland
(DOM Facility)DOE Sun Studio Sun
PowerBroker ExperSoft
JacORB, ... Strumenti open source
Anche se la curva di apprendimento è elevata e ci sono overhead nelle prestazioni
DISPONIBILITDISPONIBILITÀÀ di AMBIENTI CORBAdi AMBIENTI CORBA
Middleware e CORBA 116
Java implementation transparency
linguaggio ed ambiente unico per la programmazione su macchine eterogenee con applet aggancio al WEB e con beans componenti grafici indipendenti
CORBA network transparency
standard per la interconnessione industriale di ambienti diversi per lo scambio di servizi su macchine eterogenee
VALUTAZIONI STRUMENTI CORBAVALUTAZIONI STRUMENTI CORBA
Java CORBA efficienza unica
macchina virtuale
diversi ambienti OO
integrazione facile uso dello standard
Recommended