Sistemi distribuiti - Appunti completi del corso

IDL

• Le interfacce come un insieme di metodi e attributi
• L'ereditarietà multipla delle interfacce
• La definizione di eccezioni
• La gestione automatica degli attributi

Language Mapping

1. In modo statico, attraverso lo Stub
2. Tramite Dynamic Invocation Interface (DII)

La DII:

• Permette ai client di usare interfacce di oggetti remoti che non erano note o disponibili al tempo di compilazione.
• Offre grande flessibilità nella invocazione dei metodi di oggetti remoti, portando però ad un aumento della complessità.

Il client può fare la richiesta attraverso la Dynamic Invocation Interface o l'IDL Stub.

Le richieste sono fatte all'ORB Core, che va a trovare e passare i dati di queste richieste all'Object Representation.

Modalità di invocazione:

• Synchronous (attraverso stub): il client e l'object representation si vanno a sincronizzare, il client effettua la chiamata attraverso lo stub e si blocca fino a che...

Buon fine o meno. Come parametri e valori di ritorno vengono passati:

Oggetti CORBA: sono passati per riferimento.

Nonobject types: sono passati per valore.

Dispatching di Metodi Remoti

Quando riceve una richiesta, lo ORB Core:

• Localizza l'implementazione (servant) dell'oggetto remoto.
• Gli trasmette i dati della richiesta.
• Gli trasferisce il controllo attraverso lo Object Adapter e lo Skeleton statico o il Dynamic Skeleton.

Quando la richiesta è completata, lo ORB Core restituisce il valore di ritorno e il controllo delle operazioni al client: si ha quindi la sincronizzazione tra il client e l'implementazione dell'oggetto grazie all'ORB Core.

L'ORB Core, attraverso lo Static o Dynamic Skeleton e l'Object Adapter, interagisce con l'Object Implementation.

Object Adapter (OA)

Lo scopo dell'Object Adapter è quello di interfacciare i servant con l'ORB Core.

L'OA si occupa:

• Della generazione degli Object Reference (in

1. Cooperazione con il sistema di comunicazione dell'ORB Core
2. Attivazione e disattivazione dei servant
3. Mapping tra riferimenti a oggetti e implementazioni
4. Collaborazione con gli Skeleton per effettuare le invocazioni ai servant

Basic Object Adapter (BOA)

È l'unico tipo di OA definito prima di CORBA 2.2.

Il BOA presenta diversi limiti:

• Alcune interfacce non sono standardizzate
• Supporto di mapping solo per il linguaggio C
• Mancanza di operazioni per la registrazione delle implementazioni di un oggetto

Queste gravi lacune hanno costretto i vendor a sviluppare workaround proprietari.

I BOA sono stati deprecati a favore dei Portable Object Adapter.

Portable Object Adapter (POA)

POA succede a BOA e lo sostituisce.

POA supporta:

• Portabilità tra ORB di vendor diversi
• Oggetti

persistenti

Attivazione/disattivazione automatica dei servant

Riuso delle risorse (ad esempio, un singolo servant può rappresentare molti oggetti)

Comportamento controllabile tramite policy

Coesistenza di più istanze di POA in uno stesso server, organizzate in una gerarchia a partire da un root POA

Supporto all'invocazione di metodi sia attraverso Skeleton statico che tramite Skeleton dinamico

Architettura POA

La possibilità di avere più POA permette di gestire diversi tipi di servant. Ad esempio, si potrebbe avere un POA per gestire oggetti CORBA persistenti e un altro POA per gestire oggetti CORBA non persistenti.

Ogni POA ha una tabella chiamata Active Object Map, che mappa gli Object ID con i servant e un gestore (POA Manager).

Vi sono anche entità per l'attivazione dei servant (Servant Manager) e dei POA stessi (Adapter Activator).

POA Policies

È possibile modificare per un POA le politiche di gestione dei servant.

Si può agire su:

Accesso

Sono necessarie delle ispezioni run-time. Informazioni di implementazioni per localizzare e attivare gli oggetti.

1. Le definizioni delle interfacce (IDL) vengono registrate nell'Interface Repository, ossia lato client.
2. Dalla definizioni delle IDL vengono creati gli Stub e gli Skeleton, collegati rispettivamente al client e all'Object Implementation.
3. L'implementazione delle installazioni viene sempre registrata in un Implementation Repository, collegato ad un Object Implementation.

Interoperabilità

CORBA 1.X trascurava completamente l'interoperabilità tra diverse implementazioni, portando all'obbligo di usare ORB dello stesso vendor sia lato client che lato server per permettere di far funzionare applicazioni tra oggetti distribuiti.

CORBA 2.X definisce una specifica per l'interoperabilità attraverso:

• Estensioni per problemi lato server (es. POA)
• Introduzione dei protocolli GIOP e IIOP

Protocolli di Interoperabilità

Il General Inter-ORB Protocol (GIOP) è un protocollo di livello di trasporto che permette la comunicazione tra ORB. Il Internet Inter-ORB Protocol (IIOP) è una specifica di GIOP che utilizza il protocollo TCP/IP per la comunicazione tra ORB su reti Internet.

Inter-ORB Protocol (GIOP) specifica il formato delle richieste e il protocollo di trasmissione che permette un'interoperabilità ORB-to-ORB. Lo Internet Inter-ORB Protocol (IIOP) specifica un protocollo standard di interoperabilità per la rete Internet e lavora direttamente su TCP/IP. Non sono necessarie le RPC.

Interoperable Object Reference: L'Interoperable Object Reference (IOR) è lo standard per la rappresentazione di un riferimento all'oggetto remoto. È di fatto un URI.

General Inter-ORB Protocol: È un protocollo astratto che specifica la sintassi di riferimento e un insieme di messaggi per la comunicazione inter-ORB. Utilizza una Common Data Representation (CDR) ed effettua il multiplexing delle richieste, ossia più client possono condividere la stessa connessione allo ORB. Permette di rilassare i vincoli di sincronizzazione, attraverso delle richieste asincrone.

Internet Inter-ORB Protocol: È l'implementazione di GIOP su

17 - Web Service

Con il termine Servizio ci si riferisce ad un componente che offre una certa funzionalità (o un insieme di funzionalità) a diversi possibili client. I client possono quindi utilizzare le funzionalità offerte da un servizio nei modi più adeguati alle loro esigenze applicative.

Integrazione di Sistemi Eterogenei

L'obiettivo di un servizio è di permettere ai provider a disposizione funzioni che possono essere utilizzate da diverse applicazioni, come:

• Riuso di componenti già esistenti
• Composizione di servizi in sistemi complessi
• Approccio modulare allo sviluppo di applicazioni complesse

Eterogeneità e Standardizzazione

Per integrare sistemi eterogenei è necessario un processo di standardizzazione al fine di rendere possibile la cooperazione tra i componenti.

• Comunicazione: i protocolli di comunicazione devono essere omogenei. Possono esserci diversi formati di dati e protocolli di comunicazione: senza uno standard è impossibile una cooperazione tra i componenti.
• Interfacce ed Invocazioni di Servizi: sono legate ad un ambito applicativo. Un'invocazione simile porta ad uno sviluppo più semplice, a vantaggio dell'utilizzo dei servizi.
• Composizione: indica come comporre diversi servizi al fine di sviluppare un sistema molto complesso. Queste tre caratteristiche portano ad un'ottica di Service Oriented Architecture (SOA).