Organizzazione della lezione. Lezione 11 Oggetti Distribuiti. Marshalling: : perché. Rappresentazione Esterna dei Dati

Transcript

1 Lezione 11 Oggetti Distribuiti Vittorio Scarano Corso di Programmazione Distribuita (23-24) Laurea di I livello in Informatica Università degli Studi di Salerno,, 2 Marshalling: : perché Rappresentazione Esterna dei Dati La informazione nei programmi è memorizzata (e trasmessa) come strutture dati oggetti che possono contenere altri oggetti La trasmissione usa, invece, una sequenza di byte necessario trasformare l informazione da trasmettere attraverso il marshalling Alcuni problemi: diverse rappresentazioni in virgola mobile rappresentazione di interi in ordine diverso (big-endian e little-endian) caratteri: ASCII (1 byte) oppure UNICODE (2 bytes)? 3 Una forma standard per rappresentare strutture dati (oggetti istanza di classi) tipi primitivi Viene usata da macchine diverse per comunicare dati Il Marshalling/Unmarshalling permette: assemblaggio/disassemblaggio dei dati in modo che possano essere trasmessi utilizza una rappresentazione esterna che la piattaforma di middleware utilizza Trasparente per la applicazione 4

2 Alcuni standard per la rappresentazione esterna CORBA Common Data Representation utilizzabile da diversi linguaggi per strutture dati che sono da inviare come parametri o restituiti da una invocazione ad un metodo remoto Serializzazione di oggetti di Java utilizzabile solo da Java permette di serializzare oggetti che possono essere: inviati come parametri o restituiti da una invocazione ad un metodo remoto memorizzati su disco (oggetti persistenti) 5 6 CORBA CDR (Common Data Representation) Un esempio di CDR (1) 15 tipi primitivi Sia da trasmettere una struttura dati Person: short (16), long (32), float (32), double (64), char, boolean, octet (8), Tipi compositi, tra cui: sequence: la lunghezza (long) seguita dagli elementi string: lunghezza (long) seguita dai caratteri array: elementi in ordine (lunghezza fissata) struct: nell ordine di dichiarazione 7 struct Person { string name; string place; long year; } La descrizione della struttura dati Person viene fatta nell Interface Definition Language (IDL) un linguaggio per la specifica della interfaccia non dipendente dal linguaggio di programmazione 8

3 Un esempio di CDR (2) Un esempio di CDR (3) Data una struttura Person con valore Viene rappresentata in forma piatta con il CDR: indici bytes 5 "Smit" "h " 6 "Lond" "on " 1934 lunghezza stringa Smith (int) Smith i dati sono allineati a word (4 byte) lunghezza della stringa London London unsigned long Si usa sempre il byte-ordering del mittente si mandano anche informazioni circa il byte-ordering usato Assumendo che si usi il big-endian bytes 5 "Smit" "h " 6 "Lond" "on " Serializzazione di Java Utilizzata da Java Remote Method Invocation per poter passare oggetti e valori di dati primitivi come parametri e risultato di invocazione di metodi Si usa il meccanismo delle interface Java se una classe può essere serializzata allora deve implementare la interface Serializable che non contiene alcun metodo (marker interface) Importante: si assume che chi deserializza un oggetto non ha informazioni apriori: né sulla classe di cui l oggetto è istanza né sulle classi di cui sono istanza i campi dell oggetto ma deve avere accesso alle definizioni delle classi (file.class) 11 12

