JAXenter: Hallo Herr Kögel! Sie haben vor kurzem das neue Eclipse-Projekt EMFStore als Proposal eingereicht. Können Sie kurz erklären, um was es sich dabei handelt?
Maximilian Kögel: EMFStore ist ein Repository für EMF-Modelle. Es erlaubt, diese Modelle zu speichern und zu versionieren, vor allem aber auch kollaborativ zu bearbeiten. Modelle können dabei Modelle von Entwicklern darstellen aber auch die Daten der Endanwender einer Businessanwendung. EMFStore arbeitet dabei aus Anwendersicht wie Subversion oder CVS: Modelle können in den lokalen Workspace übertragen (checkout) und dort offline bearbeitet werden. Die lokalen Änderungen an Modellen können an das Repository übermittelt werden (commit) und Änderungen aus dem Repository zurück in den lokalen Workspace gespielt werden (update).
Da es dabei zu Konflikten, d.h. überlappenden Änderungen kommen kann, bietet EMFStore interaktive Konflikterkennung und -behebung (merging). Ausserdem kann natürlich die Historie des gesamten Modells oder auch einzelner Modellelemente abgefragt werden. Dazu stehen sowohl die Änderungen an den Elementen (diffing) als auch alle früheren Versionen der Elemente zur Verfügung. Für all diese Anwendungsfälle bringt EMFStore bereits Benutzeroberflächen mit. EMFStore steht unter EPL und ist jetzt schon auf http://emfstore.org verfügbar.
JAXenter: Wie ist das Projekt entstanden und von wem wird es heute weiterentwickelt?
Maximilian Kögel: EMFStore ist im Rahmen des UNICASE-Projekts entstanden, das ein uniformes CASE-Tool entwickelt. Für die Modelle, die in diesem CASE-Tool modelliert wurden, wurde ein Repository benötigt. Da kein vorhandenes Repository unsere Anforderungen direkt noch durch Erweiterungen erfüllen konnte, haben wir selbst ein Repository entwickelt.
Zunächst war dieses nur als Repository für den UNICASE Client konzipiert, es hat sich aber schnell gezeigt, dass unsere Industrie- und Forschungspartner das Repository auch in anderen Anwendungen einsetzen wollten. Daher haben wir schon sehr früh angefangen, EMFStore als eigenständiges Framework zu entwickeln.
Die Entwicklung von EMFStore findet zusammen mit unseren Industrie- und Forschungspartnern statt, wird aber vom UNICASE-Projekt koordiniert. Im Moment arbeiten mehr als 10 Entwickler aktiv am EMFStore.
JAXenter: Ist EMFStore bereits produktiv im Einsatz?
Maximilian Kögel: Zunächst einmal setzen wir selbst EMFStore als Repository für UNICASE ein. UNICASE ist bei unseren Industriepartnern (z.B. Flughafen München), bei unseren Forschungspartnern (z.B. Universität Heidelberg) und nicht zuletzt für unsere eignen Lehrveranstaltungen im Produktiveinsatz. Gerade in den Lehrveranstaltungen arbeiten große Teams (bis zu 50 Leute) an einem Modell, das im EMFStore gespeichert und versioniert wird. UNICASE verwendet dazu auch die von ECP (EMF Client Platform) bereitgestellten Benutzeroberflächen. Aus dem Eclipse-Umfeld nutzen nach unserem Wissen im Moment red-open und red-view EMFStore direkt als Framework. Aus dem industriellen Umfeld verwendet EADS den EMFStore für eine Anwendung im Bereich Aviation.
JAXenter: EMFStore ist ein Repository für EMF-Modelle. Bei Eclipse gibt es auch das CDO Model Repository, das schon als relativ ausgereift gelten darf. Ist es denkbar, angesichts der Überschneidungen beide Ansätze miteinander zu vereinen?
Maximilian Kögel: In seinen Anfängen verfolgte CDO einen sehr entgegengesetzten Ansatz zu EMFStore. CDO steht für "Connected Data Objects" und drückt damit auch schon den größten Unterschied zu EMFStore aus: CDO arbeitete nur online während EMFStore nur offline arbeitet. Seit einiger Zeit nähern sich die beiden Projekte jedoch an. CDO hat inzwischen einen Offline- Modus. EMFStore bietet inzwischen einen Online-Kanal, über den die Clients automatisch über Modelländerungen im Repository informiert werden.
Bezüglich der generischen Benutzeroberflächen für das Bearbeiten von Modellen, die EMFStore von der EMF Client Platform verwendet, sind wir schon mit Eike Stepper von CDO im Gespräch. Wir planen, diese so generisch zur Verfügung zu stellen, dass die Oberflächen dann gleichermassen für CDO wie für EMFStore zum Einsatz kommen können. Aus unserer Sicht muss sich zeigen, ob die Funktionalität von EMFStore und CDO in einem Framework Platz findet, bis dahin werden wir iterativ Technologien austauschen, wo es Sinn macht. Unser Ziel ist es, sowohl technisch einen Wechsel zwischen CDO und dem EMFStore transparent zu machen als auch die Unterschiede klar zu kommunizieren.
JAXenter: Wie differenziert sich EMFStore von CDO?
Maximilian Kögel: Um eine Anwendung basierend auf EMFStore zum Laufen zu bringen, genügt es, ein Ecore-Modell zu erstellen und dafür den Code mit dem EMF-Code-Generator zu generieren. EMFStore bietet dann bereits Ansichten, um die Modelle im lokalen Workspace zu bearbeiten, die verfügbaren Modelle auf dem Server anzuzeigen, Änderungen zu synchronisieren, Konflikte zu beheben, die Historie zu visualisieren und Zugriffsrechte zu vergeben.
Damit ist es sehr schnell möglich, eine laufende Anwendung basierend auf dem EMFStore zu erstellen, diese kann dann iterativ angepasst werden.
EMFStore ist ausserdem konsequent auf Offline-Arbeit ausgelegt und bietet daher beispielsweise interaktives Mergen, um konfliktierende Änderungen zu beheben. Dabei geht es technisch einen anderen Weg als CDO. Änderungen werden als Modelltransformationen aufgezeichnet, so genannte "Operationen". Diese Operationen können auch umfangreiche Modelländerungen wie Refactorings abbilden. Die Konflikterkennung arbeitet auf diesen Operationen und kann damit z.B. auch überlappende Refactorings atomar behandeln.
Natürlich hat CDO auch Vorteile gegenüber EMFStore. CDO ist explizit auf große Skalierbarkeit ausgelegt. EMF lädt von sich aus alle Modelle in den Speicher und bietet keine eigene Speicherverwaltung. Das heißt, sehr große Modelle verbrauchen auch viel Speicher. Der Speicherverbrauch hängt natürlich sehr stark vom Modell ab. Um dennoch eine Größenordnung zu nennen: In Tests haben 1.000.000 Modelelemente ein 1 GB Hauptspeicher belegt. Während CDO ein eigenes Speichermanagement mitbringt, um den Speicherbedarf zu reduzieren, unterliegt EMFStore den gleichen Beschränkungen wie EMF selbst.
EMFStore bietet außerdem keinen Online-Modus. Ein anderer nennenswerter Unterschied ist die Unterstützung für Modellmigration, die EMFStore mitbringt. Bei Änderungen des Ecore-Modells können mithilfe von COPE automatisiert Migratoren generiert werden, die bestehende Modelle im EMFStore migrieren, so dass diese wieder zum neuen Ecore-Modell konform sind.
JAXenter: Was sind die nächsten Schritte für EMFStore?
Maximilian Kögel: Wir arbeiten im Moment daran, dass EMFStore auch Modelle, die nicht für EMFStore konzipiert wurden (und keine IDs enthalten), verwalten kann. Damit würde sich die Transparenz für Framework-Anwender weiter erhöhen. Unser Ziel ist, dass es für eine Anwendung keinerlei Unterschied macht, ob sie gerade auf einer EMF-XMI-Ressource oder auf einem EMFStore Workspace arbeitet. Weiterhin arbeiten wir daran, mehr Tooling bereitzustellen, um den EMFStore auch direkt zur Verwaltung von Ecore und anderen EMF-Modellen in der Entwicklungsumgebung als Ersatz für SVN oder CVS zu integrieren.
JAXenter: Vielen Dank für dieses Gespräch!
Maximilian Kögel ist Doktorand am Lehrstuhl für angewandte Software-Technik bei Prof. Bruegge an der Technischen Universität München. Er verfügt über langjährige Erfahrung im Software Engineering, insbesondere auch für Eclipse-Technologien. Sein Forschungsfokus liegt in der Versionierung und dem Merging von Modellen. Er ist Mitbegründer und Leiter des UNICASE-Projektes, einer Platform für die Umsetzung Modell-basierter Ansätze. Im Rahmenprojekt UNICASE entstanden zwei Eclipse-Frameworks, EMFStore und die EMF Client Platform (ECP), die beide momentan als Eclipse-Projekte vorgeschlagen werden. 
