Docsity
Docsity

Prepara i tuoi esami
Prepara i tuoi esami

Studia grazie alle numerose risorse presenti su Docsity


Ottieni i punti per scaricare
Ottieni i punti per scaricare

Guadagna punti aiutando altri studenti oppure acquistali con un piano Premium


Guide e consigli
Guide e consigli


Tecnologie server side per il web, Schemi e mappe concettuali di Sistemi Informatici

Web, applicazioni per il web,Common gateway interface (CGI), PERL, script, JAVA SERVLET (strato web JEE), cookies, JAVA SERVER PAGES JSP (strato web JEE), scripting server side, jsp, php, ENTERPRISE JAVA BEANS (strato business JEE), .NET e Java EE

Tipologia: Schemi e mappe concettuali

Pre 2010

Caricato il 12/01/2010

ElenaP
ElenaP 🇮🇹

4.4

(134)

86 documenti

1 / 12

Toggle sidebar

Questa pagina non è visibile nell’anteprima

Non perderti parti importanti!

bg1
Tecnologie server side
1 INTRODUZIONE
Il problema
Il web ( web 1.0) è nato per la pubblicazione di info statiche:
- Ogni sito è la semplice unione di file tra loro referenziati
- Ogni pag è una rich indip dalla prec
- I contenuti sono predefiniti e indipendenti dalle richieste degli utenti e indipendenti dall’istante
temporale della rich
Con la diffusione del web, nasce l’esigenza di avere:
1. Pagine web composte dinamicamente in funzione dell’utente loggato, del momento della rich, delle
info provenienti dalle altre applicazioni ( pag che non esistono fisicamente ma solo dal pdv
concettuale)
2. Comportamento dell’applicazione dipendente dalle rich precedenti dell’utente ( concetto di
memoria)
NECESSITA’ DI APPLICAZIONI WEB
Applicazioni web
La rich http non indirizza solo pagine http ma un qlq tipo di file che sia archiviato sul web
server la rich può quindi essere anche l’invocazione di un programma da eseguire server-side
l’esecuzione di qst prog:
1. genera a sua volta 1 pag HTML da inviare come risp al browser
2. può richiedere la necessità di interrogare (read write update delete) un DB server side
due tipologie di applic web:
1. presentation oriented: generano contenuti interattivi e dinamici in basa alle rich C
2. service oriented: sono il punto finale di 1 web service
le applicazioni web sono responsabili della presentation logic
Funzionamento
- il C rich 1 applicazione attraverso
l’inserim dati in un forma
- il form crea la rich URL di qlc che
nn è 1 semplice file
- il S capisce che non si tratta di
una semplice pg statica e la inoltra
- l’applic esamina la rich e id la
necessità di avere dei dati: inoltra
una query a un DB
- il DB interpreta la query e
restituisce le istanze richieste
all’applic
- l’applic genera una risposta
completa e la ri-inoltra al S
- il S crea una pg HTML
contenente la risp e la invia al C
rappresentazione dei passaggi dal pdv LOGICO (non
fisico)
esmpio di azione generata dal form:
pf3
pf4
pf5
pf8
pf9
pfa

Anteprima parziale del testo

Scarica Tecnologie server side per il web e più Schemi e mappe concettuali in PDF di Sistemi Informatici solo su Docsity!

Tecnologie server side

1 INTRODUZIONE

Il problema

Il web ( web 1.0) è nato per la pubblicazione di info statiche:

  • Ogni sito è la semplice unione di file tra loro referenziati
  • Ogni pag è una rich indip dalla prec
  • I contenuti sono predefiniti e indipendenti dalle richieste degli utenti e indipendenti dall’istante temporale della rich Con la diffusione del web, nasce l’esigenza di avere:
  1. Pagine web composte dinamicamente in funzione dell’utente loggato, del momento della rich, delle info provenienti dalle altre applicazioni ( pag che non esistono fisicamente ma solo dal pdv concettuale)
  2. Comportamento dell’applicazione dipendente dalle rich precedenti dell’utente ( concetto di memoria) NECESSITA’ DI APPLICAZIONI WEB

Applicazioni web

  • La rich http non indirizza solo pagine http ma un qlq tipo di file che sia archiviato sul web server  la rich può quindi essere anche l’invocazione di un programma da eseguire server-side
  • l’esecuzione di qst prog:
    1. genera a sua volta 1 pag HTML da inviare come risp al browser
    2. può richiedere la necessità di interrogare (read write update delete) un DB server side
  • due tipologie di applic web:
  1. presentation oriented: generano contenuti interattivi e dinamici in basa alle rich C
  2. service oriented: sono il punto finale di 1 web service

