Die Datenbank Graph DB von Sones ist in .Net entwickelt, läuft aber dank Mono auch auf Linux – und seit Mono eine neue Speicherverwaltung mitbringt (Garbage Collector) sogar in vielen Fällen deutlich schneller als auf Windows. Das Linux-Magazin hat Daniel Kirstenpfad, Entwickler und CTO und Richard Doll, CEO von Sones zu dem Erfolg und Widrigkeiten bei der Portierung befragt und Erfahrungen, Tipps und Tricks fürs plattformunabhängige Entwickeln erhalten.

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?

“Bei der Entwicklung unter Windows bestehen keine Einschränkungen. “

Daniel Kirstenpfad: Unter Mono sind noch nicht alle .NET Komponenten umgesetzt. Auch MonoDevelop ist noch nicht auf dem Funktionsumfang des Microsoft Produkts Visual Studio angekommen, jedoch ist die Menge an fehlenden, wichtigen Features sehr begrenzt. Bei der Entwicklung unter Windows bestehen keine Einschränkungen. Trotz der erfolgreichen Kompilierung der Software unter Mono kam es bei der Ausführung zu Laufzeitfehlern, wie etwa dem Auftreten von “NotImplementedExceptions” oder “MissingMemberExceptions”. Deren Ursache musste von den Entwicklern erst nachvollzogen werden. Auch das Debugging war mit der Version 2.6 noch nicht voll nutzbar. Diese Fehler sind dahingehend tückisch, da die Funktionsinterfaces bereits vorhanden sind, ihre Verwendung somit möglich ist und der Code erfolgreich übersetzt wird. Wird die entsprechende Funktion dann während der Laufzeit aufgerufen, tritt ein Fehler im Programm auf. Dies kann zum Absturz des gesamten Programms führen und stellt somit nicht die erwartete Funktionsweise dar.

Linux-Magazin: Abgesehen von der Plattformunabhängigkeit: Konnten Sie noch weitere konkrete Vorteile aus der Plattform ziehen?

Daniel Kirstenpfad: Wir entschieden uns für die Verwendung der Open Source Implementierung, des Microsoft .NET Frameworks ‘Mono’ und die Entwicklungsumgebung ‘MonoDevelop’, die ebenso Teil des Mono-Projekts ist. Die Mono Laufzeitumgebung basiert ebenfalls auf dem CLI-Standard und besitzt einen eigenen JIT-Compiler, der durch Standardkompatibilität gleichermaßen in der Lage ist CIL-Codes in die entsprechende Maschinensprache zu übersetzen.: “Developing your application with Mono allows you to run on nearly any computer in existence”, lautet die Aussage des Mono-Teams. Somit erfüllt Mono unsere Anforderungen an eine Cross Plattform Entwicklung der GraphDB.

Linux-Magazin: Der in Mono 2.8 eingeführte Garbage Collector beschleunigte GraphDB enorm. Haben Sie an seiner Verbesserung mitgewirkt?

Daniel Kirstenpfad: Wir haben nicht selbst am Garbage Collector mitgearbeitet – jedoch haben wir versucht über Benchmarks und isolierte Testfälle die Entwickler so zu informieren, dass eben für große Datenmengen und komplexe Datenstrukturen reproduzierbare Testfälle und Performancemessungen verfügbar sind. Das tun wir heute noch. Beispielsweise mit unserem Benchmark Projekt. Hier werden in wenigen Sekunden enorme Datenmengen erzeugt und prozessiert – Entwickler eines Garbage Collectors haben so eine große Menge Speicherverwaltungstestfälle zur Verfügung.

In Planung: Master-Slave-Clustering und Partitionierung

Linux-Magazin: In Zukunft soll ein Master-Slave-Clustering sowie ein Partitionierungsverfahren die Last auf mehrere Maschinen verteilen.

