Architetture Distribuite, Middleware, Distributed Object Computing e Legacy System. Giuseppe Santucci &... santucci@dis.uniroma1.

Transcript

1 Architetture Distribuite, Middleware, Distributed Object Computing e Legacy System Giuseppe Santucci &... santucci@dis.uniroma1.it

2 Argomenti Concetti di base Applicazioni Client/Server Middleware tradizionale Middleware WWW Distributed Object Computing Legacy System 2

3 Concetti di base applicazioni distribuite sistemi client/server architetture a n livelli middleware 3

4 Definizione di applicazione distribuita Una semplice definizione di applicazione distribuita (che non implica necessariamente semplici conseguenze) e : Una applicazione è distribuita se le funzioni coinvolte nella sua esecuzione sono distribuite tra 2 o più computer implica comunicazione presuppone supporto per eterogeneita 4

5 La distribuzione delle applicazioni Fino a qualche tempo fa la maggior parte delle applicazioni giravano all interno di un singolo sistema Con il diminuire delle dimensioni e dei costi della macchine, è diventato vantaggioso distribuire le applicazioni su due o più sistemi, con i seguenti benefici» utilizzo di due o più macchine economiche in luogo di una macchina costosa» migliore sfruttamento di PC e workstation esistenti» crescita facilitata dell ambiente di calcolo 5

6 Esempio di applicazioni tradizionali T T T Applicazione Database Applicazione T T Applicazione T T 6

7 Esempio di applicazioni distribuite Applicazione WS WS WS WS Database WS Applicazione WS Applicazione WS WS 7

8 Le market forces che guidano l evoluzione dei sistemi distribuiti In generale le grandi trasformazioni sono guidate da una combinazione di:» nuove tecnologie» nuove necessita L affermarsi dei sistemi distribuiti e dei sistemi Client/Server (C/S) viene influenzata da tre fenomeni:» downsizing» upsizing» rightsizing 8

9 Downsizing Migrazione verso il basso delle applicazioni di business da super mini e mainframe verso PC e workstation Il processo di Downsizing partiziona le grandi applicazioni pensate per i mainframe in moduli che vengono fatti operare su uno o piu server connessi in rete Le funzioni di interfaccia utente si spostano verso workstation client. Vengono rimpiazzati i vecchi terminali a carattere con moderne interfacce grafiche Soluzioni C/S basate su hardware standard e low-cost sono gli impulsi principali che governano il processo di downsizing. 9

10 Upsizing Il processo di Upsizing rappresenta il processo bottom-up che porta reti isolate di PC ad assumere le caratteristiche di sistemi dipartimentali Connessione dei PC in LAN» In origine le LAN venivano usate per condividere costose periferiche» Poi si e passati a sistemi di , di file system distribuiti e database condivisi» Applicazioni distribuite C/S 10

11 Rightsizing Il rightsizing rappresenta il processo attraverso il quale le applicazioni vengono collocate nella più appropriata piattaforma I client richiedono servizi sulla rete e tali servizi vengono forniti dai migliori server che li offrono In questo modello un server puo essere un PC un supermini o anche un mainframe Server differenti possono coesistere: la rete e il sistema Il rightsizing fa in modo che la domanda e l offerta di servizi possano incontrarsi nel modo migliore 11

12 Evoluzione dei modelli architetturali Anni 60-70: architettura centralizzata, monolitica» host (mainframe, mini) a cui vengono collegati terminali stupidi» a tutt oggi è l architettura dominante Anni 80: reti locali di PC» terminali dotati di intelligenza propria, che condividono risorse pregiate, come stampanti, dischi, etc. Fine anni 80 - Inizio anni 90: applicazioni pienamente distribuite, modello client-server» reti locali di PC e server, connesse su collegamenti geografici Metà-fine anni 90: Internet, WWW, Distributed Object Computing» sistemi network-centrici ( the network is the computer ) 12

13 13 plicazione plicazione Interfaccia Interfaccia Utente Utente zione zione Interfaccia Interfaccia Utente Utente Hardware Hardware Software Software di di Base Base Hardware Hardware Software Software di di Base Base Il middleware Applicazione Applicazione Interfaccia Interfaccia Utente Utente Applicazione Applicazione Interfaccia Interfaccia Utente Utente Applicazione Applicazione Interfaccia Interfaccia Utente Utente Hardware Hardware Software Software di di Base Base Middleware e servizi distribuiti RETE