le applicazioni web sono responsabili della presentation logic

Funzionamento

  • il C rich 1 applicazione attraverso l’inserim dati in un forma
  • il form crea la rich URL di qlc che nn è 1 semplice file
  • il S capisce che non si tratta di una semplice pg statica e la inoltra
  • l’applic esamina la rich e id la necessità di avere dei dati: inoltra una query a un DB
  • il DB interpreta la query e restituisce le istanze richieste all’applic
  • l’applic genera una risposta completa e la ri-inoltra al S
  • il S crea una pg HTML contenente la risp e la invia al C

rappresentazione dei passaggi dal pdv LOGICO (non fisico) esmpio di azione generata dal form:

2 CGI

Common gateway interface (CGI)

 una delle prime tecniche per la creazione di contenuto dinamico è la CGI che permette ad 1 S web di inoltrare rich ad 1 prog esterno

  • la CGI è un’interf applicativa stnd utilizzata dal web-S per inoltrare la rich del C di esecuzione di un’applicazione al programma indicato e quindi rispondere al C con l’output prodotto: la CGI rappresenta quindi il metodo per passare i dati tra S e applicazione ( è parte del protoc http)
  • per interpretare i comandi è necessario un strato SW che li esegua il programma che si attiva per ogni passaggio di dati può essere:
    1. un CGIscript : Perl script(.pl)
    2. un programma eseguibile compilato (.exe .dl)
  • tale programma deve: ricevere l’ input  inoltrarlo all’applic restituire l’output al S
  • tale programma risiede in una directory (cgi-bin) sul web-S
  • uno script CGI è un piccolo programma scritto in 1 qlq ling di progr (+ comune PERL) eseguito S-side consentendo di estenderne le potenzialità:  LE CGI PERMETTONO DI ESTENDERE LE CAPACITA’ DEI WEB SERVER, in quanto possono: -prelevare dati da form HTML : vedi es -leggere/aggiornare le info dai DB: prelevo o modifico info di 1 DB -richiamare applicazioni legacy: le CGI eseguono solo applic semplici, per quelle più complesse si richiamano altri programmi ad hoc -tenere traccia dei collegamenti (sessioni) e delle preferenze degli utenti (cookies): si può avere memoria delle transazioni effettuate dall’ utente e delle scelte fatta da lui in sessioni passate

Esempio: compilazione form:

  • la pg web rich l’inserimento di info da parte dell’ut: il browser richiede uno script CGI per la gestione dei dati inviati tramite form
  • quando l’ut preme invio le info giungono a S “xyz”( modalità post o get)
  • per elaborare le info il S le deve inoltrarle ad un programma: l’applicazione CGI “getform.pl” la CGI si pone come interfaccia tra S e applicazione
  • la CGI riceve dal S in input i dati da elab e attiva lo script specificato
  • lo script esegue l’elab richesta sui dati: per es deve memorizzare i dati inseriti in un DB.
  • Lo script genera il file HTML da inviare al S
  • l’applic inoltra nuovam una risposta alla CGI
  • la CGI dialoga con il S
  • il S risponde definitivamente al aC

Modello di funzionamento

  • il B invia 1 richiesta che contiene l’indicazione dello script da eseguire - il S riceve la rich, dialoga con la CGI
  1. Problemi di prestazione: a. il prog CGI viene lanciato all’atto della rich e termina l’esecuz quando restituisce i risultati: è un processo separato che viene creato eseguito e terminato per ogni rich http tempi di risposta alti ( oper di alloc della memoria) b. richieste contemporanee rel allo stesso script generano proc CGI diversi saturazione delle ris ( CPU) per alloc dedicata di memoria per ogni rich
  2. problemi di complessità poiché i proc nascono e muoiono con la singole rch non permettono la gestione delle variabili di sessione nella memoria del server (no memorizzazione) metodo alternativo complesso che prevede la creazione di campi nascosti nelle form: la sessione deve essere mantenuta palleggiando le var di sessione tra Ce S o memorizzandole nel DB
  3. problema di portabilità è una soluzione proprietaria: dipende dal linguaggio con cui è scritta l’applicazione ed è specifica per la particolare piattaforma per cui è stata compilata ( in fx dell’ambiente operativo devo avere codici diversi: non esiste il concetto di “multipiattaforma”)

