Webframeworks
Werbung
Web Webframeworks im Java-Umfeld Welches Webframework soll im nächsten Projekt eingesetzt werden? Webframeworks – eine Kategorisierung Webanwendungen verdrängen immer mehr die klassischen Desktopanwendungen und sind aus dem Alltag nicht mehr wegzudenken – sei es als E-Mail-Client oder für die einfache Verwaltung der Bankkonten über das Web. Zur Realisierung dieser Anwendungen werden Webframeworks eingesetzt, von denen es mittlerweile alleine schon im Java-Umfeld eine fast unüberschaubar große Anzahl gibt [1]. In Foren, Blogs und Fachzeitschriften liest man regelmäßig über neu erschienene Frameworks oder zusätzliche Features. In diesem Zusammenhang fallen häufig Begriffe wie Ajax, Rich Internet Application oder Portal. Doch was bedeuten diese Begriffe eigentlich? Und welches Webframework ist für welches Projekt relevant? Der Artikel gibt einen Überblick über die verschiedenen Frameworktypen und nimmt eine Kategorisierung anhand grundlegender Design- und Entwicklungskriterien vor. von Kai Wähner Der Artikel beschreibt wichtige Designentscheidungen im Umfeld der Entwicklung von Webanwendungen. Darüber hinaus werden die verschiedenen Framework- und Technologietypen näher erläutert. Anschließend wird eine Übersicht der im Markt existierenden Webframeworks gegeben und anhand von Kriterien kategorisiert. Was ist ein Webframework? „Webframework“ wird als Oberbegriff für die Kombination mehrerer Technologien zur Entwicklung von Webanwendungen verwendet. Das Ziel ist dabei, sich wiederholende Tätigkeiten zu vereinfachen, rein technische Aufgabenstellungen (z. B. Kommunikation über Servlets) abzunehmen und die Wiederverwendung von Code zu fördern. Die Fähigkeiten eines Webframeworks sind darauf ausgelegt, schnell Ergebnisse zu erzielen und 34 javamagazin 1 | 2011 lauffähige Webanwendungen zu erstellen. Der Artikel betrachtet Webframeworks, die ohne Zusatzaufwand auf einer JVM lauffähig sind. Ajax (Kasten: „Ajax (Asynchronous JavaScript and XML)“) und entsprechend das Web 2.0 haben sich mittlerweile etabliert und werden durch nahezu alle aktuellen Webframeworks unterstützt – meist durch eigene Ajax-Komponenten, die keine JavaScript-Kenntnisse erfordern. Zumindest aber die Integration von Ajax-Bibliotheken ist immer verfügbar. Das Motto „The right Tool for the right Job“ trifft auch auf Webframeworks zu, daher soll an dieser Stelle keine allgemeine Empfehlung ausgesprochen, sondern die Bewertung der einzelnen Frameworks durch den Leser ermöglicht werden. Kategorisiert werden Webframeworks, die eine große Community verfügen, viele Add-ons anbieten, Lernen und Nachschlagen durch Fachbücher, Blogs und Forenbeiträge ermöglichen und www.JAXenter.de Webframeworks im Java-Umfeld Web Abb.1: Vergleich der Kommunikation ohne und mit Ajax durch Fachzeitschriften sowie IT-Konferenzen in Medien vertreten sind. Es wird nicht der Anspruch erhoben, alle verfügbaren Webframeworks komplett zu analysieren. Stattdessen erhält der Leser einen Überblick über die am Markt verfügbaren Frameworktypen und die Möglichkeit, zu entscheiden, welcher Typ für die Anforderungen in einem konkreten Projekt am besten geeignet ist. Multi-Page vs. Single-Page Der Unterschied zwischen Multi-Page und Single-Page wird in Abbildung 2 dargestellt. Bei einer Multi-PageStruktur besitzt die Webanwendung mehrere Seiten, durch die navigiert wird. Der Benutzer öffnet einen URL im Browser und eine konkrete Seite wird angezeigt. Während der Benutzung werden Hyperlinks verfolgt und Daten übertragen. Jede Seite besitzt daher einen eigenen URL. Durch diese Struktur sind typische „Browserfeatures“ wie Lesezeichen oder Vor- und Zurück-Navigation grundsätzlich verfügbar. Das klassische Beispiel ist Amazon, wo zuerst verschiedene Produkte, die jeweils eine eigene Seite besitzen, betrachtet und gegebenenfalls in den Warenkorb gelegt werden. Dann wird auf mehreren Seiten der Bestellvorgang (Auswahl von Adresse, Zahlungsart und Versandart) durchgeführt. Bei der Single-Page-Struktur hingegen besitzt die Webanwendung nur eine Seite, in der alle Aktionen durchgeführt werden. Durch Panels und Reiter können mehrere Seiten simuliert werden. Oft gibt es aber nur genau eine Seite zur Darstellung der gesamten Anwendung. Der Benutzer öffnet einen URL im Browser, der dauerhaft unverändert bleibt. In der Anwendung öffnen sich oft neue Fenster bzw. Dialoge (z. B. für Warnhinweise). Typische Browserfeatures wie Lesezeichen oder Vor- und Zurück-Navigation sind daher meist nur durch Mehraufwand realisierbar. Auch die Durchsuchbarkeit, die insbesondere für Suchmaschinen notwendig ist, wird erschwert. Als klassisches Beispiel für die Single-PageStruktur sei die Webanwendung Google Mail genannt, wo auf einer einzigen Seite alle Aufgaben zur E-MailVerwaltung durchgeführt werden. Action-based vs. Component-based Ein Webframework kann entweder Action-based (oft auch Request-based genannt) oder Component-based sein (Abb. 3). Bei Action-based Webframeworks wird in dem API ersichtlich, dass eine HTML-Anfrage geparst und eine HTML-Antwort erzeugt werden soll. Jede Anfrage eines Nutzers ist eine eigene Aktion. Für jede Aktion wird genau ein Objekt definiert, das Anfragen entgegennimmt und verarbeitet. Der Ablauf ist dadurch sehr linear, als Einstiegspunkt für Interaktionen wird ein Servlet oder eine Aktion mit allgemeinen Attributen (z. B. URLs, Formulare etc.) genutzt. Vorteile dieses Konzepts sind die relativ simple Entwicklung, die Möglichkeit des einfachen Testens im Webbrowser sowie einfaches Verwalten von Lesezeichen, da jede Aktion einen URL darstellt. Demgegenüber steht der Nachteil, www.JAXenter.de Abb. 2: Vergleich der MultiPage- und SinglePageStruktur Anzeige Web Webframeworks im Java-Umfeld Abb. 3: Vergleich des Action-based- und Component-based-Konzepts Abb. 4: Vergleich des clientzentrischen und serverzentrischen Ansatzes Ajax (Asynchronous JavaScript and XML) Ajax bezeichnet ein Konzept der asynchronen Datenübertragung zwischen Webbrowser und Server (Abb. 1). Dabei wird ermöglicht, im Hintergrund weitere Daten vom Server zu laden, während eine Seite im Browser angezeigt wird. Diese Daten werden verwendet, um mittels JavaScript die aktuelle Seite zu aktualisieren. Da die Seite nicht jedes Mal vollständig neu geladen werden muss, kann der Benutzer flüssiger mit der Anwendung arbeiten. Technisch betrachtet bezeichnet Ajax eine Menge von Technologien, die zur Webentwicklung eingesetzt werden. HTML wird für die Darstellung verwendet. Der Browser wandelt es in einen DocumentObject-Model-(DOM-)Baum um, der mittels JavaScript modifiziert werden kann, um die dynamische Darstellung von Inhalten zu ermöglichen. Zur asynchronen Kommunikation mit dem Server wird das XMLHttpRequestObjekt eingesetzt und in der Regel entweder XML, JSON oder reiner Text als Datenformat verwendet. Ein großer Vorteil von Ajax ist, dass kein Browser-Plug-in benötigt wird – lediglich JavaScript muss im Webbrowser aktiviert sein. Allerdings entstehen durch das neue Programmierparadigma auch einige Probleme, die von JavaScript-Bibliotheken oder Webframeworks „bereinigt“ werden müssen: 36 javamagazin 1 | 2011 dass die Konfiguration schon bei relativ kleinen Seiten unübersichtlich wird, da jede Aktion ein eigenes Objekt besitzt und deshalb auch ein eigenes Mapping notwendig ist. Somit muss trotz einfacher Seitenstruktur sehr viel Konfiguration verwaltet werden. Bei Component-based Webframeworks abstrahiert das API im Gegensatz zur Action-based-Variante vom Anfrage-/Antwortkonzept und behandelt die Webanwendung als Sammlung von Komponenten mit jeweils eigener Darstellung und eigenen Aktionen. Die Anfrage wird nicht an die Aktion, sondern an die Komponente geleitet, dort verarbeitet und in der Oberfläche angezeigt. Es entsteht kein linearer Ablauf. Zusammengehörende Typen von Informationen (z. B. Login, Logout, GetAccount) werden in Gruppen gesammelt (z. B. AccountController). Somit kann ein Objekt für mehrere Aktionen verantwortlich sein. Ein großer Vorteil ist der schnelle Einstieg für Entwickler ohne Erfahrung in der Webentwicklung, da das API Java-Desktopanwendungen (z. B. Swing) ähnelt. Das ermöglicht auch die einfachere Erstellung von eigenen Komponenten und deren Wiederverwendung. Des Weiteren ist die Konfiguration übersichtlich, da nicht für jede Aktion ein eigener Controller notwendig ist. Den Vorteilen steht der Nachteil gegenüber, dass der Entwickler auch die oft komplexe Abstraktion des Webframeworks verstehen muss, um die Features ausnutzen und Fehler nachverfolgen zu können. Die Entscheidung für ein Action-based oder Component-based Webframework hängt also vom Workflow der Webanwendung ab. Während Komponenten sehr gut einsetzbar sind, wenn Wiederverwendung und komplexe Abläufe eine große Rolle spielen (z. B. bei einer großen Webanwendung einer Bank mit vielen ähnlichen Masken), eignet sich das Anfrage-/Antwortkonzept be- ■■ Die Funktionalität der „Zurück“-Schaltfläche des Browsers ist schwer zu gewährleisten, da Webbrowser normalerweise nur jeden neuen URL in ihrer Historie abspeichern. ■■ Bei schlechter Programmierung besteht die Gefahr, dass ein Client öfters Anfragen an den Server senden muss, da es durch die Aufteilung auf mehrere Bereiche einer Seite oft auch mehrere unabhängige Events gibt. Dadurch wird die Auslastung des Webservers spürbar erhöht. ■■ Das Setzen eines Lesezeichens auf einen ganz bestimmten Zustand einer Webanwendung muss nun explizit vom Entwickler realisiert werden. ■■ Zusätzlicher Aufwand ist notwendig, um die Webanwendung einer Suchmaschine zugänglich zu machen. JavaScript-Bibliotheken wie jQuery oder Prototype ermöglichen den Einsatz von Ajax durch bereits geschriebene JavaScript-Kontrollelemente, wodurch Ajax-basierte Webanwendungen mit deutlich weniger Entwicklungsaufwand realisiert werden können. Allerdings sind im Gegensatz zu Webframeworks im Java-Umfeld immer noch Low-Level-Programmierkenntnisse in JavaScript erforderlich. Wann der Einsatz einer JavaScript-Bibliothek anstatt eines Webframeworks ausreichend sein kann, wurde unter [2] ausführlich beschrieben. www.JAXenter.de Webframeworks im Java-Umfeld Web sonders für lineare Abläufe, z. B. für einen einfachen Onlinefragebogen. Client-centric vs. Server-centric Frameworktypen Webanwendungen existieren je nach Einsatzgebiet in verschiedenen Größen und beanspruchen dementsprechend auch unterschiedlichen Zeitaufwand zur Realisierung (Abb. 5). Für jede dieser Arten von Webanwendung gibt es geeignete Webframeworks. Je nach Frameworktyp unterscheiden sich sowohl die Entwicklung der Webanwendung als auch die Benutzung durch den Endanwender. Im Folgenden werden die unterschiedlichen Typen vorgestellt. www.JAXenter.de Abb. 5: Kategorisierung von Webframeworks Abb. 6: Einordnung der Webframeworks bezüglich Frameworktyp und Komplexität Anzeige TRAINING Wichtig ist des Weiteren die Unterscheidung zwischen dem clientzentrischen und dem serverzentrischen Ansatz (Abb. 4). Beim clientzentrischen Ansatz werden die gesamte Oberfläche und Steuerungslogik beim Start auf den Client geladen. Das ist insbesondere bei Anwendungen sinnvoll, die über einen längeren Zeitraum benutzt werden, da so in der Summe weniger Daten zwischen Client und Server ausgetauscht werden. Beispielsweise startet der Mitarbeiter in einer Bank die Anwendung zur Verwaltung von Kundendaten morgens und arbeitet den ganzen Tag mit derselben Oberfläche. Diese muss nicht jedes Mal neu geladen werden, wenn eine neue Seite aufgerufen wird, sondern ist sofort verfügbar. Beim Wechsel zu einem anderen Kunden müssen statt der gesamten HTML-Oberfläche nur noch die Kundendaten (z. B. im XML-Format) vom Server übertragen werden. Beim serverzentrischen Ansatz hingegen wird die Darstellung der Oberfläche auf dem Server (z. B. durch den Aufruf einer Java-Methode) erstellt, an den Client übertragen und dann dort dargestellt (z. B. eine HTML-Seite, die Kundendaten enthält). In der oben genannten Bankanwendung müsste somit bei jedem Seitenwechsel (z. B. zur Auswahl eines anderen Kunden) neben den Kundendaten auch die HTMLOberfläche jedes Mal erneut vom Server übertragen werden, wodurch die Ladezeiten spürbar länger werden. Der serverzentrische Ansatz ist sinnvoll, wenn die Steuerungslogik aus Sicherheitsgründen oder wegen sehr leistungsschwachen Clients nicht vom Server ausgelagert werden soll. Ein weiterer Anwendungsfall ist der Einsatz von Clients ohne Browser, da hier die technische Implementierung auf Clientseite nicht bekannt sein muss. Das ermöglicht z. B. den Einsatz auf Mobiltelefonen ohne Browser, die nur Java ME unterstützen. Weitere wichtige Begriffe aus dem Umfeld von Webanwendungen werden im Kasten „Kriterien unabhängig von der Auswahl eines Webframeworks“ beschrieben. Sie haben keinen direkten Einfluss auf die Auswahl eines Webframeworks, da ihre Eigenschaften nicht nur die Oberfläche, sondern die gesamte Anwendung betreffen. Professional Scrum Master mit Ken Schwaber am 8. + 9.2.2011 in Frankfurt am Main Advanced TDD Intensiver Hands-on Kurs mit Bob Martin am 21. + 22.2.2011 in Karlsruhe Weitere Infos unter www.andrena.de Web Webframeworks im Java-Umfeld Fat Client Fat Clients besitzen die klassische Optik von JavaAnwendungen und verwenden Textfelder, Buttons, Checkboxen usw. Neben der Oberfläche wird auch die eigentliche Verarbeitung der Geschäftslogik auf dem Client vollzogen, nur die Daten werden auf dem Server gespeichert. Fat Clients werden beispielsweise mit Swing oder Eclipse RCP realisiert – und nicht mit Webframeworks. Der Begriff dient daher in diesem Artikel nur zur Abgrenzung. Klassische Webanwendung Eine klassische Webanwendung besitzt in der Regel eine Multi-Page-Struktur sowie die von Beginn der Internetära an bekannte HTML-Oberfläche. Die An- Kriterien unabhängig von der Auswahl eines Webframeworks Die folgenden Kriterien betreffen die gesamte Anwendung und nicht nur die Auswahl des Webframeworks zur Realisierung der Oberfläche. Plattformunabhängigkeit Plattformunabhängigkeit bedeutet, dass die Applikation unabgängig von folgenden Faktoren ausgeführt werden kann: ■■ Betriebssystem (z. B. Windows, Linux, Unix, Mac OS X) ■■ Application-Server (z. B. WebSphere, JBoss)/Webcontainer (z. B. Tomcat, Jetty) ■■ Webbrowser (z. B. Internet Explorer, Firefox, Safari, Chrome) ■■ Datenbank (z. B. DB2, MySQL, „NoSQL“) ■■ Programmiersprache (z. B. Java, Groovy, Scala) Mehrkanalfähigkeit Eine Webanwendung ist mehrkanalfähig, wenn sie über mehrere Kommunikationswege ausgeführt werden kann. Dabei ist ein großer Teil des entwickelten Codes für alle Kanäle nutzbar. Folgende Ziele werden erreicht: ■■ Reduzierung der Entwicklungskosten ■■ Schnellere Auslieferung von neuen Funktionen und/oder Kanälen ■■ Bessere, einheitlichere Benutzbarkeit der unterschiedlichen Kanäle Zu unterscheiden sind zwei Arten der Mehrkanalfähigkeit, die unabhängig voneinander in unterschiedlichen Kontexten betrachtet werden. Mehrkanalfähige Consumer-Anwendungen ermöglichen die Benutzung auf diversen Endgeräten wie Desktop, Laptop, Smartphone oder TV. Auf allen Endgeräten wird dieselbe Funktionalität angeboten. Die Darstellung und Benutzung ist ähnlich. Dabei treten in der Praxis allerdings einige Probleme auf, z. B. enorm unterschiedliche Displaygrößen, verschiedene Eingabemethoden oder die ausschließliche Unterstützung weniger Multimediaformate. Bei Enterprise-Anwendungen bedeutet Mehrkanalfähigkeit die Wiederverwendung von Komponenten in verschiedenen Prozessen. Für jeden Kanal kann dann ein eigener Prozessablauf spezifiziert werden. Für diese Komponenten gelten besonders hohe Anforderungen an die Unabhängigkeit und Integrierbarkeit in verschiedene Prozesse. 38 javamagazin 1 | 2011 wendung wird serverzentrisch realisiert. Die gesamte Geschäftslogik wird über Anfrage-/Antwortkommunikation durch den Server verarbeitet, wobei die Webanwendung nur die Oberfläche (d. h. das vom Server empfangene HTML) darstellt. Elementare, vom Desktop bekannte Features wie Drag and Drop oder der Zugriff auf die Festplatte und Betriebssystemfunktionen fehlen in klassischen Webanwendungen. Die Konsequenz ist mangelnde Benutzerfreundlichkeit. Immerhin muss durch den Einsatz von grundsätzlichen Ajax-Funktionen nur noch der aktualisierte Bereich der Seite neu geladen werden. Die gute Benutzbarkeit einer Desktopanwendung wird dadurch allerdings nicht erreicht. Klassische Webanwendungen benötigen kein Plug-in und laufen in jedem Browser. Allerdings entste- Offlinefähigkeit Offlinefähigkeit ermöglicht einer Webanwendung, auch ohne Internetverbindung funktionsfähig zu sein. Zur Realisierung sind zwei Möglichkeiten gegeben, die unabhängig von einem konkreten Webframework eingesetzt werden können. JavaScript-Caching kann verwendet werden, sofern Daten nur kurzfristig auf Clientseite gespeichert werden müssen. Dabei werden die Daten im Arbeitsspeicher zwischengespeichert – nach einem Browserneustart oder Absturz des Systems sind die Daten daher verloren. In der Oberfläche können neue Daten auch eingegeben werden, wenn keine Internetverbindung vorhanden ist. Die Daten werden später mit dem Server synchronisiert, beispielsweise durch einen Button-Klick. Diese Lösung benötigt eher geringen Aufwand und wird durch JavaScript-Bibliotheken realisiert, z. B. durch jCache [3]. Ein möglicher Anwendungsfall sind Einstellungstests von Bewerbern, die Aufgaben über eine Weboberfläche bearbeiten. Im Enterprise-Umfeld ist die JavaScript-Caching-Lösung allerdings oft nicht ausreichend. Gears (früher Google Gears) ermöglicht als Browser-Plug-in die Offlineverwendung von Webanwendungen. Dadurch können Daten bei fehlender Internetverbindung auch auf Clientseite persistiert werden. In Zukunft soll allerdings laut Google auf HTML5 gesetzt werden, deswegen wurde die Weiterentwicklung von Gears eingestellt. Der Support endet allerdings nicht, da bereits viele Webanwendungen Gears produktiv einsetzen [4]. HTML5 ist in den meisten Browsern noch nicht oder nur teilweise implementiert. Architekturänderungen zur Realisierung von Offlinefähigkeit Die Realisierung von Offlinefähigkeit erfordert ein Umdenken bei der Architektur, da neue Fragen entstehen, die bei klassischen „Online“Webanwendungen nicht auftreten: ■■ Welche Funktionalitäten sollen auch offline verfügbar sein? ■■ Wie soll die Datenschicht auf Clientseite isoliert werden (z. B. durch eine lokale Datenbank)? ■■ Soll das Wechseln zwischen Online- und Offlinemodus manuell oder automatisch erfolgen? ■■ Wie und wann werden die Daten synchronisiert (z. B. manuell oder im Hintergrund)? Ausführliche Erläuterungen zu diesen Fragestellungen sind unter [5] zu finden. www.JAXenter.de Ein Portal kann zusätzlich zu einem Webframework eingesetzt werden. Unabhängig vom ausgewählten Produkt entsteht dadurch ein erheblicher Mehraufwand und höhere Komplexität. Portale stellen Informationen verschiedener Anwendungen (Standardsoftware, Individualsysteme, Webseiten, externe Systeme) auf eine einheitliche Art dar und werden eingesetzt, um Informationen, Personen und Prozesse über organisatorische Grenzen hinweg in Unternehmen zu integrieren. Portale werden auf einem Portalserver deployt. Neben Webframeworks zur Entwicklung der eigentlichen Oberflächen von Anwendungen wird eine Portalsoftware benötigt. Dabei konkurrieren sowohl kommerzielle Produkte wie IBM-WebSphere-Portal und Open-Source-Produkte wie Liferay-Portal um die Kunden. Portlets Portlets sind der De-facto-Standard für die Realisierung eines Portals und sind in den JSRs 168 und 286 spezifiziert. Sie definieren beliebig kombinierbare Komponenten einer Benutzeroberfläche, die von dem Portalserver angezeigt und verwaltet werden. Jede Anwendung, die im Portal dargestellt werden soll, wird in ein Portlet integriert. Die Portlets können auch untereinander Informationen austauschen und dadurch auf Zustände anderer Anwendungen entsprechend reagieren. Detaillierte Informationen zum Portlet-Standard gibt es unter [6]. Vorteile eines Portals Wegen des erheblichen Mehraufwands beim Einsatz eines Portals im Gegensatz zur Entwicklung von einzelnen Webanwendungen ist die Einführung insbesondere bei großen Anwendungslandschaften sinnvoll. Ein Portal bietet folgende Vorteile: ■■ Integration: Die Funktionen und Daten von Anwendungen können in andere Komponenten integriert werden. ■■ Zusammenarbeit: Eine Aktion in einer Anwendung kann Änderungen des Zustands von anderen Anwendungen hervorrufen. ■■ Single-Sign-on: Ein Benutzer muss sich nur einmal anmelden und kann dann alle integrierten Anwendungen, für die er die Zugriffsrechte besitzt, verwenden. ■■ Personalisierung: Die Darstellung der Oberfläche kann durch den Benutzer oder das System individuell angepasst werden. Der Benutzer kann das Look and Feel seinen persönlichen Wünschen anpassen, beispielsweise bezüglich Inhalt, Struktur oder grafischer Darstellung. Das System kann basierend auf Metadaten den am besten zum Benutzer passenden Inhalt, z. B. passende Newsmeldungen oder die am häufigsten genutzten Anwendungen, anzeigen. Software Engineer Java (m/w) Ref.-Nr.: 10/2010 Wir wachsen kontinuierlich weiter und suchen zur Unterstützung unserer Entwicklungsabteilung in Berlin ab sofort einen Software Engineer Java! Zu Ihren spannenden Aufgaben bei Axway gehört die Mitarbeit in eigenverantwortlichen, agilen und internationalen Java Entwicklungsteams. Sie passen zu uns, wenn Sie nach einem erfolgreich abgeschlossenen Studium der Informatik oder einer vergleichbaren Fachrichtung bereits Berufserfahrungen gesammelt haben. Neben Kenntnissen der Java Entwicklung verfügen Sie über Wissen der Entwicklung von Eclipse Plug-Ins oder von BackendApplikationen. Sichere Deutsch- und Englischkenntnisse in Wort und Schrift, Teamorientierung, eine selbständige und kreative Arbeitsweise sowie Qualitätsbewusstsein runden Ihr Profil ab. Sie haben Lust, sich in einem globalen IT-Unternehmen mit flachen Hierarchien zu engagieren? Sie legen Wert auf eine attraktive Vergütung und großen Gestaltungsfreiraum mit persönlichen Entwicklungsmöglichkeiten? Dann kommen Sie zu uns! Wir freuen uns auf Ihre Bewerbung! Axway ist die Business Interaction Networks Company und der einzige Anbieter auf dem heutigen Markt, der sämtliche geschäftliche Interaktionen – E-Mail, Dateien, Nachrichten, Services, Events und Prozesse – managen, betreiben, sichern und überwachen kann. Bei über 11.000 Kunden in mehr als 100 Ländern beschleunigt Axway den Geschäfts- erfolg mit Multi- Enterprise-Transaktionen, -Prozessen und -Integrationen. Axway bietet seinen Kunden Professional Services und Managed Services sowie Cloud Computing und Software as a Service (SaaS). Axway ist in 20 Ländern vertreten und hat seinen Hauptgeschäftssitz in Phoenix, Arizona (USA). Bitte senden Sie Ihre aussagekräftigen Unterlagen mit Angaben zu Ihren Gehaltsvorstellungen und möglichem Eintrittstermin an: Axway GmbH Human Resources, Kurfürstendamm 119, 10711 Berlin Tel: (0)30 890100 Email: [email protected] www.axway.de Web Webframeworks im Java-Umfeld Webframework Frameworktyp Technologietyp Eingesetzte Technologien Action- vs. Componentbased Java Server Faces (JSF) Klassische Webanwendung Mixed Language Java, XML, XHTML (seit JSF 2.0, vorher JSP) Wicket Klassische Webanwendung Mixed Language Tapestry Klassische Webanwendung Struts Plug-in notwendig Browserunabhängig Componentbased Nein Nein JSF ist ein eigener Standard (JSF 2.0: JSR 314). Sehr viele „Add-ons“ verfügbar: Verschiedene Impementierungen (z. B. Suns Mojarra, Apaches MyFaces), Komponentenbibliotheken (z. B. RichFaces, ICEFaces), CaptainCasa (ermöglicht die einfach Erstellung eines Rich Clients durch GUI-Editor und Abkopplung von JSF Lifecycle), JBoss Seam (ermöglicht einfache Integration mit Geschäftslogik, z. B. durch EJBs). Sehr gut in Portlets integrierbar durch JSR 301 bzw. 329 (Portlet-Bridge) für JSF 1.2, Liferay Portletfaces bzw. JBoss PortletBridge für JSF 2.0. Java, XHTML Componentbased Nein Nein Sehr gute Trennung zwischen Designer und Entwickler durch „Wicket-IDs“. Starke Orientierung am OO-Konzept/SwingProgrammierung Mixed Language Java, auf XHTML basierende Markup-Sprache „TML“ Componentbased Nein Nein Stark Annotation-basiert. Jeder Versionssprung bedeutete bisher Inkompatibilität zu älteren Versionen. Klassische Webanwendung Mixed Language Java, XHTML, JSP Action-based Nein Nein Struts 2 wurde bis 2008 unter dem Namen „WebWork 2“ entwickelt. Spring MVC Klassische Webanwendung Mixed Language Java, XHTML, JSP, XML Action-based Nein Nein Teil des Spring Frameworks. Einfache Integration vieler View-Technologien möglich (z. B. JSP, Struts Tiles, Freemarker) Google Web Toolkit (GWT) Rich Client Java Java, Design optional in XML Componentbased Nein Ja Clientzentrischer Ansatz. Viele „Add-ons“ verfügbar: Komponentenbibliotheken (z. B. SmartGWT, ExtGWT), GUI-Builder (z. B. GWTDesigner) ZK Rich Client Java Java, Design optional in XML (eigene MarkupSprache „ZUML“ Componentbased Nein Ja Leichtgewichtiger, serverzentrischer Ansatz (realisiert durch eine „intelligente HTML-Seite“, die beim Start an den Client gesendet wird und eine ZK-spezifische Client-Engine besitzt) JavaFX RIA Skript­ sprache JavaFX Script Componentbased Java Runtime Environment (JRE) Ja Ausrichtung auf mehrkanalfähige ConsumerAnwendungen (Common Profile mit Basisklassen für alle Anwendungen, zusätzlich Desktop-, Mobile- und TV-Erweiterungen, 2011 wird sich JavaFX vollständig verändern. Die Skriptsprache JavaFX Script wird durch ein Java-API ersetzt. Außerdem soll auch HTML5 nativ unterstützt werden, wodurch die Plug-inNotwendigkeit entfällt. Adobe Flex RIA Skript­ sprache MXML, ActionScript Componentbased Adobe Flash Player Ja Wird nicht in Java-Bytecode übersetzt, sondern erzeugt eine .SWF-Datei. Mangels Alternativen zu JavaFX im RIA-Bereich, und da die Integration zu Java (z. B. durch GraniteDS) mittlerweile einfacher geworden ist, wurde Flex trotzdem in diesen Artikel aufgenommen. Flex ist Open Source, Runtime (Flash Player) und Tools sind proprietär und kommerziell – dafür aber auch schon sehr ausgereift. Durch Tools wie GraniteDS gut mit Java Backend integrierbar. Roma Framework CRUD-Client Java Java, diverse weitere (siehe Besonderheiten) Componentbased Nein Nein Metaframework: Für jeden Bereich wie View, Model oder Reporting kann eine beliebige Technologie eingesetzt werden (z. B. für die View liegen Implementierungen für JSP und Echo2 vor, HTML und Swing sind in Arbeit). Spring Roo CRUD-Client Java Java Action-based Nein Nein Basiert auf Spring, JPA und AspectJ. Entwicklung hauptsächlich in Roo Shell (interaktive Konsole). Frei verfügbare IDE „SpringSource Tool Suite“. Entfernen von Spring Roo-spezifischem Quellcode möglich (AspectJ-Code wird dann in die eigentlichen Klassen verschoben). Grails CRUD-Client „Moderne“ JVMSprache Groovy, JSP oder GSP Action-based Nein Nein Groovy ist neben Java die zweite Standardsprache für die JVM (JSR 241) Effiziente Entwicklung durch Groovy-Feaures möglich. Basiert auf Spring, Hibernate und Sitemesh. Lift CRUD-Client „Moderne“ JVMSprache Scala, XHTML Componentbased Nein Nein Effiziente Entwicklung durch Scala-Features möglich. Besonderheiten Tabelle 1: Überblick über Webframeworks 40 javamagazin 1 | 2011 www.JAXenter.de Webframeworks im Java-Umfeld Web hen insbesondere beim Einsatz von Ajax oft Kompatibilitätsprobleme zwischen verschiedenen Browsern. Rich Internet Applications (RIA) Bei einer RIA läuft die Oberfläche vollständig auf dem Client ab. Durch die Verwendung des clientzentrischen Konzepts wird bei diesem Frameworktyp stärker zwischen Oberflächendarstellung und Daten getrennt. Eine RIA hat eine Single-Page-Struktur und verfügt über viele Eigenschaften von Desktopanwendungen wie Offlinefähigkeit, Drag and Drop oder Festplattenzugriff. Zudem ermöglichen RIAs die Realisierung von hohen Anforderungen an die Oberfläche, beispielsweise durch Animationen, Effekte oder Multimediafeatures. Daher wird statt Java auch eine neue Skriptsprache zur Entwicklung benötigt. Die Webanwendung ist meistens nicht mehr als solche zu erkennen und kann in der Regel auch außerhalb des Browsers gestartet werden. Aufgrund dieser revolutionären Darstellung entstehen aber auch einige Nachteile für Entwickler und Anwender: CRUD-Client CRUD ist das Akronym für „Create, Read, Update and Delete“. CRUD-Clients ermöglichen in erster Linie das Anzeigen, Suchen und Bearbeiten von Datensätzen und sind daher sehr gut zur Verwaltung von Daten geeignet. Die Optik entspricht dabei einer klassischen Webanwendung. Typische Browserfeatures wie Lesezeichen oder Vorwärts- und Rückwärtsnavigation sind zumeist von Grund auf in einer Multi-Page-Struktur verfügbar. Im Gegensatz zu den zuvor beschriebenen Frameworktypen wird mit diesen Webframeworks nicht nur die Oberfläche erschaffen, sondern die gesamte Anwendung (d. h. die übliche Drei-SchichtenArchitektur mit Oberfläche, Geschäftslogik und Datenhaltung) auf einmal realisiert. Die Webanwendung ist dabei serverzentrisch. CRUD-Frameworks besitzen folgende Eigenschaften, wodurch sehr schnell Ergebnisse erzielt werden können: Bei Rich Clients wird im Gegensatz zu RIAs clientseitig kein Plug-in benötigt. •Die gesamte Webanwendung muss beim ersten Start sowie bei jeder neuen Version vollständig heruntergeladen werden. •Auf dem Client muss ein Plug-in des jeweiligen Webframeworks installiert sein, wodurch als Nebeneffekt auch Kompatibilitätsprobleme zwischen verschiedenen Browsern eliminiert werden. •Plattformneutralität geht verloren, falls das Plug-in nicht für alle gewünschten Systeme verfügbar ist. •Typische Browserfeatures wie Lesezeichen oder Vorwärts-/Rückwärtsnavigation fehlen oft. •Der (Java-)Entwickler muss eine neue Programmiersprache lernen. •Convention over Configuration: Konfiguration ist nur notwendig, falls die Default-Konfiguration nicht ausreichend ist. •Code-Generation: Durch die Erstellung des Models für die Persistierung in der Datenbank werden auch Anwendungslogik und Oberfläche für dieses Model sofort mit erzeugt. •Objekt-UI-Mapping: Für Attribute des Models wird automatisch in der Oberfläche die passende Darstellung angezeigt, z. B. für den Datentyp java.util.Date ein Kalender-Widget. •Moderne Sprache: Oft basieren Frameworks für CRUD-Clients auf „modernen“, auf JVM basierenden Programmiersprachen, um hohe Effektivität zu erreichen und die Menge des Quellcodes zu reduzieren. Rich Client Der Rich Client vermischt die Eigenschaften der beiden bereits genannten Architekturtypen. Die Oberfläche wird beim Start immer noch großteils oder vollständig auf den Client geladen, die Optik aber entspricht der einer klassischen Webanwendung. Das Ziel ist daher im Gegensatz zu RIAs nicht die Neuausrichtung der Oberflächendarstellung von Webanwendungen, sondern die Verbesserung bei der Nutzung der bereits verbreiteten und akzeptierten Darstellung. Die Oberfläche wird entweder clientzentrisch oder serverzentrisch realisiert und besitzt meist eine Single-Page-Struktur. Auf Clientseite wird im Gegensatz zu RIAs kein Plug-in benötigt, auch das Lernen einer speziellen Skriptsprache ist nicht notwendig. Dennoch können einige RIA-Features wie Drag and Drop mittlerweile relativ einfach mit Ajax-Komponenten realisiert werden. www.JAXenter.de Anzeige Web Webframeworks im Java-Umfeld Zusätzlich zu den vorgestellten Frameworktypen werden manchmal auch Portale eingesetzt (Kasten: „Portal“). PortalTechnologietyp Die verschiedenen Webframeworks unterscheiden sich in den eingesetzten Technologien, mit denen Webanwendungen realisiert werden: •Java: Die Programmierung erfolgt nahezu ausschließlich in Java. Die Oberfläche (HTML und JavaScript) wird automatisch erzeugt, Konfiguration mit XML ist nur minimal oder gar nicht notwendig. •Mixed Language: Die Programmierung erfolgt durch Java und HTML, die Konfiguration durch XML. JavaScript wird z. B. durch frameworkeigene Elemente (z. B. Tag Libraries) automatisch erzeugt. •„Moderne“ JVM-Sprache: Die Programmierung erfolgt mit einer „No-Java“-Programmiersprache wie Groovy oder Scala, die in Java-Bytecode übersetzt wird. Dadurch ist der Zugriff auf die Java-Bibliotheken ohne Umwege möglich. •Skriptsprache: Die Programmierung erfolgt vollständig in einer Skriptsprache, die explizit für die Erstellung von RIAs entwickelt wurde. Dadurch wird u. a. das bidirektionale Binding zwischen Client und Server stark vereinfacht. Zugriff auf die Java-Bibliotheken ist meist nur über Umwege möglich. Überblick über konkrete Webframeworks Tabelle 1 gibt einen Überblick über verschiedene im Markt verfügbare Webframeworks. Dort werden neben dem Frameworktyp und den eingesetzten Technologien weitere Besonderheiten der einzelnen Frameworks beschrieben. Browserunabhängigkeit bedeutet dabei, dass die Webanwendung nicht für jede Version jedes Browsers angepasst werden muss. Diese Anpassungen sind insbesondere beim Einsatz von JavaScript aufwändig. Abbildung 6 gibt noch einmal einen visuellen Überblick. Mit „Komplexität“ ist dort die Einarbeitung für Java-Entwickler gemeint und beinhaltet z. B. den Aufwand, um das Framework zu beherrschen oder neue Technologien und Programmiersprachen zu erlernen. Kombination verschiedener Sprachen und Webframeworks Durch Plug-ins können verschiedene Webframeworks kombiniert oder neben Java auch noch andere moderne Programmiersprachen in Webframeworks eingebunden werden. Die Anzahl an Plug-ins ist nur schwer überschaubar und wächst immer weiter, und auch die angebotenen Funktionalitäten unterscheiden sich. Die Qualität bewegt sich dabei zwischen unbenutzbar und sehr gut. Eine Auswahl verfügbarer Plug-ins mit sinnvollen Kombinationen: •Gracelets [7]: Eine Domain Specific Language (DSL), mit der JSF-Views mit Groovy statt XHTML rea- 42 javamagazin 1 | 2011 lisiert werden können. Außerdem können Groovy Closures statt der JSF Expression Language verwendet werden. •JSF Flex [8]: Flex-Komponenten können als JSFKomponenten genutzt werden. Der Entwickler erzeugt dabei eine JSF-Komponente, das Plug-in generiert dann die zugehörigen Flex-Ressourcen (z. B. MXML-Code, SWF-Datei) und kümmert sich um die Integration. •GwtAI [9]: Ermöglicht die Integration von Applets (und damit auch JavaFX) in GWT. Zusammenfassung Die Anzahl der verfügbaren Webframeworks ist kaum überschaubar. Die Wahl des Frameworktyps hat große Auswirkungen auf Benutzbarkeit und Antwortzeiten einer Webanwendung, allerdings sind der Aufwand und die Komplexität bei der Auswahl eines neuen Frameworks nicht zu unterschätzen. Die Entscheidung für oder gegen ein Webframework muss gut überlegt sein – eine sinnvolle Entscheidung ist nur möglich, wenn ein Überblick über die im Markt verfügbaren Webframeworks vorhanden ist. Ausblick In der kommenden Ausgabe des Java Magazins werden verschiedene Projektszenarien mit sehr unterschiedlichen Anforderungen aus dem Unternehmensalltag vorgestellt und eine Bewertung bezüglich der Eignung der verschiedenen Webframeworkkategorien durchgeführt. Dabei wird erläutert, warum sich für bestimmte Anforderungen konkrete Webframeworks besser eignen als andere. Kai Wähner ist als IT-Consultant bei MaibornWolff et al tätig. Seine Schwerpunkte liegen in den Bereichen JEE, EAI und SOA. Außerdem berichtet Kai auf http://www.kai-waehner.de/blog über seine Erfahrungen mit neuen Technologien, IT-Konferenzen und Zertifizierungen. Feedback zum Artikel gerne an [email protected]. Links & Literatur [1] http://en.wikipedia.org/wiki/Comparison_of_web_application_ frameworks [2] Müller, Florian: „Ajax – 360-Grad-Betrachtung“, in Java Magazin 01.2010 [3] http://Plug-ins.jquery.com/project/jCache [4] http://latimesblogs.latimes.com/technology/2009/11/google-gears. html [5] http://code.google.com/apis/gears/gears_faq.html#offlineArchitectures [6] Bosch, Andy: Artikelserie „Portale und Portlets“, in Java Magazin 12.2008–4.2009 [7] http://gracelets.sourceforge.net/ [8] http://code.google.com/p/jsf-flex/ [9] http://code.google.com/p/gwtai/ www.JAXenter.de
