Die Wiederentdeckung des Backends

Zwei Tier Architekturen sind hip, ich befürchte, das Wort „hip“ ist es nicht. An allen Enden der Web 2.0 Welt wird mit PHP, RAILS, mitunter auch Java Servlet Technologie gebaut. Ein bisschen Code, der die Seite zusammenhält, ein bisschen DB – klassische zwei Tier Architektur. Warum auch nicht? Es ist schnell gebaut und man spart den Kommunikationsoverhead mit dem Backend.

Dennoch scheint es gute Gründe zu geben, etwas Logik aus dem Frontend zu ziehen. Die einen bauen in ihre Servlet Engine einen Spring Container, die anderen gliedern Funktionalität in WebServices aus, einige tun sogar beides. Nicht selten sind die gleichen Entwickler, die Java früher für fast alles zu langsam empfanden diejenigen, die kein Problem damit haben, heute Ruby wegen der schnelleren Entwicklungszeiten zu bevorzugen – und die gleichen Entwickler, die mit Kommunikationsoverhead gegen EJBs argumentiert haben, heute die, die Services mit SOAP integrieren. Zeiten ändern sich.

Jedenfalls werden die Einschränkungen des zwei Tier Ansatzes spätestens dann deutlich, wenn Funktionalität ausgegliedert werden soll oder asynchrone Verarbeitung benötigt wird.

EJBs haben immernoch einen schlechten Ruf. Die waren bis EJB 2.1 unhandlich und alles andere als einfach zu benutzen. Wie ungeliebt die Technologie ist wird einem klar, wenn man sich Projekte anguckt, die durch Managemententscheidung EJB basiert gebaut wurden: Praktisch jede Firma hat dafür zunächst einmal ein eigenes Framework entwickelt, um die Komplexität des unterliegenden Frameworks vom Entwickler fernzuhalten. Die Erfolge sind zumeist mäßig. Mit der Komplexität wird auch ein größerer Teil der zugrundeliegenden Regeln für die Anwendung der Technologie versteckt, was zu teilweise abenteuerlichen Seiteneffekten führt.

EJB 3 hat mit der Konfigurationsarie, die für klassische EJBs benötigt wurde, aufgeräumt und ist ausgesprochen benutzbar. Es existiert Technologie zur Anwendungsverteilung, mit JPA benutzbare Datenbankabstraktion, Sicherheits- und Transaktionsverwaltung sowie techniken zur timergesteuerten und asynchronen Verarbeitung. Allerdings war man bislang an Java gebunden, um diese Technologie nutzen zu können.

Mit Java EE 6 und der Referenzimplementation Glassfish 3 wird sich das grundlegend ändern. Frontend ist nicht mehr nur Servlet/JSP sonder auch RAILS mit JRuby, PHP oder Python. Dabei laufen die Skriptsprachen in der JVM. Das hat einen ganz wunderbaren Vorteil: Ich kann von meiner PHP Anwendung oder direkt aus meinem Ruby Code EJBs aufrufen. Das hat schon einen gewissen Charme und ist meiner Meinung nach einer der brilliantesten Schachzüge von Sun überhaupt.

Ich kann also meine komplette Rails Applikation in einem Applicationserver zugreifen und habe die ganzen netten Vorteile wie Monitoring, Zugriff auf ein Backend und meine Applikationen laufen in der JVM auch noch schneller als vorher (der Ruby Interpreter ist nicht gerade auf Geschwindigkeit optimiert).

Das beste aus zwei Welten. Das ist ein bisschen wie Weihnachten und Ostern zusammen. Ich denke, dieser Ansatz wird viele Freunde finden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


7 × = vierzig zwei