14 Il modello Client-Server Una semplice definizione (che non implica... ) è:» La divisione di un applicazione in compiti eseguiti su due computer diversi, uno dei quali è una stazione di lavoro programmabile 14

15 Caratteristiche delle applicazioni client-server Il concetto di servizio Condivisione delle risorse Protocolli di comunicazione asimmetrici Trasparenza della posizione fisica (location) Indipendenza dalle piattaforme hardware/software ( mix and match ) Scambi di informazioni basati su messaggi Incapsulamento dei servizi 15

16 Architetture a più livelli Diversi concetti di livelli architetturali» livelli hardware» livelli software fisici» livelli software logici» livelli applicativi Il concetto sul quale ci concentriamo principalmente è quello di livello applicativo» vale a dire di quali moduli fondamentali si compone una applicazione Vedremo che esistono applicazioni a 2, 3, ed in generale n livelli» il salto concettuale avviene tuttavia tra le architetture a 2 livelli e quelle a 3 livelli 16

17 Modelli architetturali distribuiti Identificazione preliminare di componenti dell applicazione» Frammentazione delle applicazioni in livelli (o strati) applicativi» Gli strati costitutivi di una applicazione sono 3 Gestione Dati Applicazione Presentazione Localizzazione dei componenti secondo la classificazione sopra riportata 17

18 La classificazione del Gartner Group Gestione Dati Gestione Dati Gestione Dati Gestione Dati Gestione Dati Applicazione Applicazione Applicazione Presentazione Rete Applicazione Applicazione Gestione Dati Applicazione Presentazione Presentazione Presentazione ❶ ❷ ❸ 1 - Distributed Presentation 2 - Remote Presentation 3 - Distributed Function 4 - Remote Data Management 5 - Distributed Database Presentazione Presentazione ❹ Fonte : Gartner Group, 1991 ❺ 18

19 Gestione Dati Applicazione Distributed Presentation Presentazione Presentazione Server Centrale o Sistema Preesistente Gestione Dati Funzione Aziendale Automatizzata L Applicazione Logica di controllo Presentazione Sito X Rete Locale o Geografica Sito Y Sistemi Client Terminale Personal Computer Workstation 19

20 Gestione Dati Applicazione Remote Presentation Presentazione Server Centrale o Sistema Preesistente Gestione Dati Funzione Aziendale Automatizzata L Applicazione Sito X Logica di controllo e Presentazione all interno dei Sistemi Client Rete Locale o Geografica Sito Y Terminale Personal Computer Workstation Ultra-Thin Client: la collaborazione del client nell elaborazione dell applicazione è ridotta a funzioni minime 20

21 Gestione Dati Applicazione Distributed Function Applicazione Presentazione Sito X Server Centrale o Sistema Preesistente Rete Locale o Geografica Gestione Dati Funzioni Aziendali Automatizzate Comuni L Applicazione Server Sito Y Sistemi Client Personal Computer Funzioni Aziendali Automatizzate Specifiche per l utente L Applicazione Client Logica di controllo Presentazione Thin Client: la collaborazione del client nell elaborazione dell applicazione è limitata alle funzioni di pertinenza dell utente del client 21

22 Gestione Dati Remote Data Management Applicazione Presentazione Sito X Server di Gestione dei Dati Aziendali Rete Locale o Geografica Base Dati Aziendale Sistema di Gestione delle Informazioni Memorizzate Sito Y Sistemi Client Personal Computer Funzioni Aziendali Automatizzate Specifiche per l utente L Applicazione Client Logica di controllo Presentazione Fat Client: il client non si limita a servire le specificità del proprio utente, ma contiene la logica applicativa relativa all intera applicazione 22

23 Gestione Dati Distributed Data Management Gestione Dati Applicazione Presentazione Server di Gestione dei Dati Aziendali Centrale Base Dati Aziendale Sistema di Gestione delle Informazioni Memorizzate Sito X Sistemi Client PC Rete Locale o Geografica Sito Y Server di Gestione dei Dati Aziendali Locale Funzioni Aziendali Automatizzate Specifiche per l utente L Applicazione Client Logica di controllo Presentazione Base Dati Aziendale Sistema di Gestione delle Informazioni Memorizzate 23

