Analisi, progettazione e implementazione di un repository di componenti distribuite in Java basato su JNDI.

Transcript

1 UNIVERSITÀ DEGLI STUDI DI ROMA LA SAPIENZA TESI DI LAUREA IN SCIENZE DELL INFORMAZIONE Analisi, progettazione e implementazione di un repository di componenti distribuite in Java basato su JNDI. Relatore: Prof. Gianfranco Bongiovanni Candidato: Marco Bianchi Correlatori: Dott. Carlo Gaibisso Ing. Giuseppe Martufi Ing. Maurizio Vitale Matricola: Anno Accademico

2

3 Indice 1 INTRODUZIONE Ambientazione della tesi Evoluzione della programmazione object-oriented Evoluzione delle architetture software nella programmazione distribuita Evoluzione d Internet e della programmazione lato server Obiettivi della tesi Struttura della tesi 14 PARTE I: LE TECNOLOGIE UTILIZZATE 2 LE ARCHITETTURE SOFTWARE NELLA PROGRAMMAZIONE DISTRIBUITA Problema del Tempo di Risposta (Latency) Partial Failure Spazio d indirizzamento ORB RMI Architettura di RMI Le applicazioni RMI Rmiregistry Multithreading RMI e i firewall Attivazione di oggetti remoti CORBA Architettura di CORBA IDL L architettura di un ORB CORBA Multithreading CORBA e firewall L implementation repository e l interface repository JavaIDL La struttura di un applicazione CORBA basata su JAVA IDL Il supporto JAVA IDL Il Client 46

4 Il Server JAVA IDL Transient Nameservice Uso degli object reference in forma di stringa RMI-IIOP 53 3 SERVIZI DI NAMING E DIRECTORY Servizi di naming Servizi di directory Il directory Lightweight Directory Access Protocol Struttura delle informazioni memorizzate Il sistema di naming Tecniche di distribuzione Le operazioni Query Aggiornamento Autenticazione La sicurezza Java Naming and Directory Interface Package javax.naming Gestione dei contesti Il contesto iniziale La gestione dei nomi degli oggetti Il contenuto di un contesto Le altri classi del package Le eccezioni Package javax.naming.directory Gli oggetti directory Gli attributi Il contesto iniziale Le ricerche nel directory Package javax.naming.event La rappresentazione di un evento I Naming Listener L attivazione e la disattivazione di un listener Package javax.naming.ldap Package javax.naming.spi LE PROGRAMMAZIONE WEB 109

5 4.1 Evoluzione d Internet e della programmazione lato server La piattaforma J2EE Gli obiettivi di J2EE Caratteristiche generali Container e componenti Componenti lato Client Componenti di business logic Vantaggi della piattaforma J2EE J2EE: Scenari applicativi tipici Scenario Stand-Alone Client Scenario Web-Centric Scenario n-tier Scenario Business to Business Servizi offerti da J2EE Naming Deployment Transazioni Sicurezza Autenticazione Autorizzazione Pagine web a contenuto dinamico Tecnologie server side CGI (Common Gateway Interface) ASP (Active Server Pages) Sevlet e JSP Servlet Implementazione e ciclo di vita di una servlet JSP Template Text Comment Directive Action Scripting element ALTRE TECNOLOGIE UTILIZZATE Simple Network Management Protocol Breve introduzione Lo standard SNMP Il sistema di gestione SNMP L'agente SNMP Il MIB Struttura e rappresentazione dei nomi degli oggetti del MIB 142

6 PARTE II: NETLAB REMOTE COMPONENTS REPOSITORY 6 NETLAB REMOTE COMPONENTS REPOSITORY Requisiti funzionali di NRCR Requisiti non funzionali e scelte tecnologiche Portabilità Mobilità Usabilità Estendibilità Distribuibilità delle informazioni memorizzate Analisi e soluzione dell obiettivo 1: servizio di naming dinamico Utilizzatore di NRCR e vantaggi offerti da NRCR L oggetto directory repositorycomponent Struttura logica Implementazione di Component Address Provider Approfondimento sull Object Selector Implementazione dell Object Selector Un esempio pratico: SnmpObjectSelector Analisi e soluzione dell obiettivo 2: gestione delle applicazioni web NRCR Istanza di Servizio NRCR Servizio NRCR L oggetto directory repositoryservice Funzionamento della ServiceManagerServlet Spiegazione conclusiva su ServiceManager Osservazioni finali Analisi e soluzione dell obiettivo 3: Applicazione web per la navigazione delle componenti e dei servizi Due categorie d utenza: User e Developer L oggetto directory repositoryuser Implementazione dell applicazione web Funzionamento di RepositoryServlet Funzionamento ElencoServizi.jsp ed ElencoComponenti.jsp Esempio d interazione con il sistema NRCR L ambiente di sviluppo Netlab Gestione delle informazioni nel server LDAP 190

7 7 CONCLUSIONI E SVILUPPI FUTURI Sviluppi futuri Possibili miglioramenti a NRCR nell ambito del Netlab Nuovi argomenti di ricerca APPENDICE Pattern per la progettazione degli accessi ad oggetti remoti Factory Dispenser Legenda per i diagrammi di classi dei package JNDI Contenuto del CD-ROM Struttura e contenuto della cartella Sorgenti Struttura della cartella Software Struttura della cartella Documentazione 203 GLOSSARIO 204 BIBLIOGRAFIA 206

8 1 Introduzione 1.1 Ambientazione della tesi Per ambientare il lavoro svolto in questa tesi è opportuno analizzare l evoluzione che in quest ultimo decennio, ha portato tre diversi settori informatici a combinarsi tra loro per dar vita a ciò che oggi è conosciuto con il nome d applicazioni enterprise. I tre settori, di cui si evidenzieranno alcuni aspetti delle loro recenti evoluzioni, sono: La programmazione orientata agli oggetti; Le architetture software nella programmazione distribuita; Internet e la programmazione lato server Evoluzione della programmazione object-oriented Negli ultimi dieci anni si è potuto costatare la definitiva affermazione dei linguaggi orientati agli oggetti, a conclusione di un loro utilizzo sempre più frequente cominciato negli anni 80. Java è una testimonianza significativa: introdotto nel 1995, noto a tutti come il primo linguaggio multi-piattaforma, si è imposto nella comunità degli sviluppatori con una velocità sorprendente, tanto che, in meno di dieci anni, si è riuscito a ritagliare un ruolo molto importante nell ambito della programmazione lato server. Il successo dei programmi orientati agli oggetti è chiaramente legato a meccanismi come l incapsulamento, l ereditarietà e il

