Möglichkeiten und Grenzen von Google Maps Mashups am Beispiel eines Basketball-Freiplatzverzeichnisses

Inhaltsverzeichnis

Kurzfassung

Abstract

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Zielsetzung

1 Grundlagen von Mashups
1.1 Was sind Mashups
1.2 Wichtigkeit von Metadaten
1.3 Rich Internet Application
1.4 Abgrenzung zu serviceorientierter Architektur

2 Technische Aspekte der Mashups
2.1 AJAX
2.2 Application Programming Interface (API)
2.3 Architekturformen von Mashups
2.3.1 Client-Side-Mashups
2.3.2 Server-Side-Mashup
2.4 Geeignete Mashup Programmiermodelle
2.5 Kommunikationsformate
2.5.1 Anforderungsformate
2.5.2 Ausgabeformate

3 Google Maps
3.1 Key-Features
3.2 Verwendete Technik

4 Mashup-Anwendung: Freiplatzverzeichnis
4.1 Beschreibung der Anwendung
4.1.1 Aufbau
4.1.2 Umsetzung
4.2 Möglichkeiten und Grenzen von Google Maps Mashups
4.2.1 Geokodierung
4.2.2 Umgekehrte Geokodierung
4.2.3 Datenintegration mit KML
4.2.4 Darstellung von Overlays
4.2.5 Darstellung der Marker

5 Zusammenfassung und Ausblick

Quellenverzeichnis

Kurzfassung

Gegenstand der hier vorgestellten Arbeit ist eine Untersuchung von Mashups. Hierbei wird speziell auf den von Google zur Verfügung gestellten Google-Maps-Dienst eingegangen, der als Grundlage eines Mashups dienen kann. In der Seminarveranstaltung

„IT-Workshop“ hat dieser Dienst in der Applikation „Basketball-Freiplatzverzeichnis“ bereits seine Anwendung gefunden. Diese Beispielapplikation ist ihrerseits eine Erweiterung des bestehenden Freiplatzangebotes der Webseite Crossover-online.de und verbessert dadurch nicht nur die visuelle Darstellung, sondern auch die Bedienbarkeit der Anwendung. Diese Applikation dient als Ausgangspunkt der Untersuchungen.

Die hier vorliegende Arbeit bietet eine allgemeine Übersicht über die Stärken und Schwächen von Mashups. Darüber hinaus geht diese Untersuchung auf die speziellen Möglichkeiten ein, die Google mit seinem zur Verfügung gestellten Kartenservice und der dahinterstehenden Programmierschnittstelle bietet. Hierbei werden die Grenzen des Umsetzbaren dieser browserbasierten Anwendung aufgezeigt und mit sinnvollen Lö- sungsansätzen die entstandenen Problematiken gelöst.

Schlagwörter: Mashup, Google Maps, Programmierschnittstelle, Content Syndication, Aggregation 2.0

Abstract

The present research is an investigation of mashups. Therefore a special view on Google’s maps service is taken which builds the main tool for aggregation in mashups in the internet. The application “index of basketball courts” on crossover-online.de represents the basis of this exploration.

The first subject is about defining mashups and the technologies that are in use for them. After the global view on the technique of mashups, a more detailed examination of limits and problems of the Google Maps service and the corresponding application programming interface are explored. Furthermore the investigation identifies possible resolutions for the restrictions of the used technique.

Keywords: Mashup, Google Maps, application programming interface, content syndication, Aggregation 2.0

Abbildungsverzeichnis

Abbildung 1: Hype Cycle 2007 von Gartner

Abbildung 2: Mashup-Matrix

Abbildung 4: Client-Side-Mashup

Abbildung 5: Server-Side-Mashup

Abbildung 6: Erstellte Google Maps Anwendung

Abbildung 7: Aufbau der Applikation

Abbildung 8: Darstellung der Polyline

Abbildung 9: Clusterung der Google Karte

Tabellenverzeichnis

Tabelle 1: Begrenzung der Geokodierung