24 L evoluzione da due a tre livelli Monolitico 2-Livelli con Scambio Dati Host DBMS Server DBMS Dati Programma Utente con Gestione dell I/O su Schermo Data Stream verso il terminale stupido Server DBMS con stored procedure Programma Utente con Gestione dell I/O su Schermo Client Messaggi 2-Livelli con Scambio Msg Dati Programma Utente con Gestione dell I/O su Schermo Client Server Client DBMS Dati Programma Utente Messaggi Gestione dell I/O su Schermo Client/Server a 3-Livelli 24

25 Il passaggio a n livelli Server Client DBMS Dati Programma Utente Messaggi Gestione dell I/O su Schermo Client/Server a 3 Livelli Server DBMS, eventualmente con stored procedure Messaggi Programma Utente (eventuale) con Gestione dell I/O su Schermo Client Programma Utente Dati/Messaggi Client/Server a n Livelli 25

26 Requisiti e problemi di un ambiente distribuito: il ruolo del middleware Classi di requisiti cui deve soddisfare un ambiente distribuito» comunicazione» parallelismo» localizzazione dei servizi» security» sincronizzazione dei clock» Supporto per client di tipo diverso 26

27 Middleware Il termine middleware e usato per indicare tutto il software necessario per supportare l interazione tra Client e Server E la / tra client e Server, cioe l insieme delle funzioni software che vengono utilizzate per consentire al cient di ottenere un servizio dal server Dove inizia e dove finisce il campo d azione del middlware?» inizia sulle API del lato Client usate per invocare i servizi» copre la trasmissione della richiesta e della risposta sulla rete» non include il software che produce il servizio» non include l interfaccia utente 27

28 Middleware Una prima classificazione del middleware puo essere la seguente: General middleware: il substrato piu comune per C/S.» directory distribuite,» servizi di autenticazione,» servizi di timing,» remote procedure call,» servizi per la gestione delle code di messaggi Service specific middleware: necessario per particolari tipi di servizi.» Database (ODBC)» Transazioni (Tuxedo, Enchina...)» Groupware (workflow)» Object specific (ORB)» WWW middleware!!! 28

29 Un esempio famoso (storico?) di middleware: OSF DCE Diskless Support Service Other Distributed Services (Future) OSF=Open Software Foundation (oggi Open Group) DCE = Distributed Computing Environment y Time Service Service Remote Procedure Calls Other Fundamental Services (Future) t Threads OPERATING SYSTEM AND TRANSPORT SERVICES Modello architetturale indotto da DCE PCs Server HOST 29

30 OSF/DCE struttura cellulare Cellula A LAN Cellula C WAN LAN LAN Cellula B 30

31 Applicazioni Client/Server (& general middleware)

32 Caratteristiche di un sistema C/S Cosa rende i sistemi C/S differenti da altre forme di software distribuito? Relazione di Servizio: la relazione di C/S e una relazione tra processi che possono essere localizzati su macchine differenti.» Il processo server e un fornitore di servizi» il processo client e un consumatore di servizi 32

33 Caratteristiche di un sistema C/S Risorse condivise: un server puo servire piu client alla volta e regolare il loro accesso a risorse condivise Protocolli asimmetrici: Esiste una relazione molti ad uno tra client e server. I client avviano il dialogo richiedendo un servizio. I server attendono passivamente le richieste. Trasparenza rispetto alla locazione: Un server e un processo che puo risiedere sulla stessa macchina del client o su una macchina diversa connessa in rete. Il software C/S tipicamente maschera la locazione del server rispetto al client redirigendo l invocazione del servizio. Comunicazione basata su messaggi: Client e server sono sistemi accoppiati lascamente che interagiscono attraverso messaggi. 33

34 Caratteristiche di un sistema C/S Incapsulamento del servizio: la definizione di un server e fatta rispettando il principio dell incapsulamento. Un messaggio comunica al server quale servizio e richiesto. Sara poi il server a stabilire come eseguire il compito. I server possono essere modificati internamente senza comportare una modifica dei client che ne utilizzano i servizi. Scalabilita : I sistemi C/S possono essere scalati orizzontalmente o verticalmente.» scalare orizzontalmente significa aggiungere o rimuovere client con implicazioni esclusivamente a livello prestazionale» scalare verticalmente significa migrare verso una macchina server piu grande e piu veloce Integrita : Il codice e i dati del server vengono mantenuti centralmente, con benefici economici e di sicurezza. Il client, viceversa, rimane personale e indipendente 34

