Frameworks für das Web 2.0

Als Web2.0-Framework integriert Ruby on Rails die aktuellen Entwicklungen im Bereich der Internetanwendungen. Bei Web2.0 geht es aus technischer Sicht vorrangig um die Entwicklung offener Schnittstellen und desktopähnlicher Internetanwendungen. Für eine anwendungsbezogene Darstellung des Begriffs sei auf [1] verwiesen. Prinzipiell lassen sich zwei Arten von Web-Frameworks unterscheiden, von denen nachfolgend einige kurz skizziert werden:

• In ereignisgesteuerten Web-Frameworks definiert der Programmierer für spezielle Komponenten vorab die Reaktion auf ein bestimmtes Ereignis, welche dann zur Laufzeit durch Benutzeraktion mit der Komponente ausgelöst werden kann.

• Aktionsgesteuerte Web-Frameworks orientieren sich stärker an den technischen Besonderheiten des HTTP-Protokolls und definieren ihre Anwendungssteuerung entlang des webtypischen Request/Response-Zyklus. Konzeptionell lehnen sich diese Web-Frameworks stark an das Model-View-Controller- (MVC) Muster an. Das MVC-Muster beschreibt die klare Schichtentrennung nach Model, View und Controller einer Anwendung.

Das Java-basierte Web-Framework Struts [2] gehört zu den klassischen Vertretern der MVC-Architektur, wobei das Zusammenspiel von Controller und View im Vordergrund steht [3, S. 27ff]:

• Controller: Die Controller-Komponente wird durch ein Java Servlet realisiert, das bei der ersten Anfrage eines Clients ein Session-Objekt erzeugt, in dessen Kontext die Requests verarbeitet werden. Das Servlet übernimmt dabei für jeden Client die jeweilige Ablaufsteuerung. Nach der Verarbeitung eines Requests wird vom Servlet eine Antwort (Response) generiert. Die Antwort besteht bei Struts aus einer JavaServer Page. Die Ablaufsteuerung des Servlets, und damit das Verhalten der Web-Anwendung, werden dabei nicht fest im Quellcode codiert, sondern in der konfigurierbaren XML-Datei definiert.

• Model: Der Zugriff im Framework auf die Daten des Models erfolgt über JavaBeans. Eine JavaBean ist im Wesentlichen eine beliebige Java-Klasse, die den in der JavaBeans-Spezifikation beschriebenen Vorgaben hinsichtlich einer öffentlichen Schnittstelle folgt. Damit stehen auf dieser Ebene sämtliche Java-Entwicklungsmöglichkeiten zur Verfügung. Innerhalb der JavaBeans werden die Daten jedoch nicht gespeichert, sie dienen lediglich dem Transport. Die Speicherung erfolgt innerhalb der Geschäftslogik.
•  View: Die View wird durch JavaServer Pages repräsentiert. Tag-Bibliotheken erlauben Struts HTMLOutput dynamisch zu gestalten. Es stehen zahlreiche Tag-Bibliotheken zur Verfügung. Neben den Struts-eigenen wird die Verwendung der Java Standard Tag Library (JSTL) angeraten. In diesen Taglibs stehen dem Entwickler verschiedene Taggruppen zu Verfügung. Mit den Tags der Core-Gruppe der JSTL können beispielsweise Daten angezeigt werden und mit der Formatierungsgruppe lassen sich die Tags länderspezifisch anpassen.

Im Gegensatz zum aktionsorientierten Struts verfolgt Tapestry [4] einen ereignisorientierten Ansatz, wobei hiermit auch Web-Anwendungen nach dem MVC-Muster implementiert werden können. Die Vorgehensweise entspricht aufgrund der Ereignisorientierung mehr der Implementierung von Benutzeroberflächen mittels Swing oder AWT und abstrahiert damit stark von der eigentlichen Technologie des Web. Innerhalb von Tapestry existiert explizit das Konzept einer Anwendung. Die Anwendung wird gestartet, wenn ein Benutzer die URI des Tapestry-Servlets aufruft. Das Servlet instanziiert ein Engine-Objekt für jeden anfragenden Benutzer, das für diesen als Proxy fungiert. Alle in einer aufgerufenen Seite enthaltenen Komponenten werden dabei von der Engine identifiziert, ihre Komponentenspezifikationen gelesen und Instanzen erzeugt. Nach dem Rendern der Seite kann diese dann an den anfragenden Client übertragen werden. Die Engine bleibt im Applikationskontext bestehen solange der Benutzer seine Session mit der Web-Anwendung aufrechterhält.