Proposte di soluzione a problemi di prestazione

  1. tecnologia fastCGI: risolve probl di prestazione in quanto prevede la creazione di una sessione per ogni programma (non + 1 nuovo processo per ogni richiesta) notevole aumento della velocità (non rilevante il miglioramento dal pdv dell’alloc della memoria, né sol a probabilità)
  2. tecnologia PerlEx: analoga a FastCGI, cmq tecno proprietaria per migliorare prestazioni di S window
  3. tecno mod_perl: pensata per S Apache, incorpora 1 copia dell’interprete Perl all’interno dell’eseguibile del S : gli script possono così essere pre-compilati velocizzando l’esecuzione
  4. AP

Limitazione incidenza programmi CGI:

  1. API di estensione server: interfacce proprietarie che permettono di scrivere estensioni del S dandogli la possibilità di gestire autonomamente certe rich senza l’appoggio di un CGI esterno. -Pro: esecuzione rapida e sfruttamento > risorse sistema -Contro: difficoltà di sviluppo e manutenzione, rischi di sicurezza e affidabilità, problema di portabilità
  2. servlet JAVA: alternativa alle estensioni proprietarie: supera problemi di portabilità in qnt può essere interpretato da ogni SO su cui ci sia una JVM

3. JAVA SERVLET (strato web JEE)

JAVA servlet

Estensione generica del S ,ossia una classe (modulo sw) Java che può essere caricata in modo dinamico per espandere le fx (sostituendo così i progr CGI)

  • È una applicazione Java eseguita su una JVM residente su u web server  le servlet rich che il web server le supportino nativamente  oppure si può utilizzare un’estensione del web-S (servlet container) simile ad un plug-in ma installato non sul B ma sul S
  • Le servlet –similmente agli script-:
    • eseguono una seria d operazioni (calcoli, accesso DB, interazione con altre applic)
    • producono in output un file HTML che il S inoltra al B
    • vengono invocate con un hyperlink che non punta più ad una pagina HTML ma ad un bycode JAVA (.class .jar)
    • sono tipicamente invocate all’invio da parte dell’ut dei dati contenuti in un form: scritta di richiamo simile al caso CGI ma con estensione differente

Elementi fondamentali

2 elementi:

  1. classi delle API: disponibili indip dal motore web java.servlet e java.servlet.http
  2. esecutore di servlet o servlet container di tre tipologie: a. s.c.autonomo: supportano sl 1 la JVM disp dai produttori del S b. s.c.aggiuntivo: plug-in messi a disp di 1 S non progettato per supportare servlet c. s.c.incorporabile: piattaforme per il deplyment delle servlet incorporate nel S stesso esempio
  • i metodi della classe httpSERVLET gestiscono le rich dei C  è necessario specificare 2 argomenti: a. oggetto HttpServeletRequest: incapsula i dati inviati dal C alla Servlet  permette alla S di accedere alle info fornite dal B (prelevare dati dei forme + leggere cookies) b. oggetto HttpServeletResponse: incapsua i dati di risposta inviati dalla Servlet al C fornisce i metodi per risp al B ( generare dinamica mpg+ scrivere cookies)

Cookies

è un’info relativa ala C che il S colloca e conserva sul C stesso per poterla recuperare durante le successive connessioni

  • sono nati per automatizzare il login ad un sito da parte degli ut registrati: -l’UT arriva sul sito -il B verifica la presenza del relativi cookie (file di testo)
    • in caso affermativo lo invia al S insieme alla rich della pag web
  • applicazione: a. tenere traccia dei prodotti di un ordine mentre l’utente sta riempiendo il carrello 8 e quindi non ha ancora salvato l’ordine b. tenere traccia dei movimenti dell’ut sul sito 8 percorso di navigazione)
  • utilità delle info registrate: a. migliorare la navigabilità del sito b. ruotare i banner pubbl c. personalizzare la pubbl  è l’ut che autorizza il salvataggio dei cookies sul suo PC

4.JAVA SERVER PAGES JSP (strato web JEE)

Scripting server-side

  • l’evoluzione (non alternativa) delle servlet con lo scopo di separare la logica di presentazione da quella di contenuto è il linguaggio di scripting server-side
  • È un linguaggio di scripting server-side che permette di inserire delle istruzione java –da eseguire sul S- all’interno delle pag HTML: le istruzioni vengono eseguite direttamente dal S prima che siano inviate al C
  • Server side java script inserisce del codice javascript nelle pgprobl: supporto solo per Netscape= limiti di portabilità

