Architettura a oggetti distribuiti

Transcript

1 Luca Cabibbo Architettura dei Sistemi Software Architettura a oggetti distribuiti dispensa asw435 marzo 2018 First Law of Distributed Object Design: Don t distribute your objects! Martin Fowler 1 - Fonti [POSA4] Pattern-Oriented Software Architecture (Volume 4): A Pattern Language for Distributed Computing. Wiley, Coulouris, G, Dollimore, J., Kindberg, T., and Blair, G. Distributed Systems: Concepts and Design, fifth edition. Pearson, Chapter 5, Remote Invocation 2

2 Obiettivi - Obiettivi e argomenti presentare la tecnologia a oggetti distribuiti e il modello a oggetti distribuiti discutere l architettura a oggetti distribuiti Argomenti introduzione agli oggetti distribuiti modello a oggetti distribuiti e RMI architettura a oggetti distribuiti discussione 3 * Introduzione agli oggetti distribuiti Lo sviluppo dei sistemi distribuiti è stato sostenuto, nel corso del tempo, da diverse tecnologie, a differenti livelli di astrazione all inizio, dalle tecnologie di programmazione di rete offerte dai sistemi operativi (come i socket) il livello di astrazione è molto basso, l accoppiamento alla tecnologia è molto alto, nessun supporto per le difficoltà e le eterogeneità comunemente presenti nei sistemi distribuiti 4

3 Introduzione agli oggetti distribuiti Lo sviluppo dei sistemi distribuiti è stato sostenuto, nel corso del tempo, da diversi tipi di tecnologie, a diversi livelli di astrazione poi, dalle tecnologie di comunicazione strutturata (anni 80), come RPC l astrazione di programmazione distribuita della chiamata remota fornisce trasparenza rispetto ai meccanismi di comunicazione in rete di basso livello è anche alla base del modello client/server tuttavia, non fornisce trasparenza rispetto alla locazione dei servizi in rete che deve essere definita staticamente ed è poi difficile da cambiare, rendendo poco flessibile il rilascio dei servizi infatti, nello stile client/server, i client e i server sono organizzati secondo una struttura gerarchica rigida inoltre, non supporta l interoperabilità tra componenti realizzati con tecnologie differenti 5 Introduzione agli oggetti distribuiti Lo sviluppo dei sistemi distribuiti è stato sostenuto, nel corso del tempo, da diversi tipi di tecnologie, a diversi livelli di astrazione il passo successivo è costituito dalle tecnologie a oggetti distribuiti (fine anni 80 e primi anni 90) che nascono dalla confluenza di RPC e delle tecnologie a oggetti questa tecnologia basata su un modello di programmazione a oggetti distribuiti (descritto più avanti) ha svolto un ruolo fondamentale nello sviluppo dei sistemi distribuiti e del middleware il suo contributo principale è stato l introduzione della nozione di broker o object broker (discusso in una successiva dispensa) per fornire ulteriore trasparenza e maggiore flessibilità oggi è una tecnologia matura e con delle capacità avanzate anche se ha alcune limitazioni importanti 6

4 * Modello a oggetti distribuiti e RMI Un modello ad oggetti distribuiti è un estensione del tradizionale modello ad oggetti ( locali ) offerto dai linguaggi di programmazione ad oggetti questo modello introduce gli oggetti remoti che possono essere distribuiti in più processi e nodi l interazione tra gli oggetti remoti avviene sulla base dell invocazione di metodi remoti (RMI) un estensione a oggetti della chiamata di procedure remote (RPC) 7 Modello a oggetti non distribuiti Modello a oggetti tradizionale ciascun oggetto incapsula stato e comportamento gli oggetti risiedono solitamente in un singolo processo ciascun oggetto implementa un interfaccia (definita implicitamente o esplicitamente) l interfaccia è una specifica delle operazioni che possono essere invocate un oggetto può essere usato conoscendone il riferimento univoco univoco nel processo in cui vive l oggetto ad es., usato in un invocazione come destinatario i riferimenti agli oggetti sono di solito implementati come puntatori per questo, hanno significato solo nell ambito del processo in cui vive l oggetto referenziato 8

5 Modello a oggetti distribuiti 9 Modello a oggetti distribuiti ciascun oggetto incapsula stato e comportamento gli oggetti possono essere locali oppure remoti gli oggetti locali sono oggetti tradizionali questi oggetti sono visibili, nell ambito di un processo, solo localmente gli oggetti remoti sono invece distribuiti in più processi e sono visibili anche remotamente ciascun oggetto remoto implementa un interfaccia remota l interfaccia remota è una specifica (definita esplicitamente) delle operazioni che possono essere invocate remotamente in corrispondenza, gli oggetti remoti hanno un tipo remoto a ciascun oggetto remoto viene assegnato un riferimento remoto che è univoco in rete un oggetto remoto può essere usato conoscendone il suo riferimento remoto ad es., in un invocazione remota Oggetti (e invocazioni) remoti e locali C E F A B D G host remote object remote invocation process local object local invocation 10

