Kolumne

EnterpriseTales: MVC 1.0? Wer braucht das schon!

Sven Kölpin, Lars Röwekamp

Bisher war MVC 1.0 als eine der wesentlichen Neuerungen für Java EE 8 gesetzt. Doch mit der diesjährigen JavaOne und der von Oracle dort ausgegebenen Vision für die Zukunft des Enterprise-Java-Standards hat sich das grundlegend geändert. MVC 1.0 soll fallengelassen werden. Stattdessen stehen nun Cloud und Microservices im Fokus. Aber ist das wirklich ein Widerspruch?

Im September hat Oracle auf der JavaOne nach knapp einem Jahr Funkstille seine neuen Pläne für Java EE 8 vorgestellt. Die Zukunft soll in der Cloud und in Microservices liegen. An sich keine schlechte Idee und vielleicht auch die einzig richtige Entscheidung – immerhin werden so die architektonischen Entwicklungen der letzten Jahre im Standard verankert und Java EE bleibt zeitgemäß.

Zur großen Verwunderung vieler fehlte bei Oracles Vorstellung allerdings MVC 1.0 – ein zu JSF alternatives Webframework, das zwei Jahre zuvor im Community Survey [1] noch als hoch bewertetes Feature in die initiale Spezifikationsplanung aufgenommen wurde. Oracles Begründung zum Fehlen von MVC 1.0 lässt sich in einer Neuauflage des Community Surveys finden, der zur Veröffentlichung dieser Kolumne bereits geschlossen ist. Dort heißt es sinngemäß, dass der Trend bei Webanwendungen immer mehr zu clientseitig gerenderten Webanwendungen (Single-Page Applications) zu gehen scheine. Deshalb sei man sich nicht mehr sicher, ob noch die Notwendigkeit für ein alternatives MVC-Webframework bestehe.

Zu den Ergebnissen der Umfrage lesen Sie auch: Java EE ohne MVC: Oracle überträgt JSR 371 an die Community

Warum noch ein Webframework?

Es mag für einige überraschend gewesen sein, dass die Idee eines weiteren Webframeworks überhaupt eine solch große Unterstützung in der Community erfahren hat. Schließlich scheint JSF ja gut zu funktionieren. Es ist seit über zehn Jahren Teil des Standards und in fast jeder EE-Anwendung zu finden. Warum schlägt man also überhaupt ein weiteres Webframework vor?

JSF ist ein Component-based (komponentenbasiertes) MVC-Framework. Diese Art von Webframework zeichnet sich im Wesentlichen durch zwei Attribute aus: serverseitige Komponenten und Abstraktion. Komponentenbasierte Frameworks definieren sowohl ihr Aussehen als auch ihr Verhalten auf der Serverseite (serverseitige Komponenten). Das Framework, also JSF, sorgt dann für die Übersetzung der Komponenten in die für die Darstellung eigentlich benötigten Webtechnologien wie HTML, CSS und auch JavaScript. Diese Abstraktion ermöglicht es, Webanwendungen ohne die Kenntnis der darunterliegenden Technologien zu entwickeln – also Webentwicklung, ohne im Web zu entwickeln.

Abstraktion hat natürlich ihren Preis. JSF ist nicht gerade ein triviales Framework, und spätestens bei der Bugsuche oder bei komplexen Anwendungen müssen doch wieder die unterliegenden Webtechnologien verstanden werden. JSFs Abstraktion führt weiterhin dazu, dass sich neue Technologien und Features in der Regel erst spät integrieren lassen, weil sie erst in den Standard aufgenommen und dort implementiert werden müssen. Beispiele sind u. a. die Integration von Ajax in JSF erst mit Version 2.0 oder die WebSockets-Integration in JSF erst mit Version 2.3. Zusätzlich lassen sich komplett statuslose Webanwendungen durch das serverseitige Programmiermodell nur schwer umsetzen.

MVC 1.0 ist hingegen als Action-based MVC-Framework entworfen worden. Diese Art von Webframework verfolgt einen gänzlich anderen Ansatz als wir ihn von JSF kennen. Eine Abstraktion von Webtechnologien und (serverseitige) Komponenten sucht man hier vergebens. Vielmehr findet man sich in der klassischen Request- und Response-basierten Webentwicklung wieder. Weniger Abstraktion und keine Komponenten führen selbstverständlich dazu, dass Action-based MVC-Frameworks leichtgewichtiger sind als Component-based Frameworks. Durch die fehlende Abstraktionsschicht lassen sich außerdem beliebige Webtechnologien (JavaScript-Frameworks oder WebComponents), Austauschformate (z. B. HTML und JSON) und auch Templating Engines einsetzen. Auch statuslose Webanwendungen können leichter umgesetzt werden, weil aufgrund der fehlenden Komponenten kein serverseitiger Status vorgehalten werden muss. MVC 1.0 bietet mit seinem Action-based Ansatz also eine höhere technologische Flexibilität als JSF, setzt dafür aber auch eine detaillierte Kenntnis über verschiedene Technologien voraus. Damit ist MVC 1.0 die wohl lange überfällige Alternative zu JSF.

Angular - Eine Einführung

Angular – eine Einführung

Manfred Steyer

In diesem Videotutorial erklärt Manfred Steyer alles, was man für einen professionellen Umgang mit Angular benötigt und zeigt anhand eines praxisnahen Beispiels, wie man Services und Dependency Injection integriert, Pipes zur Formatierung von Ausgaben nutzt, Komponenten mit Bindings verwendet, Angular-Anwendungen mit Modulen strukturiert und Routing gebraucht.

