Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

13.02.1998 - 

Transaktionsmonitor regelt Zugriffe

Tegaron Info weicht dem Stau im Datennetz aus

Feierabendverkehr im Großraum Hamburg. Anstatt das Radio einzuschalten, wählt der Besitzer eines D1-Handys die 2211, gibt über Telefontastatur seine Fahrtrichtung ein und erhält dann eine Stunde lang in regelmäßigen Abständen - bei besonderen Vorkommnissen auch häufiger - genau auf sein Fahrtziel zugeschnittene Stauwarnungen aus dem Sprachcomputer. Anbieter dieser Dienstleistung ist die Tegaron Telematics GmbH, ein im Sommer vergangenen Jahres gegründetes Joint-venture von T-Mobil und Debis.

Das System erhält alle Standortinformationen über die zugehörige Funkzelle des GSM-Netzes, so daß der Kunde keine expliziten Angaben über seinen Standort machen muß. Zwar haben die Funkzellen unterschiedliche Dichte, die Genauigkeit der Angaben ist aber für dieses Problem hinreichend. Ausgehend von der eingegebenen Richtung definiert das System ein Gebiet, für das es alle verfügbaren Verkehrsinformationen weitergibt.

Diese Informationen stammen derzeit hauptsächlich von der Deutschen Datengesellschaft (DDG), einem Joint-venture von Tegaron und Mannesmann Autocom, sowie aus den Landesmeldestellen, die auch den Rundfunk sowie den ADAC mit Verkehrsmeldungen versorgen. Um das Verkehrsdaten-Netz noch dichter zu knüpfen, installiert der Bund im Verein mit der Industrie derzeit auf den Autobahnbrücken spezielle Sensoren, mit deren Hilfe der Verkehrsfluß beobachtet werden soll. Ein Fernziel ist zudem die Ermittlung von "Floating Car Data" durch ein automatisches Feedback von seiten der Serviceteilnehmer. Dazu wäre es notwendig, den Standort der an das System angeschlossenen Autofahrer in bestimmten Intervallen mit einem für die jeweils gefahrene Strecke ermittelten Durchschnittswert zu vergleichen. Bei einer hinreichenden Zahl von Teilnehmern entstünde auf diese Weise eine Art Verkehrsdichte-Landkarte für die gesamte Bundesrepublik.

Time to market war ein entscheidender Faktor

Doch das ist noch Zukunftsmusik. Ohnedies war der Tegaron-Dienst schon schwieriger zu implementieren, als es sich hier liest. Die größe Herausforderung für die Software-Entwickler stellte die beinahe unbeschränkte Teilnehmerzahl dar. Dazu Dieter Hack, Geschäftsführer des Hamburger Lösungsanbieters Datenrevision, dem Tegaron die Verantwortung für das Projekt übertrug: ÒStellen Sie sich vor, die Schulferien beginnen und von den bundesweit 3,5 Millionen Handy-Besitzern wollen sich auch nur 1,5 Prozent über die aktuelle Verkehrslage informieren. Dann muß das System innerhalb kürzester Zeit mehr als 5<k40>0000 Anfragen bewältigen.

Bereits kurz nach der Gründung der T-Mobil-und Debis-Tochter sollten die ersten Tegaron-Dienste ihren Betrieb aufnehmen, denn gerade in einem so jungen Marktsegement ist Schnelligkeit ein entscheidender Aspekt. Es galt folglich, schon parallel zum Entwurf des Fachkonzeptes generelle Designentscheidungen zu treffen und Architekturkonzepte zu erarbeiten. Dabei sollten sich die Vorstellungen, was mit der hier entwickelten Architektur und Technik im Detail zu leisten sein würde, teilweise erst im Laufe des Vorhabens ergeben.

Neben Time to market war eine der wichtigsten Anforderungen eine hohe Verfügbarkeit. Gefordert war eine Ausfallsicherheit von nahezu hundert Prozent " sieben Tage die Woche und 24 Stunden am Tag", erinnert sich Carl-Peter Schulthoff, der gemeinsam mit Hack die Geschäfte der Datenrevision führt.

Obschon die Hamburger dem System einen objektorientierten Entwurf zugrundelegten, entschieden sie sich dafür, im Hinblick auf die Transaktionsverarbeitung eine konventionelle, also funktionsorientierte Software zu verwenden. Ihrer Ansicht nach war nur ein leistungsfähiger Transaktionsmonitor in der Lage, die Anforderungen des Auftraggebers in puncto Skalierbarkeit zu erfüllen

Zuvor hatten die Entwickler diskutiert, ob für die Nachrichtenvermittlung zwischen den einzelnen Objekten eine Middleware auf der Grundlage der Common Object Request Broker Architecture (Corba) eingesetzt werden sollte. Laut Hack wäre es jedoch unvermeidbar gewesen, oberhalb dieser Corba-Implementierung zusätzlich einen Transaktionsmechanismus aufzubauen.