Java Server pages

  • Le pg JSP sono una tecnica stnd che risolve il problema di portabilità in quanto basata sull’utilizzo del linguaggio Java che risulta essere interpretabile da qlq S su cui ci sia 1 JVM all’interno di un JSPconteiner
  • La tecno JSP rappr 1 sol multipiattaforma per realizzare pg HTML dinamiche server side
  • una JSP è un normale doc in HTML ma al cui interno sono inserite delle porzioni di codica JAVA si possono quindi modificare le parti rel agli scripting JAVA lasciando inalterato il doc HTML e viceversa
  • quando il B chiama 1 JSG, il web-S: a. estrae il cod HTML dalla JSP b. costruisce automaticamente 1 servlet c. esegue la servlet d. l’output della servlet ( codice HTML generato dinamicamente) è inserito nella pg HTML al posto del cod JAVA originale e. la pg HTML viene inviata al C f. l’oggetto servlet è memorizzato in modo da essere accessibile per una rich successiva
  • gli script JSP sono vere porzioni di codice ( scriptlet)all’interno della pg HTML di 2 tipologie:

a. dichiarazioni: per la dich di var e metodi:

b. espressioni: script che eseguiti producono un output HTML:

  • i file per essere riconosciuti dal B devono essere salvati in .JSP
  • esempio: stampa a video di un messaggio (“prima prova JSP”)

Le sezioni tra <%.....%> sono quelle che contengono le istruzioni in linguaggio JAVA

Modello di funzionamento

  1. il B richiama JSP
  2. il S estrae cod HTML
  3. poi estrae cod java
  4. costruisce ed esegue in automatico 1 servlet
  5. Sostituisco 1 porzione del codice HTML con l’elaborazione del codice java 6. si invia la pg al B

Modello di funzionamento

Non ci sono differenze sostanziali: si compilano gli script presenti nella pg e quindi si invia la pg risultante creata dinamicamente

PHP hypertext processor

  • Linguaggio di programmazione nato nel mondo open source come semplice linguaggio di scripting per la realizzazione di pg web dinamiche
  • Si è evoluto nelle varie release fino a diventare 1 linguaggio O-O
  • Esistono numerose librerie applicative standardizzate che permettono di semplificarne lo sviluppo offrendo soluzioni alle esigenze più comuni
  • È orientato allo sviluppo rapido di applicazioni semplici poco adatto per applicazioni “mission critical”

5.ENTERPRISE JAVA BEANS (strato business JEE)

Jsp e componenti Java Bean

  • Problema JSP: difficoltà di manutenzione del cod delle applicazioni complesse perché contengono molto codice JSP che rich 1 programmatore spec
  • Soluzione Java Bean: componenti SW contenenti una classe Java che vengono inclusi in 1 pg JSP attraverso appositi TAG JSP permettendo così: -un + efficiente incapsulamento del cod -un semplice riuso del cod programmi scritti in java che racchiudono la logica d business
  • Al programmatori web risulta invisibile la sezione di codice puro che viene sostituito da richiami ai metodi della classi incluse mediante tag JSP:
  • Una volti inclusi nelle pg Java Bean possono essere invocati con la modalità di chiamata stnd per i metodi e le var dei prog ad oggetti i Bean sono code-behind risp alla JSP
  • Il programmatore non deve + essere 1 esperto perche sono disponibili molte librerie stnd di tag JSP
  • poiché la logica risiede sul S si possono utilizzare thin clientgli accessi al DB sono S side
  • I Bean rispondono ad un problema di JSP: la manutenzione del cod java all’interno dei file HTML è complessa perché non è chiaramente suddiviso dal resto del testo Con le componenti Java bean il codice Java è autonomo in modo da essere facilmente identificabile.

Enterprise Java Bean

Particolari classi java con lo scopo di facilitare le transazioni

  • Sono eseguiti da 1 EJBcontainer che provvede ai servizi di base (sicurezza e gestioni transazioni) installato all’interno di un application server Java eneterprise edition
  • Un application server è in gen un sw che fornisce l’infrastruttura e le fx di supporto di applicazioni S in un contesto distribuito complesso di servizi orientati alle realizz di applicazioni web
  • Servizi inseriti nel sw in modo modulare come componenti realizzat secondo stnd (es:http)
  • Gli enterprise bean sono portabili: è possibile generare nuove applicazioni da quelle esistenti
  • Condizioni di utilizzo:
  1. applicazione deve essere scalabile: esigenza di distribuire le componentiubicazione degli EB trasparente ai C
  2. transazioni che assicurano l’integrità dei datimeccanismi per trattare accessi contemporanei
  3. accessibilità da C diversiEB consentono C leggeri