Capitolo 1RMI e la programmazionedistribuita

GIOVANNI PULITI

IntroduzioneQuesto capitolo è dedicato alla programmazione distribuita tramite la Remote Method Interface

API, il protocollo di comunicazione e invocazione introdotto con il JDK 1.1 e divenuto ormai unadelle colonne portanti del cosiddetto Java distributed computing. Per programmazione distribu-ita si intende tipicamente quel particolare paradigma computazionale in cui una applicazioneviene organizzata in moduli differenti localizzati in spazi di indirizzamento diversi fra loro.

In questo contesto la Remote Method Invocation (RMI) consente di realizzare applicazionidistribuite in cui un programma A è in grado di invocare i metodi di un oggetto B in esecuzione suun computer remoto: in tale scenario, per semplicità, si definisce client il programma chiamante,mentre il remoto è detto server.

Molti sono i vantaggi derivanti dall’adozione di tale modello: un sensibile miglioramento delleprestazioni complessive, una maggiore semplicità nella gestione delle risorse distribuite, e unsostanziale incremento delle potenzialità operative. Ad esempio si può pensare di suddividere unprocesso computazionalmente pesante in sottoroutine più piccole ed eseguire tali “pezzi di appli-cazione” su macchine diverse ottenendo una drastica diminuzione del tempo complessivo diesecuzione.

Nel caso in cui invece l’efficienza non sia l’obiettivo principale, si può comunque trarre vantag-gio da una organizzazione distribuita, potendo gestire meglio e più semplicemente le varie risorselocalizzate nei differenti spazi di indirizzamento. Si pensi per esempio a una strutturazione a trelivelli (3-Tier) per la gestione di database relazionali in Internet: dal punto di vista del client ci sideve preoccupare esclusivamente dell’interfacciamento con l’utente e dello scambio con il serverremoto delle informazioni contenute nel database.

Un altro importante scenario in cui è utile l’utilizzo del modello distribuito è quello in cui sidebbano realizzare applicazioni che si interfacciano con codice legacy: in tal caso si può pensare

2 Capitolo 1. RMI e la programmazione distribuita

di inglobare gli applicativi esistenti (legacy appunto) in oggetti remoti e pilotarne in tal modo lefunzionalità da un client Java. In realtà, per questo genere di integrazioni si preferisce spessoutilizzare tecnologie come CORBA, dato che RMI richiede l’utilizzo esclusivo di Java comelinguaggio di sviluppo, cosa che rende difficile l’integrazione con programmi scritti in altri lin-guaggi (alla fine del capitolo viene presentata l’evoluzione di RMI, basata sul protocollo IIOP, cherisolve in parte questo problema di interoperabilità).

Modelli distribuitiUno dei requisiti fondamentali per implementare un sistema distribuito è disporre di un siste-

ma di comunicazione fra macchine diverse, basato su standard e protocolli prestabiliti.In Java la gestione dei socket è un compito relativamente semplice, tanto che si possono

realizzare in maniera veloce sistemi di comunicazione con i quali scambiare informazioni in reteo controllare sistemi remoti. L’implementazione di una connessione via socket risolve però solo ilproblema di fondo (come instaurare la connessione) ma lascia in sospeso tutta la parte di defini-zione delle modalità di invocazione e dei vari protocolli per lo scambio delle informazioni.

Prima dell’introduzione di RMI, erano già disponibili strumenti per l’esecuzione di codiceremoto, basti pensare alla Remote Procedure Call (RPC): con questa tecnologia è possibile gestireprocedure facenti parte di applicazioni remote rispetto al chiamante. Le RPC hanno visto ilmassimo del loro successo nei sistemi Unix e sono strettamente legate al concetto di processo, mamale si inseriscono nel contesto del paradigma basato sugli oggetti. È questo il motivo principalealla base dell’esigenza di una tecnologia apposita, come RMI, per la gestione di oggetti distribuiti.

In realtà il panorama della progettazione e gestione di oggetti distribuiti offre valide alternative,come ad esempio DCOM (estensione di COM proprietaria di Microsoft) o CORBA: dato cheuna trattazione approfondita delle possibili alternative esula dagli scopi di questo capitolo, si puòbrevemente dire che la scelta può ricadere su RMI nel caso in cui si voglia implementare, inmaniera semplice e veloce, una struttura a oggetti distribuiti full-Java (sia il lato client che quelloserver devono essere realizzati obbligatoriamente utilizzando tale linguaggio).

Interoperabilità e RMIPurtroppo la semplicità di RMI non sempre può essere adottata per la realizzazione di applica-

zioni distribuite. Il protocollo di comunicazione è stato progettato volutamente per effettuarealcune operazione alquanto complesse, in modo da garantire quelli che poi sono divenuti i puntidi forza di RMI, come gestione della sicurezza sulle invocazioni remote, garbage collector distri-buito e così via.

La presenza di network eterogenei di cui non è possibile a priori conoscere la reale organizzazio-ne (router che effettuano natting di sottoreti, firewall di vario tipo, per citare due casi), impedisce lacomunicazione fra client e server RMI, tanto da rendere impossibile l’adozione di tale protocollo.

In realtà queste problematiche si presentano in vario modo con tutti i protocolli di computazionedistribuita, dato che tutti si basano su sistemi, convenzioni, sintassi e semantiche di comunicazio-ne più o meno proprietarie.