9 Introduzione Ambientazione della tesi polimorfismo, che, se correttamente applicati, permettono la realizzazione di un ambiente di programmazione che sostiene lo sviluppo d applicativi più solidi e scalabili, rispetto al modello orientato al processo. Infatti: l ereditarietà favorisce la definizione di una gerarchia ben progettata di classi in modo tale da riutilizzare quel codice il cui sviluppo e collaudo hanno richiesto tempo e fatica; l incapsulamento consente di modificare le varie implementazioni nel tempo, senza infrangere il codice che dipende dall interfaccia pubblica della classe ritoccata; il polimorfismo permette di creare un codice pulito, logico, leggibile ed elastico. Inoltre l affermazione dei linguaggi di programmazione objectoriented [6] ha influenzato anche le modalità costruttive delle applicazioni software, che si sono evolute verso la programmazione per componenti. Per componente s intende un modulo software progettato per essere utilizzato ripetutamente. Oggigiorno programmare per componenti comporta almeno due importanti vantaggi: Una maggiore competitività, in termini di velocità di sviluppo e di consegna delle applicazioni; Una riduzione dei costi di sviluppo e manutenzione. 2

10 Introduzione Ambientazione della tesi Evoluzione delle architetture software nella programmazione distribuita Per sistema distribuito s intende un insieme d elaboratori autonomi connessi tra loro attraverso una rete informatica ed equipaggiati da un software specializzato, che permette loro la condivisione di risorse a livello hardware, software e dati. Gli utenti di un sistema distribuito ben strutturato dovrebbero avere la sensazione di utilizzare un unico e potente elaboratore e quindi accedere a tali risorse senza sapere dove queste siano effettivamente localizzate. La Figura 1.1 mostra la struttura di un semplice sistema distribuito in cui personal computer e workstation condividono, attraverso una rete locale, le risorse messe a disposizione dal sistema per mezzo di server dedicati [1]. Figura Esempio di semplice sistema distribuito In questo decennio le potenzialità dei sistemi distribuiti hanno catturato l interesse dei maggiori produttori di tecnologie software, grazie anche alla contemporanea consacrazione delle reti di elaboratori come strumento di lavoro per le piccole, medie e grandi 3

11 Introduzione Ambientazione della tesi aziende. I risultati delle ricerche che sono state effettuate hanno portato all affermazione di architetture software object-oriented distribuite come CORBA (Common Object Request Broker Architecture), proposta dall OMG (Object Management Group) nel 1990, DCOM (Distributed Component Object Model) proposta da Microsoft nel 1996, RMI (Remote Method Invocation) e successivamente RMI/IIOP (RMI/Internet Inter Orb Protocol) entrambe introdotte da Javasoft, rispettivamente nel 1995 e La programmazione ad oggetti ed i sistemi distribuiti trovano un naturale punto d incontro che favorisce lo sviluppo di scenari in cui le componenti in esecuzione in ambienti distribuiti (oggetti remoti distribuiti o componenti remote distribuite) mettono a disposizione del sistema delle funzionalità. Tali funzionalità possono essere sfruttate e combinate da applicazioni o da altre componenti più complesse Evoluzione d Internet e della programmazione lato server La diffusione d Internet come mezzo di comunicazione è stata favorita dalla possibilità di accedere ad un numero d informazioni potenzialmente infinito, sia in termini di quantità che di tipologia. Nella seconda metà degli anni 90 si è assistito ad un importante evoluzione della rete che si è trasformata in uno strumento in grado anche di erogare dei servizi (si pensi, ad esempio, al commercio elettronico) attraverso un nuovo tipo d applicazioni distribuite: le applicazioni enterprise [41]. 4

12 Introduzione Ambientazione della tesi Le applicazioni enterprise implicano, per definizione, l accesso ad altre applicazioni, dati o servizi sparsi all interno delle infrastrutture informatiche del fornitore di servizi. Le informazioni gestite e i dati contenuti all interno di tali infrastrutture rappresentano la ricchezza del fornitore e come tali vanno trattati con estrema cura, garantendone l integrità. Al modello bidimensionale delle vecchie forme di business legato ai sistemi informativi (Figura 1.2), è stato oggi sostituito un nuovo modello denominato e-business (Figura 1.3). Esso introduce una terza dimensione che rappresenta la necessità da parte del fornitore di garantire accesso ai dati contenuti nell infrastruttura aziendale via web a partner commerciali, consumatori, impiegati e altri sistemi informativi. Figura Vecchio Modello Business 5

13 Introduzione Ambientazione della tesi Figura Nuovo Modello Business Le applicazioni enterprise hanno reso obsoleta l iniziale architettura client-server inizialmente utilizzata in Internet per accedere alle pagine web statiche, ovvero a pagine memorizzate su server web, che vengono restituite al client senza alcun tipo di elaborazione, come mostrato in Figura 1.4. Figura Semplice architettura client server Oggi la possibilità di creare pagine web dinamiche, vale a dire pagine il cui contenuto può cambiare in base al tipo di richiesta e/o d utente, comporta, nel caso più semplice, l introduzione di un nuovo strato (three tier model) [38]. 6

14 Introduzione Ambientazione della tesi Figura Modello 3 tier In questo caso, come mostrato in Figura 1.5, si possono distinguere tre parti logiche: livello presentazione (presentation layer); livello di business-logic (business logic layer); livello dati (data layer). Il livello presentazione fornisce di solito le funzionalità strettamente legate all interazione con l utente. Il livello di business logic racchiude la logica dell applicazione e funge da ponte verso il terzo strato. Il livello dati, è il livello dove generalmente si trovano memorizzati i dati utilizzati dall applicazione web. Naturalmente questo modello costituito da tre livelli può essere ulteriormente frammentato secondo le esigenze specifiche dando così vita a ciò che è chiamato modello client-server a n strati (n-tieer model) [37]. 7

