Dispense6
annuncio pubblicitario
M. Barbaro, G. Rorato Client/Server 6 WEB Il grande successo del progetto World Wibe Web, ideato da Tim BernersLee al CERN di Ginevra nel 1989, si basa fondamentalmente sulla possibilità di collegare tra loro una grande quantità di ipertesti, termine usato per primo da Ted Nelson nel 1965, che voleva realizzare una raccolta globale di testi e di ciò parlava nel suo progetto Xanadu di cui si possono trovare informazioni più dettagliate all'indirizzo http://xanadu.net/the.project. Ciò che si voleva garantire era comunque un modo per poter avere una consultazione testi non più sequenziale ma a grafo, di testi situati su macchine anche molto distanti tra loro attraverso l’utilizzo delle reti telefoniche. Dall’ipertesto al WEB Internet è una rete eterogenea di calcolatori dislocati in tutte le parti del mondo che si basa sul protocollo di trasmissione TCP/IP; a livello più alto rispetto a questo protocollo risiede il protocollo HTTP che consente lo scambio di ipertesti. Comunque il modello di iterazione tipico della rete è quello classico client-server dove un server HTTP è un programma che gira su di una macchina in attesa di richieste dai clienti HTTP detti anche browser. Sollecitato dal browser, il server risponde inviando un documento redatto in HTML, che è il linguaggio usato per scrivere i documenti che appaiono sul Web. Un tipico esempio di applicazione Web può essere formato da una pagina HTML statica, memorizzata cioè su di un file, che permette al suo interno ad un’utente di richiamare ad esempio 109 M. Barbaro, G. Rorato Client/Server un programma CGI; quest’ultimo, una volta attivato, genera dinamicamente una pagina che contiene tutte le informazioni richieste dall’utente. Tutti questi concetti appena introdotti verranno comunque spiegati successivamente nei prossimi paragrafi del capitolo. L'HTML Verrà ora analizzato brevemente il linguaggio HTML; sebbene semplice, questo linguaggio sottoinsieme di SGML (che è un linguaggio utilizzato per indicare la semantica di un testo) è un cosiddetto Markup Language, ovvero un linguaggio di istruzioni composto di elementi che definiscono le caratteristiche di un documento e ne guidano la scomposizione sullo schermo. Sua peculiarità è di descrivere i contenuti invece delle apparenze: non rigide misure di formattazione, ma semplici etichette o tag che identificano la funzione degli elementi che compongono il testo, in contrasto invece con lo stile WYSIWYG, cioè “What you see is what you get”. Esempio di documento HTML <HTML> <HEAD> <TITLE>Titolo</TITLE> </HEAD> <BODY> Applicazioni client/server </BODY> </HTML> Sarà il browser, e quindi in una certa misura l’utente, a decidere esplicitamente come le singole parti del documento si presenteranno sulla pagina. Da notare che non tutti i browser esistenti (Netscape, Internet Explorer, ecc.) leggono un testo allo stesso modo, quindi di certe formattazioni vanno considerati anche gli effetti su browser come, per esempio, Lynx che non è in grado di visualizzare le immagini ma solo testi. URL Un URL (Uniform Resource Locator) è un qualsiasi tipo di indirizzo, o “arco”/anchor secondo la rappresentazione Web=(N,E) dove N sono i nodi e E appunto gli archi, Internet, sia esso un recapito di posta elettronica o il riferimento necessario per raggiungere una pagina Web, un sito gopher o FTP o un’area Usenet. Un URL si compone di diverse parti, divise tra loro da un separatore (/), ognuna delle quali è portatrice di una parte delle informazioni necessarie all’utente. Ecco uno schema: protocollo:[//]host[:porta][path] La prima parte di un URL sarà quindi del tipo: - http (può comunque simulare gli altri protocolli). 110 M. Barbaro, G. Rorato - Client/Server ftp, un protocollo per il trasferimento di file. telnet, un protocollo per permettere a un utente il collegamento remoto a un computer. gopher, news (protocolli che non verranno analizzati in queste dispense). La seconda parte di un URL indica il nome del server a cui ci si collega, mentre la quarta indica invece la collocazione all’interno del server della pagina a cui si vuole accedere. In “mezzo” sta il numero di porta su cui è aperta la connessione del server che, per esempio per http, è in attesa di default sulla porta 80. In questo modo quindi un client instaura una connessione di tipo socket sulla porta 80 o su quella indicata nell’URL indicando (lo fa automaticamente il browser) nella richiesta al server un metodo, (ad es. GET) indirizzo e protocollo. Se la connessione invece è di tipo telnet questi parametri vanno esplicitamente indicati dall’utente. HTTP L’HyperText Transfer Protocol (HTTP) è un protocollo che si “appoggia” al protocollo di trasmissione TCP/IP ed è usato dai client (browser) nel Web per comunicare con i server WWW. L’hypertext transfer protocol HTTP è un protocollo abbastanza semplice che permette la trasmissione di dati in formato ASCII a 7 bit. Un client instaura una connessione su un socket verso un server HTTP che attende di default sulla porta 80 o comunque su di una porta indicabile nell'URL. A questo punto il client fa una richiesta indicando metodo, indirizzo e protocollo. Un tipico esempio di richiesta è il seguente: GET address HTTP /1.0 Nella linea precedente si è introdotto uno dei metodi usati maggiormente per introdurre delle richieste, cioè GET; in alternativa si sarebbe potuto utilizzare, ad esempio, il metodo POST che prevede anche alcuni header opzionali di richiesta, una linea vuota e in alcuni casi dopo quest'ultima sono compresi dei dati per il programma server. A questo punto il server HTTP spedisce una risposta contenente una linea di stato cioè un codice numerico indicante o meno un successo, alcuni header di risposta, una linea vuota, il documento richiesto e poi chiude la connessione. Da notare che queste richieste sono effettuate automaticamente da un browser, mentre se si instaura una connessione di tipo telnet si deve indicare esplicitamente la riga di richiesta, gli header, ecc. La richiesta 111 M. Barbaro, G. Rorato Client/Server Rivedendo quanto detto nel paragrafo precedente verranno successivamente introdotti alcuni dei metodi possibili per fare una richiesta e alcuni header opzionali usati per indicare ulteriori informazioni che è possibile fornire al server. I metodi Ecco i metodi principali con cui si può formulare una richiesta: GET è il più usato dai browser per richiedere normalmente un documento; dei dati da fornire ad un programma CGI possono essere indicati dopo un carattere di questo tipo: "?". HEAD è identico a GET ma il server si limita a ritornare solo gli header di risposta. POST permette invece di indicare dei dati per un programma CGI su di una linea apposita dopo la linea vuota. Il programma CGI può usare l'header Content-Length per determinare quanti dati deve leggere. PUT, poco supportato finora, permette ad un client di chiedere ad un server di memorizzare un documento. Gli header di richiesta Ecco una descrizione di alcuni tipi di header che un client può indicare nella richiesta come intestazione: Accept specifica il tipo di formati MIME, riguardanti per esempio lo standard delle immagini, dei file audio, ecc., che il client desidera supportare. Più opzioni possono essere indicate semplicemente separandole con un “;” Connection:Keep-Alive; il protocollo HTTP 1.0 è stateless, cioè senza stato poiché crea una nuova connessione per ogni documento che viene richiesto dallo stesso client senza tenere traccia di un eventuale connessione precedente. Con questo header si vuole ovviare a questa mancanza permettendo di mantenere attiva la connessione. Content-Length è di solito aggiunto alle risposte di un server ma deve essere supportato nelle richieste di tipo POST. Cookie:namel=valuel;...;nameN=valueN; i cookie permettono di memorizzare delle informazioni utili al server per riconoscere il tipo di client nel client stesso. User-Agent specifica il tipo di browser dell'utente. I venditori possono scegliere il formato per riempire questo header; in particolare il più comune è Mozilla che viene usato per indicare Internet Explorer e Netscape. Il formato è comunque spesso simile a: Esempio: Accept: */* indica che il client accetterà di tutto. Vendor/version (platform; encryption; os) 112 M. Barbaro, G. Rorato Client/Server La risposta Dopo aver ricevuto una richiesta valida il server restituisce una linea di stato indicante un codice numerico. In particolare si ha che: un valore compreso tra 200 e 299 indica successo. un valore compreso tra 300 e 399 indica che il file richiesto è stato spostato. un valore compreso tra 400 e 499 indica un errore del client. un valore compreso tra 500 e 599 indica un errore del server.. Esistono solo alcuni codici predefiniti ma se il browser riconosce un codice sconosciuto può usare i range indicati per decidere quali azioni intraprendere. Dopo la linea di stato possono essere inclusi, analogamente a quanto visto nella richiesta, degli header perlopiù opzionali; in particolare l'header Content-Type, che indica il tipo MIME e il sottotipo dell'entità che il server sta inviando, dovrebbe essere sempre indicato in modo che il browser sappia sempre che cosa fare con il documento che gli viene recapitato. Cookie: memorizzare dati persistenti su di un client Netscape, Internet Explorer e altri browser forniscono un meccanismo che permette di memorizzare semplici informazioni sulla macchina del client. A seconda di quali parametri sono memorizzati il browser può includere questi dati in future richieste allo stesso server e che comunque non verranno spediti ad altri domini. I Cookie permettono ad un sito di memorizzare alcune preferenze di un utente, di supportare uno user-id e/o una password tali che l’utente non li debba riscrivere in successive sessioni, di tenere traccia di acquisti, di tenere traccia delle attività di un utente finché visita un certo sito, ecc. La sintassi di un cookie Il server chiede ad un client di memorizzare un cookie tramite l’header Set-Cookie; si possono avere fino a 20 cookie per sito specificando più righe per ognuno di questi. Un browser può rispedire ad un server un cookie creato in precedenza tramite l’header Cookie e inoltre più cookie possono essere specificati separandoli con “;” lungo una singola linea Cookie. Esempio: Set-Cookie: cookieName=cookieValue /*Sintassi*/ /* Nelle prossime due righe ricerca che possa permettere termine ricercato dovrebbero conciso o esteso, tramite cui si suppone di avere a che fare con un motore di agli utenti di decidere quante occorrenze di un essere riportate e di poter decidere il formato, visualizzare queste occorrenze */ 113 M. Barbaro, G. Rorato Client/Server Set-Cookie: hits-per-page=10 Set-Cookie: format=verbose /* Per il resto seguente: */ della sessione un browser spedirebbe una linea del tipo Cookie: hits-per-page=10; format=verbose Opzioni di un cookie expires è un attributo che specifica per quanto tempo un cookie può essere considerato valido. Se non è supportato il cookie sarà valido solo durante la sessione corrente. Un cookie può essere cancellato indicando una data "vecchia". Esempio: Set-Cookie: hits-per-page=10; expires=Friday, 01-Jan-1999 00:00:00 GMT path indica una serie di URL che dovrebbero ricevere il cookie dal browser. “/” indica il path più generale. domain indica la possibilità a più siti di condividere gli stessi cookie. Se viene appunto specificato tutti i siti nel dominio specificato riceveranno il cookie. Esempio: Set-Cookie: hits-per-page=10; expires=Friday, 01-Jan-1999 00:00:00 GMT path=/ domain=.search-service.com Problemi di sicurezza Molti utenti sono preoccupati per i rischi sulla sicurezza e la privatezza associati con i cookie. C’è comunque da dire che un dato cookie non è mai eseguito in alcun modo dalla macchina del client e così non potrà mai creare virus o programmi distruttivi. Oltretutto a causa della massima dimensione di un cookie (4K) e al fatto che ogni sito ha un limite di 20 cookie, questi non possono neppure essere usati per riempire l’hard disk di un utente. Il problema semmai è per i siti che memorizzano password o altre informazioni di sicurezza introducendo il rischio che questi file possano essere compromessi, specialmente perché molti utenti non sanno che un file cookie dovrebbe essere protetto. Inoltre molti sono perplessi a causa del fatto che un sito che usa cookie può tenere traccia delle pagine che un utente visita, degli argomenti più usati nei motori di ricerca, ecc. accumulando un profilo dell’utente. Per finire un sito non impedisce a siti cooperanti di condividere cookie tra i vari domini. La chiave per risolvere questi problemi risiede nella crittografia. 114 M. Barbaro, G. Rorato Client/Server CGI Il Common Gateway Interface è un metodo che permette alle pagine Web di interagire con Database o programmi che risiedono su di un server HTTP. In particolare esso è usato per tre ragioni principali: 1. 2. 3. Non è sempre desiderabile o opportuno fare girare dei processi (magari pensati per macchine più potenti come le workstation) sulle macchine dei client. Anche se oggi è difficile da pensare, non tutti sono in grado di utilizzare un browser Java. Molti servizi Web esistenti sono da tempo organizzati con interfacce CGI ed è utile sapere come è possibile comunicare con queste pagine Web. In questo paragrafo verranno illustrate le caratteristiche principali di questa tecnica senza comunque addentrarci nelle peculiarità della programmazione CGI. Common Gateway Interface Si può attivare un programma CGI indicando in una richiesta HTTP come GET o POST, un apposito URL, cioè un indirizzo che indica il path (cammino), attraverso varie directory, riservato dal server HTTP all'interno del suo dominio per i propri programmi CGI; di solito queste directory speciali sono del tipo “cgi-bin”, “cgi” o “bin” e al loro interno risiedono appunto i programmi CGI. Se ad un server viene indicato di attivare un programma CGI esso non restituirà come di consueto un documento ma manderà in esecuzione il programma, passandogli i parametri forniti dal client, per poi restituire al client l'output del programma stesso . È inoltre possibile fornire dei dati ad un programma CGI sia “appendendoli” alla fine dell’URL, usando il metodo GET di HTTP, che scrivendoli su di una linea separata usando invece POST di HTTP. Come usare le FORM HTML Uno dei modi per permettere l'interazione e lo scambio dei dati tra client e server è utilizzare le cosiddette FORM o maschere di HTML; infatti tramite questo tag di HTML è possibile definire dei campi all’interno dei quali un utente può accedere e definire alcuni tipi di dati. Questi dati sono spediti ad un programma CGI quando l’utente inizia certe azioni, come “cliccare” su di un bottone di tipo “submit” o su di una immagine di tipo “mappa”. Una volta spedito il dato il programma CGI genera una nuova pagina HTML aggiungendo i risultati e restituendoli al client in modo che questi li possa visualizzare. In alternativa è sempre possibile usare le applet Java per ottenere dell’input da spedire ai programmi CGI. Usando il tag FORM di HTML è possibile specificare l’URL del programma CGI, è possibile denominare ogni elemento di input (con il tag NAME) e, ad alcuni elementi, è possibile aggiungere 115 M. Barbaro, G. Rorato Client/Server un valore iniziale (grazie al tag VALUE) sia assegnando un valore di default che lasciando all’autore della pagina il compito di definire tale valore. Inoltre all’utente è permesso aggiungere dei valori in alcuni specifici textfield, ovvero degli spazi riservati proprio per garantire una certa interattività. Quando un utente clicca su di un bottone di tipo “submit” o su di una immagine-mappa gli elementi attivi sono accumulati in una stringa di tipo “name1=val&name2=val2&...&nameN=valN” che è poi trasmessa all’URL specificato facendo partire un comando che è di tipo GET o di tipo POST. I dati possono essere trasmessi dal client tramite le variabili di sistema o QUERY_STRING sia appendendoli all’URL dopo un carattere del tipo “?” che spedendoli in una linea separata. Il primo metodo permette ad un progettista CGI di fare un facile debug mentre allo stesso tempo però è possibile spedire solo pochi dati con il rischio che oltretutto questi siano visibili all'esterno. Per Esempio, con GET da Telnet è possibile digitare: GET .../bin/search?p=valore&q=value il CGI potrebbe restituire html search (char *p, char *q) Esempio con POST: POST /cgi-bin/search2 [ [ [p=valore&q=value...] L'ultima riga del listato rappresenta i dati da passare in input al programma CGI e che tutti i programmi CGI devono poter leggere (ad esempio PERL, JAVA stesso, ovvero linguaggi di tipo VhLL anche detti ad altissimo livello), di search2. Da notare infine che la QUERY_STRING non può essere gestita da comandi Java per questioni di portabilità in quanto un applet non deve dipendere da variabili di sistema; per ovviare a questo problema si può abbandonare il metodo GET in favore del metodo POST oppure si può incapsulare la QUERY_STRING tramite uno script come nel seguente esempio: #!/bin/sh java applicazione 'QUERY_STRING' Il tag FORM di HTML Le form HTML permettono di creare un insieme di dati da passare in input associati con un particolare URL; ad ognuno di questi elementi è possibile assegnare un nome ed un valore. Ecco come appare il tag FORM in una pagina HTML: <FORM ACTION=”URL” ...> ... </FORM> Attributi: ACTION, METHOD, ENCTYPE, TARGET (non standard), NAME (non standard), ONSUBMIT (non standard), ONRESET (non standard) 116 M. Barbaro, G. Rorato Client/Server Segue un esempio di modulo form tramite cui assegnare dei valori (in questo caso un nome e un cognome) e poi passarli ad un programma CGI definito all'interno della directory /cgi-bon/ dopo la pressione del campo submit: Pagina HTML del server: form(maschera, modulo) <FORM ACTION=”/cgi-bin/...” METHOD=GET...> nome <INPUT TYPE=”TEXT” NAME=”nome” VALUE=” “> cognome <.....> <INPUT TYPE=”SUBMIT” NAME=”Submit”> </FORM> Se invece si volesse realizzare lo stesso passaggio di parametri tramite i metodi GET e POST di HTTP, ecco come si potrebbe fare: GET url/action? cognome= & nome= oppure POST [ content-length:n [ cognome= &nome= dove “n” indica il numero di caratteri che seguono la linea bianca. Ecco ora riassunte le funzionalità di due dei vari attributi: ACTION specifica l’URL del programma CGI che processerà i dati della FORM. METHOD specifica il modo in cui dati verranno trasmessi al server HTTP; sono stati già analizzati i vantaggi e gli svantaggi di GET mentre di POST si può dire che non vi è un limite al numero di dati che possono essere spediti. Approcci alternativi al CGI Un tradizionale processo CGI è relativamente costoso da usare in termini computazionali perché richiede un bel po' di overhead far partire un nuovo programma per ogni richiesta. Sono così stati pensati un gran numero di approcci simili al CGI per evitare questo problema; questi approcci prevedono di poter utilizzare dal lato del server Java o JavaScript, delle API per poter dialogare con le librerie condivise, DLL, o Database che girino contemporaneamente al server HTTP. Ecco quindi una descrizione di due tipi di soluzioni adottate in alternativa a CGI: ISAPI (Information Server API) sviluppate da Microsoft permettono alle DLL, dei programmi in-process, di usare tutte le variabili utilizzate dal server stesso. Sono ormai supportate da molti server Windows 95 e Windows NT e permettono di indicare al server che cosa fare in caso che esso riceva determinate richieste. L'Internet Information Server supporta anche le Active Server Pages (ASP) che invece permettono al server di generare delle pagine HTML dinamiche che estendono e ricreano la pagina originale; 117 M. Barbaro, G. Rorato Client/Server tutto ciò è possibile perché esse contengono al loro interno degli oggetti che possono intervenire sulle pagine tramite degli script. Quest'ultima, comunque, è un’architettura Microsoft non portabile. NSAPI di Netscape sono delle API che permettono a delle libreria condivise (Unix) o a delle DLL di essere integrate nel server. L’object web: CORBA incontra Java Per molti aspetti il corrente paradigma HTTP/CGI, si sta ormai incrinando e le varie estensioni al CGI come cookie, ISAPI, NSAPI e ASP sono visti solo come dei “cerotti” per coprire il problema. Sorge così il bisogno per la rete (il Web) di fare un passo avanti verso l’uso di oggetti distribuiti; questo progetto prende il nome di Object Web. Per risolvere il problema si sta assistendo ad una sorta di “matrimonio” tra CORBA e Java, fatto a cui stanno aderendo tutti i venditori tranne la Microsoft che continua la sua strada con ActiveX/DCOM ed il “suo” Object Web. In questo capitolo tratteremo in breve questo sodalizio, illustrando quali vantaggi esso può portare e cercando di capire i perché dei suoi vantaggi a discapito di CGI. Il nuovo sodalizio Nel giugno del 1997 sorge l’idea, grazie all’Enterprise Server 3.0, della cosiddetta rete oggetto o Object Web, cioè di unire JavaSoft a CORBA e di fornire questi cambiamenti all’interno del nuovo pacchetto JDK V1.2. Questa unione sorge perché questi due linguaggi sembrano complementarsi in un modo molto naturale, tanto che si può dire che Java inizia dove CORBA finisce: CORBA tratta la trasparenza nella rete mentre Java si preoccupa della trasparenza nelle implementazioni. CORBA interviene per estendere le capacità delle applicazioni Java attraverso le reti, diversi linguaggi, diverse componenti, ecc. CORBA aggiunge un insieme di servizi distribuiti come ricerche dinamiche e distribuite, autenticazione, sicurezza, ecc. CORBA, grazie alla sua rappresentazione degli oggetti, non fa trapelare nulla sulla loro relativa implementazione. D’altro canto Java è un linguaggio con codice portabile che fornisce un modo nuovo, più semplice per sviluppare, gestire e distribuire applicazioni client/server. Infatti è possibile distribuire in modo immediato un’applicazione a milioni di client semplicemente ponendola su di un server Web; 118 M. Barbaro, G. Rorato Client/Server inoltre Java è utile anche per i server in quanto permette di spostare dinamicamente i servizi a seconda di dove sono più richiesti. In questo modo Java diventa il linguaggio ideale per scrivere gli oggetti CORBA di un programma server e di un client (ad esempio ora un applet può invocare altre applicazioni presenti nel server) tutto grazie anche al suo multithreading, la sua garbage collection e la gestione degli errori che permettono di scrivere oggetti distribuiti più “robusti”. Alla fine di queste considerazioni possiamo dire che CORBA aggiunge l’anello mancante tra il sistema di applicazioni portabili di Java e il sistema di oggetti nella rete. Uno degli unici svantaggi di questo connubio, almeno a prima vista, è che per far girare questo sistema occorrono due virtual machine, come si può vedere nello schema della figura seguente (Figura 46): Figura 46 Il sistema che occorre per utilizzare Java e CORBA assieme. Conflitti e loro risoluzioni A dire il vero in questo “matrimonio” ci sono state delle incomprensioni dovute al fatto che Java e CORBA in certi aspetti si sono accavallate e intromesse una nel lavoro dell’altra come per esempio quando Java ha definito il suo RMI per comunicazioni da Java a Java attraverso virtual machine. Alla fine comunque, risolti i conflitti, Java ha adottato CORBA come il suo modello per oggetti distribuiti e farà girare le API RMI sull’ IIOP di CORBA. Più precisamente ma senza andare nel particolare, JavaSoft intende includere CORBA nel core di Java ad esempio ponendo un particolare ORB CORBA/IIOP nel core di JDK 1.2 e implementando l’RMI di Java sull'IIOP di CORBA. Come diventa un'interazione client-server con l'object web Ecco i passi principali che percorre un tipico client Web per interagire con il suo server tramite l'Object Web: 119 M. Barbaro, G. Rorato 1. 2. 3. 4. 5. Client/Server Il browser Web scarica la pagina HTML. Il browser Web rintraccia l’applet Java dal server HTTP. Il browser Web carica l’applet. L’applet invoca gli oggetti CORBA del server; poiché per questa operazione occorre un firewall, è possibile, ad esempio, utilizzare il Borland Gatekeeper Visigenic che è basato sulla tecnologia MIDAS. La prossima pagina viene generata dinamicamente. Il tutto può essere riassunto tramite l'immagine presente nello schema seguente (Figura 47): Figura 47 I vari passi che rappresentano l'interazione tra un client e un server all'interno dell'oggetto rete.. Gli svantaggi delle altre soluzioni I motivi dell'introduzione della rete oggetto risiedono nel fatto che HTTP con CGI è un protocollo lento, senza stato e inadatto a scrivere applicazioni client/server moderne; con CGI, ad esempio, bisogna far partire una nuova istanza di un programma ogni qualvolta un applet invoca un metodo, cosa che con CORBA non accadrebbe. Finora, per risolvere questi problemi, ogni venditore (o quasi) ha adottato la propria soluzione introducendo così nella rete un’altra ondata di estensioni non standard ed in certi casi proprie di solo alcune piattaforme. Esempi di queste soluzioni sono quelle già viste nel paragrafo precedente come le NSAPI di Netscape, le ISAPI di Microsoft, i Web Object di NeXT/Apple, i Servlets di Java, WinCGI e FastCGI. Per evitare inoltre la mancanza di stato di HTTP alcuni di questi venditori hanno introdotti i cooki, già analizzati nel paragrafo precedente, in altri casi, come le ASPs della Microsoft, si estendono questi cookie con oggetti di sessione (invocati a turno da script) sui server che servono a rappresentare i loro client. Il vero problema, non risolto con questi approcci alternativi, è che non esiste un modo diretto che permetta ad un oggetto di un client di invocare un oggetto di un server. 120