6 Invocazione di metodi remoti (RMI) Nel modello a oggetti distribuiti, l interazione con gli oggetti remoti avviene mediante l invocazione di metodi remoti (RMI) l infrastruttura di RMI prevede la presenza di un object registry (o broker) è un servizio distribuito per gestire i riferimenti remoti degli oggetti remoti consente l accesso a un oggetto remoto a partire da un suo identificatore simbolico dinamica di RMI un processo (server) può creare uno o più oggetti remoti (di tipo remoto), esportarli (ovvero, assegnargli un riferimento remoto) e registrarli presso l object registry un processo (client) può consultare l object registry per ottenere un riferimento remoto ad un oggetto remoto dopo di che, il client può interagire con l oggetto remoto effettuando delle invocazioni di metodi remoti 11 Architettura di RMI object registry (broker) client object client proxy runtime support network support server object server proxy runtime support network support logical data path physical data path 12

7 - Implementazione di RMI L implementazione di RMI richiede diversi oggetti e moduli object A client proxy for B Request server skeleton & dispatcher for B s class remote object B Reply Remote Communication reference module module Communication module Remote reference module alcuni moduli sono standard altri moduli o classi sono generati automaticamente da un compilatore di interfacce oppure sono virtuali sulla base di meccanismi di riflessione 13 Implementazione di RMI Proxy (proxy lato client) rappresentante locale di un oggetto remoto tramite il proxy, l oggetto client comunica logicamente con l oggetto server implementa l interfaccia remota per adattare e inoltrare le richieste all oggetto remoto e gestire le sue risposte ha lo scopo di nascondere gli aspetti della comunicazione fisica ad es., la posizione dell oggetto server (viene visto dal client mediante il proxy), preparazione e decodifica dei messaggi di richiesta e risposta, invio e ricezione dei messaggi di richiesta e risposta in pratica, questo proxy delega gran parte del lavoro al modulo di comunicazione 14

8 Implementazione di RMI Moduli di comunicazione il protocollo richiesta-risposta viene eseguito da una coppia di moduli di comunicazione cooperanti per scambiarsi messaggi richiesta e messaggi risposta i due moduli di comunicazione hanno un ruolo fondamentale nella definizione della semantica dell invocazione remota (discussa in una precedente dispensa) questi moduli implementano di solito la semantica at most once Modulo dei riferimenti remoti responsabile delle corrispondenze tra riferimenti locali e remoti e della creazione di riferimenti remoti tavola degli oggetti remoti elenco degli oggetti remoti offerti elenco dei proxy conosciuti 15 Implementazione di RMI Dispatcher il server ha un dispatcher per ogni classe di oggetto remoto il dispatcher riceve messaggi richiesta dal modulo di comunicazione seleziona l operazione da eseguire ne delega la gestione allo skeleton Skeleton (proxy lato server) proxy del client nel lato server il server ha uno skeleton per ogni classe di oggetto remoto implementa metodi corrispondenti a quelli dell interfaccia remota ha lo scopo di decodificare il messaggio di richiesta e di invocare il metodo corrispondente nell oggetto remoto poi aspetta il risultato dell esecuzione del metodo, e quindi prepara e invia il messaggio di risposta 16

9 Implementazione di RMI Compilatore di interfacce responsabile della generazione delle classi per i proxy sia per lo stub che per dispatcher e skeleton a partire dall interfaccia del servizio Object registry (o broker) gestisce le corrispondenze tra nomi simbolici (stringhe) e riferimenti remoti consente ai client di ottenere riferimenti a oggetti remoti 17 * L architettura a oggetti distribuiti è un evoluzione dello stile clientserver è ancora basata sulle importanti nozioni di servizio e interfaccia i servizi vengono ancora consumati sulla base di un protocollo richiesta-risposta viene rimossa la distinzione rigida tra client e server ma, in ciascuna singola interazione, si continua a distinguere tra client e server (nell ambito di quella specifica interazione) viene fornita trasparenza dalla locazione dei servizi questo consente una maggiore flessibilità nel rilascio dei componenti distribuiti viene adottato come paradigma di programmazione un modello a oggetti distribuiti 18

10 L architettura a oggetti distribuiti (DOA) chiamata anche distributed object computing (DOC) o distributed object model sulla base di un modello a oggetti distribuiti, organizza un sistema software in un insieme di elementi software chiamati appunto oggetti distribuiti nell architettura a oggetti distribuiti, gli oggetti distribuiti sono elementi architetturali (a grana grossa) sono una nozione diversa da quella di oggetto remoto del modello a oggetti distribuiti gli oggetti distribuiti del sistema sono distribuiti tra più processi e nodi, in modo flessibile l interazione tra oggetti distribuiti avviene sulla base di invocazioni remote 19 A I A B C I B I C D E I D I E chiede servizi a Nota si tratta di una vista logica, funzionale ciascun rettangolo rappresenta un oggetto distribuito (a grana grossa) 20

