Man könnte sagen, dass es prinzipiell zwei Wege gibt, bestimmte komplexe aber unabhängige Teilfunktionalitäten eines Systems zu entwickeln:

1. Alles selbst entwickeln
2. freie Frameworks, APIs und SDKs nutzen und zu einem größeren Ganzen zusammenstecken.

Natürlich ist das auch abhängig von der Art der Software, die man entwickelt, für welche Firma man entwickelt und wie die Rahmenbedingungen aussehen. In meinen Erfahrungen zeigte es sich oft so: Man steht vor einen riesigen Aufgabe, der man aufgrund fehlender Resourcen (sei es Wissen, Zeit oder die Teamgröße) als nicht lösbar erachtet. In einigen Fällen wird man diese Aufgabe komplett ablehnen, in einigen Fällen wird man sich für eine leichtgewichtige Version entscheiden, die nur einen Teil der gestellten Aufgabe abbildet und in einigen Fällen wird man anfangen zu entwickeln und am Ende kläglich an den hohen Anforderungen scheitern.

Der oft einfachste Weg solche Aufgaben ohne Probleme mit den gegebenen Resourcen lösen zu können ist die Nutzung von OpenSource Frameworks. Für beinahe jede Aufgabe gibt es bereits eine angemessene Lösung beziehungsweise eine unterstützende Komponente, die es dem Entwicklerteam ermöglicht sich auf das wichtige konzentrieren.

Ich möchte fünf Beispiele nennen, in denen mir und meinem Team ein oder mehrere OpenSource Produkte halfen Problemlösungen zu entwickeln, für die man normalerweise weitaus mehr Zeit und Manpower benötigen würde.

Beispiel 1: Implementierung einer flexiblen Enterprise-Datenbanksuche für ein bestehendes PHP-MySQL System

Das Problem: Wir hatten es mit einer sehr großen, absolut unperformanten MySQL - Datenbanklösung zu tun: Ein Verbund von ca. 200 Tabellen mit bis zu 18 Mio Einträgen und jeweils 50 Feldern. Die Tabellen sind weder normalisiert noch auf Feldebene optimiert. Suchanfragen können ausschließlich über zwei statische Hash-Werte durchgeführt werden. Jede andere Suchanfrage legt die Datenbank für mehrere Minuten lahm. Dieser Zustand war für den Bestand des Gesamtsystems inakzeptabel, ein komplettes Re-Design der Lösung jedoch aus Kostengründen nicht möglich. Aufgrund der hohen Komplexität des Systems spielt hier auch das Risiko des Unverhersehbaren eine bestimmte Rolle. Des weiteren musste berücksichtigt werden, dass das gesamte Restsystem, in dem Datenbankzugriffe stattfinden, in PHP programmiert wurde. Was tun?

Die Lösung: Lesende Anfragen sollen von der Datenbank gelöst werden. Im gleichen Atemzug sollen Suchanfragenunschärfen zulassen und idealerweise schnell sein, die Datenbank aber nicht weiter belasten. Nach langem überlegen und planen, nach dem Ausschluss diverser zunächst vielversprechender dann aber nicht tauglicher Alternativen sind wir auf eine Lösung gestoßen:

Apache Lucene Solr