35 Architetture e sistemi C/S Molti sistemi con architetture molto differenti tra loro sono stati definiti sistemi Client/Server» File servers» Database servers» Transaction servers» Object servers» Lan servers» Windows servers» Authentication servers 35

36 Fat server o Fat client? Le applicazioni C/S possono essere differenziate sulla base di come l applicazione e suddivisa tra client e server. Il modello fat server colloca piu funzionalita sul server» groupware, transactions, object servers Il modello fat client assegna maggiore responsabilita al client» database e file server Fat clients sono la forma piu tradizionale di C/S. Il cuore dell applicazione gira sulla parte client, i client sono a conoscenza di tutta la logica dell applicazione e dei dati. Applicazioni di tipo fat server sono piu facili da manutenere su grandi installazioni in quanto gran parte del software gira sul server.» I fat server tendono a minimizzare i messaggi scambiati sulla rete fornendo servizi a maggior livello di astrazione. Incapsulamento. Invece di esportare solo dati vengono esportate anche procedure e/o metodi che operano sui dati. 36

37 Anatomia di un programma server Il ruolo di un programma server e quello di servire piu client che hanno interesse ad accedere a risorse condivise Un tipico programma server fa le seguenti cose:» attende che i client effettuino delle richieste» esegue piu richieste contemporaneamente» si occupa di gestire priorita nello svolgere il servizio» puo iniziare attivita in background» si mantiene operativo anche in condizioni estreme» cresce e puo richiedere piu risorse 37

38 Threads in ambiente Client/Server Sfruttando l inerente parallelismo dei sistemi distribuiti» i server possono servire simultaneamente più client» i client possono effettuare simultaneamente più richieste di servizio Flussi di elaborazione in parallelo si definiscono threads Servers Clients 38

39 C /S e sistema operativo (general middleware) Un sistema operativo deve fornire dei servizi utili per le tipiche funzionalita richieste da un sistema C/S Di particolare importanza i concetti di :» Thread (programma concorrente guidato dagli eventi)» IPC Interprocess communication (pipe, soket, ecc.) In un ambiente distribuito, le funzioni del sistema operativo possono essere:» funzioni di base» funzioni estese 39

40 Servizi di base del SO per il server Elevato livello di concorrenza, sia come possibilita di gestire piu processi (piu indipendenza), sia come possibilita di gestire piu threads nel singolo processo (piu efficienza, meno overhead) Task Priority. Possibilita di differenziare il livello di servizio. Task Preemption. Molto piu potente del multitasking cooperativo Semafori. Per consentire la sincronizzazione. Interprocess comunication. Per consentire la comunicazione tra processi.» local» remote 40

41 Servizi di base del SO per il server Threads Per creare efficienti programmi con elevato grado di parallelismo Intertask protection Protezione dalle interferenze con le altre risorse. Un task non deve essere in grado di mandare giu il sistema Multiuser High Performance file system Elevato numero di file aperti, locks. Gestione efficiente della memoria Gestione di grandi/numerosi programmi, memoria virtuale 41

42 Servizi estesi del SO per il server I servizi estesi devono consentire un accesso piu flessibile alle informazioni condivise.» Varieta di protocolli di rete» Estensioni del Network Operating System per consentire un accesso trasparente alle risorse» Global directories e Yellow Pages» Servizi di autorizzazione ed autenticazione» Network time» Database e Transaction services» Servizi di object brokering 42

43 Anatomia di un programma Client Il lato client fornisce il look and feel dei servizi che il sistema fornisce Tutti i client hanno in comune il fatto che richiedono servizi al server, i programmi client si differenziano su cosa innesca la richiesta e sul tipo di GUI necessaria. Sulla base di queste caratteristiche una possibile classificazione delle applicazioni client e la seguente:» non GUI clients» GUI client» OOUI clients 43

44 Classificazione dei client Non GUI client. Generano richieste al server con una interazione umana minima o nulla. Due categorie:» non richiedono multitasking (bancomat, lettore di codice a barre)» necessitano multitasking. Programmi demoni, Robots GUI. Semplici GUI client sono applicazioni dove l intervento umano e occasionale. Dialoghi di tipo seriale, presentazione di grafici. OOUI client. Interfacce iconiche dove ogni oggetto sullo schermo e un client. Molte sessioni parallele. Alta interazione. 44