Daniel Kirstenpfad: Das stimmt. Während die Master-Slave Szenarien ja fast schon zum Standard-Repertoire gehören denken wir, dass besonders ausgefeilten und auf einfache Weise beinflussbaren Graph-Partitionierungsverfahren die Zukunft gehört. Für eine optimale Verteilung von Daten in einem Graphen auf einer Anzahl von Maschinen bieten wir eine offene und Plug-In orientierte Architektur an, die es ermöglicht auch die komplexesten Fälle abzubilden. Beispielsweise durch Partitionsalgorithmen-Plug-Ins.

Linux-Magazin: Inwieweit unterstützt Sie dabei Mono? Sind Sie hier schon an dessen Grenzen gestoßen? Gibt es beispielsweise Komplikationen oder Reibungen, wenn die Instanzen der Datenbank auf unterschiedlichen Betriebssystemen laufen?

Daniel Kirstenpfad: Mono oder .NET stellen uns eine Hardware- und Betriebssystemunabhängige Platform zur Verfügung. In dieser Situation muss man natürlich darauf achten, dass beispielsweise bei Zugriffen im Dateisystem, unterschiedliche Trenn-Zeichen zum Einsatz kommen (“\” versus “/”). Hier hilft uns Mono (und übrigens auch schon .NET) dabei, diese unterschiedlichen Eigenschaften zu behandeln. Komplikationen gab es während der Portierung immer dann, wenn wir jeweils Klassenbibliotheksfunktionen verwendet haben, die es für die jeweils andere .NET Runtime nicht gab. Beispielsweise dauerte es einige Zeit, bis unter Mono die Parallel Extensions verfügbar waren, um parallele Prozesse einfach abbilden zu können. In dieser Zeit hatten wir entsprechende “#ifdef”-Segmente, welche unter Mono eben nicht parallel arbeiteten. Das Beispiel gibt es aber auch andersherum. Es gibt Bereiche, in denen ist Mono der .NET-Platform von Microsoft voraus – ich erinnere mich daran, dass auf einer Microsoft Keynote, ein Compiler-as-a-Service Feature angekündigt worden ist. Für Mono war dieses Feature innerhalb kurzer Zeit verfügbar und stabil. Jedoch dauerte noch viele Monate bis Microsoft liefern konnte.

“Es gibt Bereiche, wo Mono der .NET-Plattform voraus ist”

Linux-Magazin: Ein Problem mit Mono sind immer noch portierbare Benutzeroberflächen. In der Vergangenheit wurden immer wieder auch grafische Oberflächen für GraphDB gezeigt. Der Sones-AssemblyMerger nutzt die Windows Forms und wäre somit portierbar. Das ebenfalls schon im Sones-Blog gezeigte GraphDB Visualization Tool hingegen setzt auf die WPF und Graph#. Wird es hiervon auch eine Mono-Variante geben? Wie sind hier Ihre Erfahrungen mit der Portierbarkeit?

Daniel Kirstenpfad: Was GUI-Portierbarkeit angeht, stellt sich ja grundsätzlich nicht nur das Problem, dass man einfach das Userinterface portiert, welches auf der ursprünglichen Platform verwendet worden ist. Vielmehr muss man auch auf die jeweiligen Eigenheiten, in Belangen der Bedienkonzepte, eingehen. Insofern sehe ich die Portierung von User-Interfaces, auf andere Plattformen, weniger als technische Herausforderung. Vielmehr stellt Sie eine zusätzliche Anforderung an Entwickler und Designer, ein User-Interface zu finden, welches auf der Zielplattform für den Anwender funktioniert. Bild- und Bedienkonzepte, der Plattform sollten zudem unterstützt werden.

Wir haben bei der Umsetzung, der neuen Visualisierungen, der GraphDB einen anderen Weg gewählt. Wir verwenden HTML5 und JavaScript, um alle Gerätekategorien adressieren zu können. Für uns ist das ein einfacher und gut funktionierender Weg, die Bildsprache einer GraphDB zu transportieren und zu visualisieren.

HTML 5 und Touch für Datenbanken?

