Komponentisierte Web-Frontends

Transkript

1 Komponentisierte Web-Frontends Umsetzung im Kontext Verteilter Systeme Uni Bamberg,

2 Agenda Vorstellung Motivation Architekturkonzepte Umsetzung mit Wicket Diskussion 2

3 VORSTELLUNG Vortragende Andreas Gärtner Partner, Principal Architect Dr. Martin Trapp Partner, Principal Architect 3

4 VORSTELLUNG Senacor ist ein deutschlandweit tätiger IT-Dienstleister Dienstleistung Business Consulting Technical Consulting Software Design u. Development Senacor Unternehmen Mitarbeiter: ca. 200 Aktionäre: Management und private Investoren Standorte Schwaig b. Nürnberg (Zentrale) Bonn, München, Frankfurt, Wien 4

5 VORSTELLUNG Große Unternehmen mit komplexen IT-Landschaften bestimmen das Kundenportfolio von Senacor 5

6 Agenda Vorstellung Motivation Architekturkonzepte Umsetzung mit Wicket Diskussion 6

7 MODERNE WEB-ANWENDUNGEN Moderne Web-Frontends bestehen aus funktional reichen Bausteinen, die für unterschiedliche Zugangskanäle wiederverwendet und neu kombiniert werden können Wie erreicht man das konzeptionell, fachlich und technisch? 7

8 WEB FRONTENDS DEPLOYMENT SICHT Typische Industrieszenarien für großen Web-Anwendungen weisen einen klar geschichteten Aufbau auf Browser (z.b. Firefox) Load Balancer (z.b. F5) HTTP Server (z.b. apache) Servlet Container (z.b. tomcat) Load balancer sorgen dafür, dass die Anfragen von Benutzern gleichmäßig auf die verfügbaren HTTP Server verteilt werden HTTP Server liefern statische Inhalte wie Formulare oder Stylesheets direkt aus Die eigentlichen Web- Anwendungen laufen in Servlet Container Cluster ab Möglichst wenig Geschäftslogik im Frontend Middle Layer Serviceschicht stellt Geschäftslogik für Frontends bereit 8

9 HISTORISCHE ENTWICKLUNG IN DER WEB-ENTWICKLUNG Bei Technologien und Frameworks verschiebt sich der Fokus von Web- Seiten zu Komponentenansätzen HTTP / HTML Request / Response um irgendwie HTML- Seiten zu generieren JSP + taglibs Trennung von Darstellung und Logik Ajax / JSON / ReST Abkehr von seitenorientierten Anwendungen HTML 5 / CSS 3 Unterstützung für Funktionalitäten, die bisher RIAs vorbehalten waren Servlets / JEE / WARs Abstraktion von HTTP in Java, Servlet (Web) Container, Session Struts MVC Muster für Web-Anwendungen als verlinkte Seiten JSF Serverseitiges Komponentenmodell ähnlich zu Swing Flash RIA Dynamische Effekte + Multimedia Portlets Komponentenmodell, aber nur rudimentäre Kooperation 9

10 Agenda Vorstellung Motivation Architekturkonzepte Umsetzung mit Wicket Diskussion 10

11 STRUKTUR WAS IST DRIN IM FRONTEND? JEE Web Anwendungen realisieren GUIs, aber keine Geschäftslogik 11

12 COMPOSITES UND BOTTOM UP DESIGN Anforderungen und Planung für GUI-Bausteine top-down, aber Konstruktion bottom-up um kontextunabhängige Wiederverwendung zu erreichen Feldebene Feldgruppen Einheitliche Wertebereiche und Prüfungen durch explizite Fachdatentypen z.b. deutsche Bankleitzahl immer sechsstellig numerisch Wiedererkennbare Anordnung z.b. bei Adressdaten Fachdatentypen und Validierungsregeln Feldgruppen mit Funktionalität Dialoge Geschäftsvorgänge Seiten Anwendungen Identifikation wiederkehrender Muster wie z.b. geführte Prozesse oder Aktionen mit expliziter Freigabe Komplette, fachlich geschnittene Funktionalitäten, die einzelne Anwendungsfälle abdecken Einheitliche Darstellung mit gleichförmig genutzten Bereichen (Header, Footer, Navigation, ) Ausführungsumgebung für Geschäftsvorgänge, typischerweise rollenbasiert Wizards Haupteinstiegspunkte Layout Styling 12