45 Sistemi operativi MS-DOS. praticamente non offre nessun servizio tra quelli utili per una applicazione C/S UNIX. Molti servizi di base, molte versioni OS/2. Sistema completo, ma poco affermato MAC OS. Buono, ma in via di estinzione. Windows 3.1. Solo GUI, multitasking cooperativo. Windows 95/98. Forma ancora non soddisfacente di multitasking Windows NT. Sistema abbastanza completo (task preemption) ma ancora instabile. Windows 2000? 45

46 C/S & middleware API (Application Programming Interface) Processo client Middleware client Servizi Servizi Locali di rete Protocollo middleware Processo server Middleware server Servizi Servizi Locali di rete API 7 5,6 4,3 Sistema operativo Sistema operativo 2 Hardware Hardware 1 ISO/OSI 46

47 Middleware tradizionale 47

48 Livelli del middleware (1) Servizi di rete a basso livello? (soket, SNA logical unit, NetBios) servizi primitivi emulatore di terminale (location sensitive) file transfer (location sensitive) posta elettronica servizi di base: permettono la comunicazione tra processi remoti usando il paradigma C/S e l'accesso distribuito al file system e a risorse condivise» Meccanismi per la comunicazione RPC remote procedure call RDA remote data access MOM message oriented middleware 48

