Weniger kann mehr sein

Seitdem Ruby on Rails, ein in der Programmiersprache Ruby geschriebenes quelloffenes Web-Framework, im Juli 2004 der Öffentlichkeit vorgestellt wurde, wächst die Beliebtheit stetig. Rails ist eine wirklich andere und in vielen Hinsichten auch produktivere Entwicklungsplattform als etwa die Java Enterprise Edition (EE). Im Unterschied zur Java EE, die auf feingranularen Programmierschnittstellen und umfassenden Konfigurationsdateien basiert, fokussiert sich Ruby on Rails auf ein datenbankorientiertes Programmiermodell mit geringem Konfigurationsbedarf. Die neue Architektur hat so viel Anklang gefunden, dass etliche weitere Frameworks entwickelt wurden, die Rails emulieren – beispielsweise Turbo Gears, Cake PHP oder Trails. Solche Frameworks, von der Burton Group als Rapid Web Development (RWD) bezeichnet, begünstigen eine Anwendungsentwicklung, die hauptsächlich durch das relationale Datenbankschema gesteuert wird. Während viele Systemarchitekten davon überzeugt sind, dass sich die Logik einer Anwendung an einem Geschäftsmodellansatz orientieren sollte, ermöglichen RWD-Frameworks die Steuerung der Anwendungsentwicklung über das relationale Datenbankschema. Geschäftsobjekte, die Änderungen an den Datenbanktabellen bewirken, werden vom Datenbankschema generiert; Präsentations- und Steuerungsschicht (View und Controller) werden wiederum von den Geschäftsobjekten erzeugt. Ein weiterer wichtiger Aspekt von RWD-Frameworks ist, dass sie die Konvention über die Konfiguration stellen. Das heißt, dass Runtime- und Deployment-Merkmale eine Applikation nicht wie bei der Java EE und vielen anderen Frameworks explizit in einer XML-Datei festgelegt werden müssen. Stattdessen gehen RWD-Frameworks von einer Default-Konfiguration aus. Solche Konfigurationen können innerhalb des Quellcodes (und gelegentlich auch über Konfigurationsdateien) ausgeschaltet werden, passen aber ansonsten in den meisten Fällen. Nicht zuletzt folgen RWD-Frameworks dem Prinzip »Don’t Repeat Yourself«. Das bedeutet, dass jeder Aspekt einer Applikation innerhalb einer Anwendung nur einmal definiert wird. Das ist bei der Java EE anders. Dort werden Konfigurationsdateien zur Definition der Merkmale der Model-, View- und Controller-Schichten einer Applikation und zur Verknüpfung dieser sich oft überlappenden Definitionen verwendet. RWD-Frameworks leiten beispielsweise die Klassennamen der Geschäftsobjekte von den Bezeichnungen der sie repräsentierenden Datenbank-Tabellen ab. Dieselbe Konvention gilt auch für Default-Ansichten, für URLs für den Zugang zu solchen Ansichten, Dateinamen und Controller-Komponenten. RWD-Frameworks erweisen sich in vielen Situationen als erstaunlich produktiv. Über ein Backend in Gestalt eines relationalen Datenbanksystems können Web-Applikationen von Programmierern rasch erstellt werden. Allerdings sind RWD-Frameworks nicht für anspruchsvolle und große Unternehmensanwendungen geeignet, die verteilte Transaktionen, Messaging-Middleware und ausgefeilte Überwachungsfunktionen erfordern. In solchen Situationen fährt der Entwickler besser mit umfassenderen Umgebung wie eben Java EE von Sun Microsystems oder auch .Net von Microsoft. Die Fälle, in denen diese Breite wirklich erforderlich ist, sind jedoch nicht sehr häufig. Die meisten der 500 größten Unternehmen brauchen entsprechende High-End-Funktionen für mindestens zehn Prozent ihrer Anwendungen. Für die überwiegende Zahl der Applikationen reichen aber einfachere Mittel aus – weshalb Ruby on Rails und andere RWD-Frameworks zunehmend an Zugkraft gewinnen. Entwickler haben die Erfahrung gemacht, dass die Produktivität eines RWD-Framework in vielen Fällen fehlende High-End-Features, wie sie insbesondere in der Java EE zu finden sind, mehr als aufwiegt. Microsofts .Net, selbst sehr umfangreich und mit vielfältigen Programmiermöglichkeiten, gilt aufgrund der guten Werkzeuge als leichter zu handhaben als die betriebssystemneutrale Java EE. Jedoch spielt die .Net-Plattform wegen ihrer Größenordnung und Komplexität mit Dutzenden von Programmierschnittstellen und Tausenden von Klassen in einer anderen Liga als die RWD-Frameworks. Wie die Java-Plattform möchte .Net alles bieten und gleichzeitig so flexibel wie möglich bleiben – allerdings mit Beschränkung auf die Microsoft-Welt. RWD-Frameworks dagegen zielen darauf ab, nur ein paar Dinge auf einem Weg zu erledigen – was ein völlig anderes Wertversprechen ist. Unternehmen, für die mehr Produktivität und eine schnellere Fertigstellung wichtiger sind als Leistungsmerkmale für anspruchsvolle Unternehmensanwendungen, können sich mit RWD-Frameworks einen erheblichen Wettbewerbsvorteil verschaffen.

Richard Monson-Haefel ist Senior Analyst bei dem ­Marktforschungs- und Beratungshaus Burton Group.