Tabelle 2: Vergleich zwischen KML und KMZ

Tabelle 3: Vergleich zwischen JSON und KML

Tabelle 4: Begrenzungen der Browser

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Zielsetzung

Das Ziel dieser Arbeit ist es, einen Einblick in die Technik der Mashup-Anwendungen zu geben, die mittels des Google-Maps-Service realisiert werden.

Bevor jedoch die Google-Maps-Technik näher betrachtet werden kann, ist es notwendig einen allgemeinen Einblick in die Mashup-Technik zu geben. Hiernach wird der Fokus auf die Chancen und Möglichkeiten dieser Technik gelenkt, welche den wichtigsten Bestandteil dieser Arbeit darstellen. Um diese zu ermitteln, müssen die bedeutendsten Merkmale einer Google Map herausgearbeitet und untersucht werden. Diese teilen sich dabei in die Geokodierung zur Ermittlung der Geoinformationen, der Datenintegration bestehender Geodaten mittels dem Standardintegrationsformat KML, sowie die verschiedenen Darstellungsmöglichkeiten die eine Google-Maps-Anwendung bietet, auf. Die aus näherer Betrachtung ermittelten Limitierungen lassen dabei Problemstellungen entstehen, für die existierende kreative Lösungswege gefunden und aufgezeigt werden sollen. Diese Lösungswege werden dabei mit Hilfe von Google selbst oder mit Lö- sungsansätzen von Dritten realisiert. Aus den Beobachtungen der Problemund Lö- sungswegfindung erfolgt anschließend eine Bewertung über den tatsächlichen Sinn der existierenden Problemstellung. Dabei gilt es zu beachten, dass nicht jede Problematik, die sich in einer Google Map ergibt auch sinnvoll gelöst werden kann, da die Mashup- Technik zu abhängig von der eingesetzten Browser-, Übertragungsund Servertechnik ist.

Aus diesem Grund ist es wichtig, die Grenzen der Google-Maps-Mashup-Technik zu kennen und aus diesen sinnvolle Möglichkeiten abzuleiten, damit diese Technik zielorientiert eingesetzt werden kann.

1 Grundlagen von Mashups

1.1 Was sind Mashups

Der Begriff „Mashup“ stammt ursprünglich aus der Musikszene und beschreibt das Vermischen von Liedern verschiedener Musikrichtungen miteinander. Das daraus entstehende neue Lied stellt trotz seiner hörbaren Ursprungsklänge ein völlig neues Klangerlebnis dar. (vgl. Carl, 2008, S.3)

Dieser Grundgedanke des „Vermischens“ ist im Internet übernommen worden. Hierbei vermischen Mashups Daten verschiedener Inhaltsanbieter miteinander und schaffen somit neue Applikationen, die einen bis dahin nicht erreichten Mehrwert bieten können. (vgl. Alby, 2007, S.133) Der Autor Frank Schönefeld definiert in der Computerwoche Mashups, als eine Software, die „zwei oder mehrere Web-Dienstleistungen in einer neuen Anwendung (Webapplikation)“ integriert. (Schönefeld, 2007) Diese „Integration kann auf Daten-, Logikund Darstellungsebenen“ vollzogen werden. (Ebd.) Das entscheidende Merkmal ist dabei, dass „sich Mashups durch einfache Overlays, Kombinationen und kaum zeitliche oder logische Abhängigkeiten“ auszeichnen. (Ebd.)