15 Introduzione 1.2 Obiettivi della tesi Questa tesi è stata realizzata presso il Netlab, un gruppo di lavoro del CNR (Centro Nazionale di Ricerca) di Roma, che sviluppa ricerche in ambienti di rete. Lo scopo è di progettare un architettura software distribuita chiamata Netlab Remote Components Repository (NRCR) che permetta ad un programmatore d applicazioni enterprise e/o distribuite di essere facilitato nel creare, trovare, utilizzare componenti remote distribuite sulla rete. Più esplicitamente si vogliono raggiungere i seguenti obiettivi: 1. Permettere l accesso trasparente agli oggetti distribuiti registrati nel repository. Il termine trasparente va inteso in due modi: Trasparenza rispetto alla locazione. Si vuole dare la possibilità di localizzare e utilizzare un oggetto remoto conoscendone il nome, senza possederne a priori l indirizzo; Trasparenza rispetto all istanza. Si vuole dare la possibilità di gestire più copie dello stesso oggetto remoto 1 in esecuzione su diverse macchine. Questo significa che non si può sapere a priori a quale istanza d oggetto si sta facendo riferimento. I vantaggi sono 1 Due copie di un oggetto remoto si considerano uguali se, a parità d input, produrranno gli stessi output, indipendentemente dalla loro locazione. 8

16 Introduzione Obiettivi della tesi molteplici: si possono aggiungere nuove copie delle componenti rendendole immediatamente disponibili, si rende il sistema più robusto, si prevede la possibilità di bilanciare il carico di lavoro, ecc.; 2. Prevedere la possibilità di visualizzare i risultati prodotti dagli oggetti remoti ai navigatori Internet. Generalmente un oggetto remoto è progettato per restituire dei risultati e non per presentarli agli utenti Internet. Ad esempio, una componente software potrebbe restituire il risultato di un calcolo eseguito sotto forma di numero intero. Affinchè tale risultato possa essere visualizzato ad un utente Internet bisognerà formattare un opportuna pagina HTML. Per questo motivo il sistema deve prevedere la gestione di quello strato software che interagisce con le componenti e confeziona risultati in modo da renderli interpretabile da un web browser e presentabili all utente. In pratica si sta richiedendo al sistema una gestione delle applicazioni enterprise; 3. Pubblicizzare le componenti remote rendendo accessibili le informazioni che le riguardano attraverso un web browser. Nel precedente paragrafo sono stati evidenziati i vantaggi che derivano dal riutilizzo delle componenti. Un problema che molte società di sviluppo software si trovano costrette a risolvere è quello di far conoscere ai propri programmatori quali componenti sono già state sviluppate e quali funzionalità forniscono. Generalmente tale problema è risolto con l introduzione di un database. Il sistema NRCR 9

17 Introduzione Obiettivi della tesi prevede la possibilità di gestire tali informazioni e di renderle accessibili via web, senza dover ricorrere a un database aggiuntivo. Nel Capitolo 6.5 verrà presentata una semplice applicazione web che permette la visualizzazione dell elenco dei servizi e delle componenti disponibili nel NRCR. L obiettivo meno intuitivo è sicuramente il primo e per questo merita un breve approfondimento. Analizzando le problematiche riguardanti la programmazione d oggetti remoti, si pone particolare attenzione agli aspetti legati ai servizi di naming, vale a dire quei meccanismi che permettono di ottenere un oggetto o il suo riferimento, a partire dal suo nome. Le tecnologie tenute in considerazione come RMI, CORBA, RMI/IIOP, offrono un proprio servizio di naming attraverso speciali database che permettono la localizzazione e l uso degli oggetti remoti. Tali archivi cambiano nome secondo la tecnologia scelta ma concettualmente sono la stessa cosa. In RMI, per esempio, si parla di rmiregistry, in Corba d implementation repository, in RMI/IIOP di tnameserv. In tutte queste tecnologie per accedere ad una componente bisogna conoscere: l indirizzo della macchina su cui è in esecuzione il database che fornisce il servizio di naming; il nome con cui tale componente è stata registrata nel database. 10

18 Introduzione Obiettivi della tesi In questa tesi si vogliono creare i presupposti affinché, un oggetto sia accessibile senza conoscere l indirizzo della macchina su cui è in esecuzione il database che fornisce il servizio di naming. In altre parole, il nome con cui una componente è stata registrata nel NRCR, deve essere sufficiente per ottenerne il riferimento. In questo modo più copie di uno stesso oggetto remoto in esecuzione su macchine diverse e, soprattutto, registrate in archivi distinti, sono potenzialmente accessibili attraverso lo stesso nome. Inoltre il sistema può scegliere quale copia far utilizzare. Facendo riferimento alla Figura 1.6, si consideri il seguente esempio. Si supponga d avere tre rmiregistry in esecuzione su tre macchine distinte ( , , ). Su ognuna di queste tre macchine viene lanciata un istanza di un oggetto remoto RMI che fornisce servizi di calcolo. Tali istanze si registrano sull rmiregistry della rispettiva macchina con il nome calcolatrice. In una situazione normale per accedere ad una delle tre componenti risulta indispensabile conoscerne l indirizzo completo, ad esempio rmi:// /calcolatrice. Utilizzando NRCR basta conoscere il nome calcolatrice. Infatti si può registrare nel NRCR una componente con tale nome e indicare gli indirizzi delle tre istanze viste prima come possibili locazioni della componente. Chi vuole utilizzare la componente calcolatrice può richiederla al sistema (Figura 1.6: punto 1), che sceglie quale istanza far utilizzare e ne restituisce l indirizzo (Figura 1.6: punto 2). A 11

