Il modello di chiamata di procedura remota o RPC è un’estensione ai sistemi distribuiti del modello procedurale dei linguaggi di programmazione tradizionali.
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.
Lo stub cliente:
Lo stub servente:
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.
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:
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:
Malfunzionamenti possibili:
che possono causare
Semantiche possibili per le 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.
E’ garantita la mutua esclusione tra le procedure all’interno di uno stesso programma remoto:
Per l’esternalizzazione dei dati viene adottato lo standard XDR (eXternal Data Representation).
Sun RPC si basa su TCP o UDP:
Nel caso si usi UDP le procedure devono quindi essere idempotenti.
C’e’ bisogno sul nodo servente di un dispatcher dei messaggi dei clienti agli opportuni stub.
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 binding dinamico consente la trasparenza della locazione.
Algoritmo del port mapper
Crea una socket a un porto predefinito (111)
Accetta indefinitamente richieste di
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.
(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.
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.
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.
(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).
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.
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.
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).
I servizi offerti da un middleware TP comprendono:
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).
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.
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.
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.
In questo modello le interazioni tra processi sono tipicamente di tipo asincrono.
Lo spazio delle tuple può essere considerato uno spazio di memoria associativa.
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 TS è adatto per realizzare sistemi SOA – Service Oriented Architectures
Componenti di una SOA:
In TBM TSpaces le tuple sono strutture dati costituite da campi, che possono contenere:
Primitive per l’accesso allo spazio delle tuple:
2. La modellazione a oggetti e il linguaggio UML (richiami)
3. Generalità su Java e la programmazione ad oggetti
6. Regole di traduzione da UML a Java/C++
7. Programmazione multi-thread
8. Sincronizzazione tra thread
9. Programmazione client-server con socket TCP/IP (Java networkin...
10. Programmazione di applicazioni client-server: il Pattern Proxy...
12. Design Patterns
13. Pattern architetturali - Esempi
14. Design pattern creazionali. Esempi
15. Design pattern strutturali. Esempi
16. Introduzione alle tecnologie middleware
17. Modelli di middleware: RPC, MOM, TP, TS
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.