Modeling goes Enterprise

Die Funktionsweise beinahe jeder vorstellbaren Anwendung lässt sich im Kern auf Eingabe, Verarbeitung und Ausgabe reduzieren. Meistens spielen während der Verarbeitungsphase auch langlebige Daten eine Rolle, die entweder modifiziert werden oder das Verarbeitungsergebnis beeinflussen - oder beides. Heute würde man vermutlich eher Business Objects, Business Logic und Presentation Logic sagen. In all diesen Bereichen kann man vom Eclipse Modeling Framework [1] profitieren. Sein pragmatisches Metamodell Ecore ist gut geeignet, als direktes Vehikel für die Modelle aller möglichen realen Konzepte zu dienen. Wenn man dann die ebenfalls zu EMF gehörenden JET-Templates zur Generierung einsetzt, erhält man exzellenten Java-Code für die modellierten Klassen, der sich leicht von Hand an spezielle Anforderungen anpassen und dank semantischem Merge jederzeit regenerieren lässt (JMerge [2], eine Art intelligente Protected Regions mit "Sinn" für Grammatik und Symboltabelle von Java). Der generierte Code wird automatisch in handliche Eclipse Plug-ins verpackt, bleibt aber wegen der optionalen Abhängigkeiten auf das Eclipse Runtime auch standalone ausführbar, wie die ebenfalls generierten Modelltests und Modellbeispiele illustrieren.

Den drei Ebenen des Generats - Model Core, Editing Support und Eclipse Presentation - stehen jeweils mächtige Frameworks zur Seite, die nahezu alle technischen Aspekte behandeln, die beim Umgang mit Business Objects eine Rolle spielen. Das reicht von der Vollautomatisierung bidirektionaler Referenzen und Containment über Modellinteraktion via Commands/Adapters bis hin zu modularer Persistenz in Form von Resources, Cross References und XML/XMI als Standardserialisierung. All diese Frameworks sind wohldurchdacht und flexibel erweiterbar. Insbesondere haben sie einen positiven Einfluss auf das Anwendungsdesign, indem sie die Trennung orthogonaler Belange fördern. So muss man bei der Modellierung der Business Objects keinen Gedanken an Fragen der Persistenz verschwenden. Wichtiger noch: diese Belange haben keinen Einfluss auf die Struktur der Modelle, was Letztere wiederum langlebiger macht (Abb. 1).

Ist das wirklich so? In der Theorie vielleicht, aber in realen Anwendungen kann man das oft nicht so konsequent umsetzen, wie ein Beispiel zeigt: Eigentlich ist Containment ein Attribut logischer Beziehungen zwischen reinen Businesskonzepten und wirkt sich auch direkt auf die in der Benutzerschnittstelle angezeigte Objekthierarchie aus. Bei der Verwendung einer XML-Ressource zur Modellspeicherung landen jedoch alle Objekte, die via Containment vom Wurzelobjekt erreichbar sind, in einer einzigen Datei. Da Textdateien kaum wahlfreien Zugriff ermöglichen, müssen sie also immer komplett gelesen oder geschrieben werden. Das hat fatale Auswirkungen auf die nicht funktionalen Charakteristika der Anwendung. Wenn man jetzt die logischen Containments durch Cross References ersetzt, nur um dem Tree Iterator des XML-Serialisierers ein Schnippchen zu schlagen, dann hat man die Büchse der Pandora bereits geöffnet. Man hat zwar wirkungsvoll die Megadatei in kleine Häppchen zerschnitten, aber wie lange bleiben diese Stückchen klein? Hinzu kommt, dass man für jeden solchen Eingriff mit Zusatzaufwand in der Benutzerschnittstelle bestraft wird, denn man muss die logische Objektstruktur ja irgendwo wieder zusammenkitten. Schließlich könnte man meinen, man hätte mit der Aufteilung des riesigen Objektgrafen in mehrere Ressourcen wenigstens alle technischen Hürden auf dem Weg zu skalierbaren Modellen genommen. Aber weit gefehlt, denn das würde voraussetzen, dass der Java Garbage Collector irgendwann nicht mehr benötigte Objekte wieder aus dem Hauptspeicher räumt, so wie es die Unload Methode im Resource Interface suggerieren mag. Tut er aber nicht!

Listing 1: Studieren geht über Probieren!

Wie man sich leicht überzeugen kann, bleiben nach einem entsprechenden Aufruf alle Java-Referenzen zwischen den Objekten verschiedener Ressourcen unverändert bestehen und verhindern so die Freigabe wertvollen Speicherplatzes (Listing 1). Fairerweise muss man natürlich anerkennen, dass es sich hierbei nicht um Probleme handelt, die erst mit der Einführung von Modeling auftreten. Jede Anwendung wird früher oder später Mühe haben, die klare Eleganz des Businessmodells kompromisslos bis in die Implementierung fortzusetzen. Es gibt eben auch die nicht funktionalen Anforderungen wie Antwortzeiten, Skalierbarkeit, Mehrbenutzerfähigkeit und transaktionale Sicherheit, um nur einige zu nennen. Diese Konzepte werden von EMF zwar nicht direkt adressiert, aber EMF bietet anderen Frameworks offene Schnittstellen zur Lösung der einen oder anderen technischen Herausforderung.