Linux-Magazin: Warum wählten Sie die .NET-Plattform und beispielsweise nicht Java?
Daniel Kirstenpfad: Wir haben uns 2005 für die .NET –Technologie entschieden, da uns die Plattform die größte Flexibilität und die besten Ausdrucksmöglichkeiten, zum Zeitpunkt des Projektstarts zur Verfügung stellte. Mit der damals verfügbaren offenen .NET Implementierungen, namens Rotor und Mono war am Horizont zu erkennen, dass wir zukünftig auch platformunabhängig entwickeln können. Unsere Annahme traf später dann auch ein. Die Technologie ermöglichte es uns, die GraphDB schnell, performant und produktiv zu entwickeln.
Linux-Magazin: Also entstand GraphDB erst unter .NET und wurde dann portiert oder wurde .NET schon gewählt, weil es Mono gab?
"Schon nach wenigen Stunden lief die Datenbank auch unter Mono"
Daniel Kirstenpfad: Die GraphDB entstand erst einmal nur unter .NET. Zum damaligen Zeitpunkt war das Mono Projekt gerade bei Version 1.0 angekommen und die 2.0 in Planung. Wir hatten Vertrauen und Zuversicht in das Projekt und die Community, hinter dem Mono-Projekt. Nicht zuletzt deshalb weil wir uns auch selbst als aktiven Teil der Mono-Community begreifen und zur Verbesserung der Platform beitragen wollen. Wir haben mit GraphDB 1.0 begonnen, etwa zum Zeitpunkt als Mono.NET 4.0 Funktionalitäten verwendbar anbot, unseren gesamten Code auch unter Mono zu testen. Das lief erstaunlich gut: schon nach wenigen Stunden kompilierte alles, nach einigen Tagen lief die Datenbank unter Mono. Zum damaligen Zeitpunkt war die Platform aber ehrlicherweise noch nicht so weit, dass wir Mono, als supportete Platform anbieten konnte. Alles zeigte in die richtige Richtung und es galt die Platform so zu verbessern, dass die Herausforderungen, vor die uns die 2.6er Version von Mono stellte, gelöst werden konnten.
Linux-Magazin: Wäre C/C++ bei einer Datenbank nicht effizienter? Schließlich laufen Mono-Programme in einer virtuellen Maschine.
Daniel Kirstenpfad: Nun ist es natürlich so, dass nicht jede virtuelle Maschine gleich ist. Bei .NET allgemein handelt es sich ja um die sogenannte Common Language Runtime welche eine ganze Reihe von Diensten zur Verfügung stellt, die für moderne, datenhungrige und platformunabhängige Anwendungen unverzichtbar sind:
"Der Garbage Collector ermöglicht völlig neue Ansätze"
- Der Garbage Collector beispielsweise, kümmert sich darum, dass der von der Anwendung vormals verwendete und nun freie Speicher erkannt und wieder zur Verwendung freigeben wird. Hierbei können für verschiedene Anwendungsfälle ganz verschiedene Strategien und Konzepte zum Einsatz kommen. Für die Anwendung selbst ändert sich nichts. Sie muss nicht neu übersetzt oder angepasst werden. Auf wichtige Performance-Aspekte kann ebenfalls weiter Einfluss genommen werden.
- Echte Plattformunabhängigkeit, ohne Neu-Kompilierung: Wir sind mit .NET in der Lage eine kompilierte GraphDB auf Windows, Linux, Mac OSX einsetzen zu können, völlig unabhängig von den Prozessorarchitekturen. Ein Start auf einem Intel Prozessor, einem ARM, PowerPC oder IBM Power Prozessor sind daher problemlos möglich.
- Die Runtime stellt der Anwendung, für die jeweilige System- und Prozessorplattform optimierte Methoden zur Verfügung um zum Beispiel auf Datenträger zuzugreifen.
- Die Sones GraphDB profitiert direkt von Verbesserungen und einer Optimierung der Runtime und der dahinter liegenden Klassenbibliothek.
Linux-Magazin: Wurde die komplette Datenbank in C# geschrieben (einschließlich des Unterbaus GraphFS)?
Daniel Kirstenpfad: Ja, die 3 Schichten der GraphDB, GraphDS, GraphDB und GraphFS wurden komplett in C# geschrieben. Zusätzlich dazu gibt es natürlich Client-Libraries für beispielsweise Java, PHP, JavaScript und eine integrierte HTML5-WebShell um Ad-Hoc Anfragen an die Datenbank zu stellen und sich diese visualisieren zu lassen.
Linux-Magazin: Gibt beziehungsweise gab es eine Unterstützung durch Novell/Xamarin oder hat man Sie mit dem Code mehr oder weniger allein gelassen? Wenn es eine Unterstützung gab, wie sah die aus? Hat sich hier durch die Gründung von Xamarin etwas geändert? Konnte Sones sogar Code an das Mono-Projekt zurückgeben?
Daniel Kirstenpfad: Gleich zu Beginn des Projekts haben wir, über die verschiedensten Wege, Kontakt zur Mono-Community aufgenommen. Sei es über den IRC-Channel des Projekts oder die später von Novell angebotenen Bugtracker und Foren. Wir haben uns zu keiner Zeit alleingelassen gefühlt, im Gegenteil! Wir konnten bei Fragen und Anregungen schnell den eigentlichen Autor kontaktieren und haben immer zügig Feedback erhalten. Ich erinnere mich an einen Test, in dem wir herausfinden wollten, weshalb wir unter Mono andere Performance-Messwerte, für einen isolierten Fall, erhalten haben als unter Microsoft .NET. Wir konnten innerhalb von wenigen Minuten den Autor eines Profiling Tools (HeapShot) ausfindig machen und so die Erklärungen, für das Verhalten erhalten. Mit der Gründung von Xamarin ist aus unserer Sicht der Austausch und die Unterstützung noch einmal verbessert worden. Sicherlich gab es in der Übergangsphase einige Herausforderungen. Ich denke aber, die Situation hat sich noch einmal verbessert.
Linux-Magazin: Auf welche besonderen Probleme sind Sie bei der Portierung gestoßen?
Daniel Kirstenpfad: Nachdem, Anfang 2010 der Entschluss für Mono fest stand, galt es, eine lauffähige Mono-Version für einen Linux Server zu erstellen. Dieser sollte die Möglichkeit bieten, von verschiedenen Zugriffspunkten ein lauffähiges Software Build der GraphDB unter Linux zu erstellen. Diese Anforderung bereitete Probleme, da die Mono-Release-Pakete nur für ältere Linux Distributionen vorhanden waren. Um die damals aktuellste Mono-Release Version 2.6 nutzen zu können, musste diese erneut kompiliert werden um unter der, bei Sones verwendeten Linux Distribution Debian Linux 5.0 “Lenny“ verwendbar zu sein. Hierbei ergaben sich Schwierigkeiten, da in Mono Abhängigkeiten zu anderen Paketen einer Linux Distribution existieren, die wiederum nicht aktuell waren. Diese mussten ebenfalls neu kompiliert werden, um anschließend das gesamte Projekt neu erstellen zu können.
Durch das Erstellen der Sones GraphDB und die sich anschließende Testphase unter Mono konnten die Probleme gesichtet und in der folgenden Anpassungsphase behoben werden. Hier wurden die Unterschiede bei der Open Source Umsetzung der .NET Pakete erkennbar. Die Anpassung bedeutete, dass für die beiden Umgebungen Code-Abschnitte teilweise unterschiedlich programmiert werden müssen.
Linux-Magazin: War es ein großes Problem, dass in Mono einige .NET-Bestandteile fehlen?