13 FELDER UND FELDGRUPPEN Fachliche Datentypen für gleichförmiges Verhalten auf Feldebene. Feldgruppen sind rekursiv schachtelbar Adresserfassung 1 1 Textfeld mit Eingabevalidierung 2 2 Dropdown-Feld für Aufzählungstypen Personenerfassung Schufa-Erfassung Wiederverwendung in verschiedenen anderen Bausteinen 13

14 FELDGRUPPEN Bausteine kennen ihren Ablaufkontext nicht. Verwender kennen nur die Schnittstellen der Bausteine. Zur selben Schnittstelle sind unterschiedliche Varianten von Bausteinen möglich Aufgabe: Erfassung einer validen Bankverbindung bestehend aus Bankleitzahl, Kontonummer und Name des Kreditinstituts Kontonummer Bankleitzahl Modell: Bankverbindung Kreditinstitut Haspa Eingabe: Leeres oder teilbefülltes Bankverbindungsobjekt Ausgabe: Bankleitzahl und Kontonummer konsistent gefüllt, Name des Kreditinstituts passend gesetzt Funktionalität: Bankleitzahl ist gültig, Kontonummer überprüft, Bankname passt zur BLZ Kontonummer Bankleitzahl Kreditinstitut Hamburger Sparkasse Kontonummer Bankleitzahl Kreditinstitut Suchen HSH Nordbank Hamburg Hamburger Sparkasse 14

15 DIALOGE Dialoge beschreiben Abläufe als Abfolge einzelner Ablaufschritte Überweisung durchführen Überweisungsbestätigung Vorlagenauswahl Überweisungserfassung Bankleitzahlsuche Überweisungsdatenanzeige TAN- Legitimation durchführen Überweisungseingabe Überweisungsfreigabe Überweisungsdatenanzeige TAN-Anzeige Die Realisierung von Abläufen ist nicht Aufgabe der einzelnen Ablaufschritte sondern des umfassenden Bausteins Dialoge sind selbst wieder Bausteine, die mit anderen zusammengefasst werden können 15

16 GESCHÄFTSVORGÄNGE UND ANWENDUNGEN Realisierungen von Geschäftsvorfällen können in unterschiedliche Rahmenanwendungen eingesteckt werden GP-Suche GP-Erfassung Girokonto-VK... Komponenten-Baukasten Verkauf Vorsorge, Versicherung Kredite Kreditkarten GP-Suche Spar Baufinanzieru ng Wertpapier/ Investment Finanzstatus Partner/ Kundenmngmt. Girokonto-VK Kundenmanagement Geschäftspartner Beratung Vertriebsreporting Aktionsprodukte Transaktionen Brokerage Filiale Call-Center Abwicklung... Banking GP-Suche Sonstiges Giro & Debitkarten Antragsmanagement Nachrichtenverwaltung Beschwerdemngmt. Verwaltung Auskunft Authentifiz. & Legitimierung Finanzstatus Sparen-VK... Rahmenanwendung übernimmt Seitenlayout und Teile des Look&Feels(Styling) Unterstützung unterschiedlicher Anforderungen durch a) Parametrisierung der Bausteine und b) Rollen/Rechte-Konzept Bei Produktivsetzungen sind immer nur Teile der Software neu und intensiv zu testen Unterstützung unterschiedlicher Release Zyklen Unterschiedliches (virtuelles) Blech ermöglicht zielgerichtete Ressourcenzuordnung 16

17 SEITEN VON ANWENDUNGEN Seiten sind anwendungsspezifisch und definieren den optischen Rahmen für die Einbettung von Geschäftsvorfällen

18 Service Schnitt, Schnittstellen und Modelle Komponentisierte Web-Frontends 18

