Wirklich skalierbare Softwaresysteme entstehen heutzutage selten im Enterprise-, sondern häufiger im Web-Umfeld. Daher können Enterprise-Anwendungen von den Erfahrungen profitieren, die mit Web-Anwendungen gesammelt wurden.

Das Web hat eine eigene Architektur, die durch das HTTP-Protokoll vorgegeben wird und stellt eine Implementierung des REST-Architekturmusters dar.

Das HTTP-Protokoll ist zustandslos. Zustände werden zwischen Konsumenten (z.B. einem Browser) und  Produzenten (z.B. einem Server) transferiert. Sie werden dargestellt durch Ressourcen (Dokumente). Die Kommunikation erfolgt über das Request-Response-Muster. Da keine Zustände gespeichert werden müssen, sondern Zustände übertragen werden, ist eine Web-Architektur theoretisch beliebig skalierbar.

Klassische Web-Frameworks basieren ebenfalls auf dem Request-Response-Muster. Das Programmiermodell eines klassischen Web-Frameworks entspricht also dem Programmiermodell des HTTP-Protokolls. Ein einfaches Beispiel für ein solches klassisches Web-Framework ist die Java Servlet-API.

Auch das angegraute Apache Struts basiert auf dem Request-Response-Muster, strukturiert aber eine Web-Anwendung, indem das MVC-Entwurfsmuster angewendet wird. Ein Controller ist ein Bindeglied zwischen einer Web-View und dem Datenmodell der Anwendung. Wenn ein Request am Java Web-Container (z.B. Tomcat) ankommt, wird dieser vom Struts-Front-Controller engegengenommen. Dieser ruft beispielsweise anhand eines URL-Musters eine Action-Klasse auf. Diese Action-Klasse liest das im Request übertragene Model aus, wendet auf dieses Model Applikations-Logik an, verändert es damit und delegiert schließlich an eine Web-View, die das Model zur Darstellung bringt und im Response zurück an den Browser überträgt. Das Modell wird bei Struts in der Regel in JavaBeans – sogenannten FormBeans – gehalten, die bei jedem Request neu aufgebaut und nach dem Response zerstört werden. Zwar steht eine serverseitige Session zur Verfügung, um in dieser nutzerbezogene Zustände der Anwendung zu speichern, allerdings fügt sich diese bewusst nicht in das Konzept des Frameworks ein. Auch neuere Web-Frameworks wie Ruby on Rails, ASP.NET MVC, Grails von Springsource, Spring-MVC oder Play aus dem Typesafe-Stack folgen diesen Wurzeln.

Dieses zustandslose Programmiermodell war jedoch für Entwickler, die aus der Desktop-Entwicklung kommen, fremd. Eine Desktop-Anwendung wurde schon damals aus UI-Komponenten zusammengesetzt. Daher entstanden Web-Frameworks, die dieses UI-Komponentenmodell auf Web-Anwendungen übertragen.

UI-Komponenten haben den Vorteil, dass sich auch komplexere UI-Widgets zusammensetzen und dann konsistent verwenden lassen. Während HTML seit 1997 (bzw. 1999) mit dem 4.01-Standard stagnierte, konnten reichhaltigere UI-Widgets durch komponentenorientierte Frameworks auch von Enterprise-Entwicklern ohne fortgeschrittene Kenntnisse von HTML, JavaScript und CSS benutzt werden.

Der Zustand einer komponentenorientierten Anwendung wird üblicherweise in einem Baum organisiert. Eine Änderung des Zustands der Anwendung wird über Events und nicht über Requests ausgelöst. Meist wird der Zustand des Baums auf dem Server gehalten. Events lösen implizit HTTP-Requests aus, ohne dass sich der Entwickler darum kümmern muss.

Komponentenorientierte Web-Frameworks abstrahieren also sowohl das HTTP-Protokoll als auch HTML, Stylesheets und JavaScript und bieten statt dessen ein höheres Programmiermodell an. Beispiele für solche komponentenorientere Web-Frameworks sind JSF, ASP.NET, Apache Wicket, Lift oder das Google Web Toolkit und Vaadin.

Grundsätzlich lassen sich Web-Frameworks also stark verallgemeinert in zwei Klassen unterteilen: Web-Frameworks, die auf dem Request-Response-Muster basieren und Web-Frameworks, die dieses Muster abstrahieren und auf Komponenten basieren. Während sich bei Web-Frameworks, die auf dem Request-Response-Muster basieren, der Entwickler selbst um den Zustand der Web-Anwendung und um die Präsentationsschicht kümmern muss, wird bei Web-Frameworks, die auf dem Komponenten-Modell basieren, der Zustand meist in einem Baum auf dem Server gehalten und UI-Komponenten werden zur Verfügung gestellt.

Der Trend ging früher von Request-Response-basierten Web-Frameworks hin zu komponentenorienterten Web-Frameworks. Subjektiv beobachte ich allerdings in letzter Zeit einen Trend hin zurück zu Request-Response-basierten Web-Frameworks. Dies hat mehrere Gründe.

