Ausgangslage Einführung Web-basierte Anwendungsarchitekturen

Präsentation zum Thema: "Ausgangslage Einführung Web-basierte Anwendungsarchitekturen"—  Präsentation transkript:

1 Ausgangslage Einführung Web-basierte Anwendungsarchitekturen
application HTTP DBMS RMI Sockets CORBA EJB JDBC web server _____.class web client (browser) request URL (get, post) _____.jsp response HTML (HTML-Seiten, Applets) _____.html

2 Einführung Web-basierte Anwendungsarchitekturen
verteilte Präsentation entfernte Präsentation verteilte Anwendung fat client

3  . . . DB Presentation Domain Logic Browser Layer Layer Web-Client
Einführung Web-basierte Anwendungsarchitekturen Presentation Layer Domain Logic Layer Browser (RPC, CORBA) (z.B. HTTP) Web-Client Web-Server Application Server . . . Präsentation  (z.B. JDBC) Web-basierte Anwendungen haben eine verteilte Präsentationsschicht die Richtung der Kontrolle geht nur in eine Richtung DB DB Server

4 MVC - Model View Controller Architektur: in GUI-Anwendungen
Einführung Web-basierte Anwendungsarchitekturen MVC - Model View Controller Architektur: in GUI-Anwendungen GUI Schicht Domänen Schicht dies ist KEIN Controller für UseCases, sondern ein GUI Event-Handling Applikation Controller (Maus, Tastatur,..) Model Änderung! Model-unabhängige Funktionalität View (Window) was darstellen? Ziel: mache das Modell unabhängig vom GUI Änderung!

5 GUI-basierte Präsentation mit Controller-Klassen (UseCase Controller)
Einführung Web-basierte Anwendungsarchitekturen GUI-basierte Präsentation mit Controller-Klassen (UseCase Controller) ... presses button End sale EnterPayment : Cashier actionPerformed( actionEvent ) actionPerformed( actionEvent ) actionPerformed( actionEvent ) ... ... UseCase Controller :SaleJFrame :SaleJFrame :SaleJFrame ProcessSale Handler 1: MakeCashPayment (amount) 1: enterItem(itemID, qty) 1: endSale() ... endSale() :ProcessSale Handler :ProcessSale Handler :ProcessSale Handler enterItem(...) makeNewSale() makeCashPayment(...)

6 ... GUI- Schicht Domänen- diese Art von Interaktion
Einführung Web-basierte Anwendungsarchitekturen diese Art von Interaktion ist in HTTP nicht möglich item-Id 925AE gibt Text ein productSpec Erdnuss Riesenpack price € 1.15 wählt aus Liste quantity 1 : Cashier category Getränke Lebensmittel Drogeriewaren Haushaltswaren drückt Knopf Lebensmittel addItem endOfSale 1. textValueChanged( TextEvent ) 1.2 product Spec actionPerformed( ActionEvent ) valueChanged( ListSelectionEvent) ... :SaleJFrame GUI- Schicht Domänen- :SaleJFrame :SaleJFrame 1.1: spec := find(itemId, category) 1: enterItem(itemID, qty) implementieren EventListeners spec:Product :Register Specification

7 Objektorientierung ade?
Einführung Web-basierte Anwendungsarchitekturen Ausgangslage: eigentlich traurig Objektorientierung ade? HTTP nur eine Operation web server request URL (get, post) _____.class nur ein Servlet für alle Clients web browser nur einen Datentyp (String) ohne jede innere Struktur (flach!) _____.jsp _____.html response HTML(HTML-Seiten, Applets) nur formatierter Hypertext

8 Web-basierte Anwendungen müssen unbedingt
Einführung Web-basierte Anwendungsarchitekturen Web-basierte Anwendungen müssen unbedingt eine gut strukturierte Server-seitige Architektur erhalten. Die Praxis sieht leider anders aus. Daran ist auch die Technologie schuld.

9 der Seiten-zentrierte Ansatz
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen der Seiten-zentrierte Ansatz Web-App = Sammlung von JSPs Eingaben prüfen request database JSP JSP response Ausgaben auswählen + einfach zu Beginn (wenn es nicht weiterwächst) - Code ist eine Mischung aus Präsentation, Domänenlogik, Datenzugriffstechniken: ein Wartungsalptraum - nicht skalierbar - vieles doppelt und dreifach

