Tecnologie server side per il web, Schemi riassuntivi di Sistemi Informatici. Università degli Studi di Roma Tor Vergata
ElenaP
ElenaP

Tecnologie server side per il web, Schemi riassuntivi di Sistemi Informatici. Università degli Studi di Roma Tor Vergata

12 pagine
3Numero di download
1000+Numero di visite
Descrizione
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 bu...
20 punti
Punti download necessari per scaricare
questo documento
Scarica il documento
Anteprima3 pagine / 12
Questa è solo un'anteprima
3 pagine mostrate su 12 totali
Scarica il documento
Questa è solo un'anteprima
3 pagine mostrate su 12 totali
Scarica il documento
Questa è solo un'anteprima
3 pagine mostrate su 12 totali
Scarica il documento
Questa è solo un'anteprima
3 pagine mostrate su 12 totali
Scarica il documento

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

- la CGI attiva lo script che elabora le info dialogando con il DB

- la CGI inoltra la risposta ala S - il S invia la risposta al C

PERL PERL ( processing estraction report language) è un linguaggio interpretato attraverso cui si definiscono i CGIscript. Ogni script quando svolge le sue elaborazioni produce un ulteriore file HTML (arancio) che rappresenta la pagina che si visualizzerà all’ut: -messaggio statico: “hello!” .messaggio dinamico: contiene variabili

Modalità di comunicazione a) Invio dati dal browser: GET e POST Il B invia dati al S in formato HTML attraverso 2 mod:

1. GET: aggiunge coppie di info (nome,valore) direttamente nell’URL, dp il carattere ?

2. POST: invia i dati in uno stream separato e qst permette di risolvere delle limitazioni del GET:

a. Problemi di dim pei parametri b. Problemi di riservatezza dei parametri

GET POST Non generale: limitazione nella lunghezza URL (1024 caratt) Generale: non limitazioni numero caratteri

I parametri passati sono evidenti ( in chiaro sulla linea di

comando)

I parametri sono letti tramite stnd input e non da linea di

comando

b) Comunicazione web-S & scriptCGI • avviene attraverso variabili d’ambiente contenuti in una tabella %ENV richiamate con:

• esempi di variabili sono:

- PATH: percorso di u doc - http_ACCEPT: descrive i tipi mime accettati dal cl - REMOTE_ADDR: indirizzi IP del visitatore - REQUEST_METHOD: GEToPOST - QUERY_STRING: contiene la stringa passata al B con i param ut inseriti nel form

Con questa espressione comunico al S che i dati rel a nome+età+città+occupazione  “&” separatore; “+” spazi; “%” modifica caratteri

Problemi script Prima tecnologia disponibile per realizzazione di applicazioni web (pg dinamiche)  scopo orig solo def di 1 metodo stnd per far comunic S con fonti esterne

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)

Modello di funzionamento 1 -C inoltra le rich che include la nec di un’applic java -Il S la riceve e la inoltra al servelt conteiner -questo dialoga con l’applica java -L’applic vede la nec di operare sui dati e interroga il DB - svolta l’elab la risposta HTML generata è passata alla servlet - questa è inoltrata al web S -il webS consegna il messaggio al C

Modello di funzionamento 2 1. C invia 1 rich http al S 2. il S la converte in 1 oggetto

HTTPservletRequest 3. qst viene consegnato alla servlet 4. la servlet può interagire con un Java

Bean o con DB 5. genera una HTTPServerResponse 6. il S converte qst in 1 risp http per il C

Ciclo di vita

1. inizialization: il container carica la servlet per la prima volta

2. service: caricata in memoria la servlet genera la rispostafunzionamento vero: dati parametri in input (HTTPservletRequest) il codice Java redige un HTML per il B (HTTPservletResponse)

3. destruction: giunta alla fine della vita utile viene rimossa

Vantaggi Java servlet 1. migliori prestazioni:

a. le servlet vengono caricate al momento della prima richiesta e rimangono residenti in memoria pronte per servire altre rich , finché non vengono chiusein questo modo le rich successive vengono evase molto più rapidamente

b. le risorse server sono meno saturate in quanto diminuisce in numero di processi attivi 1 stessa servlet può gestire contemp le rich di più ut

