Applicazioni software -...
Transcript of Applicazioni software -...
1
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
A.A. 2003-04
Architetture Distribuite
2
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Applicazioni software
Un programma o un insieme di programmi progettati per supportare il lavoro di un insieme di utenti finaliComprendono tre aree funzionali:
Interfaccia utenteo Fornisce alle persone i meccanismi necessari (visualizzazioni,
controlli, …) ad interagire con il programmaLogica applicativa
o Definisce la rappresentazione logica dei dati e dei processi aziendali che l’applicazione supporta e le regole che ne governano il ciclo di vita
Base datio Offre meccanismi di accesso e memorizzazione persistente ai
dati trattati dall’applicazione
2
3
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Applicazioni aziendali:le esigenze generali
Integrare, in un unico schema, l’accesso a tutti i servizi aziendali:
Accesso ubiquo: da ogni terminale, in ogni momento, ad ogni servizio, da ogni posto (?)
Essere facilmente accessibili (utilizzabili, indicizzabili, ricercabili,…) a tutti i potenziali utilizzatori
Interni o esterni all’azienda, con o senza formazione specifica,…Persone o programmi
Garantire elevati livelli di affidabilità del servizioNon compromettere la sicurezza informatica del servizio specifico né degli altri sistemi presentiRichiedere tempi di sviluppo limitati Garantire la scalabilità verso l’alto
4
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Evoluzione delle strategie di programmazione (1)
Programmi “monolitici”Il programma realizza in sé tutte le funzionalità di cui ha bisognoLe uniche procedure non presenti nel programma sono costituite dall’interfaccia verso l’hardware del sistema operativo
Programmi con funzioni di libreriaIl programma attinge a codice esterno (librerie evolute di sistema operativo, librerie commerciali…)Si effettua una suddivisione logica delle operazioniVengono definite interfacce software per la comunicazione tra programmi e librerieNasce l’esigenza di scrivere codice riciclabile
3
5
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Evoluzione delle strategie di programmazione (2)
Programmi ad oggettiDalle librerie di funzioni si passa agli oggettiPossono esistere più istanze (oggetti) di una data interfaccia (classe): le istanze sono separate logicamente anche se presenti sullo stesso elaboratoreDiventa più semplice progettare grossi applicativi software lavorando “per componenti”Per ridurre il “time-to-market”, diventa ancora più importante scrivere codice riciclabile
6
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Evoluzione delle strategie di programmazione (3)
Programmi distribuitiil programma viene suddiviso oltre che logicamente anche fisicamente in due o più unità funzionaliCiascuna unità può essere eseguita su calcolatori differenti purché in rete tra loroOccorre che le diverse unità riescano a parlarsi e a capirsiDiventa quindi indispensabile definire regole e formati di dati precisi (protocolli) e comuni a tutte le parti coinvolte
4
7
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Sistemi distribuiti
Componenti software distinti eseguiti su elaboratori distinti in grado di apparire come unico sistemaGli elaboratori possono essere
Collocati arbitrariamenteOmogenei o eterogeneiGestiti centralmente o in modo indipendente
La diffusione di dispositivi (PC, cellulari, PDA, elettrodomestici intelligenti, …) e di connettività pervasiva (WLAN, GPRS, UMTS,…) esalterà ulteriormente la rilevanza di questo tipo di sistemi
8
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Sistemi distribuiti: esempi
Posta elettronicaTelefonia (fissa e mobile)Domain Name Service (DNS)WebFile system distribuitiVeicoli e case “intelligenti”
5
9
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Sistemi distribuiti: caratteristiche (1)
Condivisione di risorseOgni elaboratore della rete offre potenzialmente le proprie capacità (risorse) a tutti gli altri elaboratori
Supporto dell’eterogeneità (apertura)Nella misura in cui i meccanismi di interazione sono noti e utilizzabili, è possibile fare interagire sottosistemi tra loro eterogenei (hardware, sistema operativo, componenti applicativi, …)
Accesso concorrentePiù attività possono svolgersi parallelamente attraverso la rete
10
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
ScalabilitàSi può far crescere la potenza di calcolo aumentando le risorse presenti in rete
ResilienzaÈ possibile (necessario?) garantire il funzionamento del sistema anche in presenza di un malfunzionamento di una sua parte
TrasparenzaLa suddivisione in sottosistemi è (dovrebbe essere) invisibile agli utenti finali
Sistemi distribuiti: caratteristiche (2)
6
11
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Sistemi distribuiti:limiti
Complessità: diventa molto più difficile Progettare i sistemiVerificarne il comportamentoGestirli
SicurezzaMolte più opportunità di forzare il comportamento dei sistemi a beneficio di terze parti
Impredicibilità delle prestazioniDipendenze da una molteplicità di fattori non controllabili (traffico, configurazione e politiche di gestione dei sistemi utilizzati, …)
12
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Pattern di interazione Client/Server
I nodi della rete vengono suddivisi in due sottoinsiemi, non necessariamente disgiuntiClient: consumatori di servizi
A richiesta del proprio utente, iniziano il processo di interazione attraverso una richiesta di servizio verso un serverElaborano la risposta ricevuta e la presentano all’utentePossono diventare inattivi in qualunque momento
Server: fornitori di serviziOffrono servizi a richiesta dei clientPossono ricevere molte richieste contemporaneamente da client differentiDevono garantire la propria disponibilità nel tempo
7
13
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Programmi Client/ServerClient e server sono programmi distinti
non hanno quindi uno spazio di indirizzamento comunenon sono possibili interazioni indirette tramite puntatori
Occorre introdurre uno strato (middleware/S.O.) che consente la comunicazione tra i due programmiLa struttura dei programmi si complica:
È necessario far incontrare client e serverGestione degli accessi concorrenti sul serverTrasformazione dei parametri in formati adatti ad essere trasportati attraverso la rete
14
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Pattern di interazioneClient/Server
VantaggiIl client può essere (relativamente) semplice e indipendente dalla specifica applicazione lo stesso client può essere usato per una molteplicità di scopi differenti
SvantaggiLimiti nelle prestazioni: il server costituisce il collo di bottiglia
o I possibili rimedi (duplicazione dei server, utilizzo di cache) creano ulteriori problemi (coerenza dei sistemi)
Affidabilità: il malfunzionamento di un server centralizzato paralizza tutti i clientScalabilità ed estendibilità dei sistemi: come fanno i client a scoprire l’esistenza di nuovi server?
8
15
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Pattern di interazionePeer-to-Peer
Un sistema distribuito in cui tutti i nodi hanno le stesse responsabilità ed le interazioni sono simmetricheRealizzati accoppiando funzionalità client e serverVantaggi
Maggiore robustezza ed immunità ai malfunzionamentiDistribuzione del carico più uniformeMaggiori possibilità di interazione
SvantaggiMaggiore complessità dei sistemi, dei protocolli e delle interazioniNecessità di sviluppare applicativi differenti per funzioni differenti (non c’è l’equivalente del browser universale)Difficoltà di controllo centralizzato
16
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Client/server: architetture a due livelli
Thin client(Interfaccia utente)
Fat server
(Logica applicativa+
Base di dati)
Fat client
(Interfaccia utente+
Logica applicativa)
Thin server
(Base di dati)
9
17
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Limiti delle architetture a due livelli
ScalabilitàTraffico di keepalive in assenza di interazionisi stima tra 50 e 100 il numero massimo di connessioni accettabili
InteroperabilitàLa piattaforma client e quella server devono essere “compatibili”Non esiste un client universale
Difficoltà di amministrazione e configurazioneSpecialmente nel caso di fat client
18
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Architetture a tre livelli
Client: presentazione
Server: logica di servizio
Data Access Tier
DBMS
Applicationserver
Interfacciautente
10
19
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Architetture a tre livelli: obiettivi
Garantire elevate…PrestazioniFlessibilità (facilità di modificare un dato componente per utilizzarlo in altri contesti) Manutenibilità (facilità di eliminazione dei malfunzionamenti o di adattamento a nuovi requisiti)Riuso (possibilità di impiego in diverse piattaforme hardware e software)Scalabilità (possibilità di modificare un dato componente per far fronte ad una crescita delle dimensioni di un problema)
Utilizzare dei meccanismi di interazione standard tra i diversi strati per nascondere al programmatore la complessità dell’elaborazione distribuita
20
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Presentation tier
Fornisce all’utente finale l’accesso all’applicazione
Presenta le informazioni all’utente e consente l’introduzione e la manipolazione dei dati
L’interfaccia utente può essere costruita con elementi standard…
Costrutti HTML eventualmente arricchiti con codice di scripting
…o essere costituita da un programma tradizionale
Maggiori funzionalità a scapito di una minor portabilità e versatilità dell’architettura
11
21
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Middle tierDefinisce la logica applicativa del servizio:
Gestisce i processi di autenticazione degli utenti e di autorizzazioneValida i dati e le richieste ricevuti dall’interfaccia utente edesegue i comandiOpera sui dati sottostanti, garantendone la coerenza e gestendo sessioni e transazioniAggiorna il contenuto dell’interfaccia utente in base allo stato globale del sistema
È indipendente sia dalla piattaforma client (che, spesso, non è possibile imporre) che dal sistema di gestione della base dati (che impone, spesso, vincoli non marginali):
È possibile cambiarne l’implementazione/collocazione, per meglio rispondere alle esigenze del sistema
22
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Data tier
È lo strato che interagisce con il sistema di memorizzazione persistente dei dati (che può essere composto da uno o più DBMS)Può risiedere su calcolatori differenti rispetto quelli che ospitano il livello precedente Ha il compito di assicurare la coerenza dei dati in tutto l’ambiente distribuito
Locking dei datiRegole di consistenzaMeccanismi di replicazione
12
23
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Superare la barriera
Come fanno, due programmi funzionanti su calcolatori differenti a comunicare tra loro?Astrazioni di basso livello
Socket: disponibili pressoché in tutti i sistemi operativiAltri, dipendenti dalla specifica piattaforma (NamedPipe, MailSlot, …)
Astrazioni di alto livelloParadigma Web (CGI e oltre)CORBA / RMI / DCOMJDBC / ODBC.NET…
24
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Astrazioni di basso livello
Forniscono un meccanismo minimale che permette il trasferimento di informazioni da un’applicazione ad un’altraOgni applicazione deve gestire esplicitamente tutti gli aspetti della comunicazione:
Identificare l’interlocutoreImplementare un protocollo di comunicazione condivisoGestire lo scambio di dati e gli eventuali malfunzionamentiGestire i modo esplicito le risorse necessarie
VantaggiMassima flessibilità, potenziale efficienza
SvantaggiComplessità
13
25
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Astrazioni di alto livello
Forniscono un insieme di funzioni a valore aggiunto che semplificano l’interazione (middleware)Le applicazioni sfruttano l’interfaccia applicativa offerta per mediare la comunicazioneVantaggi
Semplificazione delle applicazioniSvantaggi
LatenzaSchemi di interazione più rigidiPotenziale dipendenza dalla piattaformaCosto
26
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Middleware
Applicazione 1 Applicazione 2
Middleware API
Transport API
Rete
Adattatore 1 Adattatore 2
OS OS
14
27
©M
. Bad
ella
G. M
alna
ti, 2
003-
04
Programmazione in Ambienti Distribuiti
Adattatori
Schermano (in parte) le applicazioni dai dettagli di connessioneResta evidente il modello di comunicazione (peer-to-peer o client/server)Vengono nascosti:
Accesso alle funzionalità di trasporto (TCP, UDP, HTTP, …)Gestione dei flussi di elaborazioneConversione del formato dei parametri
Possono offrire interfacce di tipogenerico (sempre uguali, le applicazioni si adattano)specifico (si definisce l’interfaccia tramite un apposito linguaggio da cui si ricavano, automaticamente gli adattatori)