Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Stefano Russo » 17.Modelli di middleware: RPC, MOM, TP, TS


Il modello RPC

Il modello di chiamata di procedura remota o RPC è un’estensione ai sistemi distribuiti del modello procedurale dei linguaggi di programmazione tradizionali.


Funzionamento del meccanismo RPC

In fase di compilazione vengono automaticamente generate speciali funzioni di interfaccia dette stub, una dal lato cliente ed una dal lato servente, che vengono poi collegate con le due parti dell’applicazione.

Gli stub implementano in maniera in gran parte trasparente al programmatore lo scambio parametri e la comunicazione attraverso la rete tra il programma chiamante (cliente) e la procedura remota chiamata (servente). A tal fine gli stub accedono direttamente ai servizi di trasporto dei protocolli di rete.


Stubs

Lo stub cliente:

  • preleva i parametri di scambio dal chiamante;
  • li impacchetta in un apposito messaggio, che affida al software di rete affinché sia trasmesso alla macchina dove risiede il servente;
  • attende il messaggio di risposta che indica il completamento della procedura remota;
  • spacchetta il messaggio prelevando i valori dei parametri di uscita;
  • restituisce i parametri al programma chiamante, che riprende controllo.

Lo stub servente:

  • attende (dal software di rete) un messaggio di invocazione della procedura;
  • spacchetta il messaggio, prelevando i parametri di scambio;
  • trasmette i parametri alla procedura chiamata, cui cede il controllo;
  • riprende il controllo al termine della procedura, ed impacchetta i parametri di uscita in un messaggio di risposta al cliente;
  • invia il messaggio di risposta e si mette nuovamente in attesa di una richiesta.

Il programma chiamante invoca una procedura a tutti gli effetti locale (stub cliente), ed analogamente la procedura remota viene invocata come una procedura locale da parte dello stub servente.

Middleware RPC

Nei sistemi RPC la comunicazione tra processi è intrinsecamente di tipo sincrono e bloccante: il processo chiamante resta sospeso fino al completamento della procedura remota. La disponibilità di meccanismi asincroni (non bloccanti) nei sistemi RPC è da considerarsi un’eccezione.
I sistemi RPC non costituiscono un vero e proprio strato middleware aperto e a sé stante; essi vengono tipicamente implementati in due modi:

  • come infrastrutture nel contesto di ambienti proprietari di Computer Aided Software Engineering (ambienti CASE);
  • dal programmatore mediante strumenti automatici di generazione degli stub: un esempio è costituito dal sistema RPCgen sviluppato da Sun Microsystems per le piattaforme Unix SunOS/Solaris.

Marshalling dei parametri

L’operazione di impacchettamento (spacchettamento) dei parametri della chiamata di procedura, svolta dagli stub, prende il nome di marshalling (unmarshalling).

Il marshalling dei parametri consiste di:

  • una conversione di formatodei dati, per tener conto delle differenze di rappresentazione tra cliente e servente: in generale le due piattaforme sono eterogenee, ed è possibile che adottino rappresentazioni interne diverse. Per es.:
    • interi in complementi alla base o complementi diminuiti;
    • a parità di rappresentazione, ordinamento dei byte big endian o little endian;
  • una serializzazione dei dati, che vengono trasformati in sequenze di byte ed impacchettati, secondo un formato compreso da cliente e servente. In particolare occorre linearizzare i dati strutturati, quali array e record.

Semantica delle RPC

Malfunzionamenti possibili:

  • nella rete;
  • nei singoli nodi;

che possono causare

  • perdita del messaggio di richiesta;
  • perdita del messaggio di risposta;
  • caduta del nodo servente dopo la ricezione della richiesta ma prima dell’invio della risposta.

Semantiche possibili per le RPC:

  • Exactly once;
  • At most once;
  • At least once;
  • Zero or more.

Un middleware RPC: Sun RPC

L’implementazione RPC di Sun Microsystems prevede come entità in esecuzione su una macchina servente un programma, che contiene una o più procedure invocabili remotamente.

Le procedure all’interno di uno stesso programma operano nello stesso ambiente d’esecuzione, quindi possono condividere variabili.