Durch die einfache Verwendbarkeit und die leicht zu erreichenden sichtbaren Ergebnisse steigt die Anzahl der Mashup-Applikationen täglich an. Nicht zuletzt durch die zahlreichen Inhaltsanbieter und den verwendbaren Werkzeugen, wie YAHOO! Pipes (vgl. YAHOO! Pipes, 2008) oder dem Google Mashup Editor (vgl. Google Mashup Editor, 2008), ist es möglich, ohne tiefer gehende technische Kenntnisse eine Mashup- Applikation zu erstellen. Dies führt dazu, dass längst nicht mehr nur von einem Mashup-Trend gesprochen werden kann, sondern durchaus von einem Mashup-Hype. (vgl. Hassler, 2008, S.65) Dies hat auch das IT-Research und Beratungshaus Gartner analysiert und führt in ihrem jährlich erscheinenden Trendbarometer, dem sogenannten Hype-Cycle, die Mashup-Technologie bereits seit dem Beginn der Web 2.0 Ära auf.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Hype Cycle 2007 von Gartner (Quelle: Alexander, 2007)

Nach dem aktuell veröffentlichten Hype-Cycle von 2007 befindet sich die Mashup- Technologie derzeit noch in der Phase der hohen, teilweise unrealistischen Erwartungen an die Technik. Trotz dieser eher kritischen Betrachtung stellt Gartner in ihrer Prognose fest, dass sich „bis 2010 […] Web-Mashups […] zum dominierenden Modell (80 Prozent) für die Erstellung zusammengesetzter Unternehmensanwendungen entwickeln“ werden. (Gartner, 2007 zit. n. Computerwoche, 2007) So sollen sich die „Mashup- Techniken […] in den nächsten fünf Jahren deutlich weiterentwickeln“. (Ebd.)

Die Analyse der Gartner Group ist jedoch kein Grund, Mashups wegen der momentan eher kritisch-analysierten Phase abzuwerten. Laut Hassler sollte man sich, unabhängig von der Analyse, bereits „zum jetzigen Zeitpunkt“ damit „auseinandersetzen wie ein langfristiger Geschäftsnutzen mit einem Mashup erreicht werden kann“. (Hassler, 2008, S.67) So kann der eigene langfristige Erfolg mit dieser Technologie gesichert werden und muss sich nicht „in die Reihe der erfolglosen Anwendungen einer gerade gehypten Technologie“ stellen. (Ebd.)

1.2 Wichtigkeit von Metadaten

Metadaten stellen „Daten über Daten“ oder, konkreter definiert, „Informationen zu Daten“ dar. (IT-Wissen, 2008) Diese Informationen sind innerhalb einer Mashup- Anwendung von großer Wichtigkeit. Sie sind der „Anknüpfungspunkt für den Datenmix“ (Kang, 2007) und ermöglichen somit erst die Aggregation der verschiedenen Dienste miteinander.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Mashup-Matrix

(Quelle: Eigene Darstellung, ProgrammableWeb.com)

Wie in der Abbildung der Mashup-Matrix ersichtlich, bilden die Knotenpunkte eine Mashup-Applikation. So entsteht aus Fotodaten und Kartendaten eine Applikation, die beispielsweise durch ein Google-Maps-Flickr-Mashup miteinander aggregiert werden kann.

1.3 Rich Internet Application

Der Begriff „Rich Internet Application“ (RIA) beschreibt ein Spektrum von Applikationen und Technologien, welche intuitive Benutzeroberflächen ähnlich einer Desktop Applikation bieten. Der einfachste Bereich wird dabei von AJAX bzw. Web 2.0 Applikationen abgedeckt, die bessere Bedienund Ansprechbarkeit zu Standard-Webseiten hinzufügen. (vgl. Heller, 2007)

Der Internetvisionär und Verleger Tim O’Reilly sieht hierbei vor allen Dingen die Google Applikationen GMail und Google Maps als Auslöser für webbasierte Anwendungen, die mit Desktop ähnlicher Bedienung und Interaktion kombiniert werden. Diese Applikationen sind somit für ihn der erste Schritt, um das vorhandene Potential des Internets zu voll skalierbaren Applikationen hin auszubauen. (vgl., O’Reilly, 2005)

