Suche
Java Magazin Retro

JSF vs. Struts

Bernhard Löwenstein
java_magazin_zeitreise
© Software & Support Media

JSF versus Struts lautete das Titelthema des Java Magazins 10.2005. Warum der Vergleich beider Webframeworks damals die Java-Welt bewegte – und was wir heute daraus lernen können -, erzählen wir in dieser Folge der Java-Magazin-Zeitreise.

Java Magazin 10.2005 - JSF vs. Struts

Die Ausgabe 10.2005 stand ganz im Zeichen vom damals immer stärker aufkommenden JSF. Bis dahin war Struts bei vielen das Webframework erster Wahl, sofern sie sich nicht selbst ein solches geschnitzt hatten. Derartige Eigenentwicklungen waren gar nicht so unüblich, obwohl es bereits Webframeworks wie Sand am Meer gab. Aber die ständige Neuerfindung des Rads gehört nun einmal genauso zu unserer Branche wie die Nullen und Einser. Struts galt laut Chefredakteur Sebastian Meyen als Erlöser und verbreitete sich deshalb relativ rasch. Auch in dem Unternehmen, in dem ich damals tätig war, wurde es eingesetzt. Mich verband damit stets eine gewisse Hassliebe, denn es war meiner Meinung nach nicht besonders intuitiv. Doch dann kam JSF – und die nächste Evolutionsstufe in Sachen Java-Webentwicklung war erreicht. Die Struts-Verantwortlichen sollten jedenfalls mit ihrer damaligen Vorhersage „JSF gehört die Zukunft!“ Recht behalten.

Heute ist JSF die Standardtechnologie für die Entwicklung von Webapplikation innerhalb der Java Enterprise Edition und weit verbreitet. Aufbau und Architektur sind auch recht ordentlich gelungen, lediglich mit einigen neueren Features kann ich mich (noch) nicht anfreunden. So schreckt es mich jedes Mal, wenn ich #{flash.keep…} lese. Und hinsichtlich der Faces Flows wird auch noch viel Überzeugungsarbeit notwendig sein, damit ich sie – und vor allem ihre Umsetzung – ins Herz schließe. In einem der Artikel zum Titelthema stellte Andy Bosch IDEs und Werkzeuge für JSF vor und meinte, dass die Technologie bereits recht gut unterstützt werden würde. Leider sind wir niemals über eine Unterstützung hinausgekommen. Von der Vision, dass die Webdesigner gleich direkt JSPs oder Facelets erstellen, sind wir jedenfalls meilenweit entfernt. Stattdessen erstellen jene statische Webseiten, die dann von den Entwicklern mühsam in die jeweilige View-Technologie portiert werden müssen. Grundsätzlich ist festzuhalten, dass wir im letzten Jahrzehnt in Sachen Applikationsentwicklung deutlich vom Weg abgekommen sind, denn interaktive Anwendungen auf Basis der bestehenden Webtechnologien zu erstellen, ist einfach mühsam. Mit HTML5 wurden zwar die Fähigkeiten des Browsers deutlich erweitert, aber erst ein Webframework wie JSF hebt den Entwicklungsprozess auf ein erträgliches Level.

Ein weiterer interessanter Artikel beschäftigte sich damit, warum so viele Softwareentwicklungsprojekte scheitern. Die Autoren stellten fest, dass sich die Entwickler viel lieber Gedanken über die einzusetzenden Technologien als über die fachlichen Aspekte machen würden, obwohl die Beschäftigung mit zweiterem wesentlich wichtiger für den Projekterfolg wäre. So werden lange bevor die eigentlichen fachlichen Probleme gelöst sind schon verschiedene Frameworks und Applikationsserver evaluiert. Projektentscheidend sind aber meist nicht die Technologieentscheidungen, sondern die Analyse des Anwendungsproblems, die Konzeption der Lösung und die Umsetzung der Fachlichkeit in eine Softwarelösung. Technologien sind immer nur Mittel zum Zweck. Es interessiert den Kunden auch in den wenigsten Fällen, mit welchem Technologiestack sein System letztendlich umgesetzt wird. Es soll ihm bei seiner Geschäftstätigkeit unterstützen und möglichst Vorteile gegenüber der Konkurrenz verschaffen. Punkt, aus, amen!

Getestet wurde weiterhin, wie es um die Interoperabilität von in Java bzw. in .NET implementierten Web Services bestellt ist. Konkret wurden dabei etliche WS-Security-Funktionalitäten unter die Lupe genommen. Wie sich bei den Versuchen eindeutig zeigte, gab es selbst bei einfachen Testfällen (z. B. UsernameToken) noch deutlichen Verbesserungsbedarf. Mittlerweile funktioniert dies zwar recht gut, es lässt sich aber nicht abstreiten, dass in Bezug auf die Web-Services-Standards allerdings einiges schief gelaufen ist. Zu viele Köche verderben den Brei.

Welche Themen wurden sonst noch behandelt? JBI wurde unter dem Motto „Highway to SOA“ vorgestellt, Chris Rupp untersuchte, ob dem klassischen Anforderungsdokument durch die agilen Prozesse der Tod droht, im EJB-Corner brachte Oliver Ihns den Lesern das Interceptor-Konzept näher, Ruby on Rails war ein Artikel gewidmet und db4o wurde als neue Lösung zur einfachen Speicherung von Objekten vorgestellt.

Geschrieben von
Bernhard Löwenstein
Bernhard Löwenstein
Bernhard Löwenstein (bernhard.loewenstein@java.at) ist als selbstständiger IT-Trainer und Consultant für javatraining.at tätig. Als Gründer und ehrenamtlicher Obmann des Instituts zur Förderung des IT-Nachwuchses führt er außerdem altersgerechte Roboterworkshops für Kinder und Jugendliche durch, um diese für IT und Technik zu begeistern.
Kommentare

Hinterlasse eine Antwort

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