10 der Seiten-mit-Beans Ansatz
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen der Seiten-mit-Beans Ansatz Web-App = Sammlung von JSPs + Beans Eingaben prüfen request database JSP bean JSP bean response DB-Mapping + Auslagerung einiger Teile der Anwendungslogik in Beans - zuviel Steuerlogik in den JSPs

11 Beispiel: Lotterie (aus Bergsten2001)
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen Beispiel: Lotterie (aus Bergsten2001)

12 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

13 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
userinfoinput.jsp <body bgcolor="white"> <jsp:useBean id="userInfo" class="com.ora.jsp.beans.userinfo.UserInfoBean" scope="request" /> <%-- Output list of values with invalid format, if any --%> <font color="red"> <jsp:getProperty name="userInfo" property="propertyStatusMsg" /> </font> <%-- Output form with submitted valid values --%> <form action="userinfovalidate.jsp" method="post"> <table> <tr> <td>Name:</td> <td><input type="text" name="userName" value="<%= StringFormat.toHTMLString(userInfo.getUserName()) %>" > </td> </tr>

14 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
userinfovalidate.jsp: reine Kontrolllogik-JSP (kein HTML) page language="java" %> <jsp:useBean id="userInfo" scope="request" class="com.ora.jsp.beans.userinfo.UserInfoBean" > <jsp:setProperty name="userInfo" property="*" /> </jsp:useBean> <% if (userInfo.isValid()) { %> <jsp:forward page="userinfovalid.jsp" /> <% } else { %> <jsp:forward page="userinfoinput.jsp" /> <% } %>

15 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

16 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
<html> <head> <title>User Info Validated</title> </head> <body bgcolor="white"> <font color=green size=+3> Thanks for entering valid information! </font> </body> </html> userinfovalid.jsp: reines HTML – trotzdem gleich als JSP anlegen für zukünftige Erweiterungen

17 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
session scope

18 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
CatalogBean ProductBeans CartBeans application scope session scope

19 controller database view model der Servlet-Controller Ansatz request
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen der Servlet-Controller Ansatz request controller servlet State change event Forward event database response view JSP model bean data Client Web Server Data + MVC Trennung der Belange: JSP als reiner View + skalierbar - etwas aufwendig bei sehr kleinen Anwendungen

20 Servlets: damit könnte man eigentlich alles machen
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen Servlets: damit könnte man eigentlich alles machen

21 controller view model Aufgaben des Controller Servlets
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen Aufgaben des Controller Servlets Event dispatcher Security gateway Model preparation Error handling Response triggering logging request controller servlet State change event Forward event response view JSP model bean data

22 controller database view model Aufgaben des Model Beans servlet JSP
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen Aufgaben des Model Beans request controller servlet validation, security Forward event State change event database response view JSP model bean data business logic data state read/write utilities

23 controller view model Aufgaben des View JSPs servlet JSP bean
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen Aufgaben des View JSPs request controller servlet validation, security Forward event State change event database response view JSP model bean data presentation logic read-only

24 page3 page2 page1 servlet bean bean JSP JSP JSP
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen controller servlet auf “process” im web.xml abgebildet post(..) action +doPost(..) -doA1(..) -doA2(..) -doA3(..) model2 bean request model1 bean <form action= “process?action=a2” method="post"> (action == “a1”) doA1(..) (action == “a2”) “url rewriting” Alternative: “hidden fields” doA2(..) (action == “a3”) response doA3(..) Forward events page3 JSP page2 JSP page1 JSP

25 init(): einmalig aufgerufen bei Instanzierung des Servlets
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen der Servlet Life Cycle init(): einmalig aufgerufen bei Instanzierung des Servlets instanziiert entweder bei erstem Request auf Servlet, oder beim Starten der Servlet Engine service(..): (doPost, doGet) bei jedem Request des Servlets destroy(..): einmalig vor dem Löschen aus der VM wann das geschieht, entscheidet Servlet Engine Merke: es gibt zu jedem Servlet nur immer höchstens ein Objekt!