4 Struttura della serializzazione di Java Il problema degli handle (1) La serializzazione di un oggetto: nome della classe, versione, numero, tipi e nomi delle variabili istanza valori delle variabili istanza Può contenere anche dei riferimenti ad altri oggetti: quando un oggetto viene serializzato, tutti gli oggetti a cui fa riferimento sono ricorsivamente (depth-first) serializzati con lui i riferimenti vengono trasformati in handles (riferimenti all interno della forma serializzata) handle per la definizione della classe (per poterla riusare) handle per i valori degli oggetti istanza delle classi (per poterli riferire) Variabili istanza diverse che fanno riferimento allo stesso oggetto devono usare lo stesso handle Esempio (relativo a Employee/Manager etc.): aggiungiamo a Manager una variabile che contiene il riferimento di un Employee che svolge compiti di segreteria per il Manager supponiamo di avere array staff di 3 Employee con i seguenti valori: staff Employee Manager secretary = Manager Harry Paul 13 secretary = Peter 14 Il problema degli handle (2) L uso della reflection nella serializzazione Se non si usassero gli handle quando si deserializza staff, ogni volta che si incontra il riferimento a Harry si ricreerebbe un nuovo oggetto staff Employee Manager secretary = Manager secretary = Harry Paul Peter Employee Harry Employee Harry 15 Java utilizza la riflessione per la serializzazione permettendo, una volta ottenuto il nome della classe ed il tipo dei parametri da passare al costruttore Nella serializzazione: si trova il nome della classe dell oggetto da serializzare si trovano nome, tipo e valori delle variabili istanza Nella deserializzazione: il nome delle classe viene usato per creare la classe si crea il nuovo costruttorie con tipo dei parametri corrispondenti a quelli specificati nella forma serializzata si usano i valori letti dalla serializzazione come parametri per il costruttore 16

5 Alcuni commenti sulla serializzazione Perché non tutte le classi sono serializzabili? sicurezza: un oggetto istanza di una classe puo essere scritto in file e letto compreso i dati privati!! istanze serializzate possono essere alterate e creare situazioni di errori quando la JVM ricarica l oggetto Per i campi da non serializzare si inserisce la keyword transient davanti alla dichiarazione del campo: descrittori di file, descrittori di finestre etc. dipendenti dalla specifica macchina ed inutili da serializzare campi di cui si vuole mantenere la privatezza assoluta Esistono altre soluzioni interface Externalizable che permette di personalizzare il formato di serializzazione (ad es. per crittografare i dati) Riferimenti remoti a oggetti Una rappresentazione di un riferimento remoto Quando un oggetto invoca un metodo di un oggetto remoto un messaggio viene inviato al server che ha l oggetto Necessario specificare il riferimento remoto Un identificatore unico (nello spazio e tempo) nello spazio: su tutti gli oggetti di tutti i processi in corso nel tempo: nessun oggetto nuovo può ottenere lo stesso riferimento di un oggetto vecchio (e non esistente più) 19 Internet address Porta: quella usata per comunicare dal processo che ospita l oggetto Unicità del processo: port number e tempo di creazione dell oggetto Unicità dell oggetto: numero dell oggetto (incrementato ad ogni creazione) Unicità host: indirizzo Internet Interfaccia: port number time object number interface chi riceve un riferimento remoto, conosce i metodi (interface) offerti dall oggetto riferito 2

6 Modelli di programmazione per il calcolo distribuito Chiamata a procedura remote (Remote Procedure Call) Derivato dalla programmazione procedurale Invocazione di metodi remoti (Remote Method Invocation) Derivato dalla programmazione orientata ad oggetti Programmazione basata su eventi Notifica di eventi che siano originati in remoto Interfacce Interface Definition Language Definizione delle possibili interazioni con un modulo del programma verso gli altri moduli Siano essi oggetti oppure procedure Specifica variabili e procedure accessibili Service interface (RPC) In client-server, specifica tipi di input/output Remote interface (RMI) Metodi e argomenti Differenza: oggetti come parametri Servono per la specifica della interfaccia Possibile un inserimento all interno del linguaggio Come con Java Remote Method Invocation Oppure piattaforma neutrale rispetto ai linguaggi IDL di Corba IDL per RPC in OSF Distributed Computing Environment DCOM IDL 23 24