19 Introduzione Obiettivi della tesi questo punto l utilizzatore può accedere alla componente nel modo usuale (Figura 1.6: punto 3). Figura Esempio di come Netlab Remote Components Repository permette l'accesso a una componente registrata E interessante evidenziare la differenza tra un sistema di naming normale (statico) e quello messo a disposizione da NRCR (dinamico). Nel primo tipo esiste un rapporto 1:1 tra il nome e l oggetto associato. Nel sistema proposto in questa tesi tale rapporto è, al momento della richiesta 1:n (Figura 1.6: punto 1) e torna ad essere 1:1 quando il sistema sceglie, tra gli n riferimenti disponibili, quale restituire (Figura 1.6: punto 2). Visto che il sistema deve fare una scelta, si è pensato di progettare un meccanismo che permetta al programmatore che utilizza NRCR, di implementare e utilizzare un proprio criterio di convenienza. In caso contrario, come si approfondirà nel capitolo della descrizione del progetto, il sistema permette di utilizzare un criterio di scelta di default. 12

20 Introduzione Obiettivi della tesi Infine è opportuno evidenziare che questa tesi è stata sviluppata all interno di un gruppo di lavoro del CNR. Per questo motivo si è posto un ulteriore obiettivo: individuare i possibili sviluppi futuri, per permettere di continuare, in successive tesi, questo lavoro di ricerca. 13

21 Introduzione 1.3 Struttura della tesi La tesi è suddivisa in due parti. La prima parte, composta di quattro capitoli, si pone come obiettivo la trattazione degli aspetti fondamentali delle tecnologie utilizzate, evidenziandone ciò che è ritenuto più inerente al lavoro affrontato. Nella seconda parte della tesi si descrive il progetto Netlab Remote Components Repository. Il codice sviluppato è contenuto nel CD-Rom allegato, insieme ai sorgenti, alla documentazione raccolta in questi mesi e alle applicazioni necessarie per la ricostruzione dell ambiente di sperimentazione. Di seguito è riportata una descrizione sintetica dei capitoli che compongono il lavoro della tesi. Parte I Le tecnologie utilizzate Cap. 2 Le architetture software nella programmazione distribuita In questo capitolo si presentano tre architetture software Java utili per progettare e implementare programmi distribuiti. Le tre architetture in questione sono RMI, JavaIDL, RMI/IIOP. Visto che, per poter spiegare JavaIDL e RMI/IIOP, è necessario conoscere alcuni aspetti dell architettura CORBA, è previsto un paragrafo che ne introdurrà i concetti di base. Il taglio che si è voluto dare a queste presentazioni, è 14

22 Introduzione Struttura della tesi di tipo teorico. Ciò significa che non si scenderà in dettagli implementativi, se non in caso di necessità. Cap. 3: Servizi di naming e directory In questa sede vengono introdotti i servizi di naming/directory e successivamente viene illustrato un protocollo standard di accesso a directory chiamato LDAP (Lightweight Directory Access Protocol), utilizzato nel progetto per accedere al directory server dove sono state memorizzate le informazioni utili al funzionamento del sistema. Infine è descritta la struttura del package JNDI (Java Naming and Directory Interface), un package java proposto da Sun, che fornisce un interfaccia che semplifica l interazione con i sistemi di naming/directory più importanti, tra cui LDAP. Cap. 4: La programmazione web Dopo una breve introduzione sull evoluzione della programmazione Internet viene presentata la piattaforma Java 2 Enterprise Edition (J2EE), evidenziandone le caratteristiche generali, i vantaggi e gli scenari applicativi tipici. In seguito vengono illustrate le tecnologie utilizzate per la scrittura di pagine web a contenuto dinamico, con particolare riguardo per le Servlet e JSP, utilizzate nella fase di implementazione. Cap. 5: Altre tecnologie utilizzate In questo capitolo è data una descrizione sommaria del funzionamento di SNMP (Simple Network Management Protocol), protocollo che permette la gestione di reti TCP/IP. SNMP è stato utilizzato per la preparazione di test di laboratorio finalizzati a 15

23 Introduzione Struttura della tesi dimostrare il funzionamento del sistema. In particolare SNMP è stato studiato per fornire un esempio di come implementare le funzioni di selezione di componenti, in precedenza accennate. Parte II Netlab Remote Components Repository Cap. 6: Netlab Remote Components Repository In questo capitolo viene spiegato il sistema NRCR. Dopo aver identificato i requisiti da rispettare, si motivano le scelte tecnologiche e si analizzano i tre obiettivi da raggiungere (già accennati in questo capitolo introduttivo). Successivamente vengono presentate le soluzioni proposte per i tre obiettivi in tre paragrafi distinti. Al termine di tale esposizione è riportato un esempio d interazione con il Sistema NRCR, utile per fissare le idee e per esplicitare il filo conduttore che mette in relazione i tre paragrafi precedenti. Il capitolo si conclude con la presentazione dell ambiente di sviluppo Netlab e la configurazione software utilizzata per verificare il funzionamento del sistema. Cap. 7: Conclusioni e sviluppi futuri In questo capitolo vengono riassunti i risultati raggiunti e gli sviluppi futuri. 16

24 Parte I Le tecnologie utilizzate

25 2 Le architetture software nella programmazione distribuita Per sistema distribuito s intende un insieme d elaboratori autonomi connessi tra loro attraverso una rete informatica ed equipaggiati da un software specializzato, che permette loro la condivisione di risorse a livello hardware, software e dati. Gli utenti di un sistema distribuito ben strutturato dovrebbero avere la sensazione di utilizzare un unico e potente elaboratore e quindi accedere a tali risorse senza sapere dove queste siano effettivamente localizzate. La Figura 2.1 mostra la struttura di un semplice sistema distribuito in cui personal computer e workstation condividono, attraverso una rete locale, le risorse messe a disposizione dal sistema per mezzo di server dedicati [1]. Figura Esempio di semplice sistema distribuito In questo decennio le potenzialità dei sistemi distribuiti hanno catturato l interesse dei maggiori produttori di tecnologie software, 18