E’ possibile avere attive su un nodo più versioni dello stesso programma.

Una tripla di interi (programma, versione, procedura) è sufficiente al cliente per identificare la procedura da invocare.

Programma remoto

Programma remoto


Un middleware RPC: Sun RPC

E’ garantita la mutua esclusione tra le procedure all’interno di uno stesso programma remoto:

  • al più una procedura può essere in esecuzione in un dato istante, anche in presenza di più clienti.

Per l’esternalizzazione dei dati viene adottato lo standard XDR (eXternal Data Representation).
Sun RPC si basa su TCP o UDP:

  • UDP: se il cliente riceve una risposta, la chiamata è stata eseguita almeno una volta (semantica at least once);
  • UDP: se il cliente non riceve risposta, la chiamata è stata eseguita zero o più volte (semantica zero or more);
  • TCP: se il cliente riceve una risposta, la chiamata è stata eseguita una volta (semantica exactly once);
  • TCP: se il cliente non riceve risposta, la chiamata è stata eseguita zero una volta (semantica at most once).

Nel caso si usi UDP le procedure devono quindi essere idempotenti.

Un middleware RPC: Sun RPC

C’e’ bisogno sul nodo servente di un dispatcher dei messaggi dei clienti agli opportuni stub.


Un middleware RPC: Sun RPC

Nella programmazione con socket TCP/UDP, cliente e servente devono concordare preventivamente il numero del porto sul quale il servente è in ascolto, perché entrambi consultano una lista pubblica e prefissata di assegnazione dei porti.
Sun RPC adotta invece un meccanismo di binding dinamico.

  • Il servente ottiene dinamicamente un numero di porto disponibile.
  • Il cliente non può dunque conoscere il porto finché il server non viene attivato.
  • Sul nodo server gira un processo RPC port mapper che gestisce una lista dei serventi attivi.
  • All’attivazione di un programma RPC, il port mapper registra la coppia (numero programma, numero porto).
  • Il port mapper opera su una socket ad un porto prefissato (111), uguale per ogni server.
  • Il cliente deve contattare il port mapper del server prima di eseguire la RPC (presenta il numero programma e riceve il numero porto).

Il binding dinamico consente la trasparenza della locazione.

Un middleware RPC: Sun RPC

Algoritmo del port mapper

Crea una socket a un porto predefinito (111)

Accetta indefinitamente richieste di

  • Registrazione di un programma RPC (dai serventi)
  • Ricerca del porto di un programma RPC (dai clienti)

Linguaggi di definizione delle interfacce

La specifica in un linguaggio IDL rappresenta un contratto tra le componenti cliente e servente di un’applicazione distribuita.

Tecnicamente, una specifica in linguaggio IDL serve a generare automaticamente il codice degli stub e poter quindi collegare le procedure applicative con quelle dello strato middleware.

Tuttavia la disponibilità di linguaggi IDL ha assunto nel tempo una valenza più generale, come strumento di specifica ad alto livello e di documentazione dal punto di vista strutturale (statico) delle componenti di un sistema software distribuito.

E’ così che anche le tecnologie middleware più recenti, in particolare le piattaforme ad oggetti distribuiti quali CORBA e DCOM hanno “riscoperto” l’importanza dei linguaggi IDL.

Il modello orientato ai messaggi

(Message Oriented Middleware, MOM)

I sistemi middleware a scambio messaggi (Message Oriented Middleware, MOM) si basano sull’astrazione di una coda di messaggi tra processi interoperanti su rete, che rappresenta una generalizzazione del noto concetto di mailbox, tipico dei sistemi operativi.


Il modello a scambio messaggi

Nel modello MOM la comunicazione è non è di tipo cliente-servente, ma tra pari (peer-to-peer), di tipo produttore-consumatore, e tipicamente asincrona, sebbene alcuni sistemi consentano anche uno scambio di messaggi di tipo sincrono.

Il modello a scambio messaggi

I sistemi MOM adottano inoltre un modello publish-subscribe, in cui i processi produttori pubblicano messaggi differenziati per tipo, ed i consumatori possono dichiararsi interessati ai messaggi in base al loro tipo.

