1 / 103

Java Enterprise Edition

Java Enterprise Edition. Gabriele Tolomei DAIS – Università Ca ’ Foscari Venezia. Programma del Corso. 09/01 – Introduzione 10/01 – Java Servlets 16-17 /01 – JavaServer Pages (JSP) 23-24/01 – Lab: Applicazione “ AffableBean ” 30-31/01 – Enterprise JavaBeans (EJB) + Lab.

melita
Download Presentation

Java Enterprise Edition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Java Enterprise Edition Gabriele Tolomei DAIS – UniversitàCa’ FoscariVenezia

  2. Programma del Corso • 09/01 –Introduzione • 10/01 – Java Servlets • 16-17/01 – JavaServer Pages (JSP) • 23-24/01 – Lab: Applicazione “AffableBean” • 30-31/01 – Enterprise JavaBeans (EJB) + Lab

  3. Modulo 2: Java Servlets • Tecnologie web server-side • Applicazioni client/server su Web (HTTP) • Java Servlets • Ruoloall’internodellapiattaforma Java EE • Esercitazione • Creazione di un progetto web dinamicosu Eclipse

  4. Il Web • Il Web nasce per consentire la condivisione di risorsedistribuitesu hosts collegatitralorotramite Internet • Definisce 2 ruoli: • Client eseguerichieste di accessoallerisorse • Server  memorizza le risorseed evade le richieste verso i clients

  5. Struttura del Web • Si basasulnoto stack di protocolli di rete TCP/IP e su di essodefinisce 3 concettifondamentali: • un sistema per l’identificazioneunivoca di risorsedistribuite(URL) • un protocollo di richiesta/rispostatramite cui le risorsevengonotrasferitetrail client edil server (HTTP) • un linguaggio(HTML) per la rappresentazione di particolaririsorse: pagine Web connessetraloro da hyperlinks (grafo del Web)

  6. URL: Uniform Resource Locator • Ogni URL ècomposto da: • protocollo (ad es.: HTTP, FTP, telnet, etc.) • user/password (opzionali per accedere al server) • indirizzo del server Websottoforma di • IP (ad es.: 157.138.7.88) • Nome (ad es.: www.unive.it) • porta del servizio TCP a cui connettersi (opzionale) • i server Web accettanorichieste di connessionesullaporta 80 (default) • path dellarisorsarichiesta (ad es.: /index.html) • eventualiparametridellarichiesta (opzionali) • utilinelleapplicazioni Web per lo scambio di datitrail browser edil server (ad es., form HTML)

  7. HTTP: HyperText Transfer Protocol • Stabilisce le “regole” con cui client e server comunicano • Definisce un formato “standard” (IETF RFC 2616) deimessaggi di richiesta/risposta • Client: apreconnessione con il server Web specificatonell’URLedinvia ad essounarichiesta HTTP • Server: evade la richiestaedinvia la risposta HTTP sullaconnessioneaperta dal Cliente e la chiude

  8. HTTP: Richiesta Client HTTP Request Request method Request headers Empty line Request body (optional)

  9. HTTP: Metodi di Richiesta • HTTP definisceiseguentimetodi di richiesta: • GET, POST, PUT, DELETE, HEAD • GET e POST sono le piùutilizzate • Eventualiparametridellarichiestapossonoesserespecificati: • nella query string (URL) se siusailmetodo GET http://example.com/sayHello?param1=val1&param2=val2 • nelcorpodellarichiesta se siusailmetodo POST in combinazione con form HTML

  10. HTTP GET (senzaparametri) http://www.example.com/index.html GET /index.html HTTP/1.1 Host: www.example.com Empty line

  11. HTTP GET (con parametri) http://www.example.com/sayHello?param1=val1&param2=val2 GET /sayHello?param1=val1&param2=val2 HTTP/1.1 Host: www.example.com Empty line

  12. HTTP POST http://www.example.com/sayHello POST /sayHello HTTP/1.1 Host: www.example.com Content-Type: application/x-www-form-urlencoded param1=val1&param2=val2 Empty line

  13. HTTP: URL-Encoding • I parametriinviatitramite form HTML nelcorpodellarichiesta HTTP POST devonoessereopportunamentecodificati • Lista di coppie (chiave, valore) • Esempio: name: Jonathan Doe, age: 23, func: a + b == 10%! sonocodificati come name=Jonathan+Doe&age=23&func=a+%2B+b+%3D%3D+10%25%21

  14. HTTP: Risposta Server HTTP Response Response status code Response headers Empty line Response body (optional)

  15. HTTP: Codici di Risposta • 2xx = Successo • 200 OK  la richiesta ha avutosuccesso • GET: l’entitàcorrispondenteallarichiestavieneinviatanellarisposta • POST: l’entitàcorrispondente al risultatodell’azionerichiestavieneinviatanellarisposta • 3xx = Redirezione • 4xx = Errore Client • 401 Bad Request, 404 Not Found, etc. • 5xx = Errore Server • 500 Internal Server Error, 503 Service Unavailable, etc.

  16. HTTP 200 OK HTTP Response HTTP/1.1 200 OK Date:… Server: Apache… Content-Type: text/html; charset=UTF-8 Empty line <html> <head> <title>…</title> </head> <body>…</body> </html>

  17. HTML: HyperText Markup Language • Linguaggio di markup (tag) con cui vengonoscrittiidocumenti Web • Vieneinterpretato e renderizzatodai browsers • Definiscealcuni tag standard • <html>  inizio del file HTML • <body>  inizio del contenuto da renderizzare • <a href=“URL”>  hyperlink ad un’altrarisorsa • <form action=“URL”>  form inviodati al server

  18. HTML: Form • Sonoutilizzati per inviareidati dal client (utentetramite browser) al server Web • All’internocontiene tag specificichedefinisconoiparametri da inviare • <input name=nome type=tipo value=valore> • type puòavereiseguentivalori: • text  campo di testo di 1 riga • password  campo password • hidden  campo nascosto • … • submit  pulsante di invio del form

  19. Java EE: Architettura Multi-tier Java EE Application Server Web Client Legacy Tier Web Tier Connector/Messaging Tier B2B Client Data Tier Business Tier Data Access Tier Client Tier Middle Tier Data Tier

  20. Contenuti web dinamici • Necessari per andareoltre le “solite” pagine web HTML statiche • Unapagina web dinamicavariailpropriocontenutoa secondadeiparametriforniti dal client al momentodellarichiesta • Il sorgente HTML dellapaginavienegenerato dal server web in mododinamico prima di essererestituito al browser e renderizzato • Client-vs. Server-side scripting

  21. Client-side scripting • La dinamicitàriguarda la singolapaginaweb • Cambiamentiin risposta ad azionispecifiche (mouse, tastiera, etc.) • Il contenutodinamicoègenerato da codice in esecuzionesulclient • Principalelinguaggio di scripting client-side: JavaScript

  22. Server-side scripting • La dinamicitàriguardapiù di unasingolapagina web • Il contenutodinamicoègenerato da codice in esecuzionelato (web) server • Gestiscesessioniutente e controllailflussodell’applicazione • HTML form, parametrinella URL di richiesta, tipo di browser usato, ecc. • Principalilinguaggi server-side: Perl, PHP, Java, ASP • Estensioni server-side: CGI, JSP, ASP.NET

  23. Tecnologie web server-side

  24. CGI: Common Gateway Interface • Interfacciatrail server web e iprogrammi (script CGI) usati per generareicontenutidinamici • Ognirichiesta al server provocal’esecuzione del corrispondente script CGI sottoforma di un nuovoprocesso • Vantaggi: • semplice, diffuso, indipendentedal linguaggio (Perl e Python piùutilizzati) • Svantaggi: • altamenteinefficiente

  25. ColdFusion • ColdFusion Markup Language (CFML) • Sviluppato e controllato da Macromedia • Potente e di facile utilizzo • Ancorapiuttostodiffuso

  26. PHP • PHP Hypertext Preprocessor • Spessoutilizzatoall’interno di server web Apache • Ideale per lo sviluppo di piccoleapplicazioni web • facile e potente • Molto popolarenellacomunità open source • LAMP (Linux Apache MySQL PHP)

  27. ASP: Active Server Pages • Sviluppato e controllato da Microsoft • Estensione per server web Microsoft IIS • Linguaggisupportati per la creazione di contenutidinamici: • VBScript • JavaScript • VisualBasic • C# (ASP.NET)

  28. Java Servlet/Java Server Pages (JSP) • Sviluppato da Java Community Process • Parte dello standard Java EE • OO, platform-independent, efficiente, scalabile,… • Consente la separazionetraillivello di presentazione (interfaccia) e la logicaapplicativa

  29. CGI vs. Servlet/JSP

  30. CGI vs. Servlet/JSP • CGI • 1 richiesta client  1 processo server • Servlet/JSP • 1 richiesta client  1 thread all’internodellostessoprocesso server JVM • Ottimizzazionedellerisorse • Processo vs. Thread

  31. Java Servlet: Vantaggi • Condividonotuttiivantaggi del swscritto in Java: • Portabilità, OO, riuso, supporto di libreriegiàesistenti, efficienza, sicurezza, etc. • Si basanosuuna ben consolidata API specifica per ilprotocollo HTTP: • processing dellerichieste • generazionedellerisposte • gestionedellesessioni e dei cookies

  32. Servlet e Applicazioni Web

  33. Servlet e Applicazioni Web (2) • Sia le Servlets che le JSPs sonoeseguiteall’interno di archivi Web (WAR) • I WAR a lorovoltasono in esecuizionesu un Servlet Container (parte dellespecifiche Java EE server) • Nelcaso di JBoss, il Servlet Container coincide con ilservizio Apache Tomcat

  34. Servlet e Applicazioni Web (3) • Le applicazioni web sono isolate l’unadall’altraall’internodellostesso Servlet Container • Il Servlet Container forniscetuttiqueiservizi di “basso livello” necessari per ilciclo di vita di Servlets e JSPs: • gestionedelleconnessioni HTTP, sessioni, threading, sicurezza, gestionedellerisorse, monitoring, deployment, etc.

  35. Ma checos’èuna Java Servlet? • Èunanormaleclasse Java checonsentel’interazionerichiesta/risposta con un’applicazione secondo ilmodello client/server • Le Servlets sonoprogettate per gestirequalunquetipo di protocollorichiesta/risposta • Tipicamentevengonousate per l’implementazione di applicazionicheinteragiscono secondo ilprotocollo HTTP (richiesta/risposta via Web)

  36. Java Servlet: Packages • Èdefinitaall’interno del package standard javax.servlet • Ogni Servlet deveimplementarel’interfacciajavax.servlet.Servlet • specificaimetodirelativi al ciclo di vita • Le Servlets chegestisconoprotocolli di richiesta/rispostagenericidevonoestenderejavax.servlet.GenericServlet • Le Servlet specifiche per la gestione del protocollo HTTP devonoestenderejavax.servlet.http.HttpServlet

  37. Java Servlet: Esempio

  38. Java Servlet: Ciclo di Vita • A fronte di unarichiesta da parte del client il container: • Verificache la Servlet siagiàstatacaricata • Se non lo è, provvede a caricare la classecorrispondente e ne genera un’istanza • Inizializzal’istanzaappenacreatainvocandosu di essailmetodoinit • Invocailmetodoservicecorrispondenteall’istanzadella Servlet passando come argomentiglioggetticherappresentano la richiesta e la risposta • La rimozionedella Servlet dal container siottienetramiteunachiamata al metododestroy

  39. JVM Servlet Container Servlet S Initialize init() Loading/Instantiation Class.forName().newInstance() 1 request = 1 thread Servicing service() YES isLoaded S NO Unload/Garbage Collector finalize() Destroy destroy() Incoming client requests for the Servlet S

  40. Java Servlet: Ciclo di Vita (2) • I metodiinit e destroyvengonochiamati solo unavolta, rispettivamenteallacreazione e rimozionedella Servlet • Il metodoservicevienechiamatounavolta per ciascunarichiesta (spesso in modoconcorrente da più threads) • Nelcaso di HttpServlet al posto del metodo service (che pure èpresente) vengonoinvocatimetodipiùspecificichecorrispondono al protocollo HTTP: • HTTP GET  doGet • HTTP POST  doPost

  41. Java Servlet: Inizializzazione • Per customizzarel’inizializzazioneuna Servlet puòimplementareo fare overriding del metodoinit • Il metodoinitprende come argomentoun’istanza di javax.servlet.ServletConfig • contieneiparametri di inizializzazione • utilizzail file descrittore in WEB-INF/web.xml • AncheGenericServletimplemental’interfacciaServletConfig • metodoinit con nessunargomento

  42. Java Servlet: Inizializzazione

  43. Richiesta/Risposta: service • La gestionedellarichiesta/rispostaèaffidata al metodo service che ha iseguentiargomenti: • ServletRequest: richiesta del cliente (lettura) • ServletResponse: risposta al cliente (scrittura) • Nelcasospecifico di HttpServletilmetodo service è un “dispatcher” verso altrimetodispecifici del protocollo HTTP (doGet, doPost, …) • HttpServletRequest: HTTP request • HttpServletResponse: HTTP response

  44. Lettura:(Http)ServletRequest • La richiesta del client consente di accederealleseguentiinformazioni: • Client: IP/hostname, porta • Browser: locale, headers, security • Request: headers, cookies, path, parameters, content-type, -length, -encoding, -body • User: authorization/authentication (role) • Session: attributidellasessione • Request shared storage: attributidellarichiesta

  45. (Http)ServletRequest

  46. Scrittura:(Http)ServletResponse • La risposta al client consente di accederealleseguentiinformazioni: • Codici di stato • Headers • Cookies • Contenuto: length, type, body • URL Encoding: session tracking • Èimportantespecificareilcodice di stato (default HTTP 200 OK) e gli headers dellarisposta HTTP prima chequestasiainviata al client

  47. (Http)ServletResponse

  48. Java Servlet: Distruzione • Il metododestroyvieneinvocatoognivoltache la Servlet deveesseredeallocata • ad es.: stop del server, reloading dell’applicazione • Possibilechiamata del metodoservicesuuna Servlet su cui èstatoinvocatoilmetododestroy in ambiente multi-threading • Thread-safe • Tutte le risorse allocate al momentodellainitsonorilasciate • Il metododestroyvienechiamatouna sola voltaduranteilciclo di vita della Servlet

  49. Java Servlet: Distruzione

  50. Java Servlet: Deployment • Prima di poteressereusatauna Servlet deveessere: • Compilatatramite le classifornitedalla Servlet API • Java EE SDK • Servlet container: ${jboss.common.lib.url}/servlet-api.jar • specificataneldescrittoredell’applicazione web (WEB-INF/web.xml) • impacchettata in un archivio WAR • distribuitasu un Servlet container (Java EE AS) • accedutatramite URL(s)

More Related