Cocoon [5] verfolgt als XML Publishing Framework einen vollständig anderen Ansatz. Hier steht die Darstellung von Daten im Vordergrund, die bereits im XML-Format vorliegen bzw. die aufgrund anderer Einflussfaktoren im XML-Format gespeichert werden sollen [6, S. 41]. Auf diese XML-Datenbasis setzt Cocoon eine flexible Präsentationsebene auf, so dass zum einen eine strikte Trennung zwischen Präsentation und Inhalt erreicht wird. Zum anderen können dadurch beliebige Präsentationsformate wie HTML, WAP oder auch PDF unterstützt werden. Grundlage für die Umsetzung der Dokumente ist hierbei XSLT. Folglich eignet sich Cocoon primär für die Erstellung von Web-Anwendungen, die auf Basis einer vorhandenen Datenbasis dem Nutzer Abfragemöglichkeiten mit individuellen Ergebnisdarstellungen ermöglichen sollen. Obwohl Cocoon auf Java basiert, ermöglicht es eine Java-unabhängige Benutzung des Frameworks. Dementsprechend nutzt Cocoon abgeschlossene Java-Komponenten, wie etwa den XML-Parser Xerces oder den XSLT-Prozessor Xalan. Der Cocoon-Nutzer beschreibt die Konfiguration dieser Komponenten sowie den Verarbeitungsfluss dann mit Hilfe von XMLDokumenten. Dadurch lassen sich ohne großen Java-Programmieraufwand komplexe Anwendungen aus einzelnen Verarbeitungsbauteilen zusammensetzen. Zusätzlich stellt Cocoon Module zur Verfügung, die Funktionalitäten wie Formulargenerierung und -verarbeitung (Cocoon Forms), Definition eines Anwendungsablaufs (Cocoon Flow) und Authentifizierung abdecken. Ein integriertes Portal Framework ist ebenfalls verfügbar.

Vergleichbar zu J2EE umfasst Microsofts Framework .NET [7] eine Anwendungsplattform, die auch verteilte serverseitige Anwendungen unterstützt. Für die Web-Entwicklung ist dabei ASP.NET die zentrale Komponente. Vor Einführung von .NET bestanden Microsofts Active Server Pages aus Script-Befehlen innerhalb der HTMLSeiten. Mit ASP.NET wird nun Code in einer objektorientierten Programmiersprache erstellt und kompiliert. Damit können auch hier Design und Programmierung voneinander getrennt werden. Insbesondere hat man bei der Programmiersprache die Wahl zwischen allen vorhandenen .NET-Sprachen wie beispielsweise C#, C++ oder Visual Basic [8, S. 25ff]. Einer der Vorteile des ASP.NET-Ansatzes liegt in der Zusammenführung der client-und serverseitigen Programmierung. So können beispielsweise für beide Seiten die gleichen Skriptsprachen eingesetzt werden, der Ausführungsort wird über eine Option bestimmt. Eine zentrale Rolle spielen dabei die Web Forms. Sie bilden die Grundlage für die Programmierung von interaktiven Formularen. Vergleichbar zu Tapestry wird auch hier die Programmausführung über Ereignisse ausgelöst, wobei das Konzept stark an der Programmierung von Windows-Benutzeroberflächen unter .NET angelehnt ist. Für Standardaufgaben können dabei vorgefertigte Bausteine, die Web Controls, eingesetzt werden. Im Vergleich zu Sprachen wie PHP wird die Programmierung mit ASP.NET vielfach als schwieriger bezeichnet. Vorteilhaft ist jedoch die Vielzahl an vorhandenen Klassen und Komponenten.