19 SERVICE-SCHNITT AUS FRONTEND-SICHT Fachlich müssen Funktionalitäten unterschiedlicher Domänen eingebunden werden Überweisung erfassen Überweisung prüfen Überweisung ausführen Buchung initialisieren Limite prüfen TAN entwerten Bankverbindung prüfen Buchung prüfen Limite reduzieren TAN reservieren Buchung ausführen Legende Auftrag protokollieren Bank Konto Kunde Sicherheit Journal 19

20 SERVICE-SCHNITT AUS FRONTEND-SICHT Viele Punkt zu Punkt Verbindungen erhöhen die Komplexität im Frontend (Spezialwissen, Flusssteuerung, Kompensation, ) Überweisung erfassen Überweisung prüfen Überweisung ausführen Bankverbindung prüfen Buchung initialisieren Buchung prüfen Buchung ausführen Limite prüfen Limite reduzieren TAN reservieren TAN entwerten Auftrag protokollieren Bank Konto Kunde Sicherheit Journal 20

21 SERVICE-SCHNITT AUS FRONTEND-SICHT Auf Anwendungsfälle zugeschnittene Services ermöglichen eine deutliche Komplexitätsreduktion für die Frontends Überweisung erfassen Überweisung prüfen Überweisung ausführen prüfen Zahlungsverkehrsmanagement initialisieren ausführen Bankverbindung prüfen Buchung initialisieren Buchung prüfen Buchung ausführen Limite prüfen Limite reduzieren TAN reservieren TAN entwerten Auftrag protokollieren Bank Konto Kunde Sicherheit Journal 21

22 FACHARCHITEKTURMODELL Facharchitekturmodelle ermöglichen die Darstellung des Zusammenspiels von fachlichem Prozess, Frontend, Middlelayer und Backends

23 DATENMODELLE AUS FRONTENDSICHT UND DTOS Wie viele unterschiedlich Modelle braucht es vom Backend bis zur GUI? Middle Layer Frontend Backends GUI GUI GUI GUI GUI Modell (Backing Beans) Modell der Serviceschnittstelle Logik Logik Logik Logik Geschäftsobjektmodell Backend-nahe Modelle JMS JPA JCA WS Backend Modell????? GUI-Bausteine Geschäftslogik Adapter Backend-nahe Modelle sind oft nicht geeignet für die Programmierung von Geschäftslogik (z.b. zu spezialisiert, zu allgemein, zu unterschiedlich) Modell der Service-Schicht stellt vertrag zwischen Middle Layer und Frontend da. Die Schnittstelle inkl. der darin verwendeten Datenobjekte sollten einem formalen Releasing unterliegen (versionierte Schnittstellen) Schnittstelle entkoppelt sich von Geschäftsobjekten durch explizite Transferobjekte (Data Transfer Objects, DTOs), damit interne Änderungen nicht auf die Schnittstelle durchschlagen DTOs können auch direkt als Backing Beans genutzt werden kein eigenes GUI Modell 23

24 Agenda Vorstellung Motivation Architekturkonzepte Umsetzung mit Wicket Diskussion 24

25 UMSETZUNG MIT WICKET Zur Umsetzung einer komponentenbasierten Webapplikation sind komponentenbasierte Frameworks am besten geeignet Historische Entwicklung im JEE Umfeld 1997: Veröffentlichung der Servlet-Spezifikation Umsetzung dynamischer Webinhalte 1999: Servlet-Spezifikation 2.1: Java Server Pages Trennung von Darstellung und Inhalt Gleichzeitig Publikation des Model 2 Anwendungsmusters Strukturierung von Webanwendungen nach Model View Controller Lange Zeit prominentestes Anwendungsframework: Struts Probleme und Herausforderungen Geringe Abstraktion vom Request- Response Paradigma und von der Servlet- Spezifikation Browser Back und Duplicate Submit Problem komplexes Handling des Anwendungszustands Keine Unterstützung von wiederverwendbaren Komponenten Komponentenbasierte Standards und Frameworks Etablierung eines Standards für komponentenbasierte Java-Webanwendungen: JSF Ziel: einfache Entwicklung und Wiederverwendung von Komponenten Open-Source Frameworks wie Tapestry oder Wicket zielen auf eine weiter veranfachte Umsetzung

