JAXenter

Morgens um halb zehn irgendwo in einem Büro. In einem Meeting wird das neue Projekt besprochen, die Anforderungsanalyse liegt auf dem Tisch. Natürlich geht es bei einem Teil wieder einmal um die Verwaltung der von der Applikation zu verarbeitenden Daten. Nach dem vorherrschenden objektorientierten Paradigma werden diese Daten in Domänenobjekten gekapselt. Da die Verwaltung dieser Objekte immer die gleiche Funktionalität abbildet, nämlich das Anlegen neuer Objekte, das Anzeigen, das Verändern und schließlich das Löschen bestehender Objekte, werden diese Anwendungsfälle zumeist einfach als CRUD-Funktionalität bezeichnet. Bei CRUD handelt es sich um ein Akronym, das sich aus den Anfangsbuchstaben von CREATE, READ, UPDATE und DELETE zusammensetzt, wobei es sich mit Ausnahme von READ um die zu den jeweiligen Aktionen gehörenden SQL-Befehle handelt. Zuweilen werden auch das Suchen nach Objekten sowie das Auflisten der Objekte zur CRUD-Funktionalität hinzugezählt.

Die Umsetzung der CRUD-Funktionalität erfolgt zumeist nach einem standardisierten Schema, sodass sich die User-Interface-Masken in der Applikation nicht besonders stark voneinander unterscheiden. Daher ist die Umsetzung dieser Funktionalität meistens keine besonders anspruchsvolle Aufgabe, sondern höchst repetativ und eintönig. Dieses Problem muss doch irgendwie einfacher zu lösen sein, hat sich vermutlich schon jeder Entwickler einmal gedacht, während er in seiner IDE Eingabefelder auf die Formulare gezogen hat, um sie anschließend mit den Domänenobjekten zu verknüpfen. Sollte uns nicht gerade der Computer solche stumpfsinnigen Aufgaben abnehmen und automatisieren? Das hat sich auch Richard Kennard gedacht, als er das Metawidget-Projekt gründete.

Der typische Datenfluss in einer mehrschichtigen Applikation beginnt am User Interface. Der User kann hier die Daten in einem Formular eingeben oder ändern. Wenn er speichert, werden die Daten aus den Eingabefeldern ausgelesen und in einem Domänenobjekt aufbewahrt. Dieses Objekt kann nun in die Tabelle einer relationalen Datenbank persistiert werden. An zwei Stellen kommt es zu einem Übersetzungsvorgang: einerseits zwischen den Eingabefeldern und dem Domänenobjekt und andererseits zwischen dem Domänenobjekt und der Tabelle der relationalen Datenbank. Für Letzteres hat sich dabei der Begriff „(Object-relational) Impedance Mismatch“ eingebürgert, da die relationale Welt der Datenbanken und die objektorientierte Welt der Programmiersprachen ein anderes Datenmodell aufweisen. Die Lösung für dieses Problem sind objektrelationale Mapper (ORM). Während sich in den letzten Jahren in diesem Bereich sehr viel getan hat und mit Hibernate und der Java Persistence API (JPA) eine allgemein anerkannte Lösung existiert, hat es auf der Seite der User Interfaces nicht viele Entwicklungen gegeben. Noch immer gilt es hier für die Entwickler, die Formulare zu designen, die verschiedenen Elemente zu platzieren und sie richtig mit den Domänenobjekten zu verdrahten.

Genau an dieser Stelle setzt Metawidget an, das dem Entwickler das Erstellen von Formularen abnimmt, indem sie dynamisch aus den Domänenobjekten generiert werden. Dabei geht es gar nicht darum, alle möglichen Anwendungsfälle komplett abzudecken, sondern nur jene Fälle, in denen standardisierte Formulare zum Einsatz kommen. In Anlehnung an OR-Mapper bezeichnet sich Metawidget daher als Object/User Interface Mapper (OIM). Metawidget versucht sich dabei in bestehende Technologien einzufügen. Es bildet eine Brücke zwischen Frontend- und Backend-Technologien. Bei den Frontend-Technologien handelt es sich um verschiedene User-Interface-Technologien, angefangen bei Swing über Java Server Faces bis hin zu Android. Backend-Technologien hingegen sind Technologien, aus denen Metawidget Informationen für die Erstellung der Formulare zieht, wie etwa XML-Dateien oder Annotationen. Tabelle 1 gibt einen Überblick über die Technologien, die Metawidget versteht. Die Formulare, die es erzeugt, werden dabei erst zur Laufzeit generiert, sodass jede Änderung im Backend beim Neustart der Applikation sofort übernommen wird, ohne dass das Frontend adaptiert werden müsste.