26 Le architetture software nella programmazione distribuita grazie anche alla contemporanea consacrazione delle reti d elaboratori come strumento di lavoro per le piccole, medie e grandi aziende. I risultati delle ricerche che sono state effettuate hanno portato all affermazione di architetture software object-oriented distribuite come CORBA (Common Object Request Broker Architecture), proposta dall OMG (Object Management Group) nel 1990, DCOM (Distributed Component Object Model) proposta da Microsoft nel 1996, RMI (Remote Method Invocation) e successivamente RMI/IIOP (RMI/Internet Inter Orb Protocol) entrambe introdotte da Javasoft, rispettivamente nel 1995 e Prima di cominciare l analisi delle varie tecnologie software è opportuno evidenziare alcuni punti chiave che bisogna prendere in considerazione quando si affronta la realizzazione di un applicazione distribuita ad oggetti, cioè un applicazione in cui gli oggetti sono istanziati e risiedono in differenti spazi di indirizzamento, probabilmente su differenti computer. Infine sarà introdotto il concetto di ORB Problema del Tempo di Risposta (Latency) In un ambiente distribuito, le varie componenti software possono risiedere ed essere eseguite un po dovunque nella rete. Un oggetto che risiede altrove, rispetto allo spazio di indirizzamento da cui ne vengono invocate le funzionalità, può essere lento ad evadere le richieste. Questo dipende da vari fattori che sono indipendenti dall oggetto locale che esegue la richiesta. I fattori determinanti sono la velocità della rete che sta tra i due oggetti, la mole di dati da trasferire fra i due, il carico di processi attualmente eseguiti dalla macchina su cui l oggetto remoto invocato è istanziato e, 19

27 Le architetture software nella programmazione distribuita naturalmente le caratteristiche hardware della macchina stessa (Figura 2.2). Figura 2.2 I tempi di risposta di un oggetto remoto non dipendono dall oggetto locale. Quest aspetto non esiste quando i due oggetti sono eseguiti all interno di una stessa applicazione eseguita dal medesimo processo della stessa macchina, ma può presentarsi anche fra due oggetti eseguiti sulla medesima macchina ma in due processi differenti Partial Failure Il temine partial failure indica la situazione in cui un oggetto, utilizzato da un applicazione, smette di funzionare (crash), senza pregiudicare definitivamente l esecuzione di tale applicazione. In un sistema distribuito la gestione degli errori è molto delicata. Se si sta realizzando un applicazione monolitica locale, tutte gli oggetti che possono fallire stanno all interno della stessa applicazione. Questo significa che, nel caso un oggetto fallisca, l applicazione se ne può accorgere immediatamente. Il discorso si complica quando si parla d applicazioni distribuite, dove le varie componenti che possono fallire sono sparse per la rete. In questo caso l utilizzatore della componente remota fallita potrebbe accorgersene dopo un tempo molto lungo, o potrebbe non accorgersene per nulla (Figura 2.3). 20

28 Le architetture software nella programmazione distribuita Figura 2.3 Crash dell oggetto remoto Fortunatamente le tecnologie esposte più avanti nel capitolo, mettono a disposizione dei meccanismi per il riconoscimento del tipo di failure. In questo modo è possibile prevedere la reazione che il programma deve avere nel caso in cui una o più componenti da lui utilizzate falliscano Spazio d indirizzamento Oggetti istanziati in differenti spazi d indirizzamento hanno un indirizzo relativo allo spazio d indirizzamento in cui sono istanziati. In un applicazione distribuita, gli oggetti remoti non possono essere istanziati e puntati normalmente, ma si ha bisogno di un meccanismo per ottenere localmente un riferimento (reference) a tali istanze (Figura 2.4). Figura 2.4 Un riferimento (rappresentato dall asterisco) remoto non si può ottenere allo stesso modo di uno locale. 21

29 Le architetture software nella programmazione distribuita Le tecnologie ad oggetti distribuiti forniscono tutte almeno una maniera per ottenere un riferimento valido localmente ad un oggetto remoto, che diventa in questo modo accessibile e utilizzabile come un oggetto locale ORB Un concetto fondamentale quando si parla di programmazione di oggetti distribuiti è dato dall ORB. ORB in inglese significa globo e nel campo della programmazione distribuita rappresenta il mondo degli oggetti remoti. L acronimo di ORB è Object Request Broker, ovvero un agente di scambio di richieste fra oggetti e rappresenta l ossatura su cui si basa la comunicazione tra gli oggetti stessi. L Object Management Group (OMG), ha definito un architettura comune per tutti gli ORB, permettendo così la nascita della specifica Common Object Request Broker Architecture (CORBA). Di conseguenza, oggi esistono un insieme di ORB che rispettano le specifiche CORBA, come JavaIDL e RMI/IIOP della Javasoft, Visibroker dell Intrise ed Orbix della Iona, e altri ORB che non le rispettano, come RMI della Javasoft, DCOM della Microsoft. Nei prossimi paragrafi verranno illustrate le tecnologie RMI, CORBA, Java IDL e RMI/IIOP [5]. 22

30 Le architetture software nella programmazione distribuita 2.2 RMI La tecnologia Remote Method Invocation (RMI) [2], fu introdotta da Sun nella versione 1.1 del JDK con l obiettivo di facilitare la comunicazione fra applicazioni Java residenti su macchine remote, presupponendo un ambiente omogeneo Java Architettura di RMI La Figura 2.5 mostra la struttura tipica di un applicazione RMI. Figura 2.5 Architettura di RMI Si nota come essa sia organizzata, orizzontalmente, in strati sovrapposti ed in due moduli verticali che individuano il lato client ed il lato server dell applicazione. Lo strato più alto è costituito, su entrambi i lati, dall applicazione che viene eseguita sulla JVM. Nel caso del client, si tratta di un applicazione vera e propria che durante il suo ciclo di vita esegue 23

