Technologie

DELFI basiert auf einem verteilten System: Die Verbindungsauskunft wird nicht aus einem Datenpool berechnet, sondern auf Basis der Daten von bis zu drei Systemen ermittelt. Die DELFI-Schnittstelle nutzt dabei das Netzwerkprotokoll SOAP (Simple Object Access Protocol), das sich auf XML (Extensible Markup Language) stützt.

DELFI basiert auf einem verteilten System: Die Verbindungsauskunft wird nicht aus einem Datenpool berechnet, sondern auf Basis der Daten von bis zu drei Systemen ermittelt. Die DELFI-Schnittstelle nutzt dabei das Netzwerkprotokoll SOAP (Simple Object Access Protocol), das sich auf XML (Extensible Markup Language) stützt.

Funktionsweise des verteilten Systems

Dem Kunden, der eine Auskunftsanfrage an DELFI stellt, bleiben die Komplexität und die Funktionsweise des verteilten Systems verborgen. Für ihn entsteht der Eindruck, alle Daten wären deutschlandweit in einem einzigen System verfügbar.

Die Arbeitsweise des Systems verdeutlicht untenstehende Grafik.

Arbeitsweise des verteilten Systems

Komponenten:
AS (Aktiver Server)/PS (Passiver Server) – Aktiver/Passiver Server
LRes (Location Resolver/ Ortsfinder) – Location Resolver/ Ortsfinder
FplA (Fahrplanauskunft (passiver Server)) – Fahrplanauskunft (passiver Server)
SC (Searchcontroller/Suchkontroller) – Search Controller/ Suchkontroller
ZMP (zentrale Metadatenplattform) – zentrale Metadatenplattform

Proprietäre Schnittstelle:
IR (Itinerary Request/Response (Reiseroute Anfrage/Antwort)) – Itinerary Request/Response (Reiseroute Anfrage/Antwort)

Datenflüsse der DELFI-Schnittstelle (zwischen LRes (Location Resolver/ Ortsfinder) und den regionalen PS (Passiver Server) bzw. zwischen SC (Searchcontroller/Suchkontroller) und den regionalen PS (Passiver Server) und dem PS (Passiver Server) der DB (Deutsche Bahn)):
CR (ConnectionRequest/Response (Verbindungsanfrage/-antwort)) – ConnectionRequest/Response
LR (LocationRequest/Response (Ortsanfrage/-antwort)) – LocationRequest/Response
MD (Metadata (Metadaten)) – Metadata (Metadaten)
PCR (PartialConnectionsRequest/Response (Teilverbindungsanfrage/-antwort)) – PartialConnectionsRequest/Response
TR (TransitionsRequest/Response (Übergangsanfrage/-antwort)) – TransitionsRequest/Response

Beiteiligte Personen:
LDS – Landesdatenadministrator
Kunde – anfragender DELFI-Nutzer

Ein Kunde stellt über sein Frontend eine Fahrplanauskunft an einen lokalen Server, den aktiven Server (AS (Aktiver Server)). Unter Zuhilfenahme eines Ortsfinders (LRes (Location Resolver/ Ortsfinder)), werden auf Basis der vom Kunden gestellten Verbindungsanfrage, die anzufragenden Auskunftsrechner in der Start und Zielregion ermittelt. Ein sogenannter Suchkontroller (SC (Searchcontroller/Suchkontroller)) ermittelt die Übergänge zwischen diesen Systemen, die Teilverbindungen und errechnet daraus die Verbindungsauskunft. Er greift hierbei mittels Schnittstellen (API (application programming interface (Programmierschnittstelle))) auf die Fahrplandaten (FplA (Fahrplanauskunft (passiver Server))) auf den passiven Servern (PS (Passiver Server)) zu. Der Prozess der Berechnung der Verbindungsauskunft wird durch Infrastrukturdaten unterstützt, die in der zentralen Metadatenplattform (ZMP (zentrale Metadatenplattform)) vorgehalten und durch die Landesdatenadministratoren (LDA (Landesdatenadministrator)) gepflegt werden.

Die Verbindungsanfrage erfolgt technisch gesehen in fünf Schritten:

  1. Ermittlung der zwischen den Auskunftssystemen vereinbarten Übergänge
  2. Ermittlung der frühest möglichen Ankunft an den Übergängen und am Zielort
  3. Ermittlung der spätest möglichen Abfahrt am Startort und an den Übergängen
  4. Ermittlung von Teilverbindungen in den Auskunftssystemen anhand des Zeitfensters, das durch die früheste Ankunft und die späteste Abfahrt festgelegt ist
  5. Verkettung der Teilverbindungen zu einer Gesamtverbindung

Ein wesentlicher Vorteil des verteilten Systems ist, dass die Teilnehmer nur jeweils ihre eigenen Daten zur Verfügung stellen- und pflegen müssen, aber dennoch deutschlandweite Auskünfte geben können. Das System ist außerdem durch seine Erweiterbarkeit flexibel und zukunftsfähig (siehe hierzu auch den Abschnitt über Zukunftsvisionen).

Ein verteiltes System bedeutet aber auch, dass die Ergebnisse der Fahrplanverbindung nur so gut sein können, wie die Qualität jedes einzelnen -beteiligten Systemes. So sind beispielsweise hinsichtlich der Verfügbarkeit alle Partner dazu angehalten, ihre Systemausfallzeiten so gering wie möglich zu halten, beziehungsweise Vorkehrungen und Maßnahmen zu treffen, um diese Ausfälle in geeigneter Form abzufangen. Auch die zeitliche Performance und die inhaltliche Qualität der Verbindungsauskunft sind an eine gut funktionierende Zusammenarbeit der Partner sowie an hochwertige, aktuelle Hard- und Softwareprodukte gebunden.