| Technical Efforts to Provide the EU-Spirit Service In general, every operator — regardless of the algorithms he uses – can participate in this open service system. Any updates of the time schedules in the local systems are automatically available for the EU-Spirit system which reduces the maintenance costs and improves the accuracy of the system and the information it provides. |
||||
| Passive Server Each provider of the EU-Spirit travel planning rings needs to provide a passive server. The passive server is a travel planning system which is able to take a SOAP/XML request as defined by the EU-Spirit API, compute the appropriate result and deliver it back to the calling programme. The EU-Spirit API consists of five functions for different purposes. They are briefly described in the following, a detailed description can be found in the EU-Spirit project documentation.
|
||||
| Active Server The active server provides access to the EU-Spirit travel planning system. It is usually a web based application which converts the user input into an appropriate EU-Spirit API request. Those are sent to the RODI or RCC respectively. The active server must be able to initiate Locations calls to the RODI and Connections calls to the RCC; the active server does not communicate directly with the passive servers. Nevertheless, it is possible to have an intelligent active server which passes only the non local requests to the EU-Spirit ring. |
||||
|
||||
| The data of each passive server represents a transport network. In order to connect this network correctly with the rest of the ring, meta data has to be generated. The most important type of meta data (and the only one discussed here) are the transition points. The purpose of transition points is to connect two transport networks. Therefore, a transition point resides always in at least two systems. In order to avoid inconsistencies, all transition points must have a unique ID. | ||||
| Imprint | ||||