31 Le architetture software nella programmazione distribuita RMI delle chiamate a dei metodi d oggetti remoti. Per quanto riguarda, invece, l applicazione server, ha un suo ciclo di vita indipendente dal client e, di fatto, ignora la sua presenza. Subito sotto il livello applicazione, si trovano i due componenti fondamentali del meccanismo RMI, lo stub e lo skeleton. Per capire il motivo di questa doppia presenza, è bene fare un passo indietro, considerando il caso non distribuito. In tale circostanza, quando un oggetto desidera invocare un metodo di un altro oggetto, deve prima ricavarne un riferimento, istanziandolo direttamente o ricevendone l indirizzo dall esterno e, successivamente, eseguire un istruzione del tipo: nomeoggetto.nomemetodo(lista parametri) Nel caso distribuito, invece, si deve ricavare il riferimento all oggetto remoto ed invocarne i metodi a distanza. La soluzione proposta da RMI, consiste nello scaricare in locale un rappresentante dell oggetto remoto e di considerarlo come se si trattasse a tutti gli effetti di un elemento locale. E la tecnologia RMI che si occupa, in maniera del tutto trasparente, di inoltrare le richieste di esecuzione dei vari metodi all oggetto remoto residente sul server RMI. In tal modo, il client ha l impressione di utilizzare una risorsa locale, ma in realtà il codice viene eseguito dal processore residente sul server remoto. I due oggetti che implementano questo meccanismo, il rappresentante locale, ed il reale oggetto remoto ad esso collegato, sono appunto lo stub e lo skeleton. Grazie a questo meccanismo il codice necessario ad invocare un oggetto remoto è praticamente identico al caso precedente. Infatti basta scrivere: 24

32 Le architetture software nella programmazione distribuita RMI nomeoggettoremoto.nomemetodo(lista parametri) L equivalenza al caso non distribuito, in riferimento all invocazione dei metodi, vale anche per il passaggio dei parametri. Ad un metodo remoto, infatti, può essere passata una variabile, un istanza di un oggetto od una collezione d oggetti. Non esistono limiti da questo punto di vista, a patto che l oggetto in questione sia serializzabile, ossia possa essere trasformato in un flusso sequenziale d informazioni trasferibili tramite uno stream [7]. Si passi ora ad analizzare gli altri strati presenti nello schema della Figura 2.5. I lati server e client sono collegati con il sottostante Remote Reference Layer (RRL) che a sua volta si appoggia al Transport Layer (TL). Il primo dei due ha il compito di instaurare un collegamento logico fra i due lati, di codificare le richieste del client, inviarle al server, decodificare le richieste ed inoltrarle allo skeleton. Ovviamente nel caso in cui quest ultimo fornisca dei risultati per il particolare tipo di servizio richiesto, il meccanismo di restituzione di tali valori avviene in maniera del tutto analoga, ma in senso opposto. Al livello RRL viene instaurato un collegamento virtuale fra i due lati, client e server, mentre fisicamente la connessione avviene al livello sottostante, definito Transport Layer (TL). Dal momento che tale collegamento è di tipo sequenziale, è necessaria la serializzazione dei parametri da passare ai metodi. La gestione dei riferimenti ai vari oggetti e tutto quello che concerne le operazioni di basso livello avvengono, in parte, tramite l RRL, ma soprattutto tramite il TL, in cui i dati vengono semplicemente visti come sequenze di byte da scrivere o leggere in certe locazioni di 25

33 Le architetture software nella programmazione distribuita RMI memoria. Quando il TL riceve una richiesta di connessione da parte del client, localizza il server RMI relativo all oggetto remoto richiesto. Successivamente viene eseguita una connessione per mezzo di un socket appositamente creato per il servizio. Una volta che la connessione è stabilita, il TL passa la connessione al lato client di RRL ed aggiunge, in una tabella opportuna, un riferimento all oggetto remoto. Solo dopo questa operazione il client risulta effettivamente connesso al server e lo stub è utilizzabile dal client. Il TL è responsabile del controllo dello stato delle varie connessioni. Se un periodo di tempo significativo passa senza che venga effettuato nessun riferimento alla connessione remota, si assume che tale collegamento non sia più necessario e, quindi, viene disattivato. L ultimo livello che, però, non viene incluso nella struttura RMI è quello che riguarda la gestione della connessione attraverso i socket ed i protocolli TCP/IP. In realtà tutte le connessioni utilizzano la pila TCP/IP. Infatti, due Java Virtual Machine (JVM) comunicano attraverso la pila TCP/IP anche se sono in esecuzione sulla stessa macchina (Figura 2.6). 26

34 Le architetture software nella programmazione distribuita RMI Figura 2.6 Transport Layer di RMI Il protocollo utilizzato da RMI a livello trasporto è Java Remote Method Protocol (JRMP). Questo protocollo, specifica, tra l altro, le regole per lo scambio di messaggi fra gli oggetti senza rispettare le specifiche CORBA. Di conseguenza RMI è un architettura chiusa e come tale può essere conveniente quando si prevede di utilizzare solamente componenti remote sviluppate in Java [4] Le applicazioni RMI Le applicazioni RMI sono spesso composte da due programmi distinti: un server e un client. Ad esempio un applicazione server generica potrebbe creare un oggetto remoto, renderlo accessibile e attendere che un client invochi un metodo di tale oggetto. A questo punto un generico client dovrebbe recuperare un riferimento all oggetto remoto e invocarne i metodi messi a disposizione. Le applicazioni java ad oggetti distribuiti hanno bisogno di: 27

35 Le architetture software nella programmazione distribuita RMI Localizzare gli oggetti remoti. Le applicazioni possono usare due meccanismi per ottenere un riferimento a un oggetto remoto: 1. attraverso il sistema di naming messo a disposizione dall architettura RMI, ovvero rmiregistry; 2. attraverso una normale operazione come un passaggio di un oggetto remoto come parametro o un oggetto remoto restituito come risultato; Comunicare con gli oggetti remoti. I dettagli che regolano la comunicazione con gli oggetti remoti sono completamente gestiti dall architettura RMI e trasparenti al programmatore che utilizza l oggetto remoto come se fosse un oggetto locale; Caricamento dei bytecode di quelle classi che sono passate come parametro o che sono restituite come risultato. RMI fornisce degli automatismi che provvedono a caricare le classi non disponibili sulla Java Virtual Machine locale; Una delle maggiori caratteristiche di RMI è, quindi, la possibilità di scaricare automaticamente il bytecode delle classi che non sono disponibili sulla virtual machine del ricevente. Un'altra importante particolarità di RMI è data dalla possibilità di passare oggetti e ritornare valori durante una chiamata a metodo, oltre che a tipi di dati predefiniti. Questo significa che dati strutturati e complessi possono essere passati come un singolo argomento, senza dover decomporre l oggetto in tipi di dati primitivi. In altre parole 28