• Webentwicklung ist schon lange nicht mehr exotisch. Die meisten Entwickler sind inzwischen Web- und nicht mehr klassische Anwendungsentwickler. Der Request-Response-basierte Ansatz einer Webanwendung erscheint vielen Entwicklern heute natürlicher als die eventbasierte Entwicklung in Komponenten-Frameworks.
• Durch HTML5 und ECMAScript 5 ist der Stillstand im Bezug auf HTML, CSS und JavaScript im Webbrowser überwunden. Reichhaltige Benutzeroberflächen lassen sich mit HTML5 (und hilfreichen Bibliotheken wie Twitter Bootstrap) viel leichter realisieren als mit HTML 4.01 oder XHTML. Komponentenorientierte Frameworks entwickeln sich inzwischen sogar langsamer als Webbrowser es tun. Modernere UIs lassen sich jetzt also mit den Basistechnologien leichter entwickeln als mit Komponenten-Frameworks. Der komponentenorientierte Ansatz fühlt sich inzwischen schwerfällig an.
• Skalierung ist heute wichtiger denn je, da viele Anwendungen inzwischen auf virtuellen Servern in der „Cloud“ gehostet werden, in denen klassisches Clustering keine Option ist. Daher ist es nicht mehr State-of-the-Art, den Zustand einer Anwendung in einer Session zu speichern.

Zwar ist ein Trend zurück zu Request-Response-basierten Web-Frameworks zu beobachten, allerdings sind dies nicht mehr unbedingt die gleichen Frameworks wie aus der Urzeit der Webentwicklung. Hier gibt es zwei Strömungen, die sich allerdings nicht unbedingt widersprechen und beide auf dem REST-Ansatz basieren:

• Web-Frameworks, die auf Partial Page Rendering und Progressive Enhancement basieren, und
• SPA-Frameworks (Single Page Applications), die MVC (bzw. MVP / MVVM) direkt im Browser implementieren.

Bei den erstgenannten Frameworks bietet der Server ein Backend, das den REST-Prinzipien folgt. Alle Logik findet auf dem Server statt. Der Browser bringt lediglich vom Server gelieferte HTML-Fragmente (HTML-Snippets) zur Darstellung, gestaltet sie mit CSS und reichert sie durch unobstrusives JavaScript an. Auf dem Server lässt sich hier JAX-RS mit einer dünnen UI-Schicht (Jersey bietet solche Features) oder ein klassisches MVC-Framework wie Spring MVC oder eine neueres Framework wie Play, das auf serverseitige Sessions verzichtet, einsetzen. Im Browser genügt eine etablierte JS-Bibliothek wie jQuery mit entsprechenden Plugins wie das jQuery-Form-Plugin und jQuery-UI. Ein echtes browserseitiges UI-Framework wird nicht benötigt. Anforderungen an eine Beispiel-Architektur, die diesem Muster folgt, definiert der ROCA-Style (ROCA = Ressource Oriented Client Architecture).

Bei den zweitgenannten Frameworks wandert das MVC-Muster vom Server in den Browser. Dies kann zu sehr leichtgewichtigen Server-Anwendungen führen. Eine Server-Komponente liefert lediglich eine per URL eindeutig identifizierbare Ressource in einem angeforderten Format (z.B. als JSON-Objekt) aus bzw. persistiert sie. MVC-Frameworks auf dem Browser kümmern sich sowohl um die Logik als auch um die Darstellung. Der Zustand der Anwendung wird im Client gehalten. Die Komplexität der Anwendung wandert also vom Server in den Browser. Daher ist ein echtes UI-Framework im Browser hilfreich. Als Beispiel für leichtgewichtige MVC-Frameworks im Browser können Ember.js, Knockout, AngularJS oder JavaScript-MVC dienen.

Neben leichtgewichtigen SPA-Frameworks gibt es auch schwergewichtigere, komponentenbasierte Frameworks wie Senchas Ext.js, die eher einem JSF oder GWT im Browser als einer angereicherten Website gleichen. Es lässt sich nur schwer beantworten, ob ein solches Framework eher das Beste aus beiden Welten bietet oder sämtliche Nachteile beider Ansätze vereint.

Auch in Enterprise-Anwendungen sollten moderne Architektur-Ansätze, die aus dem Web-Umfeld kommen, zumindest ausprobiert werden. Vorteile wie Skalierbarkeit und leichtgewichtige Anwendungen (zumindest auf dem Server) sprechen für sich. Entsprechende Frameworks sind in diesem Artikel verlinkt. Bei der Auswahl eines Web-Frameworks sollte darauf geachtet werden, dass das Framework von der Architektur her zur Architektur des Webs und seines Protokolls, dem Hypertext Transfer Protocol,  passt.

Viel Spaß beim Ausprobieren!