Den Web 2.0 Applikationen wird auch die Mashup-Technologie zugeschrieben. (vgl. Carl, 2008, S.16) Das Baukastenprinzip der Mashup-Technik erlaubt es, eine schnellere und einfachere Integration neuer Funktionalitäten oder kompletter Anwendungen in einer bestehenden Webseite zu realisieren. Auf Basis von beispielsweise Google Maps lassen sich somit einfach und schnell anwendungsfallbezogene Lösungen erstellen, die mit weiteren Webdiensten aggregiert werden können. Gleichzeitig wird durch die Anwendung entsprechender Mashupdienste der Mehrwert der Webseite durch die gesteigerte Interaktivität und verbesserte Bedienbarkeit erweitert.

1.4 Abgrenzung zu serviceorientierter Architektur

Die Service-orientierte Architektur (SOA) wird als „ein Softwarekonzept, bei dem einzelne Systeme, die sogenannten Services, bestimmte thematisch abgegrenzte Funktionalitäten und Daten anbieten“ beschrieben. (Carl, 2008, S.17) Diese Beschreibung kann somit auch auf die Mashup-Technologie übertragen werden. Denn vereinfacht betrachtet unterscheidet sich eine Service-orientierte Architektur nicht wesentlich von einer Mashup-Applikation. Dies bestätigt auch der Autor Denny Carl mit seiner These, dass „das ganze Web als SOA angesehen“ werden kann. (Ebd.) Hierbei spricht er zwar vom Web 2.0, jedoch definiert er auch: „ein Mashup ist demnach eine Software, die sich diverse Services der globalen SOA zunutze macht“. (Ebd.)

Die Service-orientierte Architektur besitzt jedoch einen viel komplexeren Ansatz, der weit über das Web hinausgeht. Frank Schönefeld ordnet Mashups zwar als Unterbegriff der SOA-Technologie zu, erkennt jedoch, dass „bewusst auf den komplizierten SOA- Orchestrierungsapparat“ verzichtet wird und bezeichnet die Mashup-Technologie deshalb „als eine Art SOA-Light“, speziell für das Internet. (Schönefeld, 2007)

Daraus leitet er die entsprechenden Einsatzgebiete der beiden Technologien ab: Während SOA-Applikationen „komplexe Logik und Abhängigkeiten zwischen den Diensten realisieren, zeichnen sich Mashups durch einfache Overlays, Kombinationen und kaum zeitliche oder logische Abhängigkeiten aus“. (Ebd.)

2 Technische Aspekte der Mashups

2.1 AJAX

Der Begriff Ajax steht für Asyncronous JavaScript and XML und wurde erstmals von Jesse James Garrett in seinem Aufsatz „A New Approach to Web Applications“ im Jahr 2005 geprägt. Die akronyme Bedeutung dieser vier Worte hat AJAX jedoch längst verloren. Viel mehr existieren für AJAX zwei verbreitete Auffassungen, welche im Folgenden erläutert werden. (vgl. Gehtland/Galbraith, 2006, S.5)

AJAX: Die Technologie

AJAX kann als eine Ansammlung von dynamisch agierenden Technologien gesehen werden, die es erlaubt, einen asynchronen Kommunikationskanal zwischen dem Browser und dem Server herzustellen. (vgl. Gehtland/Galbraith, 2006, S.5) In der Definition von AJAX wurden folgende Technologien festgehalten:

- Präsentationsform von XHTML und CSS
- Dynamische Anzeige und Interaktion mit dem Dokument Objekt Model (DOM) des Browsers
- Datenaustausch und Manipulation mittels XML und XSLT
- Asynchrone Datenabfrage unter Benutzung des XMLHttpRequest-Objekts
- JavaScript verbindet alle verwendeten Technologien (vgl. Steyer, 2007, S.12)

AJAX: Die Architektur

AJAX kann „als Sammelbegriff verwendet“ werden, „für eine Architektur, die bisher mit Webseiten nicht möglich war“. (Alby, 2007, S.135) Dabei werden asynchrone Anfragen vom Browser an den Server gesendet, die serverseitige Ereignisse auslösen können, unbemerkt vom Benutzer. (vgl. Gehtland/Galbraith, 2006, S.14)

