23/6/2008
IN OPDRACHT VAN TENUKI BV
EUROTRAFFIC ALARMERING EN RAPPORTAGE SYSTEEM
Bachelor Project Verslag | Amir Delfan, Auke Louiset en Quintin Doest
Voorwoord Met het Bachelorproject wordt de Bachelorstudie informatica van TU Delft afgesloten. Hierbij is er voor de studenten de gelegenheid om een stage te lopen bij een externe instantie. De studenten doorlopen dan een geheel software ontwikkelproject waarbij verschillende technieken opgedaan tijdens de studie worden toegepast. Verder wordt hierbij kennis gemaakt met het werken in een bedrijf. Voor dit project staat 420 uur (15 ECTS) ingeroosterd, hiervoor is het laatste kwartaal gereserveerd. Dit project is vooraf gestart met een vooronderzoek tijdens het derde kwartaal van het studie jaar (2007-2008). Tijdens het laatste kwartaal van dezelfde studiejaar is het project daadwerkelijk van start gegaan bij Tenuki BV gevestigd te Delfgauw. Tenuki maakt innovatieve, kwaliteitssoftware voor de verkeersinformatiemarkt. Het zijn bijvoorbeeld de productiesystemen die 24 uur per dag real-time de file-informatie doorgeven aan de weggebruikers via de TomTom, maar ook slimme webapplicaties die onafhankelijk van de locatie een weginspecteur ondersteunen om wegwerkzaamheden beter op elkaar af te stemmen. Het doel van het project is een automatische Alarmering systeem te ontwikkelen voor het EuroTraffic(ET) systeem van Tenuki. Daarnaast is er behoefte aan het kunnen genereren van beschikbaarheidrapportages voor het ET systeem. ET is een dochteronderneming van Visio BV en Tenuki BV die allebei gespecialiseerd zijn op het gebied van verkeersinformatie. Beide bedrijven verlenen operationele ondersteuning aan nationale Traffic Information Centers (TIC's) en zijn een van de grondleggers van de Traffic Information Transport Protocol. De reden voor kiezen van Tenuki als stageplek verschilt weliswaar per groepslid, maar waar we wel gezamenlijk voor gingen was een innovatieve, professionele Software ontwikkelaar en tegelijkertijd maatschappelijk betrokken onderneming. Dit hebben we gevonden bij Tenuki! Onze begeleiders aan de TU Delft zijn Dr. P.G. Kluit en Ir. B.R.Sodoyer (coördinator). Deze heren willen we hartelijke bedanken voor de assistentie en hulp tijdens de gehele project. Ook willen we de heer Ir.D.Koh (directeur Tenuki B.V.), mevrouw M.Koh en de rest van de Tenuki bedanken voor hun begeleiding en samenwerking in het bedrijf.
Delft juni 2008
Inhoudsopgave Voorwoord ..................................................................................................................................... 2 Inhoudsopgave............................................................................................................................. 3 Samenvatting ................................................................................................................................ 5 1 Inleiding ....................................................................................................................................... 7 2 Opdrachtbeschrijving............................................................................................................... 8 2.1 ET Systeem............................................................................................................................ 8 2.3 De opdracht........................................................................................................................ 9 2.3.1 Alarmering..................................................................................................................... 9 2.3.2 Beschikbaarheid rapportage ................................................................................... 9 3 Systeem beschrijving............................................................................................................... 10 3.1 Technische proces ........................................................................................................... 10 3.2 De huidige omgeving...................................................................................................... 11 3.3 Inventarisatie stromen ..................................................................................................... 11 4 Werkwijze en aanpak ............................................................................................................. 12 4.1 Werkwijze............................................................................................................................ 12 4.2 Aanpak............................................................................................................................... 13 4.2.1 Technieken uit Tenuki aanpak................................................................................ 13 4.2.2 Technieken uit XP aanpak....................................................................................... 13 4.2.3 Versiebeheer .............................................................................................................. 14 5 Opdracht analyse ................................................................................................................... 15 6 Architectuur keuzes................................................................................................................. 17 6.1 Architectuur eisen ............................................................................................................ 17 6.2 Verdeling van de functie over modules...................................................................... 18 6.3 Keuze tussen twee Architectuur modellen ................................................................. 18 6.3.1 Model 1........................................................................................................................ 18 6.3.2 Model 2........................................................................................................................ 19 6.4 Architectuur keuze ........................................................................................................... 21
7 Ontwerp .................................................................................................................................... 22 7.1 Monitormodules................................................................................................................ 22 7.1.1 Content monitor ........................................................................................................ 22 7.1.2 Source Monitor........................................................................................................... 24 7.1.3 Destination Monitor ................................................................................................... 25 7.2 Services............................................................................................................................... 25 7.2.1 Alarm-Controller: ....................................................................................................... 26 7.2.2 Email Alarm module:................................................................................................. 27 7.2.3 Uptime Registration:.................................................................................................. 27 7.2.4 Uptime Data Service:................................................................................................ 28 8 Graphical user interface........................................................................................................ 29 Eisen en wensen...................................................................................................................... 29 8.1 AlarmController GUI ......................................................................................................... 29 8.2 Beschikbaarheids rapportage GUI ............................................................................... 32 8.3 Beschikbaarheids Rapportage...................................................................................... 33 9 Project verloop......................................................................................................................... 34 9.1 Fase: Ontwerp en architectuur: .................................................................................... 34 9.2 Iteraties ............................................................................................................................... 34 9.2.1 Eerste Iteratie (Framework)...................................................................................... 35 9.2.2Tweede iteratie ........................................................................................................... 35 9.2.3 Derde iteratie ............................................................................................................. 36 9.3 Opleveren en overdracht .............................................................................................. 37 9.4 Documentatie en verslag............................................................................................... 37 10 Aanbevelingen...................................................................................................................... 38 11 Evaluatie.................................................................................................................................. 39 Appendix A - Vooronderzoek ...................................................................................................... Appendix B - Plan van Aanpak ................................................................................................... Appendix C - Tools ......................................................................................................................... Delphi......................................................................................................................................... Tenuki Service Bus ...................................................................................................................
Samenvatting Het EuroTraffic (ET) Systeem zet ruwe verkeersinformatie afkomstig uit vrijwel alle Europese landen om, tot klantspecifieke, uniforme informatiestromen. Het technische proces van het ET systeem bestaat uit 3 stappen: 1. De verkeersinformatie van een land ophalen. 2. De verkeersinformatie converteren. 3. De geconverteerde verkeersinformatie aanleveren aan een klant. Helaas loopt niet alles altijd zoals verwacht en kan het ET systeem van Tenuki door verschillende redenen uit komen te liggen. Tijdens dit project is er een Alarmering en Rapportage applicatie ontwikkeld die de verschillende filestromen van het ET systeem controleert. In het geval dat een file stroom niet beschikbaar is worden de beheerder van het ET systeem gealarmeerd. Dit gebeurd door een bericht te sturen via het email en/of door een pop-up met geluid van de AlarmController GUI. Door te alarmeren worden problemen eerder opgemerkt en kunnen deze sneller hersteld worden waardoor de beschikbaarheid wordt verhoogd en klanten een beter service ontvangen en afspraken over deze service beter worden nagekomen. De opdracht van dit project splitst zich in twee deelopdrachten: alarmering in het geval dat een of meerdere file informatie stromen niet beschikbaar zijn en genereren van een beschikbaarheidrapportage voor het inzien van de beschikbaarheid van de stromen. Typisch aan de werkwijze binnen dit project is dat er met een mix van beide Extreme Programming en Tenuki werkwijze is gewerkt. Van de Tenuki aanpak benadrukt het definiëren van de “wat” en “hoe” fases. Tijdens de “wat” fase is de bedoeling van de opdracht duidelijk gemaakt. Er zijn schetsen, tabellen en stukjes tekst gemaakt om de opdracht te concretiseren. Bij het “hoe ” gedeelte is er telkens een plan van aanpak gemaakt, waarin staat hoe het probleem aangepakt moet worden en argumenten die deze aanpak moeten onderbouwen. Van de XP aanpak zijn onder andere het maken van een zo simpel mogelijk ontwerp, werken in iteraties, gebruik van TestCases, Continu integratie en Pair Programming toegepast. Ook is er gebruik gemaakt van SVN voor efficiënt versiebeheer. Voor dit project is er gekozen voor bus model als architectuurmodel. Bij het bepalen van het architectuur model is er gelet op de criteria als Uitbreidbaarheid, Onderhoudbaarheid, Platform onafhankelijk en Flexibiliteit. Eerst is aangegeven waarom deze belangrijk zijn geweest voor de architectuur keuze. Vervolgens zijn twee verschillende architectuurmodellen uitgelegd en de afweging onderbouwd.
5
Na het specificeren van de functionaliteiten, zijn deze functionaliteiten vervolgens verdeelt over verschillende modules. Hierbij valt onderscheid te maken tussen monitormodules en service modules. Elke monitormodule controleert een specifiek deel van de gegevensstroom van het ET systeem en zet het resultaat van deze controle op de bus. Deze stroom is in drie delen gedeeld, de Source, Content en Destination. De service modules vangen deze berichten op en bepalen aan de hand deze berichten wat de beschikbaarheid van een stroom is. Afhankelijk van welke functie een service module implementeert stuurt deze een alarm of slaat het resultaat op in de database. Daarnaast is er nog een service module die de beschikbaarheid voor een gegeven stroom voor een bepaalde maand berekent. Verder zijn er twee GUI’s: één om alarmen mee te kunnen ontvangen en één om rapportages te kunnen opvragen. Deze zijn in overleg met de klant afgestemd op zijn wensen en eisen. Het Alarmering en Rapportage systeem is op dit moment al operationeel en heeft meerdere malen de beheerders van het ET systeem gealarmeerd. Ook is het ET Alarmering en Rapportage systeem op dit moment in staat om voor de verschillende landen beschikbaarheids rapportages te generen.
6
1 Inleiding Het fileprobleem wordt vaak door velen als een onoplosbaar probleem gezien. In een artikel van de Algemeen Dagblad op 13 mei 2008 vermeldt Pieter Hofstra(VVD) dat “bijna elke minister zijn best heeft gedaan om de files aan te pakken, maar dat het niemand is gelukt.’’ Aangezien het fileprobleem dus niet zal verdwijnen is het belangrijk dat we zo goed mogelijk met dit probleem kunnen leven. Een belangrijk onderdeel hiervan is goed geïnformeerd zijn. Het EuroTraffic Systeem zet ruwe verkeersinformatie afkomstig uit vrijwel alle Europese landen om tot, klantspecifieke, informatiestromen. Deze informatie wordt door TomTom, Wayfinder en Algemeen Dagblad aan de weggebruikers verschaft, waardoor ze zoveel mogelijk files kunnen vermijden. Helaas loopt niet alles altijd zoals verwacht en kan het ET systeem door verschillende redenen er uit komen te liggen. Om dit zo min mogelijk te laten gebeuren worden er iedere (werk)dag handmatige controles uitgevoerd om het ET systeem in de gaten te houden. Omdat de handmatige controles slechts twee keer per dag worden uitgevoerd, kunnen er stromen tussen deze controles door er uit komen te liggen. Tijdens dit project hebben de studenten van de Technische Universiteit Delft, zich gericht op het ontwikkelen van een softwarematige oplossing voor dit probleem. Namelijk automatisch alarmeren in het geval dat er één of meerdere file stromen uit komen te liggen. Daarnaast is het doel van dit project geweest om beschikbaarheid rapportages te generen voor het ET systeem. In dit verslag zullen de verschillende aspecten van dit project beschreven worden. In hoofdstuk 2 zullen we dieper ingaan op de inhoud van de opdracht. In hoofdstuk 3 zal vervolgens de systeembeschrijving van het ET systeem uitgebreid worden besproken. In hoofdstuk 4 komen de werkwijze en aanpak die tijdens het project zijn toegepast aan de orde. Daarna zal in hoofdstuk 5 de benodigde functionaliteiten benoemen worden die nodig zijn voor het ET Alarmering en Rapportage systeem. In hoofdstuk 6 komt de architectuur keuze aan de orde en in hoofdstuk 7 bespreken we de belangrijkste onderdelen van het systeem. Hoofdstuk 8 worden de graphical user interfaces(GUI) en de beschikbaarheid rapportage besproken. In hoofdstuk 9 presenteren we onze aanbevelingen voor verdere ontwikkeling van het ET Alarmering en Rapportage systeem en tenslotte is in hoofdstuk 10 de evaluatie van het bachelorproject gegeven. Wij wensen u veel leesplezier bij het lezen van dit verslag!
7
2 Opdrachtbeschrijving In dit hoofdstuk geven we naast de opdracht een analyse van welk probleem deze opdracht moet oplossen. Eerst zal in het kort het ET systeem behandeld worden, vervolgens aangeven waar de problemen zitten en tot slot hoe de opdracht deze problemen zal aanpakken. De opdracht is om een softwarematig oplossing te ontwerpen en te bouwen waarmee de status van de gegevensstromen van het ET systeem eenvoudig kunnen worden ingezien. Mocht er een storing optreden dan moet dit via berichtgeving aan de beheerder van het ET systeem worden gemeld. Verder moet de beschikbaarheid van de gegevensstromen worden bijgehouden en gevisualiseerd. In het kort: -
Er moet een tool komen die storingen detecteert en alarmeert. De beschikbaarheid van de stromen moeten worden gevisualiseerd(tekstueel en/of grafisch).
2.1 ET Systeem Het ET systeem wordt gebruikt om file informatie van verschillende Europese landen te converteren naar een gewenste vorm, bestemd voor de klanten van EuroTraffic. De huidige klanten van EuroTraffic zijn: TomTom, Wayfinder en Algemeen Dagblad(AD). De verkeersinformatie komt uit Nederland, België, Frankrijk, Engeland, Duitsland, Spanje, Italië, Oostenrijk, Zwitserland, Zweden en Finland. De combinatie van een klant en een land wordt in de rest van dit document gedefinieerd als een stroom.
Figuur werking van ET systeem
De verkeersinformatie wordt na het ophalen naar een standaard formaat geconverteerd. Dit is een formaat welke is afgesproken met de klant. Per klant varieert hoe de gegevens worden geleverd. Bijvoorbeeld momenteel worden de gegevens voor TomTom naar een XML standaard geconverteerd en word deze via ftp opgehaald. Voor het Algemeen Dagblad wordt de informatie door middel van een kaartje grafisch weergegeven en gepusht.
8
2.2 Problemen huidige systeem
Het bestaande ET systeem kan door verschillende redenen er uit komen te liggen waardoor er op dat moment niet of geen juiste file informatie aan de klant geleverd kan worden. Dit is zeer onwenselijk omdat er vaste afspraken met klant zijn gemaakt over de beschikbaarheid van het ET systeem. Als deze afspraken niet nageleefd kunnen worden heeft dit financieel gevolgen voor Tenuki. Om het systeem er zo min mogelijk uit te laten liggen worden er iedere (werk)dag handmatige controles uitgevoerd om het ET systeem in de gaten te houden.
2.3 De opdracht De opdracht splitst zich in twee deelopdrachten: alarmering in het geval dat een of meerdere file informatie stromen niet beschikbaar zijn en genereren van een beschikbaarheidrapportage voor het inzien van de beschikbaarheid van de stromen. 2.3.1 Alarmering Er is een alarmering applicatie gewenst die automatisch de staat van de verschillende stromen bijhoudt. Indien er gemerkt wordt dat de gewenste service niet geleverd is, wordt de beheerder van het systeem gealarmeerd. Dit kan bijvoorbeeld met behulp van een bericht via de mail of via een sms. Met een geautomatiseerde melding van een storing kan de beheerder meteen handelen om het probleem op te lossen. Hierdoor kan de “downtijd” van de beschikbaarheid worden verlaagd. 2.3.2 Beschikbaarheid rapportage Voor het inzien van de beschikbaarheid van de stromen is er beschikbaarheid rapportage gewenst. Met een visueel overzicht van de beschikbaarheid kan aangetoond worden wat de beschikbaarheid van het ET systeem was aan de klanten om aan te tonen dat de afspraken zijn nagekomen.
9
3 Systeem beschrijving In dit hoofdstuk wordt de technische werking en de huidige omgeving van het ET systeem in details besproken. Aan het einde van het hoofdstuk bevindt zich een overzicht van de huidige stromen.
3.1 Technische proces Het technische proces van het ET systeem bestaat uit 3 stappen: 1. De verkeersinformatie van een land ophalen. 2. De verkeersinformatie converteren. 3. De geconverteerde verkeersinformatie aanleveren naar een klant. De bovenstaande stappen worden uitgevoerd in verschillende deelprogramma’s. De reden hiervoor is dat een uitvoering van zo stap per stroom kan variëren. Een deelprogramma bestaat uit de volgende 3 functionaliteiten: 1. De ophaalfunctionaliteit van het land waar de verkeersinformatie vandaan komt. 2. De conversiefunctionaliteit om de verkeersinformatie naar het afgesproken formaat te converteren. 3. De aanlevering functionaliteit om de geconverteerde verkeersinformatie aan te leveren naar de afgesproken bestemming. Een deelprogramma is dus een combinatie van een land en een klant die de 3 stappen uitvoert.
Figuur: werking van het ET systeem
De diverse protocollen waarmee het ET systeem zijn gegevens ophaalt zijn bepaald door de landen die deze informatie leveren. Per land verschilt het systeem en de standaard waarmee vervolgens de verkeersdata wordt doorgegeven. Voorbeelden van netwerk protocollen waarmee de data wordt opgehaald zijn HTTP, FTP of een zelf gedefinieerd protocol die gebruik maakt van TCP/IP. De verkeersinformatie wordt na het ophalen naar een standaard formaat geconverteerd welke is afgesproken met de klant. Dit kan bijvoorbeeld zijn in een XML bestand. Het aanleveren van de geconverteerde verkeersinformatie wordt ook op verschillende manieren uitgevoerd. Bijvoorbeeld momenteel wordt de verkeersinformatie voor TomTom lokaal op de ET server geplaatst waarna TomTom de bestanden via FTP kan ophalen. Bij de stroom van het AD wordt de verkeersinformatie op de server van het AD gepushed.
10
3.2 De huidige omgeving In dit hoofdstuk wordt de omgeving van de server waar de ET systeem bevindt besproken. De ET server bevindt zich op een remote server. Dit is een HP server met Debian als besturingssysteem. Hierop staat een virtuele Window 2000 Server die via VMWare is geïnstalleerd. De ophaal en conversie programma’s zijn Delphi programma’s die uitvoerbaar zijn als een Windows service. Alleen het Finse programma is een Linux daemon die rechtstreeks draait op de Debian server. Service TomTomNL Service TomTomSP Service TomTomCH ET Windows services
Figuur 3.2.1 ET server
Doordat het ET systeem op twee platformen draait en dat de verschillende ET deelprogramma’s verdeeld zij over deze twee platformen vereist de omgeving van het ET systeem veel CPU snelheid en interne geheugen.
3.3 Inventarisatie stromen Zoals eerder is vermeld kan het technische proces van het ET systeem per stroom variëren. Om een inzicht te krijgen in de verschillen per stroom zijn er 2 tabellen aangemaakt. In tabel 3.3.1 staan de communicatieprotocollen per land die worden toegepast om de verkeersinformatie op te halen. In de tabel 3.3.2 staat per stroom naar welke formaat de verkeersinformatie wordt geconverteerd en hoe de geconverteerde verkeersinformatie word aangeleverd. Land
Communicatieprotocol
Klant
Land
Converteren naar formaat
Aanlevering
Nederland
Eigen standaard op basis van de TCP/IP protocol
TomTom
Nederland
XML
Opgehaald via FTP
Zwitserland
XML
Opgehaald via FTP
Spanje
XML
Opgehaald via FTP
België
HTTP
Spanje
HTTP
Italië
FTP
Oostenrijk
FTP
Zwitserland
FTP
Zweden
FTP
Finland
FTP
Nederland
Wayfinder
Italië
XML
Opgehaald via FTP
Nederland
XML
Opgehaald via FTP
Algemeen Dagblad
GIF
Gepusht naar de server van AD
Nederland
XML
Opgehaald via FTP
België
XML
Opgehaald via FTP
Tabel 3.3.2 De technische eigenschappen voor het conversieprogramma per klant en land
Tabel 3.3.1 Het communicatieprotocol per land voor een ophaalprogramma
11
4 Werkwijze en aanpak In dit hoofdstuk wordt de werkwijze en aanpak die gedurende het project is toegepast besproken. Er zal eerst een overzicht van de werkwijze worden weergegeven die in dit project is gehanteerd. Vervolgens worden de technieken die gebruikt zijn om de onderdelen van de werkwijze uit te voeren behandeld.
4.1 Werkwijze Typisch aan de werkwijze binnen dit project is dat er een mix van beide Extreme Programming en Tenuki werkwijze (voor meer informatie zie het vooronderzoek) genomen is. Het gebruik van Extreme Programming laat het gebruik van werken in iteraties toe, waarbij als eerst begonnen wordt aan de belangrijkste functies.
Bij het uitvoeren van de iteraties zijn deze functies dieper uitgewerkt. De “wat” en “hoe” definitie van de Tenuki werkwijze benadrukt de scheiding tussen wat de opdracht is en hoe je deze opdracht wil aanpakken. Bevestiging van de opdrachtgever is hierbij onmisbaar om het beheren van een project soepel te laten verlopen. Dit helpt om aan het begin van de iteratie de resultaten die uit de iteraties uitkomen precies te definiëren.
De “hoe” fase komt dan bij het uitvoeren van iteratie aan de orde. Hieronder ziet u een overzicht van de stappen van de werkwijze gehanteerd tijdens dit project: 1. 2. 3. 4. 5.
Analyseren van de opdracht om een helder beeld te krijgen van het probleem. Welke functionaliteiten zijn er nodig om dit probleem op te lossen Welke modules worden hiervoor gebouwd. Hoe hangen alle modules samen, welke architectuur is hiervoor gekozen Iteratieslag bestaat uit: a. Probleemanalyse voor de functionaliteit b. Het schrijven van Test Cases c. Implementatie functionaliteit d. Het product in een test omgeving laten draaien
6. Het product in een live omgeving laten draaien
12
4.2 Aanpak In deze paragraaf worden de technieken die gebruikt zijn om de onderdelen van de werkwijze uit te voeren uitgelegd. Er moet worden opgemerkt dat sommige onderdelen van de aanpak binnen het bedrijf veel overlap hebben gehad met de XP aanpak. Bijvoorbeeld het kijken vanuit het oogpunt van de klant en de klant gedurende het hele ontwikkelingsproces bij de ontwikkeling van het product betrekken. 4.2.1 Technieken uit Tenuki aanpak
Van de Tenuki aanpak zijn het definiëren van de “Wat” en “Hoe” door dit project gehandhaafd. Tijdens de “Wat” fase is de bedoeling van de opdracht duidelijk gemaakt. Er zijn schetsen, tabellen en stukjes tekst gemaakt om de opdracht te concretiseren. Bij het “Hoe” gedeelte is er telkens een plan van aanpak gemaakt, waarin staat hoe het probleem aangepakt moet worden en argumenten die deze aanpak moeten onderbouwen. Beide “Wat” en “Hoe” zijn telkens naar de opdrachtgever teruggekoppeld en bevestigd. Dit was vooral belangrijk voor het verwachtingsmanagement wat binnen Tenuki erg belangrijk is. 4.2.2 Technieken uit XP aanpak
Hieronder benoemen we de belangrijkste onderdelen van de XP aanpak die tijdens dit project gebruikt zijn: Simpel ontwerp
Door alle belangrijke functies op een rijtje te zetten en deze functies vervolgens te verdelen over verschillende modules, is meteen de taak van iedere van deze modules heel erg duidelijk. Door vervolgens deze modules allemaal op dezelfde wijze met elkaar te laten communiceren is er geprobeerd om onnodige complexiteit zoveel mogelijk te vermijden. Iteraties
De implementatie van de verschillende functies zijn in drie verschillende iteraties gedeeld. Tijdens de eerste iteratie zijn de belangrijkste onderdelen die het framework vormde geïmplementeerd. In de volgende iteraties is hier op voort gebouwd en zijn de bestaande functies uitgebreid en extra functie in nieuwe modules geïmplementeerd. Aan het begin van iedere iteratie stap is er telkens een analyse gemaakt van de functies die uit de desbetreffende iteratie moeten resulteren. Deze functies zijn geconcretiseerd door de resultaten van deze functie op papier te zetten, bijvoorbeeld door deze te visualiseren. De opdrachtgever heeft telkens bevestigd dat het resultaat van de analyse inderdaad functies waren die aan het eind van de iteratie af moesten zijn voordat er begonnen is met implementeren ervan. Hiermee werd ook meteen een stuk verwachtingmanagement ingevuld. Test Cases
Voor elke module hebben we eerst testcases geschreven. Deze testcases hebben we afgeleid uit de analyse die we telkens aan het begin van elke iteratie hebben gemaakt. Om dit goed te kunnen moeten de methode van de modules duidelijke één functie hebben wat de onderhoudbaarheid van de modules ten goeden komt. Verder zorgt deze aanpak er ook voor dat je duidelijk weet wanneer je klaar bent met implementeren, namelijk als alle testcases werken. Op het moment dat een bestaande functie uitgebreid wordt met een nieuwe functie is de bestaande set met testcases uitgebreid. Als er een fout is het stuk code werd gevonden is 13
ook hiervoor een extra testcase geschreven en vervolgens opgelost. Door deze aanpak kan er efficiënt goede en onderhoudbare code geschreven worden. Continu Integratie
Doordat de functionaliteiten van de applicatie over verschillende modules zijn verdeeld en dus onafhankelijk van elkaar opereren, is het vrij simpel om de nieuwe module met de rest te integreren. Pair Programming
Het toepassen van Pair Programming is vooral aan het begin zinvol, waarbij men nog niet helemaal met de ontwikkel omgeving bekend is. Ook bij complexere delen van de code is het efficiënter om met tweetallen naar een stukje code te kijken. 4.2.3 Versiebeheer
Om op een makkelijke wijze, met meerdere mensen tegelijk aan de code te kunnen werken en continue integratie van de code mogelijk te maken, hebben we gebruik gemaakt van versiebeheer. Hierbij is gekozen voor SVN omdat wij daar vanuit de TU al bekend mee waren. Als client applicatie hebben we gebruik gemaakt van TortoiseSVN Client en was er een SVN server geïnstalleerd op een van de centrale computers van Tenuki.
14
5 Opdracht analyse In dit hoofdstuk zullen we de benodigde functionaliteiten benoemen die nodig zijn voor het ET Alarmering en Monitor Systeem. De opdracht splitst zich in twee hoofd functies: 1. Alarmering van het ET systeem. 2. Creëren van een beschikbaarheids rapportage. Om te kunnen alarmeren is monitoren van het systeem een belangrijke stap. De meest logische plek om te monitoren is helemaal aan het eind van de gegevensstroom bij de klant. Aangezien het niet mogelijk is om bij de klant de ontvangen gegevens te controleren moet er eerder in de stroom een controle plaats vinden. De output van het systeem bestaat uit een XML-bestand per stroom die vervolgens wordt geüpload. Het controleren van dit bestand op correctheid is een eerste controle van de gegevensstroom. Voor het gemak noemen we dit voortaan Content Monitoring. Naast dat het XML-bestand goed gegenereerd moet worden moet deze ook opgehaald worden door de klant. Als hier iets fout mee gaat kan dit bijvoorbeeld op duiden dat er iets mis is met de verbinding. Met andere woorden: De klant kan dan niet gebruik maken van de aangeboden dienst. Controle die op deze plek plaats vindt noemen we voor het gemak Destination Monitor. Een laatste controle die informatie geeft over het functioneren van het systeem is het controleren of er aan de invoerkant ook daadwerkelijk informatie binnen komt. Als het ophalen van informatie niet goed gaat kan er ook geen correcte verkeersinformatie gegeven worden. De controles op deze plek in de gegevensstroom zullen we Source Monitoring noemen. In het onderstaande schema zijn de plekken waar monitoren plaatst vindt aangegeven:
15
Als bij het monitoren fouten in het systeem zijn geconstateerd, moeten deze fouten in de vorm van een alarm naar de beheerder van het ET systeem worden gestuurd. Dit kan bijvoorbeeld via een alarm op het beeldscherm van de beheerder of door het opsturen van een email.
Een ander belangrijke taak van ET Alarmering en Rapportage systeem is om een beschikbaarheid rapportage te generen voor de verschillende stromen. Om de beschikbaarheid van het ET systeem te kunnen bepalen is het nodig dat de gegevens over de beschikbaarheid van het ET systeem worden opgeslagen en vervolgens weer kunnen worden opgevraagd.
16
6 Architectuur keuzes In dit hoofdstuk zullen we onderbouwen waarom we voor het Bus model hebben gekozen, hiervoor zullen we eerst de eisen die aan de architectuur worden gesteld behandelen. Vervolgens zullen we onderbouwen hoe we de functies van het systeem over module hebben verdeeld en tot slot zullen we de twee architectuurmodellen beschrijven met de voor en nadelen en waarom we voor het Bus model hebben gekozen.
6.1 Architectuur eisen Het doel van het kiezen van een architectuur is keuzes maken over hoe de functies die het systeem moet gaan uitvoeren verdeeld zijn over het systeem. Deze keuzes hebben gevolgen voor verschillende eigenschappen van het systeem, zoals uitbreidbaarheid en onderhoudbaarheid. Omdat de keuzes die nu gemaakt worden later vaak lastig zijn aan te passen is het belangrijk eerst te bepalen welke eigenschappen van belang zijn voor het systeem. Zoals bij veel systemen wijzigen in de loop van de tijd de eisen van de klanten. Ook kunnen er in de loop van de tijd klanten bij komen of afvallen. Dit soort veranderingen moeten zonder veel werk kunnen worden aangepast. Verder, zoals al aangegeven bij systeem beschrijving draait het ET systeem zowel onder Linux als onder Windows. Daarnaast is het de bedoeling dat in de toekomst het gehele systeem onder Linux komt te draaien. Het systeem zal dus zowel met de huidige configuratie als met toekomstige configuratie goed uit de voeten moeten kunnen. Tot slot is het wenselijk dat als er extra controles bedacht worden dat deze gemakkelijk te integreren zijn in het bestaande systeem. Tot slot is het belangrijk dat het systeem later nog uit te bereiden valt met extra functionaliteiten. Samengevat moet de architectuur van het systeem aan de volgende eisen voldoen: 1. Uitbreidbaar: Het moet mogelijk zijn om extra functionaliteiten aan het systeem door te voeren zonder dat er grote veranderingen aan de architectuur te hoeven aanbrengen. De mogelijkheid moet open staan om in de toekomst nieuwe modules aan het systeem toe te voegen. Dit kunnen bijvoorbeeld nieuwe monitor modules zijn maar ook andere services die van deze gegevens gebruik willen maken. 2. Onderhoudbaar: Het moet voor anderen mogelijk zijn om zonder veel moeite de code te kunnen aanpassen of te verbeteren. Een voorbeeld hiervan is als een van de monitor modules verbeterd moet worden. 3. Platform onafhankelijk: Het systeem moet op verschillende besturingssystemen kunnen draaien. 4. Robuust: Als een onderdeel van het systeem niet functioneert, moet de werking van de rest van het systeem hier zo min mogelijk last van hebben. 5. Flexibiliteit: zo min mogelijk afhankelijkheden tussen de onderedelen
17
6.2 Verdeling van de functie over modules De verschillende functie die het systeem moet gaan vervullen moeten over modules verdeeld worden. Hierbij is het van belang dat de eisen zoals die hiervoor genoemd zijn zoveel mogelijk bevredigd worden. Om het systeem uitbreidbaar en onderhoudbaar te houden zullen zoveel mogelijk functies onafhankelijk van elkaar worden geïmplementeerd, om dit te bereiken delen we alle functies op in aparte modules. Door elke module verantwoordelijk te maken voor een bepaalde functie levert dit een duidelijke structuur op wat de onderhoudbaarheid ten goeden komt. Ook voor het uitbereiden van functionaliteiten is het op deze manier duidelijk waar die gedaan moeten worden. Bijvoorbeeld bij het invoeren van extra controle bij een monitor module is het duidelijk in welke module dit toegevoegd moet worden, namelijk in desbetreffende monitor module. Als er een nieuw soort van monitoren (bv werkgeheugen controle) toegevoegd moet worden, kan dit als een aparte module worden geïmplementeerd. Bij de opdracht analyse(hoofdstuk 5), hebben we gekozen om op drie verschillende plekken het ET systeem te monitoren. Namelijk bij de invoer, de geconverteerde bestanden en het ophalen van de bestanden door de klant. Behalve het monitoren moet het systeem alarmen kunnen sturen en rapportages kunnen genereren. Deze functies zijn als volgt verdeeld over 6 verschillende modules: 1. 2. 3. 4. 5.
Sourcemonitor module: Controle van de invoer Contentmonitor module: Controle van de geconverteerde bestanden Destinationmonitor module: Controle van het ophalen van de bestanden door de klant Alarm module (AlarmController): Het versturen van alarmen beschikbaarheid registratie module(Uptime Registration): Het opslaan van de beschikbaarheids data 6. beschikbaarheid rapportage module (Uptime Data Service): Ophalen en Genereren van het beschikbaarheids percentage. Nu er bepaald is welke module er in ieder geval nodig zijn om alle functionaliteiten te implementeren moet er een model gekozen worden dat de samenhang tussen de modules beschrijft.
6.3 Keuze tussen twee Architectuur modellen Tijdens het uitwerken van de architectuur zijn we tot twee mogelijke modellen gekomen. Hier zullen we de twee modellen beschrijven, de voor en nadelen ervan benoemen en vervolgens onderbouwen waarom we voor het model met de Tenuki Bus hebben gekozen. 6.3.1 Model 1
Het eerste model bestaat uit een centrale module, surveillancecontroller, die de verschillende monitormodules beheert. Door middel van events sturen de monitor modules hun informatie naar de surveillance controller die op zijn beurt de informatie doorstuurt naar de verschillende modules die er iets mee moeten, zoals de AlarmController of de UptimeController. Verder heeft de surveillancecontroller de mogelijkheid de status van de verschillende modules op te vragen om deze door middel van een GUI aan de gebruiker te laten zien. 18
* Source Monitor
1 Surveillance Controller 1
Monitor GUI *
1
Content Monitor
1
*
1 *
*
Destination Monitor
1 Uptime Controller
Uptime Rapport GUI
1 Database
1 * Alarm module
*
1 Alarm Controller
Voordelen 1. Monitor modules staan los van de Alarmeringsapplicatie en bestaat de mogelijkheid om nieuwe monitor modules aan het systeem toe te voegen 2. Doordat de hoofdmodule de verschillende monitormodules kent, kunnen deze automatisch herstart worden als er iets fout gaat. 3. Omdat de monitormodules los staan van de rest van de applicatie zijn de modules toch onderhoudbaar. Nadelen 1. Er moet bijgehouden worden welke modules er bestaan, deze moeten ook bij het hoofdsysteem geregistreerd worden (een beperking in uitbreidbaarheid) 2. Bij het vastlopen van een monitor module kan het hele systeem vast lopen. (maakt het systeem niet robuust) 3. Subsystemen zijn afhankelijk van het hoofdsysteem. Dit betekent dat met uitvallen van het hoofdsysteem ook de subsystemen uitvallen. (single point of failure, maakt het systeem niet robuust) 4. Voor verschillende besturingssystemen moet een aparte versie van de applicatie gemaakt worden(niet platform onafhankelijk) 6.3.2 Model 2
Het tweede systeem is gebaseerd op een bus structuur. Als basis hiervoor hebben we de bestaande Tenuki Bus gebruikt. Deze bus biedt twee mogelijke communicatie modellen, een 19
server-client model en een publish-register model. Verder wordt voor de communicatie zelf gebruik gemaakt van TCP-IP. De monitor modules publishen de resultaten van hun controle op de Bus en de services die hier iets mee moeten doen luisteren naar deze berichten. Voor het genereren van rapporten wordt via de Bus een request gestuurd die beantwoordt wordt door een service die deze informatie uit de database kan halen.
Voordelen: 1. Uitbreiden van het systeem met extra monitormodule kan eenvoudig omdat de berichten die zij op de Bus publishen net als elk ander bericht afgehandeld kan worden (uitbreidbaarheid) 2. Uitbreiden van het systeem met meer alarmen is eenvoudig omdat hiervoor alleen een extra module gemaakt hoeft te worden die naar de Bus luistert en zijn ding met de berichten doet (uitbreidbaarheid, onderhoudbaarheid) 3. Uitbreiden van rapportage mogelijkheden is eenvoudig omdat de service die de beschikbaarheidinformatie terug geeft niet afhankelijk is van wie om zijn service vraagt (uitbreidbaarheid, onderhoudbaarheid) 4. Doordat de afzender van een bericht niet belangrijk is voor de verschillende services kan eenvoudig een monitor module per stroom worden geactiveerd waardoor bij het vastlopen van die module alleen de informatie voor één stroom niet beschikbaar is. (robuustheid) 20
5. Doordat er gebruik wordt gemaakt van TCP-IP voor de communicatie is het geen probleem dat de ene service onder Linux draait en een andere onder Windows (platform onafhankelijk) Nadelen: 1. Als de Bus vastloopt, is er geen communicatie meer mogelijk. (aangezien de Tenuki Bus voor meerdere systemen gebruikt wordt is deze echter zeer uitgebreid getest en worden eventuele fouten snel verbeterd ). 2. Indien een service is vastgelopen kan deze niet automatisch worden herstart. (wel gedetecteerd dat deze vast gelopen is)
6.4 Architectuur keuze Er zijn twee architectuurmodellen voorgesteld. Bij ieder zijn de voor- en nadelen besproken. Om te beslissen welke architectuurmodel we gaan gebruiken hebben we aan de hand van de hiervoor genoemde voor en nadelen gekeken naar de van te voren opgestelde eisen aan een model. Hierbij waren uitbreidbaarheid, onderhoudbaarheid en platformonafhankelijkheid de belangrijkste criteria. Daarnaast is er ook gekeken naar de flexibiliteit en robuustheid van de modellen. Ondanks dat beide modellen uitbreidbaar zijn, valt meteen op dat dit bij het tweede model een stuk gemakkelijker gaat als in het eerste model door de weinige afhankelijkheden. Deze onafhankelijkheden hebben ook als voordeel dat het systeem vrij simpel blijft wat de onderhoudbaarheid ten goede komt en dat het vast lopen van een module weinig effect heeft op andere modules wat de robuustheid ten goede komt. Verder biedt het tweede model een stuk meer flexibiliteit doordat de module die de berichten afhandelen geen kennis heeft over de modules waar een bericht vandaan komt, hierdoor kan er gemakkelijk aan de eis voldaan worden dat de stromen die afgenomen worden veranderen en er klanten bij kunnen komen. Tot slot de platform onafhankelijkheid, het eerste model zou een systeem opleveren dat bestaat uit één programma dat dus maar onder één besturingssysteem kan draaien, om dus de controles op beide besturingssystemen te kunnen uitvoeren moeten er twee verschillende programma’s gemaakt worden. Het tweede model kan, doordat er van TCP/IP gebruikt gemaakt wordt, modules onder verschillende besturingssystemen met elkaar laten communiceren en is dus geheel platform onafhankelijk. Op alle criteria scoort het tweede model beter als het eerste model dus vanzelfsprekend hebben we voor het model met de Bus gekozen.
21
7 Ontwerp In dit hoofdstuk wordt de werking van alle verschillende modules behandeld. Bij de monitormodules zal er beschreven worden welke controle deze uitvoeren en waarom. Bij de service modules beschrijven we hoe deze omgaan met status berichten en hoe de logica wanneer een stroom up of down is in elkaar zit.
7.1 Monitormodules De monitormodules hebben een aantal gezamenlijke eigenschappen die we hier eerst zullen benoemen, vervolgens zullen we per module de specifieke eigenschappen benoemen. Elke monitormodule controleert een specifiek deel van de gegevensstroom van het ET systeem. Hierbij voert elke module periodiek een controle uit en published het resultaat op de Tenuki Bus door middel van een state massage. Een state massage bevat de gegevens van de stroom die gecontroleerd wordt, naam van de module die de controle uitvoert, resultaat van de controle en eventueel het fout bericht. Om deze gegevens over de bus te sturen hebben we de volgende XML- standaard opgesteld:
<ERROR>geen verbinding meer mogelijk
Om het systeem robuust te houden hebben is er voor gekozen om het mogelijk te maken dat meerdere monitormodules tegelijk kunnen draaien die ieder een of meerdere stromen in de gaten houd. Om dit mogelijk te maken zijn de gegevens van de stromen in een configuratiebestand gezet en wordt door middel van een parameter aangegeven welke stromen de desbetreffende module moet gaan controleren. 7.1.1 Content monitor
Deze module controleert of de output file voor een gegeven stroom regelmatig wordt vervangen en of de inhoud nog regelmatig veranderd. Controles
Om te bepalen wat deze module moest gaan controleren hebben we eerst gekeken naar de huidige handmatige controles, deze controles bestaan uit: De laatste updatetijd van de bestanden De laatste updatetijd in het bestand 3. Het interne geheugen status 4. De vrije ruimte op de harde schijf 1. 2.
Alleen de eerste twee van deze controles hebben betrekking op de output files die de ET systeemmodules maken. Aangezien de Content monitor alleen naar dit punt van de stroom kijkt zullen we deze punten nader bekijken.
22
De controle van de laatste “Update Time” van een bestand wordt gedaan om te controleren of de modules nog werken, als deze niet meer nieuw worden aangemaakt betekend dit dat een module vast gelopen is. De reden dat dit op deze manier wordt gecontroleerd is omdat het gegenereerde bestand de enige output is die een module genereert en dus informatie geeft over de werking van de module. Het controleren van de laatste “Update Time” in het bestand worden gedaan om te kijken of de gegevens die binnengehaald worden nog wel vernieuwd worden. Het kan gebeuren dat er nog wel verbinding is en er ook gegevens binnen komen en keurig nieuwe bestanden worden gemaakt maar dat de data in de bestanden niet meer veranderd. Dus als er om 5 uur avonds alleen nog een melding van een file van 10 uur ochtends staat klopt er iets niet. Aan de hand van deze observatie en de conclusie dat een module als output alleen dit XMLbestand heeft hebben we besloten dat de Content Monitor twee controles moet uitvoeren, het bepalen of er nog wel regelmatig nieuwe bestanden worden aangemaakt, en of de inhoud van het bestand nog veranderd. Variabele drempelwaarden
Voor deze laatste controle is het lastig om vast te stellen wanneer het te lang geleden is dat er iets veranderd is. Tijdens de spits verwacht je dat dit vaak gebeurd maar midden in de nacht is het goed mogelijk dat er helemaal geen nieuwe berichten komen en dat de inhoud van het XML-bestand niet veranderd. Om toch beter iets te kunnen zeggen over de status van de stroom die gecontroleerd wordt kan er per stroom aangegeven worden op wat voor momenten je wat voor interval tijden verwacht tussen nieuwe berichten. Dit is op te geven voor een bepaalde dag van de week, een periode of een bepaalde datum. Een voorbeeld van een configuratie bestand hiervan ziet er als volgt uit: [filetijden_werkdagen_nederland] Period= 12-07 01-09 Times= 08:00-10:00 16:30-18:00 Interval_same_content=25 Figuur 7.1.1.1 voorbeeld configuratie met de algemene filetijden in Nederland
Deze configuratie is ingesteld voor de algemene filetijden van Nederland. Hierin staan 3 instellingen: -
De periode wanneer deze configuratie geldt De tijd periodes wanneer deze configuratie geldt De drempelwaarde(in minuten) die aangeeft dat in de gegeven tijd de inhoud van het verkeersinformatie bestand moet zijn gewijzigd.
Als er meerder situatie tegelijk geldig zijn zal het kleinste interval genomen worden.
23
7.1.2 Source Monitor
Deze module controleert of het ophalen van de gegevens door de verschillende modules van het ET systeem goed verloopt. Om te bepalen hoe deze module dit kan controleren hebben we eerst bekeken welke mogelijkheden hiervoor zijn. Het eerste idee dat we hadden was controleren of er nog verbinding mogelijk was met de servers waar de informatie werd opgehaald. Dit bleek echter om verschillende redenen niet handig. Zo zegt het contact kunnen maken met een server niets over of een module zelf nog wel verbinding maakt. Ook kan een server een maximaal aantal verbindingen ingesteld hebben waardoor de controle geen informatie geeft of zelfs het ET systeem in de weg kan zitten. Om toch iets nuttigs over de ophaalkant van het systeem te kunnen zeggen hebben we het systeem verder bestudeerd. Na het bestuderen van het systeem bleek dat de werking per module verschilde maar er wel een aantal algemene dingen overeen kwamen. Zo bleek dat de meeste modules de input die ze ophalen ook locaal in een bestand opslaan. De resultaten van de analyse zijn in de onderstaande tabel weergegeven. land
actief
protocol
(kopie)input file
formaat
observaties
Nederland
ja
TCP/IP TITP
ja
.tic
Bij geen contact lege .tic
België
ja
http
ja
.xml
bij geen contact geen nieuwe xml
Frankrijk
nee
ftp
-
-
-
ja
.xml
elke 5 min nieuwe xml, bij geen verbinding geen nieuwe xml. Bij herstelde verbinding weer xml bestanden.
Spanje
ja
http
Finland
ja
ftp
Oostenrijk
ja
ftp (per event)
Italië
ja
ftp (script)
Duitsland
nee
ftp
-
-
-
Engeland
nee
ftp
-
-
-
Zweden
ja
ftp(push per event)
ja
.xml
elke 4-6 min nieuwe xml, bij geen verbinding geen nieuwe xml. Bij herstelde verbinding weer xml bestanden.
Zwitserland
ja
ftp
ja
Op het moment dat er geen verbinding is zijn er een aantal modules die geen input bestand meer opslaan. Aan de hand van deze analyse hebben we besloten een controle van deze intput bestanden te maken. Hierbij hebben we alleen gekeken naar de timestamp van het bestand. Elke stroom die dus op deze manier met zijn input bestanden om gaat valt deze controle toe te 24
passen, hierbij kan er per stroom aangegeven worden om de hoeveel minuten een nieuw bestand opgehaald dient te zijn. 7.1.3 Destination Monitor
Deze module controleert of het gegenereerde bestand ook daadwerkelijk wordt opgehaald. Omdat dit voor een groot deel via FTP gebeurd hebben we besloten dat we de log van de FTP server zullen gebruiken om te controleren of een klant de gegevens heeft opgehaald. FTP-log
Het FTP log bevat veel gegevens, voor elke bestand dat wordt opgehaald of neergezet wordt er een regel toegevoegd. Een een dergelijk regel bevat informatie over wanneer de trasactie plaats vond, wie de transactie uitvoerde, om welk bestand het ging, en of deze geüpload of gedownload werd. De controle
Per stroom controleert de Destination monitor wanneer het XML bestand voor het laatst is gedownload door een klant en of dit niet langer dan een ingestelde tijd geleden is. De controle op wie het bestand heeft gedownload vind plaats omdat voor sommige stromen, voor verschillende doelen, het bestand meerdere keren word opgehaald (bepaalde stromen worden zelfs 8 keer elke 2 seconden opgehaald). Dat het bestand opgehaald wordt betekend dus nog niet dat de klant ook met de goede service de gegevens op haalt. Tail van log-bestand Omdat naast dat meerdere stromen vaak worden opgehaald ook de Windows modules hun resultaten via FTP naar het Linux gedeelte verplaatsten is het log-bestand erg groot (tot bijna een 1 GB). Om te voorkomen dat dit problemen op levert hebben we een script gemaakt dat de tail van het logbestand neemt en alleen hier in kijkt, deze tail bestaat uit een ingesteld aantal regels, 2000 regels bleek afdoende te zijn, vanaf het einde van het bestand.
7.2 Services In deze paragraaf bespreken we de verschillende modules die als services van het ET Alarmering en Rapportage applicatie draaien. Eerst zullen we de twee services behandelen die aan de hand van de state masseges acties uit voeren, de AlarmController en de Uptime Registration module, en vervolgens de UptimeDataService. Zowel de AlarmController als de Uptime Registration module hebben een mechanisme om de algemene state van een stroom bij te houden, aangezien deze in beide gevallen gelijk is zullen we deze eerst behandelen. De State
De monitormodules sturen zoals gezegd telkens de state van de stroom die ze controleren. Aangezien er meerdere modules zijn per stroom is er een bepaalde logica nodig om deze berichten tot een algemene state te combineren. Per monitor module kan een stroom drie verschillende states aanhouden, UP” (beschikbaar), “Down” (niet beschikbaar) en “Unknown”(onbekend). Op het moment dat er een “Down” wordt ontvangen wordt de stroom meteen als niet beschikbaar beschouwd. Als er een “Up” wordt ontvangen is het afhankelijk van de state die de andere monitormodules hebben doorgegeven wat de algemene state zal 25
zijn, het zelfde geldt voor een “Unkown” bericht. Een overzicht van de precieze logica staat in de volgende tabel: State SourceMonitor
StateContentMonitor
State DestinationMonitor
Verwachte resultaat
Up
Up
Up
Up
Down
-
-
Down
-
Down
-
Down
-
-
Down
Down
Up
Up
Unknown
Up
Up
Unknown
Up
UP
Unknown
Up
Up
Up
Up
Unknown
Unknown
UP
Unknown
Unknown
Up
UP
Unknown
Up
Unknown
UP
Unknown
Unknown
Unknown
Unknown
Op het moment dat er een bericht wordt ontvangen wordt er gekeken of dit bericht de algemene state van een stroom veranderd. Als dit zo is wordt er, afhankelijk van de verandering, een Event aangeroepen van de desbetreffende module die de service levert. Om dit te doen wordt voor elke stroom per monitormodule de laatste bekende state bijgehouden. De state ven een monitormodule voor een bepaalde stroom is onbekend zolang er nog geen bericht van deze module is ontvangen voor een stroom. Veroudering
Zoals eerder gemeld sturen de monitormodules na elke controle hun state door. Hierdoor is het mogelijk om te detecteren dat een module geen berichten meer stuurt. Door periodiek te controleren hoe lang het geleden is dat het laatste bericht ontvangen is kan er een Event gestuurd worden als dit te lang geleden is, ofwel dat de “Expored Time” wordt overschreden, verder wordt de state van de desbetreffende monitor module voor die stroom op onbekend gezet. Het opgeven van deze “Expired Time” kan door middel van het configuratie bestand. Ook hoe vaak deze controle moet plaats vinden kan in dit bestand opgegeven worden. 7.2.1 Alarm-Controller:
De Alarm-Controller vangt de berichten opgestuurd door verschillende monitor modules op. Aan de hand van de informatie in deze berichten wordt de algemene state van de stroom bepaald zoals hiervoor beschreven. De Events die door deze module afgevuurd worden, zijn bestemd voor onder de AlarmController GUI en Email Alarm module.
26
Events
De AlarmController stuurt tweesoorten Events namelijk: 1. state veranderd event, als de state van een monitormodule veranderd is. 2. alarm event, als de algemene state naar niet beschikbaar veranderd. 3. state verouderd event, als een module verouderd is Deze Events kunnen door verschillende modules gebruikt worden om de beheerder te waarschuwen. De Alarm GUI maakt gebruik van de state veranderd event en de state verouderd event, de Email Alarm module van het alarm event.
7.2.2 Email Alarm module:
Zoals boven al genoemd bestaat er een speciale Event die door de AlarmController afgevuurd wordt als de state van een stroom naar niet beschikbaar veranderd, deze wordt gebruikt door de Email Alarm module. Bij het ontvangen van dit Event wordt er een email bericht gemaakt die vervolgens naar een SMTP server wordt verstuurd. De inhoud van het email bericht bevat informatie over de stroom die plat licht en is geadresseerd aan de beheerder van het ET systeem. Een voorbeeld Email sjabloon: Onderwerp: Alarm ET Systeem! Tijd:01-05-2008 Geachte beheerder van het EuroTraffic Systeem, Er is een fout geconstateerd bij de volgende stroom: TomTom Nederland Deze fout is gemeld door de volgende module: Content Monitor. Foutmelding: “The update time of the XML file is less than 10 minutes!” De gegevens van de SMTP server en de geadresseerde van het mailbericht kunnen in het configuratiebestand ingesteld worden. 7.2.3 Uptime Registration:
Uptime Registration module is net als de andere modules verbonden met de Tenuki Bus. De taak van deze module is het bepalen en bijhouden van de state van de verschillende stromen en bij veranderingen deze op te slaan in een database zodat later de beschikbaarheid van de stromen bepaald kunnen worden. Het bepalen van de algemene state gebeurd aan de hand van de ontvangen state massages zoals aan het begin van dit hoofdstuk is aangegeven. Hoe deze 27
module gebruik maakt van Events zal als eerste beschreven worden en vervolgens de database tabel die gebruikt wordt door deze module.
Events
De UptimeRegistration maakt gebruik van maar één Event als de algemene state van een stroom verandert, als dit gebeurt wordt deze verandering in de database opgeslagen. Één uitzondering hierop als een stroom voor het eerst een state krijgt toegewezen, op dat moment wordt er een controle gedaan of de database als laatste bericht voor die stroom niet al die state had. Dit om te voorkomen dat een stroom twee keer achter elkaar met de zelfde state in de database terecht komt. Database Tabel
Er was slechts één tabel nodig om de beschikbaarheid gegevens in op te slaan. Hieronder zijn een paar rijen van deze tabel te zien:
Id
Klant
12555
land
timestamp
State
Tom Tom Nederland
01-01-2008 10:00
UP
12556
Tom Tom Nederland
01-01-2008 16:00
DOWN
….
…
…
….
…
7.2.4 Uptime Data Service:
Deze module is als service geïnstalleerd en maakt connectie met de Tenuki Bus. Andere modules(waaronder rapportage GUI) kan een aanvraag hierop doen. Deze aanvraag bestaat uit een lijst van stromen en een maand. De Uptime Data Service haalt de gegevens uit de database en berekent het beschikbaarheid percentage voor de gegeven stromen en maand. Deze resultaten worden vervolgens teruggestuurd via de bus met de volgende XML formaat:
28
8 Graphical user interface In dit hoofdstuk bespreken we de Graphical user interfaces (GUI’s) behorende bij de Alarmering en Rapportage applicatie van het ET systeem. De technische onderdelen die achter deze GUI’s zitten worden in het kort benoemd. Voor meer details wordt aangeraden om het vorige hoofdstuk te raadplegen. De ontwikkelde GUI voor de Alarmering kan vanaf elke computer draaien. Dit scherm is bestemd voor de beheerder van het ET systeem. Bij het uitvallen van een van de stromen wordt de gebruiker van de GUI geattendeerd. Daarnaast heeft de gebruiker een status overzicht van de Monitor modules per stroom. De gebruiker kan dan in een oogopslag de status van een stroom zien. Rapportage GUI kan gebruikt worden voor het generen van een beschikbaarheidrapportage.
Eisen en wensen In alle fases van de ontwikkeling van de GUI’s zijn de gebruikers van deze schermen en de beheerders van het ET systeem telkens betrokken geweest. De feedback hiervan is telkens in een volgend prototype verwerkt. AlarmController GUI
De belangrijkste eis voor de Alarm GUI is dat de uitgevallen stroom in een pop-up scherm getoond wordt. Dit moet het liefst gepaard gaan met een duidelijk alarm geluid die de beheerders moet waarschuwen. Bovendien moet men meteen kunnen achterhalen om welke stroom het gaat. Deze GUI krijgt een plek voor de ingang van het bedrijf en moet voortdurend het overzicht van de stromen kunnen laten zien. Een andere eis is dat deze GUI op meerdere pc’s tegelijk kan draaien. Een wens van de gebruiker is dat de status van een stroom, zoals die volgend de monitormodules is, overzichtelijk weergegeven kan worden. Beschikbaarheids rapportage GUI
De meest belangrijke eis bij het genereren van rapporten is dat de optie om beschikbaarheids percentage weer te laten geven, standaard geselecteerd is. Alle andere extra opties kunnen eventueel ook gekozen worden. Bovendien moet per klant het overzicht van de verschillende landen worden weergegeven. Een andere eis is dat de percentages afgerond zijn weergegeven. Wensen bij de rapportage GUI zijn onder andere dat de tabel gecentreerd op het scherm is weergegeven en een lichte achtergrond om bij het printen de tekst zo duidelijk mogelijk te kunnen afdrukken.
8.1 AlarmController GUI De AlarmController GUI bevat een connectie knop die een verbinding met de Tenuki Bus op de server waar het ET systeem op draait kan maken. De berichten die door de verschillende monitor modules over een stroom worden opgestuurd komen dan via de Tenuki Bus bij deze GUI terecht. Per stroom wordt de status bijgehouden en wordt er een geschiedenis van de inkomende berichten opgeslagen. Deze kan de gebruiker helpen om de fouten beter op te sporen.
29
Figuur: AlarmController GUI
Verder worden de verschillende symbolen op deze GUI in de legenda uitgelegd, dit helpt om een beter zicht te krijgen van de stromen. Bij het alarmeren verschijnt automatisch een pop-up scherm, waarop duidelijk is aangegeven om welke stroom het alarm gaat. Daarnaast word ook het bericht( foutmelding) gegeven zodat de gebruiker aan de hand hiervan al weet welke monitor module dit probleem heeft gemeld.
Figuur: Alarm pop-up scherm
30
Overzicht van Monitor modules
In het bovenstaande figuur is er nog geen bericht van een monitor module binnen gekomen. Dit wordt aangegeven met grijze vlak in de monitor kolommen en in de status kolom is te zien dat er geen berichten van de monitor modules ontvangen zijn. Vervolgens als er berichten binnen zijn gekomen verandert deze status:
In het bovenstaande figuur geven beide ContentMonitor en DestinationMonitor voor de stroom TomTom Nederland aan dat deze stroom beschikbaar is, voor Zwitserland daar tegenover is een alarm binnen gekomen en wordt deze stroom niet beschikbaar gemeld. In de volgende stap is te zien dat de SourceMonitor voor twee stromen een bericht heeft gestuurd dat ze beschikbaar zijn. Dat de status van Spanje meteen als beschikbaar wordt geteld zonder dat er informatie van de andere monitor module bekend is hebben we voor gekozen omdat dit de meeste flexibiliteit geeft qua welke monitormodules moeten draaien. Op het moment dat er dus informatie beschikbaar is wordt die informatie meegenomen in het bepalen van de status.
31
8.2 Beschikbaarheids rapportage GUI De rapportage GUI wordt gebruikt om de beschikbaarheid percentage voor de verschillende stromen te genereren. Per klant wordt automatisch een lijst van de landen opgehaald die aangevinkt kunnen worden voor de rapportage. Deze GUI kan ook op iedere pc draaien en zal door een verbinding te maken met de Tenuki Bus de beschikbaarheid aanvragen.
In de onderstaande figuur is de Rapportage GUI te zien:
Figuur: Beschikbaarheids rapportage GUI
Voor de beschikbaarheids rapportage is het ook mogelijk om behalve het beschikbaarheids percentage, ook andere gegevens te tonen. Dit kan met behulp van het opties scherm van deze GUI:
Figuur: opties Beschikbaarheids rapportage
32
8.3 Beschikbaarheids Rapportage De beschikbaarheid rapportage is bestemd voor de klanten van EuroTraffic. Het logo en adres gegevens van EuroTraffic zijn hierop getoond. Per maand kan men een overzicht van de beschikbaarheid percentages weergeven.
33
9 Project verloop In dit hoofdstuk bespreken we hoe punten die genoemd zijn bij de werkwijze (eerder in dit document) toegepast zijn. We lopen de verschillende fasen/iteraties van het project langs en geven aan welke onderdelen hierin geïmplementeerd zijn. Tijdens de eerste weken is er vooral gewerkt aan probleem beschrijving, ontwerp en architectuur. Daarna zijn in drie iteraties van gemiddeld twee weken de verschillende functies aan de software oplossing toegevoegd. Ten laatste zijn de monitor modules en services op de werkelijke server geïnstalleerd en is de stap van oplevering en overdracht van de code uitgevoerd. Gedurende het hele project zijn er meerdere documenten ter bevestiging van de feedback van de opdrachtgever opgesteld. Deze zijn later onder andere voor het eindverslag gebruikt.
9.1 Fase: Ontwerp en architectuur: Probleem analyse
Aan het begin van het project is er veel tijd besteed aan analyse van het probleem en heeft het team zich meer verdiept in de opdracht, de opdracht beschrijving is in details uitgewerkt. Aan de hand van deze resultaten is er bepaald welke functies nodig zijn om de bestaande problemen op te lossen. Ontwerp
In deze fase zijn de functies vervolgens in de vorm van deel oplossingen in verschillende modules opgedeeld Deze modules waren: ContentMonitor, DestinationMonitor, SourceMonitor, UptimeRegistration, UptimeService en AlarmController. Kijk voor meer details over de modules in hoofdstuk 5 over ontwerp keuzes. Architectuur keuze
Rekening houdend met verschillende criteria zoals uitbreidbaarheid, onderhoudbaarheid, platform onafhankelijk, robuustheid en flexibiliteit is een overweging gemaakt om de architectuur gebruikmakend van de Tenuki Bus te gebruiken.
9.2 Iteraties Voordat er begonnen is met de verschillende iteraties is er een stresstest van de Tenuki Bus geïmplementeerd waarbij het team zich bekend heeft gemaakt met de mogelijkheden van deze architectuur Bus. De kennis die hierbij op is gedaan is door de rest van het project gebruikt. Bij uitvoeren van deze opdracht zijn drie iteraties aan de orde gekomen. Tijdens de iteraties wordt de functionaliteit van modules die aan het begin in globale lijnen is vastgelegd, in details uitgewerkt. Hierbij kan het zijn dat het ontwerp en de architectuur verfijnd worden. Aan het begin van de iedere iteratie stap is er telkens een analyse gemaakt van de functies die uit de desbetreffende iteratie moeten resulteren, daarna zijn voor de bijkomende functies nieuwe testcases geschreven en is er uiteindelijk begonnen met implementeren van de modules. Bij de eerste iteratie (Framework) is er begonnen met implementeren van de meest cruciale functies van het systeem. Dat waren de belangrijkste monitor modules, alarmeren en opslaan en ophalen van de beschikbaarheid. De tweede en derde iteraties waren vooral 34
uitbreidingen en verbeteringen van de bestaande modules. Behalve een enkele uitzondering zoals de SourceMonitor die pas in de derde iteratie is ontwikkeld. Hieronder ziet u een overzicht van de uitgevoerde iteratie: 9.2.1 Eerste Iteratie (Framework)
Tijdens de eerste iteratie zijn de meest essentiële onderdelen van de Alarmering en Rapportage systeem geïmplementeerd. De Content- en Destination Monitor horen bij het Framework omdat deze de meest belangrijke informatie geven over de beschikbaarheid van file stroom. Deze twee Monitor modules controleren de output van het ET systeem. De AlarmController hoort ook bij het Framework omdat de berichten die door de monitors verzonden worden, opgevangen en verwerkt moeten worden. De andere twee zijn gebruikt om de beschikbaarheid vast te leggen en op te kunnen halen en zullen dus de basis zijn voor het rapporteren. Hieronder zijn de verschillende onderdelen die tijdens deze iteratie geïmplementeerd nog voor de duidelijkheid op een rijtje gezet(Let op voor deze en de komende iteraties is telkens probleemanalyse en schrijven van testcases vooraf gegaan, deze zullen niet iedere keer opnieuw genoemd worden): 1. Implementeren van modules: • ContentMonitor • DestinationMonitor • UptimeRegistration • UptimeRapport • AlarmController 2. Testen van de modules op een simpele test omgeving. 9.2.2Tweede iteratie
Bij het uitvoeren van de tweede iteratie zijn er vooral uitbereidingen en verbeteringen van de bestaande modules uitgevoerd. Daarnaast zijn sommige modules naar Windows Services en Linux daemons omgezet. Dit is gedaan omdat er een voorkeur is geweest om zoveel mogelijk op Linux te draaien, zodat er zo min mogelijk onderdelen op een Vmware op de server hoeft te draaien(lees hiervoor hoofdstuk 5, ontwerpkeuzes). Ook zijn twee GUI’s geïmplementeerd en is het systeem op een realistische testomgeving getest die zoveel mogelijk de echte situatie moet nabootsen. Hier onder een lijst van de onderdelen die in deze iteratie afgerond zijn: 1. Implementeren/ verbetering van de (up/down) logica 2. Uitbereidingen bestaande Modules: controle logica (up/down) logica 3. Omzetten van modules naar Windows services: Uptimeregistratie Uptimeservice 4. Ontwikkeling van GUI’S Alarmcontroller GUI Bechikbaarheids rapportage GUI 35
5. Omzetten van de Monitor Modules naar Linux daemon ContentMonitor DestinationMonitor 6. Testen van de modules en services op een realistische testomgeving met Windows en Linux Vmwares. 9.2.3 Derde iteratie
Tijdens de derde iteratie van het project zijn weer uitbreidingen en verbeteringen toegevoerd. Hierbij zijn de resultaten uit de vorige test op een realistische omgeving gebruikt. De ContentMonitor is uitgebreid met variabele intervallen waarmee aangegeven kan worden hoe veel tijd tussen updates in het bestand verwacht worden. Hierdoor is het bijvoorbeeld mogelijk aan te geven dat het op bepaalde dagen drukken of juist rustiger is. De SourceMonitor is ook geïmplementeerd deze iteratie, omdat de tijd krap begon te worden is deze module alleen voor een aantal stromen geïmplementeerd. Omdat het per stroom verschillend is hoe de data wordt opgehaald verschild ook de manier van met deze informatie omgaan. Om toch zoveel mogelijk stormen te kunnen controleren is de controle gebouwd die voor meerdere stromen gebruikt kan worden. Daarnaast zijn er veel Services naar Linux versies omgezet zodat er zo min mogelijk op een Virtuele Machine draait, de GUI’s zijn verbeterd en is er uiteindelijk een volledig weekend test uitgevoerd. Na de weekend test is er besloten om log bestanden voor de verschillende modules bij te houden. Dit om meer zicht over de werking van de onderdelen te hebben, maar ook de stabiliteit van de applicatie beter te kunnen testen en te waarborgen. Hierna is het systeem voor de derde keer gedurende een dag lang getest en klaar gemaakt voor de installatie op de echte server. 1. Uitbereiding testcases van logica + bestaande modules 2. Verbetering van (Up/down) logica van de UptimeRegistratie, DestinationMonitor, Alarmcontroller 3. Omzetten van modules naar Windows Services: EmailAlarmService 4. SourceMonitor (TestCases + Implementatie) als Windows Service 5. ContentMonitor, rekening houden met bijzondere gevallen waarbij de file informatie mag verschillen van de algemene aannamen 6. Omzetten van de Services naar Linux daemon EmailAlarm UptimeService UptimeRegistratie 7. Verbetering GUI’s en rapportage Alarmcontroller GUI Uptime rapportage GUI 8. Weekend test 9. Log bestanden bijhouden voor verschillende modules 10. Laatste test gedurende een dag
36
9.3 Opleveren en overdracht Voordat deze fase helemaal is uitgevoerd is er een planning gemaakt van de acties die ondernomen moeten worden om de verschillende modules te kunnen installeren. Deze planning is aan de opdrachtgever overgedragen en zijn er verschillende settings opties uitgelegd. Na voltooien van deze taak is er een document opgesteld met de locatie van alle code en de plek van de “Release map” op het netwerk van het bedrijf. Ook is tijdens deze fase het uiteindelijke systeem op het echte systeem geïnstalleerd en zijn de applicatie twee dagen lang in de gaten gehouden. Tijdens deze activiteiten was de opdrachtgever nauw betrokken en werkte een van medewerkers van het bedrijf met ons samen. Deze fase is met succes afgerond en heeft het de Alarmering en Rapportage applicatie meteen al fouten kunnen ontdekken en op tijd kunnen alarmeren. Dit versterkte het vertrouwen in de gebouwde Alarmering en Rapportage applicatie!
9.4 Documentatie en verslag Gedurende het projecten zijn er meerdere documenten opgesteld en zijn er meerdere opzet versies voor het eindverslag gemaakt. Er zijn diverse afspraken met de stagebegeleider over het verslag gemaakt, ook is de opdrachtgever hierbij betrokken geweest. De beslissingen die tijdens het ontwerp en de iteraties zijn gemaakt zijn telkens op papier gezet en zijn deze door de opdrachtgever bevestigd voordat er aan iteraties begonnen kon worden. Deze documenten zijn later onder andere voor het eindverslag gebruikt. De opdrachtgever heeft veel aandacht besteed aan verslaggeving en heeft het team hierbij ondersteund. In de laatste fase van het project is er gewerkt aan het eindverslag.
37
10 Aanbevelingen In dit hoofdstuk willen we in het kort de uitbreidingsmogelijkheden voor het ET Alarmering en Rapportage Systeem bespreken. Beschikbaarheids data beheer
Een van de onderdelen die nog aan gewerkt kan worden is het beheer van de beschikbaarheid database. Het kan namelijk voorkomen dat een stroom onterecht als niet beschikbaar is opgeslagen in de database. Dit kan bijvoorbeeld als file informatie gedurende lange tijd niet gewijzigd is en de ContentMonitor wel een verandering had verwacht. Een dergelijke fout heeft natuurlijk invloed op het beschikbaarheid percentage, op zo'n moment kan handmatig de onterechte down uit de database gehaald worden, het zou natuurlijk mooier en praktischer zijn als dit door middel van een GUI zou kunnen. Verbetering bestaande monitor modules ContentMonitor
De huidige ContentMonitor controleert twee dingen: bepalen of er nog wel regelmatig nieuwe bestanden worden aangemaakt, en of de inhoud van het bestand nog veranderd is. De file informatie in een geconverteerd bestand bevat verschillende gegevens waaronder locatie, versie nummer en “expire time”. De “expire time” betekent op welke moment file verkeersinformatie niet meer geldig is. Het komt wel eens voor dat in een geconverteerd bestand een file staat waarbij de “expire tijd” al verstreken is. Dit is dan een ongeldige file informatie die dan wel aan de klant wordt geleverd. Als dit wordt gedetecteerd moet er ook een alarm optreden. SourceMonitor
Deze monitor kan uitgebreid worden met meerdere stromen. Alarmeren via een SMS bericht
Op dit moment kan het systeem op twee manieren de beheerder alarmeren, namelijk via de AlarmGUI en door het versturen van een email bericht. Men kan er voor kiezen om een SMS alarm module aan het systeem toe te voegen. Het ontvangen van de berichten via een SMS biedt het de mogelijkheid om altijd en overal zonder een pc en internet verbinding berichten te kunnen ontvangen. De logica hiervan zal dan grotendeels gelijk zijn aan die van de EmailAlarm Service. Figuur: voorbeeld alarm via een SMS bericht
Extra monitor modules
Het controleren van het interne geheugen en de harde schijf status worden op dit moment handmatig bij het dagelijkse monitoren van het ET systeem gedaan. Deze controles kunnen in de vorm van monitor modules aan het systeem worden toegevoegd.
38
11 Evaluatie Een project buiten de TU doorlopen was voor ons alle drie nieuw, in dit hoofdstuk willen we vertellen wat onze ervaringen hier mee waren. Doordat de werkwijze tijdens dit project geheel anders was dan eerdere projecten die we hebben gedaan was dit, vooral in het begin, erg wennen. Alles bij elkaar is het een zeer leerzaam en leuk project geweest. Het telkens terug koppelen wat volgens jou de opdracht is en aangeven wat op dat moment het belangrijkste is om aan te pakken heeft erg geholpen om de focus op de belangrijkste dingen te houden waardoor er geen tijd verdaan is met het maken van onbelangrijke fearures. Op zich klinkt dit als een vrij logische en makkelijke aanpak echter als technici ben je heel snel geneigd in het hoe een probleem aan te pakken te denken, in de loop van het project ging dit echter steeds beter en hebben we hier veel van geleerd. Ook het werken met XP, en dan vooral het opdelen van het proces in iteraties en TestDriven Programming, is ons erg goed bevallen. Door het proces op te delen in iteraties en in elke iteratie telkens de belangrijkste functionaliteiten die op dat moment nog missen als eerste te implementeren is de voortgang van het proces goed te volgen, wisten onze begeleiders wat ze aan functionaliteiten konden verwachten en konden ideeën over bijvoorbeeld hoe de GUI's er uit moesten gaan zien goed met de opdrachtgever worden kort gesloten. Bij het TestDriven ontwikkelen van de code hebben we in het begin wat problemen gehad, omdat de precieze methodes in het begin nog niet geheel duidelijk waren kwamen we op scenario testen uit in plaats van unit testen. Nadat we hier op gewezen zijn hebben we hier beter opgelet en heeft het TestDriven ontwikkelen van de code erg geholpen bij het efficiënt ontwikkelen van goede code, en op het moment dat we een fout tegen kwamen deze snel op te lossen. Het werken met een codeerstandaard is ook goed bevallen. In het begin was het wel wennen maar doordat we bestaande code van Tenuki als voorbeeld konden gebruiken bij een aantal functies werd de structuur ons snel duidelijk en het nut om een standaard aan te houden ook. Het maakt het begrijpen van iemand anders zijn code een stuk makkelijker waardoor het hergebruiken. Het maakt het begrijpen van iemand anders zijn code een stuk makkelijker waardoor het hergebruik van andermans ideeën goed kan en het verder werken aan een module die een ander heeft gemaakt ook goed te doen is. Zoals al verteld is het hele systeem in Delphi geprogrammeerd, dit was voor ons alle drie een nieuwe taal. Om zo een heel systeem in een nieuwe taal te doen was een leuke ervaring, in het begin was het nog wel is zoeken naar hoe je iets wat je van Java al goed kent onder Delphi deed, maar dankzij een aantal Delphi sessies op het bedrijf en bestaande projecten als voorbeeld (die door de codeerstandaard goed te lezen waren) hadden we Delphi vrij snel onder de knie. De oplevering van het product was ook een nieuwe ervaring. Toen alles geïmplementeerd was en naar onze zin werkte op de test omgeving hadden we het idee dat alles klaar was en opgeleverd kon worden. Het vervolgens daadwerkelijk opleveren van het systeem had echter meer voeten in de aarde dan we van tevoren gedacht hadden. Het was allemaal niet 39
ingewikkeld of onverwacht werk maar toch meer als we hadden verwacht. Het was leerzaam om er op deze manier tegen aan te lopen. Toen het eenmaal allemaal draaide was het ook erg leuk om te zien dat het allemaal ook echt werkte en er dezelfde middag een probleem werd gedetecteerd dat meteen hersteld kon worden. Al met al is het een zeer leerzame periode geweest waarbij het leuk was om zo in een bedrijf mee te kunnen doen en een systeem te ontwikkelen dat ook echt gebruikt gaat worden.
40
41
Appendix C - Tools Delphi
Bij het uitvoeren van dit project is er gebruik gemaakt van de programmeertaal Delphi. Een van de redenen hiervoor is dat alle bestaande modules van het EuroTraffic systeem in Delphi ontwikkelt zijn. Het moet voor Tenuki BV mogelijk zijn om de Alarmering en Rapportage applicatie te kunnen onderhouden en uit te bereiden met de al bestaande kennis in het bedrijf. De broncode moet direct leesbaar en met zo min mogelijk te onderhouden zijn. Daarom is er gedacht aan de codestandaards en de werkwijze binnen het bedrijf. Tenuki Service Bus
Tenuki Service Bus (TSB) is een bestaande bus architectuur ontwikkeld door Tenuki BV. Deze levert twee mogelijke servicebenaderingen, een Client Server benadering en een Publish Register benadering. Ook is het mogelijk dat er meerdere modules de zelfde service bieden, de bus zorgt er dan voor dat een aanvraag maar bij één van de modules aan komt, als een tweede module om dezelfde service vraagt en de eerste is nog bezig zorgt de bus er zelf voor dat die bij een andere module aankomt die dezelfde service levert. Als dit niet mogelijk is wordt het verzoek gecashed en doorgestuurd zodra dit wel mogelijk is. Verder wordt er gebruik gemaakt van TCP/IP waardoor modules die onder verschillende OS draaien van de zelfde bus gebruik kunnen maken. Deze eigenschappen leveren voor de implementatie van modules veel vrijheid waarbij weinig kennis in een module hoeft te zitten over andere modules.
42
