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

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

 . . . 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

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!

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(...)

... 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

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

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.

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

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

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

die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

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> . . . . .

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" /> <% } %>

die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

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

die 3 Architekturtypen Web-basierte Anwendungsarchitekturen session scope

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

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

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

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

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

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

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

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!

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

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>

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

main.jsp die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

die 3 Architekturtypen Web-basierte Anwendungsarchitekturen entermsg.jsp

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”

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”/>

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

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); }

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

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” …

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)

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); . . .

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

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

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

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)

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!

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

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

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

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

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

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

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

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) . . .

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

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

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) . . .

die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

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

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

die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

die 3 Architekturtypen Web-basierte Anwendungsarchitekturen

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)

+ 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(); }