49 WWW middleware Livelli del middleware (2) WEB server - WEB browser HTML / HTTP Java Middleware per dati distribuiti: permette l'accesso a piu' basi di dati remote e gestite da differenti DBMS relazionali (e.g., Informix, Oracle) in modo trasparente remote SQL gateway Middleware per la gestione distribuita di transazioni: permette la completa gestione di transazioni, garantendo: aggiornamenti trasparenti (gestione automatica della replicazione) transazioni trasparenti (decomposizione trans. automatica su piu' siti) trasparenza rispetto ai guasti (accesso ai dati replicati su siti alternativi)» TP-heavy / TP-lite 49

50 Livelli del middleware (3) Middleware per oggetti distribuiti: permette ad oggetti remoti di scambiarsi messaggi. Componenti essenziali sono:» ORB: Object Request Broker che trasferisce le richieste e le risposte tra l'oggetto client e l'oggetto server» Repository: descrizione di tutti gli oggetti disponibili utilizzato dall'orb per trovare gli oggetti di interesse sulla rete» E.g., Corba, OLE/ActiveX, OpenDoc, Oracle WRB Middleware specializzato» Mobile computing» Multimedia» Legacy access/integration» Groupware Distributed operating system (DISOS)?? 50

51 Portabilita' ed interoperabilita' (1) Le API influenzano la portabilita' delle applicazioni C/S. Ad esempio, un client che usa le API di Informix deve essere riscritto per utilizzare le API di Oracle. Il protocollo di interazione tra il middleware client e quello server influenza la interoperabilita' delle applicazioni C/S. Ad esempio un middleware client Informix non riesce a scambiare dati con un middleware server Oracle. Occorre prevedere un eventuale "gateway". E' quindi importante considerare i livelli di standardizzazione possibili 51

52 Portabilita' ed interoperabilita' (2) API Protocollo Esempi Totally open Open Open DCE RPC Corba Open API Open Proprietary ODBC Open protocol Proprietary Open DRDA ISO RDA Proprietary Proprietary Proprietary OLE/ActiveX 52

53 Middleware di base ~= Network Operating Systems (NOS) Scopo del middleware NOS: fornire una singola immagine di sistema per tutti i servizi di rete. Il middleware NOS fornisce l infrastruttura logica indispensabile per sviluppare sistemi informativi distribuiti. Senza il NOS lo sviluppo di applicazioni C/S sarebbe enormemente difficoltoso e costoso. Spesso i middleware commerciali si appoggiano sui servizi forniti dal NOS. (e.g., un middleware per basi di dati si appoggia su Netware di NT) 53

54 Servizi offerti dal NOS Il NOS nasce con le LAN (essenzialmente : file server/ print server). Successivamente introduce servizi utili per C/S:» Comunicazione remota» Servizio di directory» Sicurezza» Gestione dei guasti» Scheduling dei task» Time service E' importante notare che il NOS offre servizi all'interno di una LAN! Occorrono quindi dei "gateway" per far colloquiare due NOS distinti 54

55 RPC - Remote Procedure Call Il middleware RPC fa in modo che l invio di una richiesta da un client verso un server avvenga come se fosse una normale chiamata locale di procedura Meccanismo che facilita la programmazione L'interazione e' sincrona: il processo client viene sospeso finche la procedura chiamata non termina. I parametri vengono passati come una procedura ordinaria. Il software run time raccoglie i parametri, li impacchetta (Marshalling), forma un messaggio e lo invia verso il server remoto Il server riceve la richiesta, spacchetta i parametri (Unmarshalling), e manda la risposta al client. 55

56 Il meccanismo di Remote Procedure Call Main Proc A Proc B 1 Client Main Server ProcA Server Proc B 2 Client Main Client Stub Server Stub Server ProcA Server Proc B Una copia prototipo della procedura da chiamare viene inserita nel codice del client : client stub. Il client stub riceve i parametri e si preoccupa di inoltrarli sulla rete fino al server che implementa la procedura. Un server stub si occupa di ricevere tali parametri ed inviare indietro il risultato. (Gli stub sono il middleware!) 56

57 IDL - Interface Definition Language Gli stub del client e del server vengono generati tramite un opportuno linguaggio di specifica : IDL IDL permette di specificare in modo dichiarativo la struttura dell'interfaccia, ovvero:» operazioni disponibili» parametri necessari Le specifiche della interfaccia vengono "compilate" nei linguaggi del client e del server, ottenendo il server stub ed il client stub Il client ed il server vengono compilati ed eseguiti Approccio tipico C/S Ovviamente non esiste uno standard per IDL 57

58 Sviluppo di applicazioni con RPC Client Source Interface Definition File (IDL) Server Source IDL Compiler Client Stub Source Header File Server Stub Source X Compiler Client Executable RPC Runtime Library Y Compiler Server Executable 58

59 Riassumendo Il client effettua una chiamata locale ad una procedura stub che la trasforma in un messaggio di rete nel formato previsto (tipicamente TCP/IP soket) e "scopre" l'indirizzo del server (bind) utilizzando, ad esempio, una diretory distribuita Il messaggio viaggia sulla rete e viene ricevuto dallo strato di trasporto della rete del server (gateway?) Il server stub riceve il messaggio, lo converte in una chiamata locale e lo invia al server Il server esegue la chiamata e restituisce al server stub il risultato Il server stub... 59

60 Caratteristiche del NOS per supportare meccanismi RPC Localizzazione delle funzioni del server ed avvio del server Definizione dei parametri (NIDL) Network Interface Definition Language. NIDL compiler, header stub e skeleton. Gestione dei malfunzionamenti Automatic retry, only once semantics. Connection-Oriented vs. Connectionless RPC Sicurezza Specifica del livello di sicurezza richiesto. Funzioni di ricerca del server. Binding = Associazione C/S. Hardcoded binding Vs. binding con ricerca su direttorio, dynamic binding. Nel caso di dynamic necessità di pubblicizzare un server. Rappresentazione dei dati Necessità di utilizzare una forma canonica di rappresentazione per i dati. 60

61 Risoluzione delle differenze tra le rappresentazioni dei dati RPC risolve automaticamente le differenze di rappresentazione dei dati tra sistemi eterogenei (ISO-OSI 6 presentazione) Ciò avviene per mezzo di opportuno codice associato agli stub per mezzo dell IDL compiler Esistono diversi approcci a questo problema:» Rappresentazione canonica comune a volte inutile» DCE impiega lo schema receiver makes it right» Altri sistemi impiegano lo schema sender makes it right implicano la conoscenza di tutti i formati dei client e dei server 61

62 Workflow di una comunicazione sincrona client 1 client si attiva directory Il server si attiva server Selezione del servizio riceve il messaggio 3 Preparazione del messaggio Decodifica messaggio Chiamata sincrona 2 Esegue il servizio M i d d l e w a r e 62

63 RPC: ulteriori considerazioni Generazione degli stub : manuale / automatica (IDL) Nel caso di binding dinamico occorre trovare la coppia <host,server> appropriata. Directory centralizzata/distribuita. Semantica della chiamata in caso di malfunzionamenti server: Exactly once At most once At least once Gestione degli errori timeout chiusura del server (automatica / da parte del client) Passaggio dei parametri: valore, variabile? Interazioni asincrone? Dimensione del risultato non nota? (e.g., query SQL) Estensioni : RPC + transazioni 63

64 Message Oriented Middleware (MOM) MOM consente a client e server di scambiare generici messaggi utilizzando code di messaggi gestiti in modo asincrono. Le applicazioni comunicano in rete semplicemente mettendo messaggi in code e prendendo messaggi dalle code. MOM elimina tutti i dettagli della comunicazione fornendo un API molto semplice. MOM consente la comunicazione senza la necessità di avere una connessione attiva Client e server possono essere operativi in tempi differenti. Grande disaccoppiamento ed indipendenza. Un programma può decidere quando prelevare i messaggi dalla coda. Possibilità di comunicazione one-to-many many-to-one. 64

65 Prodotti di middleware MOM MOM è un componente chiave del middleware assolutamente essenziale per una certa classe di sistemi distribuiti Se l applicazione può tollerare un certo livello di indipendenza dai tempi di risposta, i meccanismi MOM forniscono il modo più semplice per realizzare sistemi distribuiti MOM risulta particolarmente indicato nel caso di mobile computing Standard IBM: MQI Messaging and Queuing Interface 65

66 MQI API L API MQI consiste di un insieme di nove semplici chiamate L API MQI definisce un interfaccia tra il programma applicativo ed il gestore locale delle code. Il gestore delle code fornisce trasparenza sulla locazione dei soggetti coinvolti e gestisce la consegna dei messaggi Anatomia di un programma MQI: stabilisci la connessione con il gestore locale delle code MQCONN apri una coda per lo scambio messaggi MQOPEN inserisci o prendi messaggi MQPUT MQGET oppure interroga lo stato della coda MQINQ chiudi la coda MQCLOSE disconnetti MQDISC 66

67 Problemi con il middleware MQseries E una tecnologia sviluppata per risolvere problemi di comunicazione relativi a piattaforme eterogenee Di vecchio stile Non sono previsti meccanismi di interoperabilità con altri MOM Usa un sistema proprietario di directory Non supporta lo scambio di messaggi di grandi dimensioni come BLOB (Binary Large Object) 67

68 Confronto tra MOM ed RPC Caratteristica MOM RPC Metafora Ufficio Postale Telefono Relazione tra client e server Sequenza di attivazione Asincrona Nessuna Sincrona Stile Accodamento Call-Return Dati persistenti Sì No Il Server deve essere attivo prima che il Client possa comunicarci Necessità di disponibilità del partner Bilanciamento del carico Supporto di transazioni Filtraggio di messaggi Prestazioni Elaborazione asincrona No Impiego di coda singola in modalità FIFO o prioritybased Sì (in alcuni prodotti) Sì Lente (c è un passaggio in più) Sì Sì Per mezzo di servizi aggiuntivi (TP Monitor) No No Veloci Limitata (per mezzo di threads) Fonte: Essential Client-Server Guide,

69 Remote Data Access (RDA) Permette ad un client di accedere, tramite uno statement SQL (tipicamente una interrogazione), ad una o piu' basi di dati remote La differenza essenziale rispetto a RPC e' la dimensione del risultato:» RDA prevede, dopo la prima comnnessione, un dialogo tra client e server per il reperimento di una tupla alla volta (SQL FETCH)» dialogo sincrono Tipi di API:» Embedded SQL: il programmatore puo' aggiungere comandi SQL all'interno del codice distinguendoli tramite indicatori speciali (e.g., $)» Call level interface (CLI) : il comando SQL e' passato come stringa al server (chiamate addizionali permettono di specificare il server, chiudere la connessione, ecc.) Il piu' noto esempio e' Open Database Connect (ODBC)» Non e necessario un IDL Comandi SQL statici e dinamici» dinamici : permettono di formulare query estemporanee» statici : permettono di individuare piani esecutivi a tempo di compilazione 69

70 Stored Database Procedure Procedure scritte in una estensione dell'sql con istruzioni condizionali e di ciclo (spesso linguaggio proprietario del DBMS). Vengono compilate e memorizzate presso il server per poter essere eseguite tramite una chiamata speciale. Vantaggi principali:» efficienza» migliore gestione della integrita' dei dati (e.g., tutte le funzionalita' di update possono essere realizzate tramite stored procedure)» introducono una sorta di "object orientation" per i server di basi di dati 70