Tegaron.de Dynamische Navigation

Sicherheit durch Tegaron

by admin file under Infos

Neben dem „Time to market“ wurde die hohe Verfügbarkeit eine der wichtigsten Anforderungen. Eine Ausfallsicherheit von fast 100 Prozent für sieben Tage die Woche und rund um die Uhr war die Forderung. Von den Hamburgern wurde ein System für einen objektorientierten Entwurf zugrunde gelegt. Es fiel die Entscheidung, dass im Hinblick auf die Verarbeitung der Transaktionen eine konventionelle, funktionsorientierte Software zu verwenden. Allerdings war nur ein leistungsfähiger Transaktionsmonitor fähig, die Anforderungen des Auftraggebers für eine Skalierbarkeit zu erfüllen. Von den Entwicklern wurde diskutiert, ob es für die Vermittlung von Nachrichten zwischen einzelnen Objekten eine Middleware auf Grundlage der Common Object Request Broker Architecture (Corba) zum Einsatz kommen sollte. Hack hielt es für unvermeidbar, dafür zusätzlich oberhalb dieser Corba-Implementierung einen Transaktionsmechanismus aufzubauen. Der Datenrevision Geschäftsführer war allerdings der Ansicht, es fehle den verfügbaren CORBA Implementierungen die Produktreife. Von den Entwicklern wurde daher die Nutzung eines Werkzeuges als Softwarebus beschlossen, um dies speziell für das Online Transaction Processing auszulegen: einen OLTP-Monitor. Die Hamburger schrieben eigene C++-basierte Interfaceklassen, um die Verbindung zwischen dem funktionsorientierten Tool und Softwareobjekten des Gesamtsystems herzustellen. Die Architektur des Systems bestand im Wesentlichen von einem Server für Daten, Kommunikation und Applikation, die zusammen untereinander via Messaging kommunizierten. Angebunden für den Short Message Service (SMS) waren zum Beispiel Schnittstellen, damit Nachrichten vom Endgerät des Nutzers in das System eingespeist werden konnten. Ebenso um Datenbanken für Verwaltung und Überprüfung der Kunden auszulagern. Arbeitsplätze der Verkehrsinformation konnten ebenfalls über Messaging auf den Kommunikationsserver zugreifen. Für Verkehrsdurchsagen diente ein Voice-Server für die Assemblierung und wurde über "Oracle Stored Procedures" angebunden. Auf das Produkt "Tuxedo" von der kalifornischen BEA Systems Inc. fiel die Wahl auf den geeigneten OLTP-Monitors. Die Nordlichter verzeichneten damit in der Vergangenheit gute Erfahrungen. Tuxedo enthielt einige Funktionen, die eine parallele Verarbeitung von Prozessen erleichtern sollte. Eine Anwendung wie Tegaron Info lief nur dann ausreichend schnell, wenn die Vorgänge der einzelnen Programmschritte unabhängig voneinander arbeiteten und für den nächsten Aufruf zur Verfügung standen, sobald der vorherige erledigt war. Vom Kunden musste daher verhindert werden, vom Anruf bis zum Erhalten der Antworten die Prozesskette zu blockieren. Zusätzliche Geschwindigkeiten wurden von den Entwicklern dadurch herausgeholt, indem häufig benötigte oder arbeitsintensive Services des Öfteren parallel ausgeführt wurden und bedarfsmäßig auf verschiedene Rechner verteilten. Bei der aufwendigen dynamischen Routenplanung hat sich das ausgezahlt.

Erweiterungen mit überschaubarem Aufwand

VerkehrssicherheitEs hatten sich durch die hochgradig parallelisierten Verarbeitungen einige Fehlfunktionen eingeschlichen. Es konnte vorkommen, dass ein Dienst eine Anfrage mit unterschiedlichen Nachrichten an das Endgerät beantwortet hat. Es gab die Gefahr der Nachrichtenüberholung und diese trafen in der falschen Reihenfolge beim Endgerät ein. Ein zusätzlicher Aufwand sollte das Problem lösen. Das Einbinden externer Komponenten, wie der Voice-Server und das geografische Informationssystem (GIS) in das transaktionsorientierte Konzept der Datenrevision, gestaltete sich als schwierig. Die Hamburger entwickelten eine Bibliothek für Schnittstellen und die Hersteller wurden um Anpassung ihrer Produkte an dieses Interfaces gebeten. Mit dem OLTP-Monitor musste sich nicht jeder Entwickler auskennen, da Tuxedo bereits das Gerüst für die gesamte Applikation bildete. Die spezifischen Zugriffe von Tuxedo wurden in wenigen Dienstleistungsklassen gekapselt und konnten auf einfache Art genutzt werden. Der objektorientierte Charakter der Applikation hatte dazu beigetragen, dass für technische Weiterentwicklungen das Entwicklungsteam gelassen blieb. Die Änderung der Funktionsaufrufe betraf nur einen Bruchteil der Klassen.

Was war der nächste Schritt?

Tegaron besaß reichliche Ideen für Dienstleistungsangebote im D1-Umfeld. Dazu gehörte ein Notfallsystem und dies wurde bei der internationalen Autoausstellung (IAA) damals zum ersten Mal vorgestellt. An die Technologieintegration wurden hohe Anforderungen gestellt. Bei einem Unfall sollte eine spezielle GSM-Karte automatisch die Notrufzentrale benachrichtigen und mithilfe eines Global-Positioning-Systems (GPS) den ermittelten Standort mitteilen. Ein Callcenter musste nun versuchen, eine Verbindung zum Fahrer herzustellen, damit vom Operator die Situation überprüft werden konnte. Zudem waren Konferenzschaltungen zwischen Polizei und Rettungsdiensten möglich, damit eine, bis zu 50 Prozent, schnellere Hilfe gewährleistet war.