blogoscoop
 
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne
25 Bewertung(en)
Loading ... Loading ...
am 23.09.2008 von Michael Goldschmidt

Ein einsamer Western- und Actionhelden in einem IT-Blog? Es gibt Projekte und Anwendungen, die auch ohne Revolver und Schwarzpulver einige Aufmerksamkeit verdienen. In diesem Fall lohnt sich ein Blick auf Eastwood Charts und damit meine ich nicht die allseits bekannt Filmlegende, sondern eine Open Source Implementation der Google Chart API.

Im Zuge des JFreeChart-Revivals bin ich über Eastwood Charts gestolpert: Ein Stück Java-Code, zu einem Paket geschnürt, erstellt aus einem Seitenaufruf ein kleines Diagramm.

Google Chart API:doubleSlash Logo

Das Herzstück dieser Implementation bildet die schonmals erwähnte Java-Bibliothek JFreeChart. In ein Servlet Container gesteckt und mit einer Java Runtime ab Version 1.4.2 befeuert, werden damit je nach Aufrufparameter kleine on-the-fly Diagramme erstellt. Doch dies eigentlich nichts Neues, wenn nicht auch Google etwas damit zu tun hätte.

Eastwood Charts stellt an sich selbst den Anspruch eine unabhängige Open Source Implementation der Google Chart API zu sein und API-konforme Aufrufe in gleichwertige Diagramme umzuwandeln. Doch wozu das Ganze? Wenn Google eine API und dazu einen entsprechenden Online-Dienst zur Verfügung stellt, sollte dies doch eigentlich ausreichend sein.

Betrachtet man diese Konstellation jedoch etwas kritischer, dann werden zumindest diejenigen Anwender skeptisch, die sensible und geschäftskritische Daten visualisieren wollen. Vorteile wie dynamische Diagrammerstellung direkt aus der Web-Oberfläche heraus, Datenverarbeitung im Frontend, keine Backend-Entwicklung mit Java, usw. überzeugen nicht, solange Online-Dienst und kritische Daten in einem Satz genannt werden. Ebenso mindern Fragen nach Verfügbarkeit, sichere Datenübertragung, Google-AGBs, uvm. die offensichtlichen Vorteile dieser einfachen Chart API. Hier setzt Eastwood Charts an und bedient Projektverantwortliche und Entwickler, bei denen die  genannten Faktoren schwer ins Gewicht fallen.

Der Project Leader David Gilbert liefert die Lösung auf dem Silbertablett: Die Eastwood ZIP-Datei von der Sourceforge-Seite herunterladen, entpacken und die entsprechende WAR-Datei z.B. in einem Apache Tomcat starten. Schon erfüllt Eastwood Charts seine Bestimmung: Verarbeite Google Chart API – konforme Anfragen und liefere ein Diagramm als Antwort zurück.

Daten verkehren nur noch innerhalb definierter Netzwerkgrenzen und müssen nicht erst den Weg über das Internet und die Server von Google nehmen. Ebenso liegt die Verfügbarkeit des Dienstes in der Obhut der eigenen IT-Verantwortlichen.

Natürlich wirken die Linkkonstrukte dieser Diagramme (siehe doubleSlash-Logo) recht kryptisch, da alle Informationen für ein solches Chart innerhalb einer Anfrage übermittelt werden. Ebenso verlagert sich die Logik und Datenverarbeitung in die Oberfläche und dies ist nicht unbedingt im Sinne eines jeden Software-Architekten. Doch es gibt sicherlich auch Anwendungsbereiche, in denen diese Punkte nicht besonders tragisch sind. Wer kann bspw. von sich behaupten, dass sein Fimenlogo bei Google gerendert wird?

Im direkten Vergleich hinkt auch die Open Source Variante seinem Google-Pendant in den Details leider etwas hinterher. Es werden z.B. nicht alle Aufruf-Parameter zu 100% so dargestellt wie es bei Google der Fall ist. Doch ein Blick auf die Beispiel-Seite verspricht ein gutes, vielleicht auch schöneres Produkt. Zudem werden im Forum Fehler kommuniziert und behoben. Und natürlich darf unter der GNU Lesser General Public License (ab Version 2.1) jeder selbst Hand anlegen und gefundene Fehler beheben.

In jedem Fall überzeugt das Ergebnis und macht Lust auf mehr. Denn solange solche Diagramme nicht browser-unabhängig in HTML erstellt werden können, gibt es dank der Google-Implementierung und Eastwood Charts zwei echte Alternativen.

Es dürfte jedenfalls spannend bleiben, was die Zukunft in diesem Bereich bringt. Wie wird das Duell Google vs. Eastwood langfristig ausgehen? Werden neben David Gilbert zukünftig noch andere Entwickler den Mut aufbringen und sich mit Google messen?

Selbst Google lehrte uns in jungen Jahren:

Man muss kein Clint Eastwood sein, um sich erfolgreich mit scheinbar übermächtigen Gegnern zu duellieren.

Eine Antwort zu “ High noon showdown: Google vs. Eastwood ”

  1. Jan Schubert sagt:

    Spannend. Die Länge von solchen HTTP GET sollte aber beachtet werden. Auszug aus
    RFC 2068:

    Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths.

Kommentar verfassen