Linux-Magazin: Auf der CeBIT 2010 haben Sie eine pfiffige und viel beachtete Benutzeroberfläche für GraphDB auf einem Surface Table von Microsoft gezeigt. Diese wäre auch für Tablet-PCs prädestiniert. Planen Sie hier in der Zukunft entsprechende Apps? Wie schätzen Sie das Potential der Mobilgeräte auch im Hinblick auf GraphDB ein?

Daniel Kirstenpfad: Wir konnten, im Rahmen dieses Projekts, ersten Erfahrungen mit dem Surface Table sammeln. Solche User-Interface Konzepte ermöglichen es, dass Anwender unsere Lösung leicht und intuitiv bedienen und verstehen können. Unsere neuen HTML5 Visualisierungsmöglichkeiten kann man daher ebenfalls, über ein Touch-Interface, auf allen Arten von HTML5-fähigen Tablets abbilden. Wir schätzen das Potenzial von mobilen Endgeräten enorm hoch. Damit meinen wir an dieser Stelle nicht nur Smartphones und Tablets.

Linux-Magazin: Wie beurteilen Sie Xamarins Fokussierung hin zu den mobilen Plattformen?

Richard Doll: Wir begrüßen das ausdrücklich aus 2 Gründen: Mobile Plattformen sind populär und haben die größten Developer Communities erzeugt. Durch die Verschiedenheit und die Beschränkungen der Anbieter, hat sich hier ein glasklarer Anwendungsfall, für die Portierbarkeit von Mono Code Development ergeben. Das kann nur gut sein, für die Bekanntheit und das Wachsen von Mono. Für viele Entwickler einer populären Plattform heißt das, dass sich für das Mono-Projekt die kommerziellen Chancen erhöhen und das sichert die Zukunft.

Linux-Magazin: Wird Mono dabei langfristig auf der Strecke bleiben? Könnte es zukünftig zu Problemen kommen, wenn sich Xamarin zunehmen auf Mobilgeräte konzentriert und die Unterschiede zwischen .NET und Mono immer deutlicher werden?

Richard Doll: Das sehen wir nicht so. Xamarin hat ein gewachsenes Interesse an Mono und hat bereits gezeigt, dass sie mit Nachdruck weiter an allen Bestandteilen, von Mono weiterarbeiten. So wurde MonoDevelop weiter entwickelt und bereits neu aufgelegt. Wir können hier keine Verlangsamung erkennen. Außerdem hat der höhere Freiheitsgrad, den die Entwickler bei Xamarin haben auch schon auf der Monospace spürbar positive Stimmung erzeugt. Das war innerhalb von Novell oft deutlich schwerer, weil dort natürlich auch auf andere Ziele Rücksicht genommen werden musste, die nichts mit Mono zu tun hatten.

“Eine Mono-Foundation erübrigt sich durch Xamarin”

Linux-Magazin: Sones hatte im Frühjahr die Gründung einer Mono Foundation und die Einführung einer europäischen Monospace Konferenz angeregt. Wie geht es hier voran? Wenn die beiden Projekte auf Eis liegen: Woran scheiterte es?

Richard Doll:Die Foundation war unter dem düsteren Vorzeichen angedacht worden, dass Xamarin mit Attachmate noch keine Einigung über den Fortgang der Mobile-Produkte erzielt hatte. Zur Freude aller wurde dies jedoch in der Woche vor der Monospace in Boston erreicht und damit erübrigte sich eine Foundation. Xamarin hat sich bereit erklärt als „Steward“ des Mono-Projektes dessen Weiterpflege zu unterstützen. Damit entfiel ein wesentlicher Grund für die Foundation.

Der zweite Grund, die Organisation der Entwickler-Konferenzen wurde durch die Schaffung eines Non-Profit- Unternehmens (nach US-Recht) inzwischen von 2 Mitgliedern der Community, die auch die Boston-Konferenz organisiert hatten, gesichert.