26 Servlet Initialisierung in init():
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen Servlet Initialisierung in init(): in die Methode direkt hineinimplementiert: private Attribute. Servlet-Scope: werden geteilt von allen Requests Attribute mit Applikations-Scope: ServletContext.set/getAttribute(..) für jede Applikation gibt es genau ein ServletContext Objekt. Also: alle Servlets und JSPs einer Applikation teilen dieses Objekt über web.xml Parameter: werden im <init-param>-Tag gesetzt servlet-spezifisch: über ein ServletConfig Objekt wird aus den Parametereinträgen (<init-param>-Tag innerhalb <servlet>-Tag) in web.xml erzeugt und in init() mit getInitParameter(..) gelesen applikationsspezifisch: über ServletContext Objekt, aus (<context-param>-Tag innerhalb <web-app>-Tag) in web.xml. oder aus ServletContext.setAttribute(..)in anderen Servlets oder JSPs erzeugt

27 web.xml die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
<servlet> <servlet-name> pbController </servlet-name> <servlet-class> com.ora.jsp.servlets.PBControllerServlet1 </servlet-class> <init-param> <param-name>maxNews</param-name> <param-value>100</param-value> </init-param> </servlet>

28 Anwendung “Project Billboard” (Bergsten2001)
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen Anwendung “Project Billboard” (Bergsten2001) login.jsp

29 main.jsp die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

30 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
entermsg.jsp

31 Anwendung “Project Billboard” (Bergsten2001)
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen Anwendung “Project Billboard” (Bergsten2001) action= showPage &page= . . . action=updateprofile oder =showPage&page=entermsg.jsp action=authenticate action=“storeMsg”

