Anwendungsarchitektur von mobilen Location Based Services (LBS)

Mobile LBS Dienste (Standordbezogene Dienste) sind in aller Munde. Das Web wird mobil und damit rücken die Möglichkeiten ortsabhängige Informationen abzurufen in den Vordergrund. Mobile Navigation via Handy, Fotografieren mit Ortsangaben oder ortsabhängige Werbeeinblendungen sind Beispiele dafür. Was zeichnet nun solche Dienste in der Softwarearchitektur aus? Was ist besonders?

Typischerweise kommen Ideen für LBS-Dienste aus dem Marketing und die IT-Abteilung hat sich Gedanken über die dafür notwendige Anwendungsarchitektur zu machen. Neben neuen Diensten sollen vor allem auch existierende Datenbestände des Marketings (wie z.B. Kunden– oder Fahrzeugdaten) in die neuen Anwendungen integriert werden.

So gesehen, ein typisches SOA-Projekt. Allerdings mit ein paar Besonderheiten.
.

Besonderheiten einer LBS-Architektur

Eine dieser Besonderheiten in einer Service orientierten LBS-Architektur sind die speziellen und unterschiedliche Fähigkeiten verschiedener Ausgabegeräte. Die knapp 800 verschiedenen (Java ME) Handymodelle auf dem Markt müssen aufgrund fehlender Standards immer noch individuell anprogrammiert werden. Besonders drastisch ist dies, wenn man die Auflösung, Größe und Geschwindigkeit der unterschiedlichen Displays mit berücksichtigen muss.

Aber nicht nur bei Handys, sondern auch bei der nächsten Generation von Bordcomputern in PKWs spielt sich Ähnliches ab. Zwar ist die Anzahl von Deutschen Automarken -und somit die Variantenvielfalt der Bordcomputer- überschaubarer, doch stellt sich auch hier die Frage wie diese Dienste in das Fahrzeug gebracht werden können. Vor allem müssen diese Web-, Wetter-, Stau– oder Nachrichtendienste via Spracheingabe gesteuert und über eine API an den Webserver angebunden werden.

Verschlüsselte personalisierte Daten

Je nach Sensibilität der übertragenen Daten (TV-Bilder also nicht), findet die Kommunikation verschlüsselt über HSDPA, UMTS oder GPRS statt. Hierbei wird unterschieden ob es sich um personalisierte Daten, wie z.B. persönliche POIs (Points Of Interests) oder aber die zu jeder LBS-Architektur gehörenden Kartendaten handelt. Gibt es für die Übertragung von digitalem Kartenmaterial via http/s inzwischen GeoWeb-Standards (WMS, WFS, WCS) so müssen die POIs und Mediendaten jeweils spezifisch an einen SOA-Bus angebunden werden. Zwar existieren auch hier verschiedene Standards zur GEO-Kodierung (KML, GeoRSS, GML), doch müssen die Bilder, Fotos, Grafiken, Zahlen etc. zunächst aus den Tiefen der Unternehmensdatenbanken ausgegraben, aufgewertet und modifiziert in die neue LBS-Anwendung gebracht werden.

Spätestens an diesem Punkt müssen dann Fragestellungen zur klassischen IT-Integration, Prozessdesign und Verankerung im Unternehmen beantwortet werden. Genau die Fragestellungen also, an denen sich der Erfolg eines größeren Softwareprojekts entscheidet. Ob LBS oder nicht.

Zwei Beispiele von LBS-Diensten mit dahinterliegenden SOA-Prinzipien

SnapSpot ist ein von doubleSlash prototypisch entwickelter Integrationsdienst zur einfachen Geokodierung, Speicherung und Nachbearbeitung von beliebigen persönlichen POI´s. Software für einige gängige Handys mit GPS-Maus oder integriertem GPS-Receiver ist verfügbar. Watchee ist ebenso ein mit doubleSlash Unterstützung entwickeltes Open Source Projekt zum Tracken von mobilen GPS-Receivern. Inkludierte Buddyfunktionen für verschiedene Handymodelle mit unterschiedlichen Betriebsystemen. Besonderheit ist das Verfahren zur komprimierten Datenübertragung und die technische SOA-Infrastruktur im Hintergr