7 Oggetti Distribuiti (1) Oggetti Distribuiti (2) Modello client-server Interazione chiamando metodi dal client verso un server che gestisce le chiamate di metodo per l oggetto Remote Object Reference Permette il riferimento ad un oggetto remoto Remote Interface Indica quali metodi sono invocabili remotamente A remote invocation B local C invocation local E invocation local invocation D remote invocation F Garbage collection distribuita in generale, effettuato in cooperazione con quello locale basato sulla conta dei riferimenti remoti attivi in alcuni sistemi si introduce il lease riferimento remoto a termine Eccezioni introduzione di eccezioni remote peculiare rispetto alle eccezioni usuali supporto per il trattamento a livello applicazione Trasparenza: un dibattito Lo scopo di RPC (Remote Procedure Call) nessuna distinzione nella sintassi trasmissione e marshalling completamente trasparente Una grande idea: computazione locale = computazione distribuita Forse non proprio una grande idea una chiamata (invocazione) remota può fallire per tanti motivi in più, rispetto alla chiamata (invocazione) locale 27 28

8 Computazione locale e distribuita Una visione unificante (?) - 1 Criterio utilizzato per la distinzione computazione locale: programmi che condividono lo stesso spazio di indirizzamento computazione distribuita: programmi che usano diversi spazi di indirizzamento (possibilmente su host diversi) Una visione unificante: due le strade possibili un paradigma di computazione che fa apparire tutti gli oggetti come locali un paradigma di computazione che fa apparire tutti gli oggetti come remoti (inutilmente complicata per il programmatore) A note on Distributed Computing di Waldo, Wyant, Wollrath e Kendall (Sun) (1994) Computazione locale o distribuita, la metodologia di programmazione object-oriented non fa distinzioni Un oggetto viene definito in termini di interfacce (comportamento) e classi (implementazione) La implementazione di un oggetto è nascosta così come la natura dell oggetto: locale o remoto Una motivazione: la semantica del comportamento non cambia 29 3 Una visione unificante (?) - 2 Gli ostacoli alla unificazione dei paradigmi - 1 I principi di questa visione unificante : Latenza da 3 a 5 volte in ordine di grandezza Problemi di performance Lo sviluppo tecnologico può velocizzare le chiamate remote ma lo stesso miglioramento si otterrà dalle chiamate locali Una differenza ovvia ma non la principale: spesso viene assunto che è la unica differenza la progettazione OO per una applicazione dà origine ad una sola soluzione naturale (senza curarsi del contesto in cui la applicazione viene eseguita) performance e gestione malfunzionamenti sono legati alla fase implementativa (e quindi non alla fase progettuale) l interfaccia di un oggetto risulta indipendente dal contesto in cui viene usato l oggetto Commenti? questa visione non è vera, anche se sarebbe bello se 31 32

9 Gli ostacoli alla unificazione dei paradigmi - 2 Gli ostacoli alla unificazione dei paradigmi - 3 Accesso alla memoria Partial failures e concorrenza Puntatori in uno spazio di indirizzamento locale non sono validi in un altro spazio di indirizzamento remoto Se si vuole che il sistema renda trasparente questa differenza l accesso deve essere completamente trasparente (niente puntatori dal paradigma, solo riferimenti) Ma, inoltre, si deve fornire traduzioni a riferimenti incrociati: A riferisce a B, ma A viene usato in remoto Nel calcolo distribuito un malfunzionamento di solito non rende inutilizzabile il sistema I malfunzionamenti devono essere specificati nella interface non solo nella implementazione La concorrenza è naturale nel distribuito nel multithread l ambiente è circoscritto, sotto completo controllo del programmatore, ed è disponibile l aiuto di gestori centralizzati (S.O.) C è differenza eccome! La fusione dei modelli comporta: un modello complesso (se tutto è considerato distribuito) un modello che permette di realizzare sistemi inaffidabili (se tutto è considerato locale) Esistono differenze di cui bisogna tener conto nella progettazione non solo nella implementazione Che il programmatore non osi unire ciò che è separato 35