Architectures for Distributed Computing Chapter 5
annuncio pubblicitario
Architectures for Distributed Computing Chapter 5 Piergiorgio Cremonese Silvia Giordano Netikos SUPSI Netikos Pisa - Italy [email protected] http://www.netikos.com © SUPSI-DTI Silvia Giordano CH-6928 Manno [email protected] http://www.supsi.ch Architecture 1 10/06/2004 Contents Network Applications Architecture J2EE Summary Laboratory: Network Applications Architecture © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 2 1 Overview Concept of tiers The ancestors of the client/server architectures The current three tiers architecture Multi-tiers architectures practical example © SUPSI-DTI Silvia Giordano Architecture 3 10/06/2004 Chapter goals: Use the modern view of current applications Understand the main features of evolving applications and their related models © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 4 2 Introduction client server model behind distributed applications and how this model was born and is evolving: View with tiers One tier architecture Two tiers architecture Three tiers architecture Multi-tiers architecture © SUPSI-DTI Silvia Giordano Architecture 5 10/06/2004 Tiers One application is running on a single computer Two tier tiers application is running on two computers Three tiers add a middle layer n-tiers © SUPSI-DTI unlimited number of programs to run simultaneously Silvia Giordano 10/06/2004 Architecture 6 3 Overview Concept of tiers The ancestors of the client/server architectures The current three tiers architecture Multi-tiers architectures practical example © SUPSI-DTI Silvia Giordano Architecture 7 10/06/2004 The ancestors Mainframe architecture centralized intelligence Users with simple terminals File-sharing © SUPSI-DTI architecture server downloads files from the shared location to the desktop environment. user jobs run (including logic and data) in the desktop environment for low usage Silvia Giordano 10/06/2004 Architecture 8 4 Client/Server model Client/server paradigm ❒ standard ❒ proprietary Client must contact server ❒ server process must first be running ❒ server must have created socket (door) that welcomes client’s contact Client contacts server by: ❒ creating client-local socket ❒ specifying IP address, port number of server process © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 9 Main components of C/S model A presentation component: A business component: A perform some type of data manipulation. data access component: © SUPSI-DTI presents information to an external source and obtains input from that source. interfaces either with a data storage system such as database systems or hierarchical file systems, or with some other type of external data source as a data feed or an external application system. Silvia Giordano 10/06/2004 Architecture 10 5 One Tier Architecture Pros: easier management easier control more secure Cons: © SUPSI-DTI scalability portability lack of flexibility Silvia Giordano 10/06/2004 Architecture 11 Two Tier Architecture typical client/server architecture pros © SUPSI-DTI faster development and deployment of applications hardware-independent database systems small servers fat client (Javaapplets) Silvia Giordano 10/06/2004 Architecture 12 6 cons © SUPSI-DTI Two Tier Architecture worst security, reliability, scalability, and control effective for simple applications client application must enforce its own security process each database must also enforce its own security process scalability Silvia Giordano 10/06/2004 Architecture 13 From Two To Three Tier Architecture third (middle) tier server between client and server effective distributed client/server design with hidden complexity flexibility, maintainability, reusability: provides separate process management scalability: can handle large number-of-users functions : queuing, application execution, and database staging © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 14 7 Overview Concept of tiers The ancestors of the client/server architectures The current three tiers architecture Multi-tiers architectures practical example © SUPSI-DTI Silvia Giordano Architecture 15 10/06/2004 Three Tier Architecture Client/server © SUPSI-DTI model sub-divided into: the data layer the logic layer, or middle-tier (difference with 2-tiers) the presentation layer, or client Silvia Giordano 10/06/2004 Architecture 16 8 Three Tier Architecture fat clients are splitted into two pieces : a thin client the application logic, running on a server easy deployment of simple clients logic is centralized © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 17 Different Three Tier Architecture Three tier with TP monitor technology Three tier with message server Three tier with an application server Three tier with an ORB architecture Distributed/collaborative enterprise architecture © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 18 9 Three tier with TP monitor technology Transaction Processing (TP) monitor (middle tier) message queuing, transaction scheduling, and prioritization service client connects to the TP monitor the transaction is handled by TP monitor (client is not blocked) effective for scalability © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 19 Three tier with message server intelligent messages messages = headers (with priority information), address number and identification number prioritized and processed asynchronously good solutions for wireless infrastructures © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 20 10 Three tier with an application server main body of an application server to run on a shared host smaller client © SUPSI-DTI more secure more scalable Silvia Giordano 10/06/2004 Architecture 21 Three tier with an ORB architecture support distributed objects two prominent distributed object technologies: © SUPSI-DTI Common Object Request Broker Architecture (CORBA) COM/DCOM Silvia Giordano 10/06/2004 Architecture 22 11 Distributed/collaborative enterprise architecture based on Object Request Broker enhanced by using shared, reusable business models (not just objects) on an enterprise-wide scale enterprise is a system comprised of multiple business systems or subsystems improve effectiveness organizationally, operationally, and technologically © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 23 Three Tiers Architecture advantages pros of both one-tiered approach and the two-tiered approach flexible architecture Object reuse Easier system maintenance More effective use of data and networks Higher developer productivity through specialization new perspectives of computational work in methodological and also in production views: multi-tiers © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 24 12 Comparison of Tiers Architectures Architecture One tier Two tiers Three tiers N tiers © SUPSI-DTI Silvia Giordano Pros Simple Very high performance Self-contained Clean, modular design Less network traffic Secure algorithms Can separate UI from business logic Can separate UI, logic, and storage Reliable, replicable data Concurrent data access via transactions Efficient data access Support multiple applications more easily Common protocol/API Cons No networking -- can't access remote services Potential for spaghetti code Must design/implement protocol Must design/implement reliable data storage Need to buy database product Need to hire DBA Need to learn new language (SQL) Object-relational mapping is difficult Quite inefficient Must learn API (CORBA, RMI, etc.) Expensive products More complex; thus, more potential for bugs Harder to balance loads Architecture 25 10/06/2004 Overview Concept of tiers The ancestors of the client/server architectures The current three tiers architecture Multi-tiers architectures practical example © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 26 13 Applicazioni multi-tier: distribuzione delle risorse Il concetto di base delle applicazioni multi-tier è la distribuzione delle risorse (interfaccia, computazioni, dati) fra varie macchine Ogni tier accumuna componenti software uniformi Esempio tipico: applicazioni client-server (2tier: uno è il client, l’altro il server) © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 27 Applicazioni multi-tier Le applicazioni 2-tier erano le più diffuse nel passato Oggi la tendenza è di usare applicazioni 3-tier o 4-tier: © SUPSI-DTI Interfaccia utente, sul client [protocollo standard, per esempio via web] Logica di business, sul server Dati di impresa, su un DBMS Silvia Giordano 10/06/2004 Architecture 28 14 Applicazioni multi-tier Macchina dell’utente finale (client) Interfaccia utente Gestore protocollo } Server di applicazioni Logica di business Dati © SUPSI-DTI Silvia Giordano Server dati Architecture 29 10/06/2004 Applicazioni multi-tier Interfaccia utente Gestore protocollo Logica di business Dati © SUPSI-DTI Silvia Giordano 10/06/2004 Thin client: GUI basata su FORM HTML Applet: GUI fornita da un’applet scaricata via web Rich/thick client: GUI fornita da un’applicazione stand-alone, che però comunica tramite il protocollo dato con il server Batch/Poor client: interfaccia a linea di comando, fornita da un’applicazione stand-alone come sopra Architecture 30 15 Applicazioni multi-tier Interfaccia utente Gestore protocollo Logica di business Dati © SUPSI-DTI Silvia Giordano Web-based: le comunicazioni con la UI sono trasportate come pacchetti HTTP (GET/POST/PUT) XML-based: le comunicazioni con la UI sono trasportate come messaggi SOAP Custom: le comunicazioni con la UI sono trasportate secondo un protocollo privato (via socket) Altro: (CORBA, protocolli specifici di un dominio) Architecture 31 10/06/2004 Applicazioni multi-tier Interfaccia utente Gestore protocollo Logica di business Dati © SUPSI-DTI Silvia Giordano 10/06/2004 Applicazione all-in-one: server tradizionale Applicazione basata su Enterprise beans: entity beans, session beans, ecc. Applicazione basata su Web components: servlet, JSP Applicazione basata su Web services: componenti JAX-RPC Architecture 32 16 Applicazioni multi-tier Interfaccia utente Un Gestore protocollo Un Logica di business qualunque DBMS relazionale Per cui sia disponibile un driver JDBC DB specializzato DB orientato agli oggetti DB semistrutturato … Un legacy system con funzione di data warehouse Dati © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 33 Applicazioni multi-tier via web Usare come protocollo di comunicazione la tecnologia web presenta molti vantaggi pratici © SUPSI-DTI È possibile realizzare applicazioni accessibili con un semplice browser I task di formattazione vengono lasciati al linguaggio di markup (HTML+CSS, WML, ecc.) Rimane possibile creare rich client, fornendo così vari livelli di interazione per gli stessi servizi Silvia Giordano 10/06/2004 Architecture 34 17 Applicazioni multi-tier via web © SUPSI-DTI Silvia Giordano Architecture 35 10/06/2004 Applicazioni multi-tier via web Interfaccia utente tecnologie più comunemente usate per applicazioni multi-tier via web con J2EE: Gestore protocollo Logica di business Dati © SUPSI-DTI Silvia Giordano 10/06/2004 Interfaccia utente basata su web Tomcat o application server analoghi come gestore di protocollo Logica di business basata su Servlet o JSP Dati accessibili tramite JDBC L’uso di tecnologie basata su Java e/o open source ci garantisce la durata dell’investimento Architecture 36 18 Overview Concept of tiers The ancestors of the client/server architectures The current three tiers architecture Multi-tiers architectures practical example © SUPSI-DTI Silvia Giordano Architecture 37 10/06/2004 Esempio1: Forum via servlet Directory Dati Utente Web Server Applet Servlet Browser DBMS JDBC Dati magazzino © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 38 19 Esempio1: Forum via cgi Directory Dati Utente Web Server javascript CGI Browser DBMS ODBC/DBI Dati magazzino © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 39 Esempio2 H2S: Un sistema proprietario da HTTP a SMS © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 40 20 Physical Architecture Silvia Giordano M © SUPSI-DTI S /G IN S2 ET N R TE TS PO S1 Architecture 41 10/06/2004 Logical Architecture WEB httpd HTTP AS H2Sd checker listener H2S client SMS gateway smsq smss H2S receiver SMS Browser SMS IP © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 42 21 Esempio2: H2S via servlet Web HTTP browser jk Controller Jsp Servlet DS LDAP smsq smsSender H2SServer © SUPSI-DTI Silvia Giordano H2S H2S Client DB JDBC Application Server Architecture 43 10/06/2004 Esempio2: H2S via CGI HTTP Web browser cgi CGI application smsq H2S smsSender H2SServer © SUPSI-DTI Silvia Giordano 10/06/2004 H2S Client DS LDAP DB JDBC Application Server Architecture 44 22 Architecture CGI DB http Web cgi CGI browser smsq H2S smsSender H2SServer © SUPSI-DTI Silvia Giordano H2SClient Architecture 45 10/06/2004 Components Role Web Access Functionality UnSafe Document Repository (imgs,..) Application Server Dynamic Presentation Check Controls Business Logic Security Data Access Functionality © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 46 23 Application Server Controller Manages requests coming from the access point (e.g. Web) JSP © SUPSI-DTI Presentation Layer: it is implemented as an exetension of HttpServlet: compiled at RunTime Silvia Giordano 10/06/2004 Architecture 47 Application Server Servlet Action Actions triggered by events: used for logic and presentation PreCompiled Classes © SUPSI-DTI Implement Business Logic PreCompiled Silvia Giordano 10/06/2004 Architecture 48 24 Applet & Servlet Le servlet sono per certi versi analoghe alle applet Le servlet stanno a un application server come le applet stanno a un browser In entrambi i casi, un contenitore estende le proprie capacità caricando componenti esterni: si tratta quindi di plug-in Le applet risiedono normalmente © SUPSI-DTI Sul server, da cui vengono recuperate via HTTP Nella cache locale del browser Le servlet risiedono normalmente sul server, in un’area nota all’application server Silvia Giordano Architecture 49 10/06/2004 Applet & Servlet Le © SUPSI-DTI applet si usano spesso senza servlet applet che non necessitano di processing server-side: ricevono un po’ di parametri all’avvio, e si limitano a mostrarli in altri casi, le applet si collegano a un server (non servlet) scritto in Java o altri linguaggi, e usano un protocollo privato volendo, le applet possono comunicare con il server via HTTP (simulano una FORM) Silvia Giordano 10/06/2004 Architecture 50 25 Applet & Servlet Le © SUPSI-DTI servlet si usano spesso senza applet spesso processano input proveniente da FORM tradizionali in altri casi, i dati possono essere generati da una pagina con Javascript, memorizzati in campi hidden di una FORM “invisibile” e inviati al servlet è anche possibile che un servlet processi input proveniente da altre sorgenti Silvia Giordano Architecture 51 10/06/2004 Applet & Servlet Applet e servlet si possono anche usare insieme (come nel nostro esempio) È © SUPSI-DTI l’applet raccoglie e pre-elabora i dati, offrendo una bella GUI all’utente quando i dati sono pronti, li manda al server via HTTP il server li passa alla servlet per l’elaborazione server-side però un uso poco comune Silvia Giordano 10/06/2004 Architecture 52 26 Differenza fra Servlet e CGI Gli script CGI vengono eseguiti dal S.O., quindi sono potenzialmente meno portabili Le Servlet vengono eseguite dalla JVM integrata nell’application server, quindi sono “isolate” dal S.O. e dunque più portabili © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 53 Differenza fra Servlet e CGI Gli script CGI vengono caricati ed eseguiti una volta per ogni richiesta – quindi, il costo di avvio (latenza) è alto Le Servlet vengono caricate solo una volta; poi si crea un Thread (di Java) per ogni richiesta – operazione meno costosa, e dunque si ha una latenza più bassa © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 54 27 Differenza fra Servlet e CGI Gli script CGI possono essere scritti in qualunque linguaggio: potete scegliere il linguaggio più adatto al particolare scopo Le Servlet devono essere scritte necessariamente in Java: spesso va bene, ma a volte non è conveniente © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 55 Differenza fra Servlet e CGI Il protocollo CGI è supportato da tutti i Web server (anche se a volte con qualche piccola differenza) Le Servlet sono supportate solo da alcuni Web server (quelli che fungono da application server) c’è comunque una buona scelta di prodotti commerciali È sempre possibile affiancare un application server a un web server, anche su due porte diverse sulla stessa macchina fisica © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 56 28 Server che supportano le Servlet Versione Servlet supportata Versione JSP supportata Apache & Sun – Tomcat 2.4 2.0 Apache + Jserv 2.0 1.0 Borland AppServer 2.3 1.2 IBM WebSphere Application Server 2.4 2.0 2.2 1.1 2.4 2.0 Prodotto IONA iPortal Application Server (ora migrati su Jboss) javaSystem Application Server 8 ... e parecchi altri … © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 57 Struttura delle Servlet Le Servlet sono classi Java che implementano l’interfaccia javax.servlet.Servlet Una classe può implementare Servlet direttamente Ma più comunemente estende HttpServlet © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 58 29 Dialogo con le Servlet Il dialogo fra Servlet e il browser è di tipo client/server client → server interfaccia ServletRequest server © SUPSI-DTI Silvia Giordano → client interfaccia ServletResponse Architecture 59 10/06/2004 Metodi di Servlet Metodo Descrizione init() Inizializza la servlet (e alloca risorse) service() Serve una richiesta destroy() Elimina la servlet (e libera le risorse) getServletInfo() Restituisce informazioni sulla servlet (una stringa) getServletConfig() Restituisce la configurazione della servlet © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 60 30 Ciclo di vita di una Servlet Al primo caricamento viene chiamato init() Per ogni richiesta, viene chiamato il metodo service() Alla fine, viene chiamato destroy() © SUPSI-DTI es: quando il container termina Silvia Giordano 10/06/2004 Architecture 61 Servlet e HttpServlet L’interfaccia delle Servlet è piuttosto generica… GenericServlet la implementa e la estende con metodi di utilità Gestione parametri, gestione contesto, file di log La classe di sistema HttpServlet specializza GenericServlet per il protocollo HTTP © SUPSI-DTI ci sono HttpServletRequest e HttpServletResponse associate Silvia Giordano 10/06/2004 Architecture 62 31 Un esempio (una HttpServlet) public class SimpleServlet extends HttpServlet { public void doGet(HttpServletRequest richiesta, HttpServletResponse risposta) throws ServletException, IOException { String titolo = “Risposta dalla mia Servlet"; risposta.setContentType("text/html"); PrintWriter out = risposta.getWriter(); out.println("<HTML><HEAD><TITLE>"); out.println(titolo); out.println("</TITLE></HEAD><BODY>"); out.println("<H1>" + titolo + "</H1>"); out.println("<P>... resto della pagina ..."); out.println("</BODY></HTML>"); out.close(); } © SUPSI-DTI Silvia Giordano 10/06/2004 } Architecture 63 Gestione della persistenza È importante ricordare che ogni singola richiesta HTTP viene trattata separatamente da tutte le altre © SUPSI-DTI come fa una povera servlet a gestire sessioni che comprendono più di una richiesta? come fanno più servlet che costituiscono una sola applicazione a passarsi dati e comunicare fra di loro? Silvia Giordano 10/06/2004 Architecture 64 32 Gestione della persistenza Abbiamo sostanzialmente due vie Gestire manualmente la persistenza Adatto quando i dati da rendere persistenti sono pochi o poco strutturati Bastano in genere poche righe di codice Affidarci agli Scope Object offerti dal framework Adatto per usi sofisticati Consente vari livelli di persistenza © SUPSI-DTI Silvia Giordano Architecture 65 10/06/2004 Gestione manuale della persistenza Usando © SUPSI-DTI i cookie la servlet scrive i dati che vuole rendere persistenti tramite i cookie successive richieste – alla stessa servlet o a servlet diverse – si porteranno dietro i cookie scritti nel client Silvia Giordano 10/06/2004 Usando sessionID la servlet associa un identificatore unico ad ogni sessione il sessionID viene usato come chiave per accedere a un DB sul server successive richieste accedono al DB con la stessa chiave Architecture 66 33 Gestione dei cookie – scrittura Si crea un cookie con 1. cookie = new Cookie(nome,valore); Si impostano gli attributi del cookie 2. cookie.setComment(...); cookie.setDomain(...); cookie.setMaxAge(...); ...eccetera Si invia il cookie con la risposta 3. risposta.addCookie(cookie); © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 67 Gestione dei cookie – lettura 1. Si recuperano i cookie dalla richiesta k = rich.getCookies(); 2. Si cerca il “nostro” cookie for (i=0; i<k.length; i++) if (k[i].getName().equals(“nostro”)) { nostro=k[i]; break; } 3. Si estrae il valore memorizzato nel cookie (se lo abbiamo trovato) valore=nostro.getValue(); © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 68 34 Gestione del session ID 1. Si estrae la sessione dalla richiesta, creandola se necessario (primo accesso): HttpSession sess= richiesta.getSession(true); 2. Si memorizzano/leggono i dati: a. b. © SUPSI-DTI da un DB, usando sess.getID() come chiave dalla sessione stessa, usando sess.putAttribute(chiave,valore) e sess.getAttribute(chiave) Silvia Giordano Architecture 69 10/06/2004 Gli Scope Objects Ciascun componente web (servlet o pagine JSP, che vedremo più avanti) può accedere a 4 Scope Objects: ServletContext – il container HttpSession – la sessione corrente HttpServletRequest – la richiesta corrente JspContext – la pagina corrente (per JSP) Ogni Scope Object fornisce metodi putAttribute() e getAttribute() per memorizzare a recuperare oggetti arbitrari associati a chiavi alfanumeriche © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 70 35 ServletContext ServletContext rappresenta il container che sta eseguendo la Servlet corrente (e, di solito, tutte le altre) Il ServletContext è unico all’interno della JVM Alcuni container offrono varie configurazioni: Una sola JVM per tutte le servlet: ServletContext è globale, come pure i dati memorizzati in esso Più JVM, ciascuna delle quali esegue più servlet: ci sono più ServletContext; per avere un contesto globale occorre usare un DB esterno © SUPSI-DTI Silvia Giordano Architecture 71 10/06/2004 ServletContext Per ottenere il ServletContext, basta chiamare il metodo della servlet getServletContext() Da tenere a mente: il ServletContext è condiviso; più servlet in esecuzione allo stesso tempo potrebbero accedere concorrentemente ai dati… Soluzione: usare i costrutti Java per la mutua esclusione (synchronized) © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 72 36 HttpSession Una sessione può persistere per un periodo di tempo specificato, e coprire più richieste HTTP (e anche più visite distinte) Solitamente, una sessione è associata a un singolo utente dell’applicazione web Il framework si occupa della persistenza della sessione Usando cookie se il browser li supporta Tramite URL rewriting altrimenti © SUPSI-DTI Silvia Giordano Architecture 73 10/06/2004 HttpSession Per ottenere l’HttpSession, basta chiamare il metodo getSession() della richiesta (come già visto) Anche l’HttpSession potrebbe essere usato concorrentemente, se abbiamo Servlet che fanno partire nuovi Thread Se si usa URL rewriting, bisogna avere cura di chiamare encodeURL() su ogni URL che viene inclusa nella risposta! © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 74 37 Notifiche Argomenti avanzati Molte operazioni sulle o delle servlet generano eventi (modello publish/subscribe) Caricamento Creazione e scaricamento di una servlet o associazione di una sessione ecc. © SUPSI-DTI Altre componenti web possono registrare il loro interesse ad essere notificate quando l’evento x si verifica, implementando l’interfaccia xListener Uso molto raro… Silvia Giordano Architecture 75 10/06/2004 Argomenti avanzati Re-routing, inclusione e filtri È possibile alterare il cammino “naturale” di richieste e risposte Re-routing: le richieste possono essere inoltrate da una servlet a un’altra (o a un CGI!) Inclusione: la risposta di una servlet (o CGI) può essere inclusa in quella di un’altra Filtri: la richiesta o risposta può passare attraverso uno o più post-processori, che la possono modificare © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 76 38 Caratteristiche delle Servlet Velocità Portabilità molto veloci, il codice è compilato, e una volta caricato viene tenuto in memoria dal server – bassa latenza e alta banda ottima – Java è sempre lo stesso ovunque Fattori temporali © SUPSI-DTI provare una Servlet richiede (i) modificare il codice (ii) compilare il codice (iii) riconfigurare il web server: non è adatto alla prototipazione rapida Silvia Giordano 10/06/2004 Architecture 77 Caratteristiche delle Servlet Competenze con poche aggiunte, basta conoscere Java Per servlet complesse, occorre conoscere Java bene… Supporto © SUPSI-DTI il supporto da parte di terzi è ancora un po’ limitato (ma in crescita: si aspetta che diventi standard in Apache) la tecnologia è portabile, ma al momento dipende molto da Sun/IBM/Borland/Oracle Ci sono ambienti di sviluppo molto belli e completi (inclusi Eclipse e IBM WebSphere Studio) Silvia Giordano 10/06/2004 Architecture 78 39 Deployment Punto dolente! Ogni server ha modalità proprie per la configurazione Esistono però formati standard di deployment © SUPSI-DTI Silvia Giordano Sono parte delle specifiche J2EE Architecture 79 10/06/2004 Confronto fra CGI, Perl e Servlet Caratteristica CGI mod_perl Servlet Portabile fra web server si no (solo Apache) si (limitata) Portabile fra S.O. si (con poche varianti) parziale si Un processo per ogni richiesta si no no Perdite di memoria (leak) no si no (in teoria) Linguaggio C, Perl, sh, ecc. Perl Java Tipi stretti no no si Persistenza no (va fatta a mano) no (va fatta a mano) si Persistenza verso DB no (va fatta a mano) si si Portabilità fra DB no (ad hoc) no (ad hoc) si (via JDBC) Controllo dei diritti no (solo via S.O.) no (solo via S.O.) si (diritti Java) Supporto da IDE no no si (es.: WebSphere) © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 80 40 JavaServer Pages – JSP Le pagine JSP sono normali documenti testuali Contentono un mix di markup standard (es., HTML) e di istruzioni speciali Concettualmente simili alle pagine ASP (ma più potenti e portabili) © SUPSI-DTI Silvia Giordano Architecture 81 10/06/2004 JSP e Servlet Le Servlet funzionano bene per pagine con tanto contenuto e poca “grafica” Però tutta la pagine deve essere generata in Java... ...bisogna mettere mano al codice Java anche solo per cambiare il colore di sfondo! JSP (come ASP) immerge codice (Java) in pagine HTML © SUPSI-DTI separazione fra presentazione e logica Silvia Giordano 10/06/2004 Architecture 82 41 Esempio: una pagina JSP <HTML> <%@ page language=“java” import=“it.netikos.JSP” %> <H1>Benvenuto!</H1> Oggi è <jsp:useBean id=“calendario” class=“JSPCalendar” /> <UL> <LI>giorno: <%= calendario.getDayOfMonth() %> <LI>mese: <%= calendario.getMonth() %> <LI>anno: <%= calendario.getYear() %> </UL> <% if (calendario.get(Calendar.AM_PM)==Calendar.AM) { %> buon giorno! <% } else { %> buona seeeeeraaaaa... <% } %> </HTML> © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 83 Elementi di una pagina JSP Una pagina JSP può contenere cinque tipi di elementi: 1. 2. 3. 4. 5. © SUPSI-DTI direttive JSP, fra <%@ e %> azioni JSP, fra <jsp: e /> (ma vedremo più avanti una versione estesa) espressioni, fra <%= e %> scriptlet, ovvero codice fra <% e %> parti fisse, tutto il resto Silvia Giordano 10/06/2004 Architecture 84 42 Direttive JSP Ci © SUPSI-DTI sono tre tipi di direttive: di pagina (linguaggio, dimensioni buffer, trattamento errori, ecc.) include (per inserire altri file dentro la pagina) taglib (estensioni del linguaggio JSP) Silvia Giordano Architecture 85 10/06/2004 Azioni JSP (istanzia un bean e gli assegna un nome) jsp:setProperty (assegna un valore a una proprietà di un bean) jsp:getProperty (legge il valore di una proprietà, lo converte in stringa, e lo manda in output) ... e alcune altre jsp:useBean © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 86 43 Espressioni fra <%= e %> viene valutata Il valore ottenuto viene converito in stringa La stringa viene sostituita al posto di <%= ... %> L’espressione © SUPSI-DTI Silvia Giordano Architecture 87 10/06/2004 Scriptlet Il codice fra <% e %> viene eseguito L’immersione può anche essere parziale, come nel nostro esempio precedente: <% if (calendario.get(Calendar.AM_PM)==Calendar.AM) { %> buon giorno! <% } else { %> buona seeeeeraaaaa... <% } %> © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 88 44 Trattamento delle pagine JSP Ma, esattamente, cosa accade quando un web server deve trattare una pagina JSP? Quali caratteristiche derivano alle JSP da questo trattamento? © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 89 Trattamento delle pagine JSP La prima volta che al server viene richiesta una certa pagina JSP, oppure se la pagina è stata modificata rispetto all’ultimo accesso precedente, la pagina viene compilata e diventa una Servlet (.java) La Servlet viene a sua volta compilata e produce un file eseguibile (.class) Il codice del .class viene caricato nel server, viene eseguito, e tenuto pronto per eventuali altre richieste successive © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 90 45 Trattamento delle pagine JSP Container p.class Java compiler client client client p.java JSP compiler p.jsp p.jsp © SUPSI-DTI Silvia Giordano Spazio web 10/06/2004 Architecture 91 Caratteristiche di JSP Ereditano tutte le buone caratteristiche delle Servlet In più, rendono facile fare modifiche: © SUPSI-DTI la compilazione è automatica – si può fare prototipazione rapida se si vuole modificare l’aspetto delle pagine HTML, non c’è bisogno di toccare il codice – il livello di competenze richiesto è più basso Silvia Giordano 10/06/2004 Architecture 92 46 Uso tipico di JSP Il merito principale delle JSP è di separare la presentazione (parte HTML) dalla logica applicativa (parte codice) Per sfruttare al meglio questa separazione, è bene ridurre al minimo le scriptlet <% … %>, e spostare tutta la logica all’interno di JavaBean appropriati Implementazione in stile MVC (Model-ViewController) © SUPSI-DTI Silvia Giordano Architecture 93 10/06/2004 Uso tipico di JSP L’architettura MVC prevede un modello astratto della realtà che si vuole modellare (M) Separatamente, uno strato di software legge lo stato del modello e ne produce una vista (V) Analogamente, uno strato di software detto controller interpreta le azioni dell’utente e le effettua apportando modifiche al modello (C) Nel nostro caso, M è implementato come un insieme di Javabean; pagine JSP fungono da V e C © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 94 47 Uso tipico di JSP Con una chiara separazione fra presentazione e logica applicativa: La pagina JSP può essere creata inizialmente dal programmatore, ma poi migliorata graficamente e mantenuta da un designer HTML Il programmatore può cambiare il comportamento dell’applicazione modificando i bean, senza più toccare la pagina JSP © SUPSI-DTI Silvia Giordano Architecture 95 10/06/2004 H2S Architecture via JSP (1) http Web jk Controller browser Jsp Servlet smsq smsSender H2SServer © SUPSI-DTI Silvia Giordano 10/06/2004 DB jdbc H2S H2SClient Architecture 96 48 H2S Architecture via JSP (2) http Web jk Controller browser Jsp DB smsq jdbc smsSender H2SServer © SUPSI-DTI Silvia Giordano H2SClient H2S Architecture 97 10/06/2004 Components Role Web/Application Server Access Functionality UnSafe Document Repository (imgs,..) Application Server CGI Dynamic Presentation Check Controls Business Logic Security Data Access Functionality © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 98 49 JavaServer Faces JavaServer Faces (JSF) è una tecnologia di interfaccia utente per applicazioni Web, basata sulle tecnologie tipiche di Java (servlet e JSP) In particolare, fornisce una tag library che mette a disposizione molti tag per la costruzione di interfacce grafiche, la validazione dell’input, e il routing degli eventi © SUPSI-DTI Silvia Giordano Architecture 99 10/06/2004 JavaServer Faces I tag JSF vengono tradotti con opportuni elementi di FORM HTML (o, potenzialmente, con altri meccanismi adatti allo scopo) I FORM così generati sono dinamici Componenti GUI possono apparire all’interno di <c:if>, <c:forEach>, ecc. Il framework si occupa del re-rendering e del dispatching © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 100 50 References Java Servlet 2.4 Specification Java Servlet Web site Java Servlet Technology http://java.sun.com/products/servlet/download.html#specs http://java.sun.com/products/servlet Capitolo 11 di E. Armstrong, J. Ball et al., “The J2EE 1.4 Tutorial”, Novembre 2003 M. Hall, J. Brown, “Core Servlets Java and JavaServer Pages, vol 1: Core Technologies”, 2nd edition C. McClanaham, E. Burns, “JavaServer Faces Specification”, v1.0 JavaServer Face Web page http://java.sun.com/products/jsf © SUPSI-DTI Silvia Giordano 10/06/2004 Architecture 101 51
