ELEMENTI DI PROGETTAZIONE SOFTWARE

Транскрипт

1 ELEMENTI DI PROGETTAZIONE SOFTWARE Massimiliano Redolfi Architetture Architetture logiche e fisiche

2 Stand Alone tipico applicativo anni 1980 nessun problema di concorrenza spesso nessuna scomposizione orizzontale reale dell applicativo ma un soluzione monolitica scalabilità nulla Client Server: database condiviso tutta la logica sul client fat client (very fat) problemi di aggiornamento e gestione dei client elevate richieste di risorse sul client i client evolvono con l applicativo

3 Client Server a due livelli logica di interazione legata al client logica applicativa nel server, spesso integrata nel database (store procedure, ) client come player (Oracle Form) o sistemi dedicati (AS/ 400, ) Architetture WEB/Mobile (3-tier) logica di interfaccia sul client ridotti problemi di aggiornamento dei client separazione netta tra informazione e sua rappresentazione logica applicativa completamente centralizzata il client non è che un player generico per linguaggio standard (html, ) si possono aggiungere nuove tipologie di client senza modificare l applicativo

4 Macrolivelli logici di un software applicativo la scomposizione permette di: semplificare modularizzare riutilizzare integrare distribuire lo sviluppo ed il sistema realizzato concentrarsi su un dato problema Macrolivelli logici di un software applicativo: Client ambiente utente controlli interazione con l utente nel contesto dell utente

5 Macrolivelli logici di un software applicativo: Presentation multicanalità separazione tra informazione e sua rappresentazione interazione con la logica applicativa Macrolivelli logici di un software applicativo: Business logica applicativa rutine e librerie comuni gestione dell accesso alle informazioni gestione delle transazioni congruenza applicativa dell informazione

6 Macrolivelli logici di un software applicativo: Data storage permanente dell informazione gestione della coerenza strutturale dell informazione Architetture Multilayer Facilità di gestione Scomposizione ben definita Automatizzazione Riutilizzo Gestione delle Responsabilità Modulrità Scalabilità Distribuzione del lavoro Protezione della conoscenza

7 Architetture Multilayer: livelli comuni e propri Livelli Framework Livelli applicativi Architetture Multilayer: Sicurezza e Gestione Sicurezza Autorizzazioni Utenti Oggetti - Ruoli MANAGMENT

8 Architetture distribuite: ICARO-NET necessità di interagire con sistemi distribuiti sul territorio necessità di integrare informazioni provenienti da sistemi eterogenei un caso pratico: progetti per l egovernment (approfondiremo durante il corso) Affidabilità e scalabilità di un sistema informatico

9 I sistemi in cluster Affidabilità e Scalabilità: tali caratteristiche vanno di pari passo con il concetto di clustering Un cluster è un gruppo di server che lavorano in totale coordinazione in modo da: apparire come una singola entità all utente sopperire al fallimento di un nodo con l inserimento di un altro in modo trasparente (failover). Questo sistema architetturale fa in modo che i dati e gli stati logici siano sempre attivi e preservati, e permette di aggiungere componenti hardware o aumentare l utenza più agevolmente (scalabilità). Application & DB Cluster: Dedicated Secondary Node primario secondario il nodo primario supporta tutti gli utenti in linea, mentre il secondario è in standby. in caso di fault, il secondario entra in gioco divenendo il primario e prendendosi carico delle risorse in uso. active/passive: uno dei due nodi non è mai in funzione tipicamente su 2 nodi utilizzata spesso nei database server quando clustered info (RAID esterno)

10 Application & DB Cluster: High Avaliable Cluster primario secondario affidabilità paragonabile alla configurazione Active / Passive ma performance più elevate in quanto entrambi i nodi sono on line la capacità dei nodi deve essere scelta non per prestazioni del singolo sottosistema, ma per essere in grado di sobbarcarsi anche delle risorse del compagno in caso di fallimento active/active: entrambi i nodi sono sempre on-line load balancing predittivo tipicamente su 2 nodi utilizzata nei database server con elevate performance maggiori difficoltà di gestione e costi superiori all A/P clustered info (RAID esterno) Web Cluster: Load Balancing NLB Cluster tutti i nodi erogano gli stessi servizi bilanciamento del carico basato su virtualizzazione dell indirizzo IP delle macchine le macchine compaiono all esterno come un unica entità in caso di fault di una macchina le richieste vanno sulle restanti macchine (ovviamente le sessioni aperte sulla macchina in

11 Architetture cluster a più livelli NLB A/A A/P Tipica architettura di FARM (non sono rappresentati i sistemi di sicurezza e gestione) Caching Web Cache Database Cache

12 Replica DB-A DB-B distribuzione delle informazioni in sedi diverse, tipicamente dati in lettura (snapshot) allineamento delle informazioni presenti in più database, in modo asincrono (snapshot bidirezionali su elementi diversi) integrazione delle informazioni provenienti da sistemi diversi (ad esempio integrazione delle informaizioni provenienti da ERP e CRM per la costituzione di un sistema di CM) (merge replication) gestione di database distribuiti (transactional replication) Complessità/costo Disaster recovery: prepararsi in tempo Non solo perché un fulmine potrebbe distruggere il vostro IDC, ma perché anche una patch può creare gravi inconvenienti è sempre il caso di: mantenere aggiornati i backup dei database, compresi i log file ed i database di sistema mantenere attivi gli adeguati sistemi di auditing, e provvedere al backup delle informazioni da queste registrate (installazione di applicativi, service pack, variazione di configurazioni hw/sw, ) mantenere aggiornati eventuali sistemi per la gestione delle funzionalità di minima

13 Disaster recovery: prepararsi in tempo Cosa succede se un incendio distrugge il data center? il piano di disaster recovery: piano di ripristino temporaneo (sempre più spesso i sistemi sono ridondati, anche con caratteristiche e risorse diverse grazie alla virtualizzazione ) piano di acquisto e messa in servizio dei sistemi andati perduti piano di comunicazione elenco delle persone da contattare in caso di disastro, con indicazioni delle modalità di contatto definizione del responsabile del piano stesso etc