26 UMSETZUNG MIT WICKET mvn archetype:generate -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.5.3 web.xml HomePage.html wicket-example WicketApplication.java HomePage.java 26

27 UMSETZUNG MIT WICKET Hello, Bamberg! HomePage.html- Markup <html xmlns:wicket=" strict.dtd" > <head> <title>wicket Quickstart Archetype Homepage</title> </head> <body> <strong>wicket Quickstart Archetype Homepage</strong> <br/><br/> <span wicket:id="message">message will be here</span> </body> </html> HomePage.java- Implementierung HomePage.java- Implementierung public class HomePage extends WebPage { public HomePage(final PageParameters parameters) { } } add(new Label("message", Hello, Bamberg!")); 27

28 UMSETZUNG MIT WICKET Merkmale und Konzepte Automatische Zustandsverwaltung Komponentenbasiert Separation of Concerns (Präsentation und Logik) Convention over Configuration Wicket Einfache Entwicklung Objektorientiert 28

29 UMSETZUNG MIT WICKET Alles ist ein Baustein Component <abstract> MarkupContainer WebComponent WebMarkupContainer Page <abstract> Image Form Panel WebPage Label 29

30 UMSETZUNG MIT WICKET Modelle stellen die Daten für die Bausteine bereit Das Modell bietet den Komponenten Zugriff auf die Domänenobjekte (in Verteilten Systemen oft über DTOs) Manipulation des Zustands einer Komponente erfolgt über Veränderungen des Modells Page Delegate Domain Component IModel ModelData Component Kunde Konto Adresse 30

31 UMSETZUNG MIT WICKET Detachable Models gewährleisten die effiziente Nutzung von Ressourcen Komponentenbäume werden in Page Maps ( Seitenhistorie) serialisiert Modelle werden in Properties der Komponenten referenziert Person p =...; add(new Label<String>("firstname, new PropertyModel<String>(p, "firstname"))); Implementierungen von IModel müssen serialisierbar sein Wird das Domänenobjekt im Model direkt referenziert, so muss auch dieses serialisierbar sein und der Speicherbedarf pro Session wächst LoadableDetachableModel lädt das Domänenobjekt beim ersten Zugriff gibt es am Ende der Request-Bearbeitung frei private class PersonModel extends LoadableDetachableModel { private long id; public PersonModel(long id) { this.id = id; protected Object load() { return personservice.getpersonbyid(this.id); } } 31

32 UMSETZUNG MIT WICKET Integration von Services über Spring Herausforderung Services sollen mit Hilfe von Spring in Wicket-Komponenten injiziert werden Wicket ist unmanaged, d.h. die Komponenten können an beliebigen Stellen mit new erzeugt werden Wicket-Komponenten werden häufig serialisiert und deserialisiert Ggf. werden die Daten in der Session über die Knoten eines Clusters repliziert Spring ApplicationContext sollte möglichst nur einmal beim Anwendungsstart initialisiert werden Lösung Der ApplicationContext wird über einen in der web.xml zu deklarierenden Listener beim Start der Webanwendung initialisiert: <listener> <listener-class> org.springframework.web. context.contextloaderlistener </listener-class> </listener> Die Dependencies werden in den Komponenten annotiert Ein ComponentInstantiationListener sorgt dafür, dass beim Instanziieren ein serialisierbarerproxy in die Komponenten injiziert wird 32

33 UMSETZUNG MIT WICKET Wicket macht die Realisierung und Nutzung von Komponenten einfach Eigenschaften Umsetzung in Wicket Komponenten stellen prozessorientierte Endbenutzerfunktionalität in Form von Zustand und Verhalten bereit Komponenten sollen in unterschiedlichen Kontexten wiederverwendbar sein, weisen daher im Vergleich zu Objekten eine höhere funktionale Kohäsion auf Komponenten Implementierung einer oder mehrerer Java-Klassen, die von der abstrakten Klasse Component erben (Bausteine) Schreiben einer XHTML- Seite, die das Markup der Komponente realisiert Ggf. Zusammenfassung mehrerer Bausteine zu einem jar (Komponente) Und sonst nichts! 33

34 UMSETZUNG MIT WICKET Implementierung und Integration von Komponenten (1/3) Implementierung public class AdressePanel<T extends Adresse> extends Panel { public AdressePanel(String id, T adresse) { super(id); add(new AdresseForm<T>("adresseForm", adresse)); } private final class AdresseForm<T extends Adresse> extends Form<T> { public AdresseForm(String id, T adresse) { super(id, new CompoundPropertyModel<T>(adresse)); } } } add(new DropDownChoice<String>("land, LandEnum.getEnumValues())); add(new TextField<String>("strasse")); add(new TextField<String>("hausNr")); add(new TextField<String>("plz")); add(new TextField<String>("stadt"); 34

35 UMSETZUNG MIT WICKET Implementierung und Integration von Komponenten (2/3) Markup <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <html xmlns= xmlns:wicket= <body> <wicket:panel> <form wicket:id="adresseform"> <label>strasse und Hausnummer</label> <input type="text" wicket:id="strasse" class="size-m" /> <input type="text" wicket:id="hausnr" class="size-s" /> <label>postleitzahl, Wohnort</label> <input value="" wicket:id="plz" type="text" class="size-s" /> <input value="" wicket:id="stadt" type="text" class="size-m" /> <label for="ausstellungsdatum">land</label> <select wicket:id="land" class="size-l" > <option>deutschland</option> </select> </form> </wicket:panel> </body> </html> 35

36 UMSETZUNG MIT WICKET Implementierung und Integration von Komponenten (3/3) Verwendung - Markup <html>... <div wicket:id="adressepanel" />... </html> Verwendung - Code final Panel panel = new AdressePanel("adressePanel", kunde.getadresse()); 36

37 UMSETZUNG MIT WICKET Behaviors Ein Behaviorist ein verkapseltes Verhalten, mit der eine Komponente erweitert werden kann und das bei bestimmten Events während des Lebenszyklus aufgerufen wird Hinzufügung von JavaScript Events Hinzufügung von Ajax-Verhalten Beispiel plzfield.add(new AjaxFormComponentUpdatingBehavior("onchange") protected void onupdate(ajaxrequesttarget target) { String stadt = plzsucheservice.find(getmodelobject().getplz()); getmodelobject().setstadt(stadt); target.add(getcomponent().getparent().get("stadt")); }}); Vorgefertigte Behaviors AutoCompleteBehavior AjaxSelfUpdatingTimerBehavior... 37

38 UMSETZUNG MIT WICKET Besondere Herausforderungen im industriellen Umfeld Zustandsverwaltung und Lastverteilung In der Regel Lastverteilung über einen Cluster mit mehreren Servern Wicket hält die Seiten und deren Modelle (den Zustand) transparent für den Entwickler in der HTTPSession. Ältere Seiten werden im Standardfall auf die Festplatte ausgelagert Replikation im Cluster kann teuer werden Lösungsoption: Sticky Sessions und Verwendung eines Datenbankbasierten Second-Level Caches für ältere Seiten Sicherheit Sicherheit ist in Wicket per Design eingebaut URLs enthalten keine sensitiven Daten Komponentenpfade sind relativ zur Session URL-Verschlüsselung erlaubt die Realisierung extrem sicherer Webseiten Die Integration von externen Security-Frameworks (z.b. Spring Security) ist extrem einfach 38

39 Agenda Vorstellung Motivation Architekturkonzepte Umsetzung mit Wicket Diskussion 39

40 Vielen Dank Diskussion Andreas Gärtner Dr. Martin Trapp Komponentisierte Web-Frontends

41 Backup

42 UMSETZUNG MIT WICKET Das Model 2 Anwendungsmuster strukturiert eine Webanwendung in die Bausteine Model, View und Controller Webcontainer Browser Request 1 Servlet 3 Controller 2 Response 5 JSP View 4 JavaBean Model Enterprise Resources 42