Le piattaforme MOM sono adatte per applicazioni guidate dagli eventi (event-driven): quando si verifica un evento, un processo produttore affida al middleware la responsabilità di prendere in consegna un messaggio ed inoltrarlo o semplicemente notificarne la disponibilità ai processi interessati al suo consumo. Molti sistemi MOM realizzano anche meccanismi di persistenza dei messaggi.

Il modello transazionale

(Transaction Processing, TP)

Il modello transazionale è in uso da decenni in applicazioni critiche di accesso a basi di dati, quali quelle in ambito bancario o assicurativo, o nei sistemi di prenotazione delle compagnie aeree.

Una transazione è una sequenza di elaborazioni che, pur eseguita in concorrenza con altre ed in un contesto in cui sono possibili malfunzionamenti e guasti, gode di ben precise proprietà atte a garantirne la correttezza, note in letteratura come proprietà ACID (Atomicità, Consistenza, Isolamento, Durata).

Il modello transazionale

Le proprietà ACID

Atomicità: una transazione è un’unità di lavoro indivisibile (proprietà del “tutto o niente”): l’unità di lavoro viene svolta per intero, oppure viene interamente annullata (rollback); non sono possibili esecuzioni parziali.

Consistenza: una transizione che parte da uno stato consistente delle risorse (dati) accedute, deve rilasciare le risorse stesse in uno stato consistente.

Isolamento: l’esecuzione di una transazione in concorrenza con altre, con cui compete per l’accesso alle risorse, deve essere equivalente ad una qualunque esecuzione sequenziale, come se fosse eseguita isolata dalle altre transazioni.

Durata: gli effetti di una transazione (aggiornamento dello stato delle risorse) devono essere persistenti.

Il modello transazionale

La tecnologia dei cosiddetti TP monitor è nata al principio degli anni ‘70 per lo sviluppo di applicazioni affidabili di accesso ad archivi centralizzati su sistemi di tipo mainframe.

Con lo sviluppo dei sistemi di gestione di basi di dati (DBMS), la gestione delle proprietà transazionali è stata incorporata nel motore dei sistemi DBMS.

Tuttavia i TP monitor hanno continuato a svolgere il ruolo di concentratori di connessioni a basi di dati, consentendo di ridurre il sovraccarico per il DBMS e migliorare le prestazioni in applicazioni su grande scala.

Il modello transazionale

La tecnologia è stata successivamente estesa al contesto dei sistemi distribuiti, ed oggi questa tipologia di sistemi middleware fornisce servizi affidabili e sicuri di aggiornamento dati per lo sviluppo di applicazioni di tipo cliente-servente a più livelli in ambiente eterogeneo.

Tuttora l’uso di sistemi TP monitor appare come la migliore soluzione per garantire l’integrità transazionale in applicazioni su vasta scala, ed in ambiente in cui coesistono sistemi DBMS diversi.

Per questo motivo anche altre categorie di middleware tendono ad incorporare funzionalità di tipo TP (es: servizio TP CORBA).

Middleware TP

I servizi offerti da un middleware TP comprendono:

  • assegnazione di priorità alle richieste, schedulazione e dispatching ai DBMS;
  • gestione di transazioni distribuite tra DBMS eterogenei;
  • gestione di transazioni multiprocesso;
  • bilanciamento del carico;
  • condivisione delle connessioni a un DBMS tra più clienti, per un aumento delle prestazioni;
  • creazione dinamica di nuove istanze dei processi di TP, per garantire scalabilità con l’aumento del carico;
  • ripristino da malfunzionamenti.

Middleware TP

Uno standard per i sistemi TP è lo X/Open Distributed Transaction Processing (DTP).

X/Open DTP definisce le interfacce applicative (API) tra il TP monitor, le applicazioni ed i gestori delle risorse (DBMS o gestori di archivi).


Middleware TP

Sia la parte cliente sia quella servente di un’applicazione distribuita accedono ai servizi del middleware mediante l’interfaccia applicativa chiamata TX.

Le primitive dell’API TX consentono al programmatore applicativo di demarcare una sequenza di istruzioni di accesso ai dati come un’unica unità di lavoro (transazione), cui il TP monitor deve garantire le proprietà ACID.