36 Le architetture software nella programmazione distribuita RMI RMI permette di trasportare oggetti attraverso le infrastrutture di un architettura enterprise senza necessitare di codice aggiuntivo. Infine, va rilevato l impegno profuso dagli ideatori di RMI nella realizzazione di un accurato insieme d eccezioni java che possono essere lanciate dagli oggetti remoti, catturate e interpretate dai client. Con tali eccezioni si risolvono brillantemente problematiche come latency e partial failure Rmiregistry L rmiregistry è un demone in esecuzione su una determinata macchina e, generalmente, in ascolto su una well-known port (1099), che offre un servizio di naming/directory (cfr. Capitolo 3). In poche parole rmiregistry permette di ottenere il riferimento ad un oggetto remoto a partire dal nome con cui lo stesso oggetto si è precedentemente registrato. L rmiregistry è gestibile attraverso una classe statica, Naming, che fornisce un metodi per la registrazione, bind(), la cancellazione, unbind(), e la ricerca, lookup() di componenti remote. In particolare, il metodo lookup() permette ai client di ottenere il riferimento a un oggetto remoto specificando, come parametro, una URL con la seguente forma: rmi://<host_name>[:<port>]/<service_name> Multithreading RMI non implementa esplicitamente politiche di multithreading per la gestione concorrente di connessioni client. Si ha la garanzia che 29

37 Le architetture software nella programmazione distribuita RMI quando un oggetto client acceder ad un oggetto server, le richieste vengono eseguite su un thread differente, solo se l oggetto client è eseguito su una macchina diversa da quella di un oggetto client precedentemente accettato. Ciò comporta che, se più client richiedono servizi ad un oggetto server, viene garantita per ciascuno di essi l esecuzione dei metodi invocati su un thread separato, solo se le richieste provengono da host differenti. E sottinteso che, se uno o più oggetti sullo stesso host, inviano più richieste concorrenti allo stesso oggetto server, l evasione delle richieste risulta sequenziale per l utilizzo di un unico thread. Per questo motivo lo schema di progettazione di tipo Factory o Dispenser possono risultare necessari quando si realizzano server RMI (per approfondimenti sui pattern Factory e Dispenser, si consulti l Appendice 8.1) RMI e i firewall Il Transport Layer (TL) di RMI di solito utilizza connessioni via socket con l host che fornisce servizi remoti. Purtroppo può accadere che tra un client e un server RMI sia posizionato un firewall, che non permette questo tipo di connessione. Il TL fornisce, al riguardo, due soluzioni alternative basate sul protocollo HTTP. Per permettere il passaggio attraverso un firewall, il TL impacchetta la richiesta utilizzando il protocollo HTTP, abilitato per il passaggio attraverso un firewall. La richiesta assume l aspetto di un POST HTTP, mentre la risposta del server viene impacchettata in una RESPONSE HTTP. I due metodi alternativi per inviare la richiesta tramite POST sono i seguenti: 30

38 Le architetture software nella programmazione distribuita RMI 1. Se il proxy del firewall indirizza la richiesta http direttamente ad una porta della macchina host ricevente, essa è reindirizzata alla porta alla porta su cui il server RMI è in ascolto. Il TL sulla macchina ricevente deve pertanto essere, e lo è, in ascolto tramite un socket che sia in grado di decodificare il POST verso una chiamata RMI standard; 2. Se il proxy del firewall indirizza la richiesta solo verso porte HTTP, allora la richiesta viene reindirizzata all httpd in ascolto, e deve essere innescata una CGI (Common Gateway Interface) che reindirizzi internamente la richiesta sulla porta su cui è in ascolto il server RMI. A questo punto il TL sulla macchina ricevente è in ascolto tramite un socket che sia in grado di decodificare il POST verso una chiamata RMI standard, come nel caso precedente. Quindi, i client RMI tentano automaticamente delle connessioni HTTP verso i server quando non è possibile una connessione diretta via socket. I server RMI automaticamente identificano la richiesta come una POST HTTP e formattano la risposta in una RESPONSE HTTP Attivazione di oggetti remoti Con la versione 1.2 del JDK è stata introdotta un estensione molto interessante di RMI. Quest estensione permette di tenere dormienti degli oggetti remoti fino a quando non ne venga fatta una richiesta esplicita da parte di un client. 31

39 Le architetture software nella programmazione distribuita RMI Nel caso di una normale registrazione di un oggetto remoto presso un rmiregistry, la macchina virtuale relativa all oggetto rimane attiva, perché ha innescato dei thread di comunicazione con l rmiregistry, il quale, a sua volta, ha una macchina virtuale separata. Con un approccio di questo genere, si verifica uno spreco di risorse ogniqualvolta si registri un oggetto utilizzato sporadicamente. Tale spreco può diventare inammissibile in situazioni in cui il numero d oggetti remoti è molto grande. Con la nuova versione di RMI, questo problema è risolvibile, potendo definire come dormienti certi servizi, che verranno istanziati e attivati solo a richiesta da parte di un client. Questa nuova funzionalità viene chiamata attivazione, e funziona come visualizzato nella Figura 2.7. Figura Attivazione di oggetti remoti Un client invia tramite l ORB di RMI una richiesta per un riferimento ad un oggetto remoto. La richiesta viene ricevuta sull rmiregistry e smistata al demone di attivazione rmid. L rmid possiede una descrizione dell oggetto da attivare: identificativo, gruppo di appartenenza e classe di implementazione (bytecode). L rmid 32