32 die init-Methode des Controller Servlets
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen die init-Methode des Controller Servlets public void init() throws ServletException { DataSource ds = null; try { ds = new DataSourceWrapper("sun.jdbc.odbc.JdbcOdbcDriver", "jdbc:odbc:example", null, null); } catch (Exception e) {} // Ignore all in this example EmployeeRegistryBean empReg = new EmployeeRegistryBean(); empReg.setDataSource(ds); getServletContext().setAttribute("empReg", empReg); NewsBean news = new NewsBean(); getServletContext().setAttribute("news", news); Zugriff auf news-Bean von anderen Servlets: NewsBeans newsBeans = (NewsBeans) getServletContext.getAttribute(“news”); Zugriff auf news-Bean von JSPs dieser Anwendung: <jsp:useBean id=“news” scope=“application” class=“com.ora.jsp.beans.news.NewsBean”/>

33 Controller Servlet: zentralisierte Request Bearbeitung
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { String action = request.getParameter("action"); // Check if the user is authenticated if (!isAuthenticated(request) && !("authenticate".equals(action) || "logout".equals(action))) { doForwardToLogin(request, response); } else { if ("authenticate".equals(action)) { doAuthenticate(request, response); } else if ("logout".equals(action)) { doLogout(request, response); } else if ("storeMsg".equals(action)) { doStoreMsg(request, response); } else if ("updateProfile".equals(action)) { doUpdateProfile(request, response); } else if ("showPage".equals(action)) { doShowPage(request, response); } response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED); } } } Besonderheit: jeder Request dieser Anwendung bedarf einer Authentifizierung Controller Servlet: zentralisierte Request Bearbeitung

34 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
private boolean isAuthenticated(HttpServletRequest request) { boolean isAuthenticated = false; HttpSession session = request.getSession(); if (session.getAttribute("validUser") != null) { isAuthenticated = true; } return isAuthenticated; public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { doPost(request, response); }

35 der Parameter origURL dient dazu, die ursprüngliche URL des Requests
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen private void doForwardToLogin(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { String origURL = HttpUtils.getRequestURL(request).toString(); String queryString = request.getQueryString(); if (queryString != null) { origURL += "?" + queryString; } String loginURL = "login.jsp" + "?origURL=" + URLEncoder.encode(origURL) + "&errorMsg=" + URLEncoder.encode("Please log in first"); forward(loginURL, request, response); Besonderheit: der ursprüngliche, nicht authentifizierte Request wird “gespeichert”, damit der Benutzer ihn nicht nochmals eingeben muss der Parameter origURL dient dazu, die ursprüngliche URL des Requests zu speichern – was man natürlich auch in dem Session Objekt hätte tun können

36 Authentifizieren eines Requests …
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen Authentifizieren eines Requests Servlet Request “xyz?abc=123” [nicht authentifiziert] doForwardToLogin origUrl (hidden) origUrl=“xyz?abc=123” login.jsp forward action=authenticate hidden:origURL name, password doAuthenticate redirect origUrl userNameCookie, passwordCookie [authentifiziert] doXYZ Request “xyz?abc=123” …

37 login.jsp (Ausschnitt)
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen <form action="process?action=authenticate" method="post"> <% String origURL = request.getParameter("origURL"); %> <input type="hidden" name="origURL" value="<%= origURL == null ? "" : origURL %>"> Please enter your User Name and Password, and click Enter. <p> Name: <input name="userName" value="<ora:getCookieValue name="userName" />" size="10"> Password: <input type="password" name="password" value="<ora:getCookieValue name="password" />" size="10"> <input type="submit" value="Enter"> Remember my name and password: <input type="checkbox" name="remember" <%= CookieUtils.isCookieSet("userName", request) ? "checked" : "" %> > <br> (This feature requires cookies to be enabled in your browser) </form> login.jsp (Ausschnitt)

38 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
private void doAuthenticate(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { String userName = request.getParameter("userName"); if (userName == null) { throw new ServletException("Missing User Name"); } String password = request.getParameter("password"); if (password == null) { throw new ServletException("Missing Password"); try { EmployeeRegistryBean empReg = (EmployeeRegistryBean) getServletContext().getAttribute("empReg"); boolean isRegistered = empReg.authenticate(userName, password); if (isRegistered) { EmployeeBean emp = empReg.getEmployee(userName); HttpSession session = request.getSession(); session.setAttribute("validUser", emp); . . .

39 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
. . . Cookie userNameCookie = new Cookie("userName", userName); Cookie passwordCookie = new Cookie("password", password); int maxAge = MAXUSERCOOKIEAGE; if (request.getParameter("remember") == null) { maxAge = 0; } userNameCookie.setMaxAge(maxAge); passwordCookie.setMaxAge(maxAge); response.addCookie(userNameCookie); response.addCookie(passwordCookie); // Redirect to the originally requested URL or main String next = request.getParameter("origURL"); if (next == null || next.length() == 0) { next = getShowPageURL(request) + "main.jsp"; response.sendRedirect(next); else { String loginURL = "login.jsp" + "?errorMsg=" + URLEncoder.encode("Invalid User Name or Password"); response.sendRedirect(loginURL); Unterschied zu forward: Umleitung geschieht Client-seitig Aktivierung wieder über Servlet

40 warum reicht es nicht, “am Anfang” zu authentifizieren?
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen warum reicht es nicht, “am Anfang” zu authentifizieren? wichtige Besonderheit von Web-Anwendungen: die einzelnen Schritte eines UseCases in einer Web-Architektur sind voneinander entkoppelt: es gibt keine zentrale Steuerinstanz eines UseCases damit kann der Client (Browser) jeden Schritt potentiell selber aktivieren, wann er will (sofern er den Request schon einmal ausgeführt hat, ihn also kennt) eine strenge Kontrolle über den UseCase Ablauf bedarf einer besonderen Steuerlogik, die anders ist als eine GUI-Steuerlogik

41 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
<head> <title>Project Billboard</title> </head> <body bgcolor="white"> <jsp:useBean id="validUser" scope="session" class="com.ora.jsp.beans.emp.EmployeeBean" /> <h1>Welcome <%= validUser.getFirstName() %></h1> . . . <form action="process?action=updateProfile" method="post"> <input type="checkbox" name="projects" value="JSP" <input type="checkbox" name="projects" value="Servlet“ main.jsp (Ausschnitt) Informationsver-arbeitung auf Server

42 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
. . . <a href=process?action=showPage&page=entermsg.jsp>Post a new message</a> <p> <jsp:useBean id="news" scope="application" class="com.ora.jsp.beans.news.NewsBean" /> <% NewsItemBean[] newsItems = news.getNewsItems(validUser.getProjects()); pageContext.setAttribute("newsItems", newsItems); %> <table> <ora:loop name="newsItems" loopId="newsItem" className="NewsItemBean" > <tr> <td colspan="2"> Project: <jsp:getProperty name="newsItem" property="category" /> </td> keine Informationsver-arbeitung auf Server, reiner Seitenwechsel main.jsp (Ausschnitt)

43 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
Im Unterschied zu den anderen Aktionen soll hier nur auf eine andere Seite verzweigt werden. Anstatt von einer Seite direkt auf eine andere Seite zu verweisen, wird hier immer ein Durchlauf durch das Servlet erzwungen (Authentifizierung). private void doShowPage(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { String url = request.getParameter("page"); if (url == null) { throw new ServletException("Missing page info"); } forward(url, request, response); private String getShowPageURL(HttpServletRequest request) { return request.getContextPath() + request.getServletPath() + "?action=showPage&page="; private void forward(String url, HttpServletRequest request, RequestDispatcher rd = request.getRequestDispatcher(url); rd.forward(request, response); gibt eine absolute URL zurück, um den nächsten Request wieder über das gleiche Servlet auf die nächste Seite zu lenken. Ist besser als diese URL direkt hineinzukodieren!

44 anstatt die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
Servlet Request “action=showPage&page=xyz.jsp” [authentifiziert] doShowPage xyz.jsp [page existiert] forward anstatt Request “xyz.jsp” xyz.jsp

45 wie sind in diesem Beispiel die Zustandsübergänge der Session kodiert?
Einführung Web-basierte Anwendungsarchitekturen wie sind in diesem Beispiel die Zustandsübergänge der Session kodiert? wie macht man dies bei komplexeren Sessions? Beispiel: ProcessSale makeNewSale EnteringItems enterItem endSale makeCashPayment WaitingForPayment authorized makeCreditPayment AuthorizingPayment makeCheckPayment

46 zwei Ansätze zur Spezifikation einer WEB-Anwendung A) Frontend-basiert
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen zwei Ansätze zur Spezifikation einer WEB-Anwendung A) Frontend-basiert beginne mit einem Satz verlinkter, statischer HTML-Seiten als Frontend-Prototyp. Es gibt hauptsächlich zwei Hyperlink-Typen: Dateneingabe (HTTP Parameter) verarbeiten, Resultat anzeigen data entry (neue Entität), Resultat über Erfolg, evtl. Daten-Echo Resultat sind Daten, die mit Dateneingabe identifiziert werden verzweigen zu anderem “Menu” (nächster Arbeitsschritt) manchmal können a) und b) in einem Link zusammenfallen gehe zu dynamischen Seiten (JSP) über, und bilde die Links auf Zustandsübergangslogik eines oder mehrerer Servlet-Controller ab, mit “forwards” auf die JSPs definiere das Domänenmodell (Beans) verbinde Servlets und JSPs mit dem Domänenmodell

47 zwei Ansätze zur Spezifikation einer WEB-Anwendung B) UseCase-basiert
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen zwei Ansätze zur Spezifikation einer WEB-Anwendung B) UseCase-basiert schreibe wie im Unified Process mit UML UseCases mit Arbeits-schritten, und definiere für jeden UseCase ein Controller Servlet schreibe für jeden Arbeitsschritt des UseCases eine Operation des Controllers definiere in einem State-Diagramm Zustandsübergänge eines Controllers (UseCase), um Arbeitsschrittsequenzen einzuschränken definiere für jeden Arbeitsschritt eines UseCases das Interaktionsereignis auf einer Web-Seite (samt Eingabedaten) organisiere diese Ereignisse in eine Reihe von Web-Seiten (JSPs), unter Berücksichtigung von 3 definiere das Domänenmodell (Beans) verbinde Servlets und JSPs mit dem Domänenmodell

48 zwei Ansätze zur Spezifikation einer WEB-Anwendung A) Frontend-basiert
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen zwei Ansätze zur Spezifikation einer WEB-Anwendung A) Frontend-basiert B) UseCase-basiert in beiden Ansätzen: gehe nach den Normalfällen das Ganze nochmal durch für die Spezialfälle/Fehlerfälle am besten: immer beide Ansätze durchgehen

49 zwei Ansätze zur Spezifikation einer WEB-Anwendung
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen zwei Ansätze zur Spezifikation einer WEB-Anwendung Problem: Jedes Servlet ist ein Controller für einen UseCase Dann aber sollte man innerhalb einer Session eventuell mehrere Servlets (Use Cases) laufen lassen können: parallel/verschachtelt Problem damit: Session Management für mehrere UseCases/Servlets – es gibt nur globalen Bereich pro Session, aber nicht pro Session-Servlet! Lösungen verschachtelte/parallele UseCases nur über jeweils neue Sessions. verschachtelte/parallele UseCases in einem Session-Objekt, in dem man “per Hand” Servlet-spezifische Zustände führt

50 Erqweiterungen 1. Fehlerbehandlung
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen Erqweiterungen 1. Fehlerbehandlung Basisausnahme: ServletException wenn diese Exception nicht aufgefangen wird: unschöne Fehlermeldung im Browser deshalb: Exception im Servlet auffangen und verzweigen (mit forward) auf spezielle Fehler JSP wo auffangen? so spät (so ”weit oben”) wie möglich: in der service-Methode des Servlets

51 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
HttpServlet public final void service ( HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException { try { super.service( request, response ); } catch( Throwable aThrowable ) { handle( aThrowable, request, response ); } } BaseServlet service(request,response) handle(exception, request,response) protected void handle (Throwable aThrowable, HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { RequestDispatcher dispatcher = getServletContext().getRequestDispatcher( "error.jsp" ); dispatcher.forward( request, response ); } MyServlet handle(exception, request,response) doPost(request,response) doGet(request,response) . . .

52 2. das Servlet unabhängig von den spezifischen Aktionen machen
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen Erqweiterungen 2. das Servlet unabhängig von den spezifischen Aktionen machen Idee: pro Aktion ein spezielles Aktionenobjekt definieren Abbildung des Aktionsnamens (Request Parameter) auf ein Objekt entweder dynamisch mittels Class.forName während des Request Services, oder in einer Hashtable während der Initialsierung des Servlets anlegen, am besten über Servlet Initialisierungsparameter

53 page2 page1 page3 servlet bean bean JSP JSP JSP
die 3 Architekturtypen Web-basierte Anwendungsarchitekturen controller servlet auf “process” im web.xml abgebildet post(..) action +doPost(..) model2 bean request model1 bean [action == a1] process(req,res) <form action= "process?action=a2" method="post"> A1 [action == a2] process(req,res) “url rewriting” Alternative: “hidden fields” A2 [action == a3] process(req,res) response Forward events A3 page2 JSP page1 JSP page3 JSP

54 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen
BaseServlet service(request,response) handle(exception, request,response) MyServlet handle(exception, request,response) doPost(request,response) doGet(request,response) . . .

55 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

56 Einführung Web-basierte Anwendungsarchitekturen
Anzahl Dauer Beans as x00-x000 sehr kurzlebig x kurzlebig x längerlebig von mehreren Anwendungen geteilt Problem: Skalierbarkeit Lösung: untersage private Verbindungen zwischen Clients und kostspieligen Ressourcen. Benutze statt dessen Ressourcen-Pools langlebig

57 Einführung Web-basierte Anwendungsarchitekturen
Dynamic content creation and delivery Input collection; validation? Screen flow State management? Support for multiple clients Business logic? Beans as

58 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

59 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

60 die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

61 für jeden „Go-Button“ (HTML buttons mit submit, links auf servlets) mit eigener Funktion: ein eigenes Servlet ein einziges Servlet als Controller, das auf Supportklassen verzweigt, die die speziellen Funktionen ausführen (z.B. mit dem Command-Pattern)

62 + forward(String aPage) BaseServlet
«interface» HttpController + forward(String aPage) BaseServlet { processRequest(req, res); } HttpMethodServlet +doGet( req, res ) +doPost( req, res ) +handle( exception, req, res ) -processRequest( req, res ) -getHttpController( req, res ) { HttpController controller = getHttpController( req, res ); controller.process(); }