2. standardizzazione del linguaggio a. le servlet sono scritte i linguaggio java  linguaggio stnd b. le servlet possono quindi interagire con altri oggetti java distribuiti, usando le fx RMI

(remote method invocation)  interoperabilità e scalabilità 3. requisito di portabilità: essendo scritte in Java non esistono problemi di portabilità tra diversi

sistemi operativi _ una servlet sviluppata per Apache può essere usata anche su Miscosoft IIS 4. mantenimento sessione ut: attraverso l’esecuzione di caching di operazioni gia eseguite si facilita la

memo di dati ut 5. sicurezza: esecuzione su una JVM 6. gestione on thread separati nello st proc o da thread a + proc ma su S diversi. Interazione + stretta

con il S e quindi > sfruttamento delle potenzialità, attraverso una comunicazione bidirezionale

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

compito sviluppatore + semplice perché non dv + curare la parte statica (=grafica)focus su contenuti

Efficienza JSP 1. la prima volta che si effettua la rich di visualizzazione del file JSP questo viene compilato creando 1

oggetto servlet che sarà archiviato in memoria per servire le rich successive  non dovendo più ricompilare il codice la seconda volta si risparmia Cp elab

2. eseguito la servlet il l’output è inviato al B che potrà interpretarlo come fosse una semplice pg HTML

3. ad ogni rich successiva il B controlla se sulla pg JSP è stata effettuata qlc modifica -SI: esegue nuovamente la compilazione e memorizza il nuovo servlet -NO: richiama il servlet già compilato

ASP Active Server Pages • tecnologia analoga a JSP sviluppata da microsoft • Ambiente di scripting server side basata su VBScript che processa script che vengono incorporati nelle pg HTML ( vengono poi eseguiti sul S) • permette di:

1. usare diversi linguaggi per inserire istruzioni nella pg HTML ( stnd: VBScript) 2. creare pg con contenuti dinamici 3. accedere a componenti ActiveX

• è u file testuale (asp) che contiene: a. testo b. TAG HTML c. Comandi script

• ASP è stato progettato per la generazione di piccole parti di contenuto dinamico demandando alla libreria COM lo svolgimento di operazioni + avanzate è una soluzione proprietaria di Microsoft e quindi presenta probl di diffusione (solo S microsoft)

Delimitatori e tag • I comandi e le espressioni di output degli script ASO sono differenziati sia dal testo che dai TAG HTML dai delimitatori <%------%>. • Si usano gli stessi comandi anche per racchiudere le espressioni di output, che generano l’HTML dinamico da inserire nelle pg

• Per usare latri ling di scripting 8 supportati dallo scripting engine) diversi da VBScript si dv usare i tag<SCRIPT> </SCRIPT> + gli attributi LAGUAGE e RUNAT

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”

11

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

12

Application server • 1 application server comprende:

1. contenitore di componenti server side (servlet o ling di scripting) 2. modulo per la gestione degli accessi e della sicurezza 3. modulo per l’accesso al DB 4. mod per gestire le transazioni 5. interfaccia per accedere ai sistemi legacy 6. componenti per massimizzare le prestazioni (sist di caching o bilanciatori di carico)

A).NET e Java EE 2 application S alt: 1. java 2 platform edition: server realizzato

da Sun costituito da moduli interamente realizzati in Java

2. microsoft.NET: realizzato da Micosoft come evoluzione di COM (component obj model) involucro degli oggetti COM per rendere possibile l’accesso alle fx dello strato interno

Benefici application S • semplificazione delle attività di sviluppo: possibilità di usare gli strumenti di sviluppo più diffusi sul mkt • supporto di diversi linguaggi: in fx del S scelto si può usare il ling di programmazione voluto • riuso del codice: la logica applicativa può essere riusata e condivisa (logica di program ad oggetti) • gestione delle transazioni: gest delle trans con DB tc siano sicure ed affidabili • scalabilità: supporto per la distribuzione di componenti in rete • alte prestazioni: multithreading, bilanciamento dinamico, caching • estensibilità: grazie all’aqc di moduli applicativi aggiuntivi • robustezza: logica applicativa modificabile senza interruzioni nell’erogazione dei servizi • sicurezza: fx spec di sicurezza end2end

non sono stati rilasciati commenti
Questa è solo un'anteprima
3 pagine mostrate su 12 totali
Scarica il documento