40 Le architetture software nella programmazione distribuita RMI controlla che non ci sia già una JVM in esecuzione per il gruppo di appartenenza dell oggetto richiesto, e in caso negativo ne esegue una. Ad essa passa un istanza dell oggetto ottenuta dal bytecode. Il riferimento a quest istanza è poi passato al client tramite l ORB. 33

41 Le architetture software nella programmazione distribuita 2.3 CORBA La presentazione di CORBA [9] che verrà fatta in questo paragrafo ha una duplice finalità. Da una parte, i concetti illustrati rendono semplice la comprensione di JavaIDL e RMI/IIOP, gli argomenti trattati nei paragrafi successivi. Dall altra, la simmetria che questo paragrafo ha rispetto al precedente, fornisce un implicito confronto tra alcuni aspetti e problematiche comuni di CORBA e RMI Architettura di CORBA Nell autunno del 1990 uscì dall OMG la guida all Object Management Architecture (OMA) che, attraverso varie vicissitudini, arrivò a gennaio del 1995 ad assumere la forma delle specifiche attuali Common Object Request Broker Architecture (CORBA). L architettura CORBA ha quattro elementi principali costituenti: L ORB, Object Request Broker, è il motore vero e proprio, che permette la comunicazione fra gli oggetti remoti; I CORBAServices sono servizi atti a completare ed aumentare le funzionalità di base di un ORB. Fanno parte di essi: o Life Cycle Service, per creare, copiare, rilocare e cancellare oggetti agganciati all ORB; o Persistence Service, per rendere persistenti gli oggetti agganciati all ORB su banche dati ad oggetti, relazionali, o semplici file; 34

42 Le architetture software nella programmazione distribuita CORBA o Naming Service, per localizzare gli oggetti agganciati all ORB; o Event Service, per far viaggiare gli eventi sull ORB; o Concurrency Control Service, per gestire i problemi di concorrenza per l accesso agli oggetti dell ORB; o Transaction Service, per gestire azioni di commit/rollback su oggetti dell ORB che prevedano una possibilità di recupero; o Relationship Service, per gestire relazioni fra gli oggetti dell ORB, associazioni dinamiche e di contenimento; o Externalization Service, per far viaggiare i dati con meccanismi di streaming; o Query Service, per operazioni di query sugli oggetti dell ORB, basatosulle specifiche dell ODMG (Object Database Management Group) per un sovrainsieme dell SQL chiamato OQL, Object Query Language; o Licensing Service, per misurare l utilizzo degli oggetti dell ORB e permettere una politica di si paga per quel che si usa o Properties Service, per associare dinamicamente delle proprietà allo stato di un oggetto dell ORB; 35

43 Le architetture software nella programmazione distribuita CORBA o Time Service, per la sincronizzazione di eventi che viaggiano sull ORB e che sono legati a tempi predefiniti; o Security Service, per la sicurezza degli oggetti dell ORB. Autenticazione e così via; o Trader Service, le pagine gialle dell ORB. Gli oggetti si registrano sulle pagine gialle specificando il tipo di servizio messo a disposizione, e le pagine gialle mettono a disposizione un meccanismo di ricerca a tutti gli oggetti che ne siano interessati; o Collection Service, per manipolare i tipi di collezione più comuni; o Startup Service, per operazioni predefinite d inizializzazione di un ORB; Le CORBAFacilities sono in continua evoluzione e mirano a formare due tipi di servizi, orizzontali e verticali. Gli orizzontali sono utili a tutti gli oggetti dell ORB, come, per esempio, servizi per la costruzione delle interfacce utente, per lo scambio documentale, agenti mobili; quelli verticali, invece, sono dedicati ad una tipologia ben precisa di applicazioni, per esempio finanziarie, telecomunicazioni, governative; I business objects, ovvero gli oggetti applicativi da agganciare all ORB, sono quelli che sviluppati dai programmatori; 36

44 Le architetture software nella programmazione distribuita CORBA Per finire, la versione delle specifiche CORBA 2.0, definisce anche come si devono parlare oggetti agganciati ad un ORB di implementatori differenti; in realtà definisce come questi ORB devono parlare tra di loro. Quest ultimo è il passo che permette una federazione d oggetti interoperanti, le implementazioni dei quali possono essere scritte in qualunque linguaggio supportato. Per esempio un ORB che permette l aggancio d oggetti implementati in C++ può parlare con un ORB che aggancia oggetti COBOL o Java. Il protocollo che permette questo scambio d informazioni è IIOP, Internet Inter Orb Protocol, su cui il GIOP, General Inter Orb Protocol, si basa per il trasporto su reti TCP/IP [8] IDL Come già accennato, CORBA permette l interazione tra oggetti scritti con differenti linguaggi di programmazione. Per rendere possibile ciò l OMG ha dovuto introdurre un livello d astrazione che permettesse di descrivere le funzionalità di un oggetto sull ORB senza scendere nei dettagli implementativi. L OMG ha così progettato la specifica per un linguaggio che permettesse di descrivere l aspetto esteriore di un oggetto sull ORB; questo linguaggio si chiama IDL, Internet Definition Language. Naturalmente, per poter descrivere e portare a massimo comune denominatore tutto quello che i vari linguaggi permettono si è dovuti scendere a compromessi e pertanto, un oggetto descritto con IDL potrebbe risultare più limitato di uno scritto, ad esempio, utilizzando RMI. [10] 37

45 Le architetture software nella programmazione distribuita CORBA E importante chiarire che per poter definire un interfaccia per l ORB di un oggetto scritto con un linguaggio ben preciso, è necessario che esista l esatta corrispondenza fra IDL e quel linguaggio. Linguaggi di cui esiste la specifica ufficiale di corrispondenza sono, ad esempio, il C, il C++, Java. Per Java si è giunti ad una specifica definitiva solo verso la metà del L architettura di un ORB CORBA Si prenda ora in esame com è fatto e funziona un ORB CORBA, e come gli oggetti possano parlarsi tra di loro tramite esso. Se si confronta la Figura 2.8 con Figura 2.5 si noterà un evidente somiglianza: in fondo anche RMI ha il suo ORB, solo più limitato. 38