Die Mashup-Technologie verwendet ähnliche Architekturformen. Diese basieren jedoch nur zum Teil auf der hier vorgestellten AJAX-Architektur. Deshalb soll in dieser Arbeit der Begriff AJAX nur in Form einer Ansammlung von Technologien verwendet werden.

2.2 Application Programming Interface (API)

Damit ein Mashup die entsprechenden Daten eines Content-Providers nutzen kann, ist ein Application Programming Interface (API) notwendig. Dieses ermöglicht „im Netz den standardisierten Zugriff auf Daten“ eines Content-Providers, um diese selbst weiterverarbeiten zu können. (Carl, 2008, S.17) Um sinnvoll mit den Daten eines Content- Providers arbeiten zu können, ist eine Öffnung der Inhalte für Dritte notwendig, da

„Applikationen […] im Web […] grundsätzlich geschlossene Systeme“ sind. (Carl, 2008, S.18) Diese können jedoch über Schnittstellen „offener gestaltet werden“. (Ebd.) Dazu wird der „externe Zugriff auf Daten und Anwendungen […] über festgeschriebene Vorgehensweisen“ ermöglicht. (Ebd.)

Eine API bildet somit „die wichtigste Komponente einer Applikation, um Teil einer größeren Applikation“, wie beispielsweise einer Mashup-Applikation zu werden. (Alby, 2007, S.133) Bei der Verwendung existieren keinerlei Beschränkungen die Anzahl der verwendeten APIs betreffend. Diese können beliebig miteinander kombiniert werden und schaffen somit einen Nutzen, der von den Content-Providern in der neu entstandenen Form nicht vorgesehen war. Der Autor Tom Alby folgert daraus: „So wie der Remix ein Teil der Social-Software-Kultur ist, so wird er es auch im Gebrauch von APIs.“. (Alby, 2007, S.133)

2.3 Architekturformen von Mashups

Die Architektur von Mashups kann nicht klar definiert werden. Es existieren für viele unterschiedliche Anwendungsfälle verschiedene Lösungsmöglichkeiten. Die Autoren Ed Ort, Sean Brydon und Mark Basler haben Mashups dennoch definiert und zwei extreme Ausprägungen festgehalten. Diese beiden Definitionen finden jedoch ausschließ- lich in der JAVA-Welt ihre vollständige Gültigkeit, weshalb die nachfolgenden Ausführungen dieser beiden Extremformen an die allgemeinen Techniken des Internets angepasst werden. (vgl. Ort/Brydon, 2007)

2.3.1 Client-Side-Mashups

In einem Client-Side-Mashup läuft die komplette Applikation innerhalb der Browserumgebung ab. Die getätigte Eingabe eines Users über das User-Interface wird von der Applikationslogik verarbeitet. Von dieser werden die benötigten Daten vom Client über einen Http-Request angefordert und direkt von der API des Content-Providers verarbeitet. Das Ergebnis wird mittels eines Http-Response wieder zurückgegeben. Die Applikationslogik verarbeitet hierauf die erhaltenen Daten und aktualisiert die Darstellung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Client-Side-Mashup

(Quelle: Eigene Darstellung in Anlehnung an Ort/Brydon, 2007)

2.3.2 Server-Side-Mashup

In einem Server-Side-Mashup stellt der Client die Anfrage für die benötigten Daten an den Webserver. Dieser schickt eine der API des Content-Providers entsprechenden Anfrage über den Http-Request an die entsprechende API weiter. Der Http-Response des Content-Providers wird vom Webserver verarbeitet und für die Darstellung im Client aufbereitet. Der Client erhält die Daten des Webservers bereits in einer Form, die keine weitere Verarbeitung benötigt. Die Applikationslogik des Client muss somit nur noch für die Aktualisierung der Darstellung sorgen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Server-Side-Mashup

(Quelle: Eigene Darstellung in Anlehnung an Ort/Brydon, 2007)