Apache Solr. Dabei handelt es sich um einen auf Lucene basierenden Enterprise Suchserver. Durch dieses Produkt konnten wir unsere Ziele allesamt erreichen und benötigten dafür geradeeinmal 2 Entwickler, die drei Wochen an der Integration arbeiteten. Solr erlaubt es anhand einer Webserviceähnlichen Schnittstelle über HTTP Anfragen zu stellen und die flexible Konfiguration der Indexstruktur. Wir haben eine auf Suchanfragen optimierte Struktur geschaffen, und damit die gesamte Datenbankstruktur auf Solr abgebildet. Die Aktualität des Index wird gewährleistet indem wir mit Hilfe von Triggern eine Update Tabelle füllen, die in lurzen Zeitabständen ausgelesen und auf den Index übertragen wird. Um doppelte Datenhaltung zu vermeiden und die Einhaltung der Datenschutzrichtlinien zu gewährleisten sind im Index ausschließlich die Primärschlüssel der Suchergebnisse gespeichert. Im bestehenden System mussten alle lesenden Prozesse durch Anfrage an den Solr-Server abgelöst werden. Mit den Ergebnislisten werden dann die Daten aus der Datenbank geholt. Eine Suchanfrage, für die man bisher ca. 20 Minuten benötigte dauert heute nur noch 0,1 Sekunde. Wir können komplexe Auswertungen erstellen und flexibel auf spezielle Datenbankanfragen von Kunden reagieren. Der größte Vorteil von Solr aber ist seine Unabhängigkeit. Das System, in dem die Suche integriert werden musste, war in PHP geschrieben. Die standardisierte HTTP Schnittstelle, die es erlaubt neben XML auch JSON oder HTML als Ergebnis zu erhalten erlaubte es uns den Dienst separat auf einem eigenen Server aufzubauen und dann einfach über einen HTTPClient einzubinden.

Beispiel 2: Implementierung eines Text-Analyse-Systems zur Extraktion und Überführung von strukturieren Daten aus Freitexten in eine relationale Datenbank.

Das Problem: Bestimmte Prozessentscheidungen beim Kunden erfordern die Einbeziehung srukturierter Informationen, die lediglich in Textform vorliegen. Der manuelle Aufwand der Strukturierung dieser Texte ist allerdings so enorm, dass der Einsatz der Daten sehr teuer ist. Die Implementierung eines Text-Information-Retrieval Systems, welches die Strukturierung automatisiert wäre für ein kleines Team von ca. 10 Programmierern kaum durchfürbar. Eine einfache Lösung ist für die Komplexität der Texte und der Vielfältigkeit der zu strukturierenden Informationen kaum denknar.

Die Lösung: Von der Universität Sheffield wird ein OpenSource System angeboten, welches genau diese Aufgabe lösen kann. GATE.

Hierbei handelt es sich um ein Framework zum einlesen und verarbeiten textueller Information. Neben des eigentlichen Prozessframeworks besteht GATE aus zahlreichen Plugins verschiedener Anbieter, die zu diversen Zwecken eingesetzt werden können. Die wichtigsten GATE Plugins sind unter ANNIE (A Nearly-New Iniformation Extraction system) zusammengefasst. Für unsere Aufgabe haben uns insbesondere zwei Mechanismen geholfen: Der JAPE-Transducer und der sogenannte Gazetteer. Grundlegend ist GATE aus Sprachresourcen (LR) und Processing Resources (PR) aufgebaut. Letztere werden in Pipelines beliebig zusammengebaut und verarbeiten genannte Sprachresourcen (Dokumente bzw. Korpora). Die Inhalte eines Dokuments werden entlang der Processing Pipeline annotiert.

Der Gazetteer fügt Named Entity Annotationen zum Text hinzu. Dazu haben wir diverse Lookupdatenbanken aufgebaut: Vornamen, Nachnamen, Städte, Postleitzahlen, Bundesländer, Rechtsformen, Toplevel Domains etc. Diese Annotationen wiederum werden in diversen JAPE Regeln in ihren Kontexten betrachtet, so dass man auf den Inhalt und Zweck der Daten schließen kann.

Die so ermittelten Daten werden analysiert und rückwirkend auf ihre Qualität bewertet.

Das Ergebnis: Wir können in weniger als 20 Minuten 4000 Dokumente einlesen, auswerten, strukturieren und in einer Datenbank speichern. Aufgrund bestimmter Muster lassen sich sichere von unsicheren Strukurierungen trennen. Unsichere Ergebnisse werden in einem manuellen Prozess nachgeprüft und ggf. angepasst, so dass wir insgesamt eine 100%ige Erkennunsrate erreichen.