Einsatzgebiete von Webframeworks

Beispiel 4: Externe Unternehmensdarstellung

Anforderungen: Die Webseite eines Reiseveranstalters, die Informationen zum Unternehmen bietet und gleichzeitig als Buchungsplattform dient, basiert auf veralteten Technologien und soll komplett neu entwickelt werden. Im Vordergrund stehen maximale Erreichbarkeit und hohe Nutzerfreundlichkeit.

Lösung: Die Anforderungen entsprechen einer klassischen Webanwendung. Eine „multi-page“-Struktur mit Lesezeichen und Vorwärts-/Rückwärtsnavigation wird benötigt. Nicht gewünscht hingegen sind die Notwendigkeit eines Plug-ins auf dem Client oder Ladezeit beim Start der Anwendung.

Technologieauswahl: Die Auswahl des Webframeworks hängt immer auch von der Größe der zu erstellenden Anwendung ab. Für die konkrete Aufgabe sind verschiedene Frameworks gut geeignet.

Bei kleineren und mittleren Anwendungen können mit Tapestry oder Wicket schnell gute Ergebnisse erzielt werden, da die Programmierung hauptsächlich in Java erfolgt (objektorientiert bei Wicket, annotationsbasiert bei Tapestry). Spring MVC ist eine gute Alternative, falls für die Anwendungslogik (Reisebuchungen, Kundenverwaltung) ebenfalls Spring eingesetzt wird.

Soll hingegen eine sehr große Anwendung entstehen, ist der JSR-Standard Java Server Faces (JSF) die erste Wahl. Neben sehr vielen Komponentenbibliotheken (z. B. ICEFaces, RichFaces, PrimeFaces) sind noch andere sinnvolle Erweiterungen verfügbar, beispielsweise JBoss Seam zur nahtlosen Verbindung von JSF mit anderen Java-EE-Komponenten. Auch die Verbreitung durch Community und Fachliteratur ist bei dieser Technologie dank des Standards am größten. Dadurch ist die Zukunftssicherheit für Bugfixes und Change Requests sowie die Suche nach weiteren Entwicklern höher als bei anderen Frameworks.

Beispiel 5: Große Enterprise-Anwendung für diverse Geschäftsfelder

Anforderungen: Diverse Anwendungen für unterschiedliche Aufgaben erhöhen die Komplexität in einem großen Versicherungsunternehmen. Die verschiedenen Anwendungen, die bisher unterschiedliche Technologien eingesetzt haben, müssen in eine einheitliche Webanwendung integriert werden. Damit sowohl der Versicherungsvertreter vor Ort beim Kunden (auch offline) als auch der Verkäufer im Büro und der Berater im Call-Center auf die Anwendung zugreifen können, wird auch Enterprise-Mehrkanalfähigkeit benötigt. Die Darstellung muss trotz verschiedener Anwendungen einheitlich sein.

Lösung: Hierfür erscheint nur der Einsatz eines Portals sinnvoll, wobei die Auswahl eines geeigneten Portalservers nicht Bestandteil dieses Artikels sein soll. Damit können auch Webanwendungen verschiedener Frameworks in eine Oberfläche integriert werden, denn fast alle aktuellen Frameworks ermöglichen eine Integration in Portlets. Durch das Portal kann auch die Enterprise-Mehrkanalfähigkeit umgesetzt werden, da für jeden Mitarbeiter nur die relevanten Portlets angezeigt werden. Beim Außendienstmitarbeiter erfolgt auf einem kleinen Laptopbildschirm dann ein anderer Prozess und eine andere Darstellung als beispielsweise beim Berater im Call-Center. Durch GEARS wird Offlinefähigkeit in der jeweiligen Webanwendung realisiert. Der Mitarbeiter kann alle relevanten Daten vor Ort beim Kunden speichern und bei der nächsten verfügbaren Onlineverbindung mit dem Server synchronisieren. Eine Migration von GEARS auf den noch nicht fertigen Standard HTML 5 und dessen Features für Offlinefähigkeit wird von Beginn an bei der Planung beachtet.

Technologieauswahl: Bei einer neu hinzukommenden Webanwendung ist zusätzlich zur sonstigen Evaluierung noch zu prüfen, ob und wie einfach sich ein Framework in ein Portlet integrieren lässt. Positiv zu erwähnen ist hier sicherlich JSF, das für JSF 1.2 durch die beiden JSRs 301 und 329 Portlet Bridge for JSF eine sehr gute Unterstützung bietet. Auch für JSF 2.0 sind bereits „Bridge“-Implementierungen von JBoss [8] und Liferay [9] in Arbeit. Der Einsatz verschiedener Webframeworks kann für die unterschiedlichen Portlets natürlich sinnvoll sein, beispielsweise wenn für ein Portlet „RIA-Features“ benötigt werden. Nicht zu unterschätzen ist der zusätzliche Aufwand für die Kommunikation zwischen verschiedenen Portlets.

