MIDDLEWARE e CORBA - unibo.itCORBA.pdf · 2005-05-09 · Middleware e CORBA 19 OMG- Object...

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


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


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.


Lo strato di disaccoppiamento tra i livelli di sistema consente la semplificazione del progetto sia della parte applicativa sia del supporto


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



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 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


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


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


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, …



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, …



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



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


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 !?


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


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


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


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



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


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


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


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



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



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



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


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


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


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


Ambiente Object Framework

ObjectObject Management Management ArchitectureArchitecture OMAOMA


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


• 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


Oggetti Applicativi

Servitori

ORB

Clienti

Cl1 Srv1

Object Request Broker (ORB) deve coordinare la invocazione di servizi locali e remoti (dinamico)


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??



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


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


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


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


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


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


Visione di insieme della architettura

CORBA ARCHITETTURACORBA ARCHITETTURA


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


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


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


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


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


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)


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)


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


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


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


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


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


ThreadAThreadB

ThreadC


Servitore

Coda RichiestePool di Thread

Richieste in Coda


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


Thread3Thread1

Thread2

Generazione su richiesta

ServitoreCoda Richieste

Richieste in Coda

Client3

Più Servant


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


ServantA ServantB ServantC


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


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


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


ARCHITETTURA CORBAARCHITETTURA CORBA


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)



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


Visione di insieme della architettura base di supporto al servizio



Visione di insieme della architettura base di supporto al servizio



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


Linguaggio per definire le interfacce in CORBA indipendente dai singoli linguaggi concreti di programmazione

CORBA IDLCORBA IDL


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


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


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


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


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


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


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


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




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


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


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


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


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


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


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


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



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:


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


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


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


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


POA viene gestito da un POA Manager che esprime lepolitiche (come mappare servant e object reference) e lerealizza

PORTABLE OBJECT ADAPTERPORTABLE OBJECT ADAPTER


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


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



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)



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


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


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();



Ad ogni interfaccia definita e compilata

Si generano delle trascrizioni delle informazioni nell’IR

in base ai tipi che possono essere riconosciuti



Struttura più completa dei tipi in un IR


Repository

CostantDef

TypeDef

ModuleDef ExceptionDef InterfaceDef

AttributeDef OperationDef

ParameterDef

ModuleDef

TypeDef

TypeDef

CostantDef

CostantDef

ExceptionDef InterfaceDef

ExceptionDef

ExceptionDef

Contiene

Contiene

Contiene

Contiene


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


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


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


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


ARCHITETTURA CORBAARCHITETTURA CORBA


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



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


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



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


NAMING SERVICENAMING SERVICESi determinano dei grafi di contesti e di riferimenti agli oggetti da relazioni di contenimento di contesti (attraverso Object Reference)


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


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);

}


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


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}


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


TRADING SERVICETRADING SERVICEInterfaccia di un Servizio


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


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


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


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


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 Channel oggetto che permette e agevola la comunicazione molti-a-molti



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


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


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

MIDDLEWARE e CORBA - unibo.itCORBA.pdf · 2005-05-09 · Middleware e CORBA 19 OMG- Object...

Documents

Transcript of MIDDLEWARE e CORBA - unibo.itCORBA.pdf · 2005-05-09 · Middleware e CORBA 19 OMG- Object...