RoR wurde von D. H. Hansson im Juli 2004 veröffentlicht [9]. Es ist quelloffen (open source) unter der MITLizenz freigegeben. Rails bildet eine Umgebung und stellt alle Hilfsmittel zur Entwicklung von geschäftskritischen, datenbankbasierten Web-Anwendungen. Die grundlegenden Ziele sind Einfachheit, Wiederverwendbarkeit, Erweiterbarkeit, Testbarkeit, Produktivität und Veränderbarkeit. Den entscheidenden Teil hierfür tragen die nachfolgend vorgestellten Prinzipien von RoR bei.

Die Umsetzung von MVC resultiert in der klaren Separierung des Codes nach Zweck. Maßgeblich hierfür sind die Subframeworks "Active Record", "Action View" und "Action Controller".

RoR vermeidet Konfiguration im weitesten Sinne. Die einzige Konfigurationsdatei nennt sich database.yml und beinhaltet Art, Benutzername und Passwort der verwendeten Datenbank. Für jedes Projekt können drei verschiedene Datenbanken definiert werden: development, test und production. Die Rails-Komponenten arbeiten ohne Konfiguration problemlos zusammen. Sie sind im Framework fest verbunden. Konventionen können auch überschrieben werden, um spezielle Funktionen und individuelle Anpassungen zu ermöglichen.

DRY setzt voraus, dass "jedes Stück Wissen eine einzige, eindeutige und maßgebliche Repräsentation in einem System hat" [10, S. 24], sich also selten bis nie wiederholt. Bei einem "Stück Wissen" kann es sich um Daten und Metadaten, Logik, Funktionalität oder einen Algorithmus handeln. RoR ist als Umgebung so angelegt, dass einmalige Deklaration und Wiederverwendung so einfach wie möglich gemacht werden. Das DRY-Prinzip sticht unter anderem bei der Betrachtung von Active Record ins Auge, da Attribute und Werte von Klassen ausschließlich in der Datenbank und nicht im Programmcode festgelegt werden.

Mit dem Konsolenbefehl scaffold erstellt RoR anhand des Datenbankschemas ein grundlegendes Gerüst aus Controllern und View-Templates, mit CRUD-Funktionalität (Create-Retrieve-Update-Delete). An vielen Stellen bietet RoR zusätzlich Generatoren für wiederkehrende Elemente, die viel Arbeit sparen, wie zum Beispiel für ein Login-Formular. Oft wird RoR in Presse und Internet als Framework für das Schreiben einer Web2.0-Anwendung an einem Nachmittag beworben. Hierbei beziehen sich die Autoren meist auf die Scaffolding-Funktion. Das automatische Generieren des Projektgerüsts spart viel Zeit und erlaubt es dem Entwickler sofort mit dem Kern der Applikation zu beginnen, erstellt aber keineswegs eine fertige Anwendung und ist nur ein kleiner Teil von RoR.

Ohne zusätzlichen Zeitaufwand durch Deployment kann der aktuellste Stand immer durch Neu-Laden im Browser angerufen werden. Das Projekt muss nicht erst kompiliert und ausgeführt werden muss.

RoR basiert auf der bislang selten verwendeten, dynamisch typisierten Programmiersprache Ruby [11]. Diese wurde 1995 von Y. Matsumoto vorgestellt. Die leichte Verständlichkeit vereinfacht Lernprozess und Wartung. Ruby wird direkt beim Aufruf vom Ruby-Interpreter des Webservers verarbeitet. Ruby ist objektorientiert, auch im Bereich der Datentypen gibt es keine Ausnahmen. Ungeachtet dessen kann in Ruby auch prozedural programmiert werden. In vergleichsweise wenig Code kann durch Loops und Arrays, zusammengefasst in „Blocks", sehr viel Funktionalität untergebracht werden. Ruby-Code ist leicht zu lesen und lehnt sich hauptsächlich an die Sprachen Perl, Python, Smalltalk und LISP an.

