Als Router : eingehende Stadis-Anfragen für die GDSe nicht transparent (also quasi unsichtbar) auf mehr als ein Veranstalter-System weiterleiten will. Routing kann über Veranstaltercode plus Reiseart, oder sogar über Analyse der TOMA-Anfrage erfolgen.

Als Protokoll-Konverter : Eingehende und ausgehende Nachrichten ein voneinander abweichendes Transportprotokoll nutzen (z.B. XML, Stadis München ´auf/zu´, Stadis München ´stehender Socket´ oder STADIS ´SDS-Verfahren´)

Als Regler : Den STADIS-Datenverkehr vor dem eigentlichen Veranstalter-Rechner regeln möchte, um Überlastungen des Rechners im Vorfeld, oder auch unnormale Nutzung durch ein GDS zu verhindern.

Eingangsseitig :

Auf der Eingangsseite des Gateways verhält sich das System wie ein Veranstalter-System und steht als Kommunikations-Server bereit für den Empfang von Stadis-Nachrichten von GDSen (oder anderen Arten von Clients).

Das Stadis-Gateway kann Eingänge für mehrere GDSe gleichzeitig bereit stellen. Durch Analyse der STADIS-Nachricht wird ermittelt, welches Veranstalter-System anzusprechen ist.

Eingänge können auch fest an ein Veranstalter-System gekoppelt werden.

Das Stadis-Gateway kann auf Wunsch per STADIS-XML angesprochen werden und dient somit als Protokoll-Konverter, der gleichzeitig aber auch Zugänge zu mehr als einem Veranstalter-Rechner aufbauen kann.

Ausgangsseitig :

Auf der Ausgangsseite verhält sich das Gateway wie ein GDS und sendet Requests an Veranstalter-Systeme. Für das VS ist das STADIS-Gateway somit letztendlich unsichtbar („transparent“).

Für jeden Ausgang kann individuell geregelt werden, wieviel Requests pro Sekunde max. gesendet werden können, wie viele Requests parallel gesendet werden dürfen, und wie viele Requests gequeuet werden, bevor Requests wegen Überlastung abgelehnt werden.