Kategorien
Architektur

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.

Kategorien
Tools

Java EE Arbeitsumgebung

Ich werde oft gefragt, was bei einer Entwicklung im Enterprise Java Umfeld hilft. Hier meine derzeitigen Favoriten:

Teil 1: Tools

IDE: Netbeans

„Wozu brauche ich überhaupt eine IDE? Ein Editor tut es doch auch.“ Das ist erstmal nicht falsch. Was bei einer IDE meist nett ist, sind die Tools zum Refactoring und zur Navigation im Quellcode.

Ich selbst habe jahrelang Eclipse benutzt und es ist eine wirklich gute IDE. Was mich in jüngster Zeit immer wieder gestört hat ist die unterschiedliche Qualität der benötigten Plugins. Es geht einfach zu viel Zeit verloren bin dem Versuch die Plugins so zu kombinieren, dass man eine einigermaßen funktionierende Arbeitsumgebung hat. Für die Tools, die ich benutze ist die Unterstützung in Netbeans deutlich besser und spätestens seit der 6er Version steht Netbeans auch in Punkto Geschwindigkeit nicht mehr nach.

Build Tool: Maven 2

Das Probem in größeren Projekten ist oft einen Build Prozess zu bauen, der einigermaßen nachvollziehbar ist und diese Standards dann über die einzelnen Unterprojekte beizubehalten. Innerhalb von kürzester Zeit kommt es so zu einem Modulwidldwuchs mit Abhängigkeiten, die nur noch von einem Mitarbeiter durchblickt werden, der leider schon seit Jahren nicht mehr in der Firma ist.

Maven gibt im Wesentlichen eine Projektstruktur vor. Zusätzlich sind automatisierte Tests, Dokumentationsgeneration sowie automatische Codeanalyse bereits in den Build Prozess integriert. Das Hauptargument für die Meisten dürfte jedoch die automatisierte Verwaltung von Bibliotheksabhängigkeiten sein.

Continuous Integration: Hudson

Es ist zwar schön und gut, wenn ein Build lokal auf dem Entwicklerrechner läuft, allerdings hat man zu oft das Problem, dass er eben auch nur auf diesem läuft. Was hilft, ist ein Build in einer neutralen Umgebung. Gleichzeitig möchte man fertige Builds auch anderen Entwicklern zur Verfügung stellen. Das wohl genialste CI Tool ist Hudson. Mit keinem Tool ist es einfacher ein Projekt aufzusetzen.

Configuration Management: Subversion

Ich gebe zu, es viel mir schwer, mich von dem seit über 10 Jahren benutzen cvs zu trennen. Aber im Java Umfeld ist insbesondere die von Subversion gebotene Möglichkeit Ordner zu verschieben (wenn man z.B. mal ein Paket umbenennt) unbezahlbar. Transaktionale Commits sind in einem größeren Entwicklungsumfeld ebenfalls ein Plus sowie die feingranulare Rechteverwaltung.

Bug Tracking: jira

Das Tool kostet Geld aber es ist nach meiner Erfahrung jeden Cent wert. Komplexe Rechteverwaltung, hierachische Projektstrukturen, Zeitverwaltung. Die Liste der Features ist quasi endlos. Für mich klar die Nummer eins der Bugtracker.

Wiki: Confluence

Source Code Dokumentation ist eine Sache aber im Entwicklungsprozess fallen noch eine Menge anderer Dokumente an: Anforderungen, Designdokumente oder auch einfach Anleitungen, Tips und Tricks usw. Damit diese Dokumente aktuell gehalten werden, müssen sie permanent für alle Beteiligten im Zugriff und änderbar sein. Gleichzeitig sollten diese Änderungen nachvollziehbar sein. Das alles sind Anforderungen, die ein Wiki erfüllt. Confluence ist ein sehr gutes Wiki System. Wenn man Jira kauft, gibt es das für einen relativ geringen Aufpreis dazu. Neben den herausragenden Verwaltungsmöglichkeiten halte ich insbesondere die Möglichkeit, Wiki-Seiten direkt aus Word heraus zu ändern, für ein absolutes Killerargument. Gerade in den kundennahen Abteilungen sitzen oft Mitarbeiter, die sich mit Word deutlich besser als mit der Wiki Sprache anfreunden können. Wer schon einmal versucht hat, aus einem shared Verzeichnis das gerade für das Projekt aktuelle Word Dokument herauszufinden, wird wissen, wovon ich rede. Kommunikation ist alles und Confluence ist eine gute Hilfe.

Application Server: Glassfish

Der Open Source Appliaction Server von Sun ist einfach großartig. Ursprünglich war er nichts weiter als die Referenzimplementaion von Java EE 5. Inzwischen ist es ein solider und schneller Applicationserver mit einem Beeindruckenden Featureset und einer extram agilen Community. Die Adminstartions Tools und Oberfläche sind das Beste, was ich bislang gesehen habe. Großartig sind auch die Call Trace Features und vor allem die unverschämt gute Dokumentation. Ich glaube nicht, dass es derzeit einen besseren Java EE 5 Applicationserver gibt. Die Installation mit einem Wizzard dauert wenige Minuten und spätestens wenn man einen Blick auf die Adminoberfläche geworfen hat, ist zumindest die Vorentscheidung bereits gefallen.