Im Folgenden werden die wichtigsten Bestandteile des Frameworks kurz erläutert. Für eine weitergehende Darstellung sei auf [12, S. 10ff] verwiesen.

Das Subframework Active Record stellt die Verbindung zwischen Domain-Objekten und der Datenbank her. Es setzt die vom Action Controller ankommenden Create-/Read-/Update- und Delete-Befehle in SQL-Befehle um, sendet die Abfragen an die Datenbank und schickt die empfangenen Ergebnisse an den Action Controller zurück. Active Record übernimmt auch die Validierung, ob ein Benutzer das Recht besitzt, auf einen bestimmten Datensatz zuzugreifen bzw. ihn zu verändern. Das Subframework verfolgt den Ansatz des Object/Relational Mapping (ORM) nach [13]: Klassen sind direkt Datenbanktabellen zugeordnet. Die Datensätze stellen Objekte der Klasse dar, die Tabellenspalten die Attribute. Normalerweise verlangt ORM eine umfangreiche Konfiguration per XML. RoR umgeht dies mit den Konventionen in Active Record. Tabellen werden über

ActiveRecord::Base so angesprochen, wie sie in der Datenbank heißen - die benötigte Klasse wird automatisch erstellt. Der Konfigurationsaufwand zur Verbindung von Daten und Variablen entfällt durch die Umsetzung des Prinzips "Convention over Configuration". Active-Record-Klassen beziehen ihre Attribute folglich direkt aus der Datenbank-Tabellendefinition. Um Vererbung in einer relationalen Datenbank darzustellen benutzt Rails ein weiteres Pattern aus [13]: Single Table Inheritance. Assoziationen werden in RoR durch Fremdschlüssel in der Datenbank und einer Deklaration in Active Record definiert. Eine Sammlung von Validierungsmethoden ermöglicht das Überprüfen von eingegebenen Daten auf Existenz oder auf ein bestimmtes Format. Dass dies direkt in Active Record geschieht ist eine weitere Umsetzung des DRY-Prinzips. Schlägt eine Validierung fehl, generiert Rails automatisch eine Fehlermeldung im Stil "Das Feld XY darf nicht leer sein" und gibt sie im View aus.

Der Action Controller ist die zentrale Steuerungseinheit einer Rails-Anwendung. Er nimmt Anfragen entgegen und sendet einen View an den Client zurück. Im Controller werden sogenannte Actions definiert, die festlegen, wie der Controller auf bestimmte HTTP-Requests reagieren soll. Der Action Controller schließt von URLs auf Aktionen bzw. Objekte und leitet zum richtigen View weiter. RoR verwendet "Pretty-URLs", beim Apache-Webserver beispielsweise durch die mod_rewrite-Funktion ermöglicht. Desweiteren durchläuft der Action Controller vor dem Ausführen einer Aktion einen Before-Filter, und nach Abschluss einen After-Filter. Im Before-Filter können spezifische Aktionen wie zum Beispiel die Weiterleitung auf eine Login-Seite hinterlegt werden. Der After-Filter kommt besonders bei Optionalitäten wie der Überprüfung, ob der Benutzer für die Serverantwort eine verschlüsselte Übertragungsform wünscht, zum Einsatz. Die Filter werden bewusst im Backend (dem Action Controller) gehalten um erneut Wiederholungen im Frontend (das heißt im View) zu vermeiden. Action Controller stellt auch die Verbindung zu Active Record her und liefert Daten aus der Datenbank an Action View, Web Services und Mailer. Weitere Funktionen des Action Controllers sind beispielsweise Session-Handling und Zuweisung von Layouts.

