KV78turbo potentiele downtime en update
Stefan de Konink
We gaan vandaag proberen om de huidige KV78turbo data stromen van onze
normale webserver af te halen en te termineren op ons nieuwe redundante
realtime distributie platform. Aangezien dat als b-bingo overkomt:
momenteel draaien alle openOV services op de machine die ook
bijvoorbeeld openkvk faciliteert. Realtime informatie moet snel
doorgestuurd worden, en daar is gewoon een dedicated platform voor nodig.
De VerkeersInformatieDienst is bereid gevonden om ons kwa infrastructuur
bij te staan. Dat levert buiten een 1.5ms snellere verbinding naar GOVI
ook een gigabit pijp op de AMS-IX op. Door deze bijdragen kunnen we
naast KV78turbo ook de overige realtime OV datastromen verwerken, en dit
doorleveren naar derden. Daar later meer over.
We verwachten enige KV78turbo downtime bij het overschakelen van server
naar nieuwe server, waar *alleen* de KV78demo API last van zal
ondervinden. Als de eerste data stroom is over gezet zullen we de 'demo'
API ook gaan inrichten op een vaste plek. KV55 zal worden afgeschakeld
van GOVI wanneer alle informatie via KV78turbo beschikbaar is, op dat
moment draaien we dus *zelf* KV55. Als je dus KV78turbo van ons zou
ontvangen, kun je theoretisch ook zelf een KV55 API draaien.
Afgelopen week is er ook gesproken met de NS over integratie van de
NS-API. We gaan een klein experimentje doen om dit te faciliteren binnen
de bestaande APIs, maar dat betekent ook dat je alle informatie die wij
nu pushen, ook integraal kunt ontvangen (voor zover je dat nog niet met
XMPP deed).
Hoe werkt dat alles technisch?
BISON standaarden werken op basis van HTTP POST berichten, KV78turbo
ook. Wij ontvangen de HTTP POST en zetten die om in een ZeroMQ PUSH
bericht met een enveloppe en een data gedeelte. Denk bij de enveloppe
aan: GOVI/KV8, GOVI/KV7planning, GOVI/KV7kalender
Deze berichten hoeven dus niet te worden ge�nterpreteerd, maar kunnen
direct worden gepushed naar een ZeroMQ PubSub. De PubSub doet niets
anders dan alle inkomende berichten doorsturen naar eenieder die daarmee
is verbonden. Stel dat je alle data wilt hebben, zit je daar goed.
Echter filters in ZeroMQ werken alleen client side, dat is niet altijd
even praktisch, we kiezen er dus voor een aantal bericht categorie�n te
bundelen zodat je geen dubbele informatie ontvangt.
Voor echt statische informatie verandert er eigenlijk niets. KV1 blijft
bereikbaar via <http://kv1.openov.nl/> en de afgeleiden als GTFS gewoon
via <http://gtfs.openov.nl/>
Stefan
Stefan de Konink
Iets later dan gepland, maar sinds vanmiddag live: ons nieuwe distributie
platform. Het eerste systeem ontvangt inmiddels data, en de data wordt ook
doorgestuurd naar het oude systeem waar nu nogsteeds KV78demo draait.
Wat betekent dit?
Wil je *nu* live en statische data ontvangen, de data die wij van GOVI
krijgen alles-in-een? Neem dan contact op met het secretariaat van
openov.nl je krijgt dan een op maat gemaakte licentie (voor de
tekst: <http://openov.nl/license/GOVI-1.0-TravelInfo>) je kunt deze
ondertekenen en opsturen (de scanner is sneller!).
Wij zetten dan direct de firewall open, en je kunt met een voorbeeld
ontvanger aan de slag. De webinterface die dit allemaal moet automatiseren
is nog niet publiek, maar we gaan natuurlijk niet flauw doen en jullie
daar op laten wachten.
Verwachtings management;
De data die je gaat ontvangen is heel wat meer data dan bijvoorbeeld
NS-API. Momenteel zitten Amsterdam & Omstreken, Zeeland en Noord-Brabant
in KV78turbo. Betekent dat je ieder moment van de dag, alle actuele
vertrektijden binnen krijgt. Het is dus een server2server dienst, geen
API.
Zelf bijdragen?
openOV gebruikt heel wat handjes en diensten van de community, overheden
en bedrijfsleven. Hosten van een redundante node voor ons netwerk,
ontwikkelen aan omzetting van de data, of gewoon valideren: "klopt het
wel?" Is heel erg gewenst en wordt erg gewaardeerd :)
Stefan