Empfehlungen

Nach diesen konkreten Beispielen aus dem Unternehmensalltag sollen nun noch einige generelle Empfehlungen zur Auswahl eines Webframeworks gegeben werden.

  • Ein Team sollte sich über mehrere Projekte hinweg auf ein paar wenige, konkrete Frameworks jedes Frameworktyps konzentrieren und diese dafür effizient einsetzen.
  • Alle wichtigen Begriffe, wie beispielsweise „Webframework“ oder „RIA“, sollten vor der Evaluierung in einem Glossar definiert werden, da ansonsten sehr schnell Missverständnisse und unnötige Diskussionen entstehen können.
  • Bei der unüberschaubar großen Anzahl an verfügbaren Webframeworks ist darauf zu achten, dass nicht nur einem Hype gefolgt wird (Kasten: „Hype oder Trend“).
  • Weitere Faktoren, wie etwa das bereits vorhandene Wissen der Mitarbeiter oder politische Aspekte, müssen von Beginn an bei der Evaluierung beachtet werden.

Neben den genannten Empfehlungen sind wichtige Anti-Patterns bei der Auswahl eines Webframeworks zu beachten (Kasten: „Anti-Patterns bei der Auswahl eines Webframeworks“).

Anti-Patterns bei der Auswahl eines Webframeworks

Im Folgenden werden einige Anti-Patterns vorgestellt, die bei der Auswahl eines Webframeworks beachtet werden sollten.

Jede moderne Anwendung muss eine RIA sein!

Meinung: Eine RIA ist modern. Jedes moderne Unternehmen hat RIAs. Der Benutzer möchte unbedingt eine RIA verwenden, statt eine veraltete klassische Webanwendung mit HTML-Oberfläche!

Sachlage: Anwendungen benötigen in erster Linie eine übersichtliche Struktur. Informationen sollen leicht gefunden werden. Die Navigation soll intuitiv und sinnvoll sein. Eine klassische Webanwendung mit einfachen HTML-Links und PDFs zum Download ist dem Benutzer oftmals wichtiger als bunte Optik, Animationen und allemal lieber als lange Ladezeiten, eine Bedienung ohne Menüs und sichtbare Navigation oder unter Umständen sogar die vorherige Installation eines Plug-ins.

Fazit: Eine RIA ist modern und eindrucksvoll, deswegen aber noch lange nicht immer sinnvoll. Der Benutzer möchte in erster Linie eine Anwendung, die seinen Ansprüchen gerecht wird.

Wir haben mehrere Webanwendungen. Dann nehmen wir doch ein Portal!

Meinung: Mit einem Portal kann auf sehr einfache und effiziente Weise eine Menge von Anwendungen zusammengefügt und als eine Einheit dargestellt werden.

Sachlage: Portale dienen der Integration, Zusammenarbeit und Personalisierung von Anwendungen. Diese Ziele müssen allerdings mit enormem Zusatzaufwand bei der Entwicklung erkauft werden, da Portalserver sehr komplexe Produkte sind und jede Webanwendung zusätzlich zu ihren eigentlichen Aufgaben noch für diese „Bonusfeatures“ bereit gemacht werden muss.

Fazit: Ein Portal macht nur dann Sinn, wenn es die Anforderungen der Anwendungslandschaft auch tatsächlich verlangen.

CRUD-Frameworks sind der effizienteste Weg zur neuen Anwendung!

Meinung: Das manuelle Erstellen einer Oberfläche ist unnötiger Aufwand und nicht mehr zeitgemäß. Code-Generation, Convention over Configuration und moderne Programmiersprachen nehmen dem Entwickler sehr viel Arbeit ab.

Sachlage: Für Anwendungen zur Verwaltung von Daten sind CRUD-Frameworks sehr gut geeignet. Wie auch im Erfahrungsbericht unter [10] zu lesen ist, können einige Fallstricke den schnellen Erfolg aber leicht zunichte machen. Gerade bei einem komplexeren Datenmodell sind die Grenzen oft schnell erkennbar. Auch der Aufwand zum effizienten Anwenden einer neuen Programmiersprache ist nicht zu unterschätzen.

Fazit: CRUD-Frameworks sind in erster Linie für CRUD-Clients mit einfachem Datenmodell sehr gut geeignet.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.