GRUNDLAGEN

DELFI basiert auf einer CORBA (Common Objects Requests Broker Architecture)-
Implementierung, einer Schnittstellendefinition in der IDL (Interface Definition
Language) und besteht nur aus einem Modul (module DELFI-3).

Folgende Grafik bietet eine Übersicht über die DELFI-3-Interfaces und die
zugehörigen Methoden. Alle Interfaces wurden im module DELFI-3 definiert.

DELFI-3-Interfaces

Der Suchcontroller benutzt für die verteilte Verbindungssuche die Funktionen des
Interfaces „DistributedScheduleInfo“, welches in der DELFI-IDL definiert ist. Es
werden die API-Funktionen GetTransitions, GetPartialConnections und
GetPartialRoutes der passiven Systeme aufgerufen.

Ausgehend von der Suche über drei Systeme, gliedert sich der Ablauf einer
verteilten Verbindungssuche im Suchcontroller in fünf Teile. (Die Suche über zwei
Systeme funktioniert analog zu der Drei-System-Suche, während die Suche über
ein System trivial ist.)

Geschildert wird die Suche nach einem Abfahrtszeitpunkt. Der Kunde gibt einen
Start- und einen Zielort sowie eine Wunschabfahrtszeit ein. Bei einer Ankunftssuche
müssen die Schritte 2 bis 4 jeweils rückwärts durchgeführt werden.

Für den Ablauf wird davon ausgegangen, dass unter Nutzung der Funktion GetStop
in den Systemen die Start- und Zielorte ermittelt worden sind und dem
Suchcontroller die eindeutigen Schlüssel der Start- und Zielhaltestellen vorliegen,
mit denen die weiteren Anfragen eindeutig erfolgen können.

1. Im ersten Schritt müssen die Übergangspunkte im Start- und Zielsystem
   bestimmt werden: Die API-Funktion GetTransitions wird jeweils im Start- und
   im Zielsystem aufgerufen, um eine Menge von potentiellen Übergangspunkten
   zwischen Regional- und Fernverkehrssystem zu ermitteln. Die Antwort aus
   beiden Systemen (Start- und Zielsystem) ermöglicht nun die weitere Anfrage
   von Teilverbindungen aus diesen beiden Systemen (Startpunkt zu
   Übergangspunkten bzw. Übergangspunkte zu Zielpunkt).
   
   
2. Im zweiten Schtitt erfolgt die Bestimmung der frühestmöglichen Ankunft am
   Ziel: Mit Hilfe der API-Funktion GetPartialConnections werden
   aufeinanderfolgend Start-, Fernverkehrs- und Zielsystem aufgerufen. Dabei
   werden die frühesten Ankunftszeiten und die Zahl der Umstiege, die an den
   Übergangspunkten bei einem Aufruf ermittelt werden, an das nächste System
   weitergegeben. Der letzte Aufruf, also die Antwort des Zielsystems, liefert
   dann die frühestmögliche Ankunft am Ziel.
   
   
3. Im dritten Schritt erfolgt die Bestimmung der spätestmöglichen Abfahrt am
   Start: Ausgehend von der in Schritt 2 ermittelten frühestmöglichen Ankunft
   wird die API-Funktion GetPartialConnections aufeinanderfolgend in
   umgekehrter Reihenfolge für Ziel-, Fernverkehrs- und Startsystem
   aufgerufen. Die so per Ankunftssuche ermittelten spätesten Abfahrtszeiten
   und die Zahl der Umstiege an den Übergangspunkten, werden bei jedem
   Aufruf an das nächste System weitergegeben. Der letzte Aufruf, also die
   Antwort des Startsystems, liefert die spätestmögliche (und damit optimale)
   Abfahrt am Start. Als Optimierungsmaßnahme werden alle Übergangspunkte
   entfernt, deren spätestmögliche Abfahrt vor ihrer in Schritt 2 ermittelten
   frühestmöglichen Abfahrt liegen.
   
   
4. Im vierten Schritt kann dann die eigentliche Verbindung ermittelt werden: Die
   in Schritt 3 gewonnene optimale Abfahrtszeit sowie die spätestmöglichen
   Abfahrtszeiten und Zahl der Umstiege an den Übergangspunkten werden
   benutzt, um mittels GetPartialRoutes aufeinanderfolgend in Start-,
   Fernverkehrs- und Zielsystem Teilverbindungen abzufragen.
   
   
5. Im abschließenden fünften Schritt können nun die Teilverbindungen verkettet
   werden: Die Teilverbindungen aus den Antworten in Schritt 4 werden zu einer
   oder mehreren Gesamtverbindungen kombiniert.