Action View ist für die Darstellung der Daten zuständig. Typischerweise werden Daten im HTML-Format dargestellt. Die Darstellungsform wird in Templates festgelegt, damit die Präsentationsschicht vom Rest der Anwendung getrennt ist. Es gibt verschiedene Arten von Templates in RoR, am wichtigsten sind RHTML und RXML. RHTML-Templates mischen Ruby Code mit HTML. Sie agieren als Vorlagen, die zur Laufzeit durch die Ausführung des Ruby Codes mit Inhalt gefüllt werden. Hierzu wird der Ruby-Code als sogenannter "Embedded Ruby-Code" in einem Tag der Form <% ... %> eingeschlossen. RHTML-Templates können von Grafikdesignern mit HTML-Kenntnissen entworfen werden, Entwickler binden dann lediglich die benötigte Funktionalität ein. Für die Erzeugung von XML-Dateien verwendet RoR eine eigene Builder-Bibliothek. Der Builder wird durch das Präfix xml.* im RXML-Template angesprochen und setzt Ruby-Befehle in XML-Tags um. RoR stellt vorimplementierte Helper-Methoden zur Verfügung, die vor allem für Formatkonvertierungen, Formularfelder, Fehlermeldungen und Seitenmanagement hilfreich sind.

Mit Action Web Services unterstützt Rails den Trend zu Serviceorientierten Architekturen (SOA) und macht es damit leicht, Funktionalität zu veröffentlichen und externe Services einzubinden. Die Web2.0-Technologie "Asynchronous JavaScript and XML" (AJAX) gestaltet Ruby-on-Rails-Anwendungen interaktiv und eröffnet neue Möglichkeiten in der Web-Entwicklung [14].

RoR verkörpert die Grundsätze des Agilen Manifests [15]. Es verzichtet auf schwergewichtige Werkzeuge und stellt stattdessen "Individuen und ihre Interaktionen" in den Vordergrund. Scaffolding und unmittelbares Feedback liefern schon zu einem frühen Zeitpunkt im Entwicklungszyklus eine erste lauffähige Version. Es wird inkrementell und in kleinen Schritten entwickelt. Durch das Scaffolding hat der Entwickler den aktuellen Stand jederzeit lauffähig parat und kann daher effizient mit dem Kunden zusammenarbeiten, alle Themen direkt am laufenden System diskutieren und infolgedessen Änderungen viel schneller umsetzen. Wie bei allen Web-Frameworks ist aber gute Software nach wie vor das Ergebnis guter Arbeit professioneller Entwickler. Auch RoR ist, wie alle Frameworks, keine "silver bullet".

[1] Bächle, M: Social Software, in: Informatik Spektrum, Heft 2, Bd. 29 (2006), S. 121 - 124

[2] struts.apache.org, abgerufen am 15.11.2006

[3] Weßendorf, M.: Struts. W3I, 2. Auflage, 2006

[4] tapestry.apache.org, abgerufen am 15.11.2006

[5] cocoon.apache.org, abgerufen am 15.11.2006

[6] Niedermeier, S.: Cocoon 2 und Tomcat, Galileo Press, 2006

[7] www.microsoft.com/net, abgerufen am 15.11.2006

[8] Esposito, D.: ASP.NET-Programmierung, Microsoft Press, 2006

[9] www.rubyonrails.org, abgerufen am 31.10.2006

[10] Hunt, A.; Thomas, D.: Der Pragmatische Programmierer. Hanser, 2005

[11] Eine Übersicht zu Ruby findet sich unter www.rapidwebdevelopment.de sowie

www.rubyonrails.org/docs, beide abgerufen am 31.10.2006

[12] Wirdemann, R.; Baustert, Th.: Rapid Web Development mit Ruby on Rails. Hanser, 2006

[13] Fowler, M.: Patterns of Enterprise Application Architecture. Addison-Wesley Longman 2002

[14] Garret, J.J.: Ajax: A New Approach to Web Applications,

www.adaptivepath.com/publications/essays/archives/000385.php, abgerufen am 15.11.2006

[15] www.agilemanifesto.org, abgerufen am 31.10.2006

Prof. Dr. Michael Bächle, Prof. Dr. Paul Kirchberg

Studiengang Wirtschaftsinformatik

Marienplatz 2

88212 Ravensburg

{baechle, kirchberg}@ba-ravensburg.de