Wir sind weiter an einer europäischen Version der Mono Conference interessiert und sind bereits im Gesprächen, mit der Non-Profit Organisation in USA und einigen Schlüsselpersonen, im deutschen Open Source Umfeld. Wenn sich diese Gespräche konkretisieren wird dies bekanntgegeben.

Prinzipiell werden wir nicht als alleiniger Ausrichter der Monospace in Europa auftreten, aber Sones wird gerne einen Beitrag leisten.

“Die guten Gründe für Mono werden immer mehr”

Linux-Magazin: Wie schätzen Sie generell die Zukunft von Mono ein? Die Referenzliste auf der Mono-Projektseite ist im Moment noch relativ mager im Vergleich zum .NET-Softwareangebot aus der Windows-Welt. Würden Sie nach Ihren Erfahrungen auch anderen Unternehmen dazu raten auf Mono zu setzen?

Richard Doll: Wir sehen (s.o.) einen sehr positiven Trend für Mono und aus unserer Sicht wird Xamarin dazu beitragen, die Community stark zu vergrößern, durch die Verbreitung ihrer Mobile-Produkte.

Die Plattform hat sich stetig verbessert – von daher sind die guten Gründe für Mono eher gewachsen.

Linux-Magazin: Wie sehen Sie die Patent-Problematik rund um Mono?

Richard Doll: Sones kann hier keine verbindliche Auskunft geben, aber Microsoft hat sich im Verlauf der letzten Jahre immer kooperativer gezeigt, wenn es um Mono ging. Der Verkauf von Novell an Attachmate war eine wesentliche Zäsur und dennoch ging daraus eine neue Firma – Xamarin – hervor, die weitreichende Vereinbarungen im Rahmen von Mono-Technologie treffen konnte. Von daher sehen wir die Entwicklung hier positiv.

Linux-Magazin: Aus Ihrer Erfahrung: Für welche Art Software eignet sich Mono besonders gut und wo liegen die Grenzen?

“Mono eignet sich auch für Plattformen, an die Microsoft bei .NET nie gedacht hat”

Daniel Kirstenpfad: Mono eignet sich grundsätzlich für alle Arten von .NET Software, denn erklärtes Ziel ist ja, die .NET Platform möglichst umfassend zu unterstützen. Natürlich ist es nun so dass Mono noch ganz andere Zielplatformen mitbringt als Microsoft .NET überhaupt adressieren will und kann: Android und iOS. Würde ich eine mobile, native Applikation für Android, iOS und Windows Phone 7 schreiben, würde ich Mono ernsthaft in Betracht ziehen. Bei disziplinierter Trennung von Code und Präsentation kann man sozusagen alle großen Platformen, mit einem Streich abdecken und dennoch eine an die Zielplatform angepasste UI-Umsetzungen liefern.

Linux-Magazin: Was würden Sie einer Firma oder einem Entwickler raten, der mit Mono plattformübergreifend programmieren möchte? Worauf sollte er besonders achten?

“Am Anfang steht das Build- und Test-System”

Daniel Kirstenpfad: Ich würde grundsätzlich darauf achten, ein entsprechendes Build- und Test-System, schon zu Beginn der Entwicklung aufzusetzen. Damit kann der Entwickler automatisiert unter Mono und .NET auf verschiedenen Platformen den aktuellen Stand der Entwicklung durchtesten. Es ist für uns von unschätzbarem Wert, solche Tests und Continuous Integration Dienste zu nutzen. Schon um mögliche Pitfalls im Bezug auf die Verfügbarkeit und Nichtverfügbarkeit von Klassenbibliotheksfunktionen zu vermeiden. Niemand sollte blind darauf vertrauen, dass die Software auf einer Platform fehlerfrei läuft, wenn er es nicht getestet hat. Zumindest das automatisierte Testen ist hier ein Muss.

Wenn noch keinerlei Erfahrung mit Mono vorliegt, würde ich kleine Schritte gehen. So gewinnt man Vertrauen und Sicherheit zur Technologie. Die Community zu fragen und selbst zu helfen ist immer eine gute Idee.