Scarica programma intero di quinta superiore TPSIT e più Appunti in PDF di Informatica solo su Docsity!
SISTEMA CENTRALIZZATO
Composto da una singola macchina dove al suo interno ci sono dati e applicazioni che girano su una singola CPU che è un componente autonomo che viene condiviso tra vari utenti (le decisioni vengono prese da una singola autorità centrale, che può distribuire compiti e risorse secondo le sue priorità e obiettivi) è composto da una singola macchina dove all’interno ha dati e applicazioni che girano soltanto sulla singola CPU della macchina che viene condiviso dai vari utenti e dai vari processi che sono in elaborazione
SISTEMA DISTRIBUITO
è un insieme di macchine connesse tra loro, ognuna di esse è indipendente e connesse tramite la rete. In un sistema decentralizzato, i nodi lavorano insieme in modo autonomo per raggiungere un obiettivo comune senza bisogno di un'autorità centrale che li coordini. Si ha questo tipo di sistema quando si verificano 2 condizioni:
elaborazione di tipo distribuito
archivi di dati di tipo distribuito
POSSONO ESSERE:
- DI CALCOLO: utilizzati per sistemi di calcolo ad alte prestazioni. Si dividono in CLUSTER COMPUTING e GRID COMPUTING. CLUSTER COMPUTING -> I nodi sono disposti a grappolo, composti da hardware e software simili (omogenei) e sono interconnessi tra loro tramite rete locale, sfrutta la potenza combinata di più computer. Le caratteristiche sono: potenza elevata di elaborazione, velocità di trasferimento e centralizzazione fisica delle macchine. GRID COMPUTING -> I nodi sono disposti a griglia e sono composti da hardware e software eterogenei. Utilizza risorse di calcolo eterogenee e distribuite geograficamente come se fossero un'unica risorsa virtuale.
- PERVASIVI: Si basano su una connessione wireless come i sistemi domestici i dispositivi indossabili e le reti di sensori
- INFORMATIVI MODERNI: Ai sistemi informatici tradizionali vengono integrati i sistemi Legacy che si basano su architetture mainframe con terminali poco sofisticati COMPONENTI DI UN SISTEMA DISTRIBUITO
- CLIENT (web-browser): tipologia di applicazione che richiede un servizio in rete
- SERVER (server-web): tipologia di applicazione che offre un servizio in rete a chi lo chiede
- ACTOR: in base alla situazione può prendere il ruolo di client o di server BENEFICI LEGATI AI SISTEMI DISTRIBUITI AFFIDABILITÀ: Grazie alla ridondanza di questi macchinari se si dovesse verificare un guasto viene sostituito da un componente attivo INTEGRAZIONE: La capacita di un sistema di integrare componenti eterogenei (dispositivi molto grandi fino a sistemi molto piccoli, che comunicano allo stesso modo in rete) TRASPARENZA: Fa in modo che il sistema distribuito venga visto come un unico sistema di elaborazione. Si divide in: Di Accesso: Nasconde il modo di accedervi e le differenze di rappresentazione Di Locazione: Nasconde dov'è localizzato la risorsa Di Concorrenza: Nasconde agli utenti finali la concorrenza della risorsa condivisa Di Replicazione: Nasconde all'utente la duplicazione delle risorse
Ai Guasti: Nasconde il guasto e ripristino di una risorsa Alla Migrazione: Nasconde lo spostamento di una risorsa su un processo Alle Prestazioni : Nasconde all'utente finale le operazioni di riconfigurazione del sistema Di Scalabilità: Espande il sistema senza interrompere il servizio ECONOMICITÀ: I sistemi distribuiti offrono un rapporto qualità prezzo migliore rispetto ai servizi centralizzati APERTURA: Un sistema distribuito favorisce un'apertura verso componenti hardware e/o software a fornitori diversi per avere: Inter-operabilità: Implementazioni diverse sul pc di diverso tipo in modo da creare un unico sistema Portabilità: Una operazione per un sistema operativo può funzionare su un altro con la stessa interfaccia Ampliabilità: Ampliare il sistema tramite l'aggiunta di nuovi componenti hardware o software CONNETTIVITÀ E COLLABORAZIONE: La capacità del sistema distribuito di condividere risorse hardware e software in modo da arricchire ogni utilizzatore PRESTAZIONI E SCALABILITÀ: L'aggiunta di nuovi sensori e risorse nel sistema distribuito determina l'aumento delle prestazioni per sostenere le richieste TOLLERANZA AI GUASTI: Se in un sistema distribuito c'è un componente guasto questo non deve influenzare il corretto funzionamento del sistema SVANTAGGI DEI SITEMI DISTRIBUITI PRODUZIONE DI SOFTWARE: I programmatori si devono sempre tenere aggiornati sui linguaggi di programmazione COMPLESSITÀ : Aumenta sia sul punto di vista hardware e software SICUREZZA: Con lo sviluppo delle reti Internet hanno dovuto sviluppare sistemi di sicurezza per la prevenzione e garantire la privacy delle persone COMUNICAZIONE: Con lo sviluppo del sistema distribuiti il numero degli utenti che lo utilizzano è aumentato, viene richiesta più banda di trasferimento di dati ARCHITETTURE DISTRIBUITE HARDWARE Nel corso degli anni sono state fatte varie definizioni di architetture di sistemi distribuiti, quella di Flynn è la più importante dove si ricavano più combinazioni tra flusso di istruzioni e flusso di dati. SISD (Single instruction single data): è una combinazione a monoprocessore, che esegue un'istruzione alla volta in modo sequenziale su un unico flusso dati SIMD (Single instruction multiple data): è una combinazione multi-processore, che eseguono un singolo flusso di istruzioni su più flussi dati. Usata nelle macchine per il calcolo matriciale e vettoriale MISD (multiple instruction single data): è una combinazione multi-processore vengono eseguite più istruzioni su uno stesso flusso dati MIMD (multiple instruction multiple data): Ogni processore legge le proprie istruzioni ed opera su propri dati. Questa traspirazione si differenzia su come viene gestita la memoria: Memoria fisica condivisa: Architettura che ha in comune un unico spazio di indirizzamento fra i processori, ciò comporta uno scambio di dati fra processori molto più veloce e semplice, ma può portare a problemi di accesso -> integrare sistemi di sincronizzazione Memoria privata: Ogni processore possiede una propria area di memoria privata e della comunicazione tra processi avviene tramite scambio di messaggi SISTEMI DISTRIBUITI PERVASIVI Sono dispositivi che hanno alla base una connessione wireless come i sistemi domestici e reti di sensori. Devono avere alcuni requisiti: Cambi di contesto: Può variare in qualsiasi momento l'ambiente. Composizione ad-hoc: un nodo può essere usato in maniera molto diversa da diversi utenti
HTTP -> protocollo di trasporto -> regola comunicazione tra Server Web e Browser Web
---> Usa modello Client-Server ● Client -> Browser Web -> richiede e riceve risorse -> attività attiva ● Server -> elabora richieste e risponde al Client -> attività passiva = sempre in ascolto per eventuali comunicazioni Ha due versioni: si DIFFERENZIANO principalmente da come vengono scambiate delle sequenze di messaggio
- http 1.0 -> prot. Non permanente -> cioè ad ogni richiesta il Client deve re-inviare tutti i dati per autenticarsi
- http 1.1 -> prot. Permanente -> la connessione una volta effettata, un Client può spedire n richieste. connessione ● incanalata -> richieste eseguite in successione -> inserite in una coda (pipeline) ● non incanalata -> richieste aspettano la risposta dei quella precedente -> passa una richiesta alla volta URI = URN + URL / URN = IDENTIFICA NOME RISORSA / URL = IDENTIFICATORE DI RISORSE COVERSAZIONE CLIENT-SERVER Client effettua richiesta http alla porta 80 -> al server arriva richiesta di autentificazione -> il client invia richiesta -> server elabora e re-invia risposta al client Richiesta http (Request http) ● RIGA INIZIALE -> Metodo, Url, Versione http < Metodo >< Url >< Versione > ● HEADER -> Informazioni per Identificare un Messaggio [header] ● BODY -> dati trasportati dal messaggio [body] Risposta http (Response http) ● RIGA DI STATO -> Versione Protocollo E Codice Di Stato ● HEADER -> Informazioni per Identificare un Messaggio ● BODY -> dati trasportati dal messaggio -> contiene in genere pagina html richiesta HEADER ● generali della trasmissione ● relativi all'entità trasmessa ● riguardanti la richiesta effettuata ● riguardanti la risposta generata Header Generali della trasmissione (richiesta e risposta)
- DATA -> data e ora trasmissione
- MIME-VERSION ->
- TRANSFER-ENCODING -> Indica COMPRESSIONE dati trasferiti
- CACHE-CONTROL -> meccanismo di caching per la risposta
- CONNECTION -> tipo di connessione da usare ● Keep-alive -> rimane attiva alla fine della risposta ● Close -> si chiude
Header entità -> Forniscono informazioni sul body del messaggio o sulla risorsa richiesta
- Content-type -> Indica se si tratta di un testo di un'immagine-> presente se c’è body
- Content-base -> indica URL di base
- Content-Length -> indica lunghezza in byte del body
- Content-encoding -> indica la codifica
- Content-Language -> indica il linguaggio
- Content-location -> indica l’URL della risorsa
- Content-MD5 -> indica il valore Digest dei dati criptati con MD
- Content-range ->indica il range richiesto dalla risorsa
- Expiras-> indica la data di validità della risorsa
- Last-modified -> data e ora ultima modifica Header Richiesta -> info passate al server da client nella richiesta
- User-agent -> versione e tipo browser – versione e S.O. client
- Referer -> indica l'URL della pagina da dove il client manda la richiesta
- Host -> nome di dominio del server e la porta TCP/IP
- Accept -> negoziano il formato dei File
- If-modified-since -> richieste condizionali soddisfatte se richiesta vera
- Authorization -> indica l’autorizzazione all’accesso alla risorsa-> es. credenziali login Header Risorsa -> info passate al client dal server nella risposta
- Server -> descrive il tipo
- Accept-ranges -> specifica il range che accetta
- www-autenticate -> indica il tipo di autenticazione e le credenziali per accedere al server METODI http
- GET -> richiede una risorsa al server ● ASSOLUTO -> risorsa richiesta senza condizioni ● CONDIZIONALE -> risorsa richiesta se soddisfatte delle condizioni nell’ header (campi -> IF) ● PARZIALE -> richiesta una parte di risorsa
- POST -> simile al GET-> contiene le informazioni richieste nel Body Non sicuro pk -> blocco dati nel body, ci sono header che descrivono il body, l’URI non una risorsa ma programma
- PUT -> Memorizza una richiesta all'URL specificato risorsa ● Presente -> la modifica ● Non Presente -> la crea
- DELETE -> richiede la cancellazione della risorsa all’URL specificato Server risponde con: ● 200 ok -> azione effettuata, include entità ● 202 accepted -> azione non ancora eseguita ● 204 no content -> azione effettuata, non include entità ● 405 -> richiesta non autorizzata
- HEAD -> Richiede solo l'header, senza la risorsa Usato per Verificare: ● se la risorsa è valida ● se la risorsa è accessibile dall’esterno ● se la cache non è stata modificata nel tempo
ORGANIZZAZIONE A LIVELLO E A STRATI -> (elaborazione lato server) il modello a livelli corrisponde spesso a quello a strati L'architettura client - server è organizzata a livelli. Ogni livello fa da Client per i server a livello inferiore e da server per i Client a livello superiore. Le applicazioni di rete si dividono in tre strati di funzionalità: ● front-end -> interfaccia verso l’utente ● logica applicative ( o middleware) ● back-end -> accesso alle risorse nel DB stessa cosa si può fare per le applicazioni informatiche: Presentation Layer, bussiness logic layer e resource management layer EVOLUZIONE ARCHITETTURA A LIVELLI -> avvenuta con il miglioramento delle macchine nel tempo 1° LIVELLO -> caratterizzato da un mainframe al quale erano collegati molti terminali, avevano il compito di effettuare operazioni di input e output 2° LIVELLO -> dagli anni 80 -> architettura client-server -> ci sono due sottocategorie ● THIN-CLIENT-> Server si occupa logica applicativa e gestione dati -> Client software presentazione ● THICK-CLIENT-> Server si occupa gestione dati -> Client software presentazione e logica applicativa PROBLEMA ---> Scalabilità 3° LIVELLO -> dagli anni 90 l'architettura client-server si divide in tre livelli: front-end, logica applicativa(usando il middleware) e back-end. Middleware= è una serie di tecnologie che aiutano lo sviluppatore nella gestione delle complessità. ha lo scopo di realizzare comunicazioni e interazioni fra i componenti software di un sistema distribuito. VANTAGGI - > maggiori prestazioni, sicurezza, tolleranza ai guasti SVANTAGGI - > difficoltà di progettazione, sviluppo e amministrazione n-Livelli -> generalizzazione del modello client server a 3 livelli vengono inseriti n livelli nel mezzo APPLICAZIONE DI RETE (o Sistema Distribuito)--> pk si ha un’elaborazione su + macchine diverse Eseguite a livello applicazione dove vengono messi a disposizione i protocolli che fanno comunicare le app con host remoti È un insieme di processi eseguiti su 2 o + computer contemporaneamente interagendo tra loro condividendo risorse comuni (accesso al DB di un server). ● USER-AGENT --> fa da interfaccia tra utente e aspetti comunicativi ● IMPLEMENTAZIONE DEI PROTOCOLLI --> fanno interagire l’applicazione con la rete ARCHITETTURE PER LE APPLICAZIONI DI RETE
- CLIENT-SERVER Ci deve essere un Server Passivo che resta in ascolto per offrire un servizio e 1 o + Client che si connettono tramite la socket del server. SERVERFARM --> si usa quando un server normale non riesce a soddisfare la mole di richieste che gli arrivano ---> è UN SERVER CON STESSO HOST NAME MA CON + INDIRIZZI IP PER ESSERE DIROTTATE LE RICHIESTE.
- PEER-TO-PEER
Architettura che si basa sulla comunicazione fra una coppia di host (ognuno di essa fornisce una risorsa), che condividono risorse distribuite. Non devono passare per forza da un server per comunicare ● P2P Decentralizzato: _un peer funzione Server e Client, _si adatta ad un continuo cambiamento della rete _Per localizzare i peer non localizzati con gli indirizzi IP, ma viene usata una tecnologia più elevata ● P2P Centralizzato: è presente un Server centrale che conserva le informazioni dei peer ed esegue ricerche di una risorsa centralizzata per segnalare la posizione della risorsa all’host richiedente ● P2P Ibrido: Sono presenti super-peer determinati dinamicamente, tramite un algoritmo di elezione, che hanno anche la funzione di indicizzazione: gli altri nodi, sono anche chiamati leaf peer. SERVIZI OFFERTI DALLO STRATO DI TRASPORTO ALLE APP DI RETE
- TRASFERIMENTO DEI DATI AFFIDABILE: GARANTISCE SERVIZIO DI CONSEGNA DATI. Mette a disposizione 2 protocolli: tcp/ip e udp/ip. ● Tcp/ip: protocollo orientato alla connessione --perdita dei dati non accettata --effettua controlli --di flusso -> adattandosi alla velocità --sulla congestione in rete -- sull’integrità del messaggio ● Udp/ip: protocollo non orientato alla connessione -> perdita dei dati accettata pk non offre controlli
- AMPIEZZA DI BANDA Alcune app per funzionare richiedono una larghezza di banda specifica
- TEMPORIZZAZIONE Alcune app. di rete accettano solo piccoli ritardi in termini di ricezione dei dati per poter essere efficaci Il prot tcp/ip garantisce l’arrivo del pacchetto, ma non viene specificato il tempo di ricezione -> viene usato così un prot in tempo reale RTP che studia i ritardi nella rete
- SICUREZZA Un’app può richiedere l’invio dei dati cifrati -> malintenzionato intercetta -> riservatezza rimane integra Porte di Comunicazione (Socket) -> formato : [ind IP Server : num porta logica] Sono porte logiche che servono a far virtualizzare l’indirizzo di porta fisica della macchina in modo da connettersi a più servizi possibili. -> non connettendosi soltanto ad una sola porta --- identifica univocamente un processo quindi un server Esistono 2^16 (65535) socket sia per UDP/IP che per TCP/IPb ● da 0 a 1023-> porte riservate ai servizi in ascolto passivo ● da 1024 a 49151 -> usate da server e Client ● da 49152 a 65535 -> porte dinamiche assegnate ai processi applicativi
un Host può unirsi o abbandonare un gruppo può appartenere a più gruppi diversi contemporaneamente un host per inviare un messaggio ad un altro Host in un gruppo non ha l'obbligo di essere dentro APPLICAZIONI LATO SERVER(PROGRAMMAZIONE SERVER-SIDE) Il meccanismo che genera in formato HTML, in seguito a un’elaborazione dal processo Web server in esecuzione sul server, dinamicamente la risposta in funzione della richiesta fatta dal client. elaborazione server-side -> capacità del server di eseguire operazioni e di elaborare richieste provenienti da un client (ad esempio, un browser web) senza richiedere che il client stesso esegua il codice programmazione server-side -> si riferisce al processo di creazione di servizi web che vengono eseguiti su un server e forniscono funzionalità ai client. Ci sono diverse tecnologie di programmazione server-side si differenziano per: ● Linguaggi di sviluppo che sono supportati ● L’ambito applicativo per cui sono stati concepiti ● Meccanismi di connessione al server web ● Server web supportati I linguaggi usati lato server si dividono in: ● Codice separato associato ad un URL : CGI e Java Servlet ● Codice embedded in HTML: PHP CGI (Common Gateway Interface) -> è una tecnologia che consente ai server web di eseguire programmi esterni e di restituire i loro risultati come pagine web dinamiche. Sono scritti con più linguaggi diversi. Richiesta di una risorsa da un client ad un server I programmi CGI vengono eseguiti sul server web ogni volta che un client (ad esempio, un browser web) invia una richiesta HTTP. Quando il server riceve una richiesta per un programma CGI, il server esegue il programma e utilizza il suo output per generare una pagina web da restituire al client.
CGI vs Java Servlet
CGI-> eseguiti da SO collaborando con il server WEB e per questo meno portabili, vengono caricati ed eseguiti per ogni richiesta alzando tempi di latenza Servlet -> + portabili pk scritte in Java ed eseguite dalla JVM, sono caricate una sola volta e viene creato un thread ad ogni richiesta, possono essere usate per qualsiasi servizio richiesto al server basato su un’architettura Client-Server, Persistenza JAVA SERVLET-> usate per risposte multiple in modo concorrente, manipolare dati in un DB remoto… Una servlet è un componente software scritto con il linguaggio Java che viene eseguito sul server e gestisce le richieste e le risposte di un'applicazione web. Le servlet vengono utilizzate per generare contenuti dinamici per il client. Le servlet sono gestite interamente da un container (esempio Tomcat), software java, che viene caricato ed eseguito su un server web occupandosi del ciclo di vita di una servlet. COMUNICAZIONE TRA CLIENT WEB E SERVER WEB Il ciclo di vita di una servlet è gestito dal Servlet Container, che è il software server che fornisce l'ambiente di runtime per l'esecuzione delle servlet.
- una richiesta HTTP arriva al Servlet Container, cerca la servlet appropriata per gestire la richiesta. Una volta creata se non istanziata il Servlet Container crea una nuova istanza della servlet.
- La servlet riceve la richiesta HTTP e utilizza i metodi della classe HttpServletRequest per accedere ai dati della richiesta (come i cookie, l'URL richiesto, ecc.) e utilizza i metodi della classe HttpServletResponse per generare la risposta HTTP (come la pagina HTML da inviare al client, i codici di stato HTTP, le intestazioni HTTP, ecc.).
- La risposta HTTP generata dalla servlet viene poi inviata al Servlet Container, che la invia al client web come risposta alla richiesta originale.
REALIZZAZIONE DI UNA SERVLET
La realizzazione di una servlet in Java prevede la creazione di una classe Java che estende la classe HttpServlet e l'implementazione dei metodi service(), doGet() e/o doPost() per gestire le richieste HTTP inviate alla servlet. Le servlet implementano due package principali: ● Package javax.servlet è la base per API servlet che definiscono: le interfaccie, le classi per comunicazione, i metodi per gestione ciclo di vita e esecuzione operazioni. ● Package javax.servlet.http; estensione funzionalità di base con caratteristiche protocollo http di request e response. Classe HttpServlet -> classe astratta estende la classe generica Servlet -> questa classe astratta estende la classe generica Servlet, implementa il metodo service() (per interpretare richiesta client e invocare metodi opportuni ) e fornisce una serie di metodi per gestire le richieste http, metodi doGet() e doPost(). Classe httpServletRequest, estende ServletRequest, questa interfaccia rappresenta una richiesta HTTP in arrivo e fornisce metodi per accedere ai parametri inviati dal client Classe httpServletResponse, estende ServletResponse, questa interfaccia rappresenta una risposta HTTP in uscita e fornisce metodi per impostare i parametri che il client riceve dopo l’elaborazione della servlet
CICLO DI VITA DI UNA SERVLET
● Init(), viene inizializzata la servlet sul server web tramite il container e settaggio variabili globali per
prima richiesta (invocato 1 sola volta)
● service(), riceve, elabora e risponde alle richieste dei client (invocato ad ogni richiesta del client)
● destroy(), viene distrutta la servlet, quando il server web rilascia tutte le risorse usate. (invocato 1
volta)
DEPLOYMENT DI UN’APPLICAZIONE WEB
DEPLOYMENT -> è composto da una serie di passaggi per poter eseguire una servlet sul server. I passaggi previsti dal deployment sono: la definizione del run time environment di una application web (WEP), stabilire il posizionamento di tutti i file, mappare con un URL delle servlet, definire le impostazioni di default, configurare i vincoli di sicurezza Va scelto il nostro container per le servlet da poter installare, nel nostro caso Tomcat che dovrà preoccuparsi di fornire un ambiente di esecuzione alla nostra servlet. Dopo aver configurato Tomcat, quest’ultimo richiede per ogni WAP una particolare strutturazione delle directory collocate a partire dalla cartella principale webapps, che è la top level directory di tutte le applicazioni, che deve essere rispettata dal programmatore: ● creiamo la root directory -> contiene tutti i file e le risorse necessarie all'esecuzione dell'applicazione web ● dentro alla root directory creiamo una subdirectory WEB-INF dove memorizziamo il file web.xml ( file che contiene le definizioni delle servlet). WEB-INF si divide in due sottocartelle classes e lib o WEB-INF/ classes -> contiene i file .class delle servlet o WEB-INF/lib -> contiene i file di libreria .jar delle servlet
import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; /**
- Servlet implementation class provaServlet / @WebServlet("/provaServlet") public class provaServlet extends HttpServlet { private static final long serialVersionUID = 1L; /*
- @see HttpServlet#HttpServlet() / public provaServlet() { super(); // TODO Auto-generated constructor stub } /*
- @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response) / protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // TODO Auto-generated method stub response.getWriter().append("CIAO "+ request.getParameter("fname") +" " + request.getParameter("lname")).append(request.getContextPath()); } /*
- @see HttpServlet#doPost(HttpServletRequest request, HttpServletResponse response) */ protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // TODO Auto-generated method stub doGet(request, response); } }
PROVA
Nome: cognome