Zudem äußerte der Datenrevi-sion-Geschäftsführer die Ansicht, daß den verfügbaren Corba-Implementierungen bislang die Produktreife fehle. Deshalb beschlossen die Entwickler, als Softwarebus ein Werkzeug zu nutzen, das speziell für das Online Transaction Processing ausgelegt war, kurz: einen OLTP-Monitor. Um die Verbindung zwischen diesem funktionsorientierten Tool und den Software-Objekten des Gesamtsystems herzustellen, schrieben die Hamburger eigene C++-basierte Interface-Klassen.

Die Architektur des Systems besteht im Kern aus einem Verbund von Daten-, Kommunikations- und Applikationsserver, die untereinander via Messaging kommunizieren. Angebunden sind beispielsweise Schnittstellen für Short Message Service (SMS), mit deren Hilfe die Nachrichten vom Endgerät des Nutzers ins System eingespeist werden, aber auch die ausgelagerten Datenbanken für die Verwaltung und Überprüfung der Kunden sowie die Billing-Informationen. Die Arbeitsplätze der Verkehrsinformation greifen ebenfalls via Messaging auf den Kommunikationsserver zu. Ein Voice-Server dient der Assemblierung von Verkehrsdurchsagen. Er ist unter anderem über "Oracle Stored Procedures" angebunden.

Das Rennen um die Wahl des geeigneten OLTP-Monitors machte das Produkt "Tuxedo" von der kalifornischen BEA Systems Inc., mit dem die Nordlichter in der Vergangenheit bereits gute Erfahrungen gemacht hatten. Gemäß der Einschätzung der Datenrevision enthält Tuxedo einige Funktionen, die die parallele Verarbeitung von Prozessen erleichtern.

Eine Anwendung wie Tegaron Info laufe nämlich nur dann hinreichend schnell, wenn die Vorgänge "entserialisiert" würden. Das heißt: Die einzelnen Programmschritte (im Jargon der Objektentwickler: "Services") müssen quasi unabhängig voneinander arbeiten, so daß sie für den nächsten Aufruf zur Verfügung stehen, sobald sie den vorhergehenden erledigt haben. Dazu noch einmal Hack: "Würde der Kunde von dem Moment seines Anrufs bis zum Erhalten der Antworten eine Prozeßkette blockieren, so wäre das eine Katastrophe."

Zusätzliche Geschwindigkeit holten die Entwickler dadurch heraus, daß sie besonders häufig benötigte oder besonders arbeitsintensive Services mehrmals parallel ausführten und bei Bedarf sogar auf unterschiedliche Rechner verteilten. Das zahlt sich vor allem bei der aufwendigen dynamischen Routenplanung aus.

Erweiterungen mit überschaubarem Aufwand

Durch die hochgradig parallelisierte Verarbeitung schleicht sich allerdings auch schon mal die eine oder andere Fehlfunktion ein. Wie Hack erläutert, kommt es bisweilen vor, daß ein Dienst auf eine Anfrage mit unterschiedlichen Nachrichten an das Endgerät antwortet. Zudem bestehe die Gefahr, daß sich Nachrichten überholen und in der falschen Reihenfolge beim Endgerät einträfen. Um dieses Problem zu lösen, sei zusätzlicher Aufwand notwendig gewesen.

Schwierig war auch die Einbindung externer Komponenten - dazu zählen beispielsweise der Voice-Server und das Geografische Informationssystem (GIS) - in das transaktionsorientierte Konzept der Datenrevision. Die Hamburger mußten hier eine Schnittstellen-Bibliothek entwickeln und die Hersteller bitten, ihre Produkte an diese Interfaces anzupassen.

Obschon Tuxedo das Gerüst für die gesamte Applikation bildet, muß sich keineswegs jeder Entwickler mit dem OLTP-Monitor auskennen. Die Tuxedo-spezifischen Zugriffe sind, so erläutert Hack, in wenigen einfach zu nutzenden Dienstleistungsklassen gekapselt. Der objektorientierte Charakter der Applikation trage auch dazu bei, daß das Entwicklungsteam technischen Weiterentwicklungen relativ gelassen entgegensieht. ÒSollten Funktionsaufrufe geändert werden müssen, so ist hiervon nur ein Bruchteil der Klassen betroffen.

Der nächste Schritt

Ideen für Dienstleistungsangebote im D1-Umfeld hat Tegaron genug. Dazu gehört beispielsweise ein Notfallsystem, das zur Internationalen Auto-Ausstellung (IAA) erstmals vorgestellt wurde. Es stellt hohe Anforderung an die Technologieintegration: Im Falle eines Unfalls benachrichtigt eine spezielle GSM-Karte automatisch die Notrufzentrale und teilt ihr den mit Hilfe eines Global-Positioning-Systems ermittelten Standort mit. Gleichzeitig wird versucht, über ein Call-Center die Verbindung zum Fahrer aufzubauen, so daß der Operator die Situation überprüfen kann. Zudem ist es möglich, Konferenzschaltungen zwischen Polizei und Rettungsdiensten herzustellen, was eine bis zu 50 Prozent schnellere Unfallhilfe bedeuten kann.