L’interfaccia tra il TP monitor ed i gestori delle risorse viene detta XA.

Le applicazioni accedono ai servizi di un gestore delle risorse attraverso la sua specifica interfaccia, ad esempio SQL per un DBMS.

Middleware TP

Un middleware TP si rende praticamente necessario quando una transazione distribuita coinvolge più DBMS eterogenei.

Una tecnica per la gestione di transazioni distribuite è quella del protocollo di commit a due fasi (Two-phase Commit o 2PC).

Tutti i principali sistemi DBMS commerciali sono in grado di gestire archivi distribuiti su nodi di rete diversi implementando il protocollo 2PC.

La semantica transazionale non è però garantita in pratica con quando sono coinvolti DBMS di produttori differenti.

In questo caso un TP monitor serve a coordinare i DBMS eterogenei.

Il modello dello spazio delle tuple

Sul modello dello spazio delle tuple si basa Linda, uno dei primi sistemi classificabili come middleware.

In Linda la comunicazione tra applicazioni ha luogo attraverso l’astrazione di uno spazio virtuale di memoria condiviso.

Due applicazioni possono sincronizzarsi e scambiarsi dati inserendo e prelevando strutture dati (le tuple) dallo spazio virtuale.


Il modello dello spazio delle tuple

In questo modello le interazioni tra processi sono tipicamente di tipo asincrono.

Lo spazio delle tuple può essere considerato uno spazio di memoria associativa.

  • Accesso per tipo e contenuto, non per indirizzo.

Un’operazione di lettura richiede una tupla-modello (pattern), da confrontare con le tuple presenti nello spazio.

Il modello è tornato di una certa attualità con la moderna tecnologia JavaSpace, su cui è basata anche la tecnologia Jini.

Il modello dello spazio delle tuple

Il modello TS è adatto per realizzare sistemi SOAService Oriented Architectures

Componenti di una SOA:

  • Servente (provider);
  • Cliente (requestor);
  • Catalogo dei servizi (registry).

Un middleware TS: IBM TSpaces

In TBM TSpaces le tuple sono strutture dati costituite da campi, che possono contenere:

  • tipi primitivi (interi, reali, stringhe, …);
  • tipi complessi (array, oggetti, …).

Primitive per l’accesso allo spazio delle tuple:

  • write(tuple): aggiunge una tupla;
  • take(tuplePattern): rimuove una tupla corrispondente al pattern (se esiste);
  • waitToTake(tuplePattern): come take, ma bloccante;
  • read(tuplePattern): legge senza rimuovere;
  • waitToRead(tuplePattern): come read, ma bloccante;
  • count(tuplePattern): conta le tuple corrispondenti al pattern.

I materiali di supporto della lezione

AA. VV., Java Server Programming – J2EE Edition, Wrox Press, 2000.

Bernstein P.A., Middleware: A Model for Distributed Services, Communications of the ACM, Vol. 39, N. 2, 1996.

Birrell A.D., Nelson B.J., Implementing Remote Procedure Calls, ACM Transactions on Computer Systems, Vol. 2, N. 1, 1984.

Gelernter D., Generative Communication in Linda, ACM Transactions on Programming Languages and Systems, Vol. 7, N. 1, 1985.

Carriero N., Gelernter D., How to Write Parallel Programs: A Guide to the Perplexed, ACM Computing Surveys, 1989.

Coulouris G., Dollimore J., Kindberg T., Distributed Systems: Concepts and Design, Addison-Wesley, 1998.

Edwards W.K., Joy B., Core Jini – 2nd ed., Prentice Hall, 2001.

Lehman T.J. et al., Hitting the distributed computing sweet spot with TSpaces, Computer Networks, Vol. 35, 2001.

Monson-Haefel R., Enterprise Java Beans, O’Reilly, 2000.

Mullender S., Distributed Systems, Addison-Wesley, 1993.

Natis Y., Pezzini M., Shulte R., Middleware Deployment Trends: Survey of Real-World Enterprise Applications, Gartner Strategic Report, 1999.

Sing Li, Professional Jini, Wrox Press, 2000.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93