Warum nicht einfach SPAs?

Wie Oracle beschrieben hat, lassen sich Webanwendungen mit JAX-RS und dem passenden JavaScript-Framework auch jetzt schon ohne den Einsatz von JSF entwickeln. Die Rede ist dann von Single-Page Applications (SPAs). SPAs zeichnen sich vor allem dadurch aus, dass sie clientseitig gerendert werden. Der Server ist in diesem Fall nur noch Datenlieferant und nicht mehr für das Erzeugen von HTML-Fragmenten aus dem serverseitigen Businesscode zuständig. Templating Engines und serverseitige Webframeworks haben hier ausgedient.

Es ist aber sehr kritisch, SPAs als Allheilmittel der Zukunft anzunehmen. Vor allem im Enterprise-Umfeld sehnen wir uns schließlich nach Standardisierung und Zukunftssicherheit – zwei Eigenschaften, die wir in den letzten Jahren bei JavaScript-Frameworks weniger gesehen haben. Zudem zwingen Single-Page Applications quasi zu RESTful-Architekturen. Auch das ist in der realen Welt nicht immer erstrebenswert.

SPAs sind folglich dann eine Alternative, wenn grundsätzliche architektonische Voraussetzungen vorhanden und rein clientseitig gerenderte Frontends mit komplexer UI-Logik erforderlich sind. In der Realität trifft dies aber aktuell nur bei einem Bruchteil der Enterpreise-Anwendungen zu.

Und Microservices?

Die Idee, Microservices-Architekturen in Java EE zu standardisieren, ist, wie eingangs erwähnt, ein wichtiger und richtiger Schritt für die Zukunft der Java-EE-Plattform. Allerdings ist es genauso wichtig, monolithische Ansätze nicht in Vergessenheit geraten zu lassen – Java EE ist schließlich keine Microservices-Plattform. Das bedeutet, dass RESTful-Architekturen und somit clientseitig gerenderte UIs nicht als universaler Lösungsweg für die Entwicklung von Webanwendungen in der EE-Plattform gesehen werden können und sollten. Leichtgewichtige und serverseitig gerenderte Webapplikationen werden auch zukünftig von Relevanz sein.

Zusätzlich darf nicht vergessen werden, dass Microservices nicht zwingend ausschließliche Datenlieferanten sind. Sie können sehr wohl auch eigene, serverseitig gerenderte UIs zur Verfügung stellen. Dafür muss es in der EE-Plattform aber unbedingt ein leichtgewichtiges Webframework geben, weil Microservices einen vergleichsweise geringen Footprint benötigen. JSF ist für diese Aufgabe nur bedingt geeignet.

Fazit

Action-based MVC-Frameworks sind nichts Neues. Struts und vor allem Spring MVC sind seit Jahren die großen Vertreter in diesem Umfeld. Spring MVC ist dabei JSFs größter Konkurrent in diversen Frameworkvergleichen (z. B. [2], [3]). Der Bedarf nach einem Action-based MVC-Framework und damit die Notwendigkeit für dessen Standardisierung sind also ohne Zweifel gegeben. Einen ähnlichen Weg hat im Übrigen vor Jahren das .NET-Umfeld eingeschlagen. Auch hier leben ein Component-based – ASP.NET Webforms – und ein Action-based – ASP.NET MVC – Webframework nebeneinander.

Nach dem ersten Community Survey 2014 wurde MVC 1.0 stetig vorangetrieben. Die Expert Group hat bereits eine Spezifikation [4] und eine Referenzimplementierung mit dem Namen Ozark [5] veröffentlicht. Beides hat einen vergleichsweise geringen Umfang, weil bewusst stark auf bereits vorhandene Spezifikationen aufgesetzt wurde, wie JAX-RS, CDI oder BeanValidation. MVC 1.0 ist also in keiner Weise als Ballast für die Java-EE-Plattform zu bewerten, selbst wenn wider Erwarten in ein paar Jahren tatsächlich keine Notwendigkeit mehr für Action-based MVC-Frameworks bestehen sollte.

Oracles Aussage darüber, dass neue Webanwendungen anscheinend nur noch mit SPAs entwickelt werden, ist mit besonderer Vorsicht zu genießen. Schließlich hatten wir in der Java-EE-Plattform bisher schlichtweg keine Alternative zu JSF und waren somit dazu gezwungen, diesen Weg zu gehen. Ein leichtgewichtiges, serverseitiges Webframework hätte vielen EE-Projekten mit großer Wahrscheinlichkeit besser getan als rein clientseitige Ansätze. Java EE 8 ist definitiv ein Schritt in die richtige Richtung. MVC 1.0 aus dem Fahrplan zu entfernen, aber weniger. Wir können nur hoffen, dass die Geschichte eine gute Wendung nimmt. In diesem Sinne: stay tuned…

Geschrieben von
Sven Kölpin

Sven Kölpin ist Enterprise Developer bei der open knowledge GmbH in Oldenburg. Sein Schwerpunkt liegt auf der Entwicklung webbasierter Enterprise-Lösungen mittels Java EE.

Lars Röwekamp

Lars Röwekamp ist Geschäftsführer der open knowledge GmbH und berät seit mehr als zehn Jahren Kunden in internationalen Projekten rund um das Thema Enterprise Computing.

Kommentare

Schreibe einen Kommentar

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