11 Oggetti distribuiti Nell architettura a oggetti distribuiti, ciascun oggetto distribuito è un elemento software (a grana grossa) più precisamente, ogni oggetto distribuito è di solito composto internamente da un gruppo di oggetti (a grana più piccola) molti di questi oggetti sono oggetti locali tradizionali inoltre, c è anche un oggetto remoto, che è una facade che rappresenta l intero gruppo di oggetti questo consente agli altri oggetti distribuiti di poter invocare le operazioni di questo oggetto distribuito distributed object facade remote object o1 o2 o3 local objects o4 21 Comunicazione tra oggetti distribuiti Nell architettura a oggetti distribuiti, la comunicazione tra oggetti distribuiti basata su un paradigma di comunicazione di tipo RMI è supportata da un opportuna infrastruttura di comunicazione in particolare, il servizio di middleware utilizzato nell architettura a oggetti distribuiti è chiamato un object request broker (ORB) o più semplicemente broker il broker agisce essenzialmente come un bus software per consentire la comunicazione tra i diversi oggetti distribuiti 22

12 Comunicazione mediante broker A B C I A I B I C Object Request Broker D E I D I E Questa è, invece, una vista di deployment mostra l infrastruttura di comunicazione potrebbe mostrare anche i computer/nodi su cui sono rilasciati i diversi oggetti distribuiti 23 Interazione tra oggetti distribuiti Interazione tra oggetti distribuiti gli oggetti server (ovvero, gli oggetti che offrono servizi) possono registrare i servizi che forniscono presso il broker ovvero, presso il servizio di directory gestito dal broker gli oggetti client possono poi fare richieste (invocazioni remote) agli oggetti server tramite il broker usato come indirezione oppure, possono consultare il servizio di directory del broker per ottenere un riferimento remoto a un oggetto server ad es., tramite un identificatore simbolico dell oggetto server e poi interagire direttamente con l oggetto server i ruoli client e server non sono fissati in modo statico, ma si riferiscono a una singola interazione infatti i diversi oggetti possono in generale essere sia client di servizi che server di altri servizi 24

13 Conseguenze Conseguenze architettura aperta, flessibile e scalabile possibile riconfigurare il sistema dinamicamente, migrando gli oggetti tra nodi questo consente, ad es., di rimandare decisioni su dove fornire i servizi, oppure di cambiare decisioni per sostenere qualità come scalabilità e disponibilità consente l introduzione dinamica di nuove risorse, quando richieste può essere favorita la modificabilità con oggetti a grana piccola coesi e poco accoppiati l affidabilità può beneficiare del fatto che lo stato degli oggetti è incapsulato 25 Conseguenze Conseguenze le prestazioni peggiorano se sono utilizzati molti oggetti a grana piccola o con servizi/operazioni a grana piccola le prestazioni dipendono dalla topologia e dalla grana degli oggetti e della loro interfaccia in generale è opportuno avere oggetti a grana grossa, che comunicano poco la sicurezza beneficia dall incapsulamento dei dati ma la frammentazione dei dati influisce negativamente maggior complessità rispetto ai sistemi client/server 26

14 Usi del modello a oggetti distribuiti È possibile identificare due modalità principali di utilizzo del modello a oggetti distribuiti questo modello può essere usato come un modello logico per strutturare e organizzare un sistema software gli elementi dell architettura sono macro-oggetti distribuiti che offrono servizi mediante la loro interfaccia remota il modello a oggetti distribuiti viene utilizzato per effettuare la decomposizione del sistema la tecnologia a oggetti distribuiti può anche essere usata come base (flessibile) per l implementazione di sistemi client/server ovvero, il sistema software viene organizzato secondo un architettura logica di tipo client/server ma tecnologicamente client e server sono realizzati come oggetti distribuiti che interagiscono mediante un servizio di middleware a oggetti distribuiti 27 * Discussione Le tecnologie a oggetti distribuiti (fine anni 80 e primi anni 90) insieme all architettura a oggetti distribuiti hanno costituito un avanzamento significativo rispetto alle prime tecnologie di comunicazione strutturata (come RPC) maggiore trasparenza e maggiore flessibilità nella comunicazione remota in particolare, forniscono indipendenza dalla locazione dei componenti e la possibilità di ri-deployare i componenti in modo flessibile 28

15 Discussione Tuttavia, queste tecnologie presentano anche alcuni limiti tra cui mancanza di strumenti di deployment e configurazione, e per la gestione delle dipendenze il rilascio degli oggetti distribuiti richiede la scrittura e l esecuzione di script ad-hoc per creare, configurare e registrare questi oggetti gli oggetti distribuiti devono scoprire e connettersi in modo esplicito agli oggetti da cui devono fruire dei servizi mancanza di servizi standardizzati di supporto alle qualità gli oggetti distribuiti devono gestire direttamente ed esplicitamente aspetti come persistenza, notifica di eventi, transazioni, sicurezza, replicazione, bilanciamento del carico mancanza di trasparenza nella distinzione tra oggetti remoti e oggetti locali difficile cambiare i confini della distribuzione 29