Automated web applications testing

DEPARTEMENT HANDELSWETENSCHAPPEN EN BEDRIJFSKUNDE

Automated web applications testing

Bert Heymans & Jurgen Vanhex

Afstudeerwerk ingediend tot het behalen van het diploma van Gegradueerde in de Toegepaste Informatica

Promotoren :

Dhr. H. Saris (Beta Nine) Dhr. S. Van Caekenberghe (Beta Nine) Mevr. M. Luwel (HL) Academiejaar 2002 - 2003

DEPARTEMENT HANDELSWETENSCHAPPEN EN BEDRIJFSKUNDE

Automated web applications testing

Bert Heymans & Jurgen Vanhex

Afstudeerwerk ingediend tot het behalen van het diploma van Gegradueerde in de Toegepaste Informatica

Promotoren :

Dhr. H. Saris (Beta Nine) Dhr. S. Van Caekenberghe (Beta Nine) Mevr. M. Luwel (HL) Academiejaar 2002 - 2003

Voorwoord Dit stageverslag is een zelfstandig gemaakt werk dat gemaakt werd in opdracht van de Hogeschool Limburg ter afsluiting van het laatste jaar Toegepaste Informatica. Wij hebben stage gelopen bij Beta Nine en onze begeleiders waren Hein Saris, Sven Van Caekenberghe en Ivan Melotte. De promotor op school was Marina Luwel. De uitwerking van onze opdracht gebeurde onder Linux Mandrake 9.0 en RedHat 8.0. De Java code werd geschreven in IntelliJ 3.0.4 van Idea. De code werd getest met JDK1.4.1. Hein, Sven en Ivan willen we bedanken voor de dingen die ze ons hebben geleerd op het gebied van Java programmatie. Marco, Jochen, Ronald, Tim en Nicky willen we bedanken voor de vele hulp, steun en tips die ze ons gegeven hebben om het project op punt te stellen. Tot slot willen we iedereen bedanken voor de toffe sfeer gedurende de afgelopen 10 weken. Hasselt, 14 juni 2003

Automated Web Application Testing

1

Inhoudsopgave 1 2

Het bedrijf .........................................................................................................................4 Java....................................................................................................................................5 2.1 De geschiedenis van Java ..........................................................................................5 2.2 Voor- en nadelen van Java ........................................................................................8 2.2.1 Taalkenmerken ..................................................................................................8 2.2.2 Objectgeoriënteerd ............................................................................................9 2.2.3 Distributed.........................................................................................................9 2.2.4 Robuust............................................................................................................10 2.2.5 Veilig...............................................................................................................10 2.2.6 Platformonafhankelijkheid ..............................................................................10 2.2.7 Hoge prestaties ................................................................................................11 2.2.8 Multi threaded .................................................................................................11 2.2.9 Publiek toegankelijk (open source) .................................................................11 2.2.10 Internet en intranet...........................................................................................11 2.3 Java netwerkprogrammering ...................................................................................12 2.3.1 Wat zijn sockets?.............................................................................................12 2.3.2 Een minimale client.........................................................................................13 2.3.3 Een minimale server........................................................................................14 3 Gebruikte tools ................................................................................................................15 3.1 Linux .......................................................................................................................15 3.1.1 Geschiedenis van Linux ..................................................................................15 3.2 IntelliJ IDEA ...........................................................................................................16 3.2.1 Omschrijving...................................................................................................16 3.2.2 Intelligente en gebruiksvriendelijke Java editor..............................................17 3.2.3 Besluit..............................................................................................................21 3.3 Concurrent Versions System (CVS)........................................................................22 3.4 The Jakarta Project ..................................................................................................23 3.4.1 Ant...................................................................................................................23 3.4.2 Log4j ...............................................................................................................24 3.4.3 JUnit ................................................................................................................24 4 Gebruikte technologieën..................................................................................................27 4.1 Hyper Text Transfer Protocol..................................................................................27 4.1.1 Geschiedenis....................................................................................................27 4.1.2 Wat is HTTP?..................................................................................................27 4.1.3 Functionaliteit..................................................................................................27 4.1.4 Eigenschappen.................................................................................................28 4.1.5 HyperText Transfer Protocol methoden..........................................................30 4.1.6 HTTP header lines...........................................................................................33 4.1.7 Cookies en de privacy .....................................................................................35 4.1.8 Voorbeeld ........................................................................................................37 5 Extreme Programming ....................................................................................................39 5.1 Inleiding...................................................................................................................39 5.2 Kostencurve.............................................................................................................40 5.2.1 Feedback..........................................................................................................41 5.2.2 Refactoring ......................................................................................................41 5.2.3 Automatische unit tests ...................................................................................41 Hogeschool Limburg 2002-2003-06-09

Heymans Bert Vanhex Jurgen


2

5.2.4 Eenvoud van ontwerp......................................................................................41 5.2.5 Pair Programming............................................................................................42 5.3 De werkwijze van XP..............................................................................................43 5.3.1 De menselijke factor........................................................................................43 5.3.2 Verantwoordelijkheid......................................................................................43 5.3.3 Standaarden verplicht ......................................................................................43 5.3.4 Levenscyclus van een project ..........................................................................44 5.4 Nadelen....................................................................................................................46 5.5 Besluit......................................................................................................................47 6 Stageproject .....................................................................................................................48 6.1 Probleemstelling......................................................................................................48 6.2 Proxy-tunnel ............................................................................................................49 6.2.1 Gebruik............................................................................................................49 6.2.2 Trafiek .............................................................................................................49 6.2.3 Opname ...........................................................................................................50 6.3 Client-simulator.......................................................................................................54 6.3.1 Gebruik............................................................................................................54 6.3.2 Eén player sessie van dichtbij bekeken ...........................................................55 6.3.3 Het geheel van sessies in een simulatie...........................................................57 6.4 Testing framework ..................................................................................................58 6.5 De GUI in beeld ......................................................................................................61 6.5.1 Recorder en browser........................................................................................61 6.5.2 LoadTester.......................................................................................................62 7 Lijst met figuren ..............................................................................................................65 8 Bronvermelding...............................................................................................................66 8.1 Boeken.....................................................................................................................66 8.2 Websites ..................................................................................................................66

Hogeschool Limburg 2002-2003-06-09



3

Inleiding Om onze opdracht tot een goed einde te brengen hebben we verschillende dingen moeten bestuderen: • technologieën die enorm bijdragen leveren voor de Java community zoals log4j, JUnit en ant • een zeer grondig begrip van het HTTP protocol • het principe en de opbouw van een Proxy • de reflection technologie binnen Java • JFreeChart, een Java class library om grafieken te genereren Men heeft ons steeds aangemoedigd de Extreme Programming methodologie toe te passen met in het bijzonder de pair-programming. Dit is een zeer aangename, constructieve manier van werken. Het opzet van onze opdracht bestond erin een tool te ontwikkelen die kon gebruikt worden om webapplicaties te testen. Het testen zou gebeuren door eerder opgenomen surf-sessies in het veelvoud opnieuw te simuleren op de webapplicatie. Dit moest gebeuren op een manier die zo menselijk mogelijk was. De resultaten van de test moesten duidelijk kunnen maken wat de webapplicatie aankon, vandaar de titel van ons project: “LoadTester”. Onderdelen en troeven: • een proxy-tunnel, de session-recorder waar een browser op kan connecteren onzichtbaar voor de browser en de server - die een sessie opneemt in een gemakkelijk te begrijpen en flexibel XML formaat • een client-simulator, de player die de opgenomen sessie(s) opnieuw afspeelt en resultaten genereert • een framework die zeer gemakkelijk toelaat zelf plug-ins te schrijven om resultaten te interpreteren • een grafische frontend voor de recorder en de player geschreven in SWING • de mogelijkheid om een custom gui te schrijven voor een set van testresultaten • enkele voorbeeld plugins waaronder bijvoorbeeld een grafische representatie van het verloop van de request-response intervallen van de sessies in een grafiek In dit verslag zullen we eerst de gebruikte technologieën en tools toelichten en vervolgens dieper ingaan op de structuur en werking van ons project.




4

1 Het bedrijf

Beta Nine is een jong, dynamisch softwarehuis gelegen in het Villerspark nabij het Virga Jesse ziekenhuis in het centrum van Hasselt. Het werd opgericht in 1996 door Sven Van Caekenberghe. Oorspronkelijk werkte hij alleen en gebruikte hij Smaltalk als programmeertaal. Later werd er overgeschakeld op Java en kwam er een vennoot bij, Hein Saris. Ook werden er in de volgende jaren 6 extra programmeurs, dit zijn allen oud-studenten van de Hogeschool Limburg Hun activiteiten bestaan vooral uit het realiseren van projecten voor klanten. Het ontwikkelen van deze projecten gebeurt echter niet bij de klant, maar in hun kantoor in het Villerspark. De hoge kwaliteit van de geleverde software zorgt ervoor dat Beta Nine veel tevreden klanten heeft, zoals onder andere VTM (bv.: www.rijbewijs.be), Netvision, Idewe, GPS-Buddy (www.gps-buddy.com),… Hun motto is trouwens: “Software is written to suit your unique needs”. Toch heerst er een ontspannen sfeer in het bedrijf. De bedrijving van de Extreme Programming methodologie draagt hier zeer toe bij. Het uitkiezen van een project gebeurt in overleg met andere collega’s. Hierbij gaan ze zeer selectief te werk. In elk project wordt er gebruik gemaakt van de allerlaatste ontwikkelingen en nieuwe technologieën om het programmeren leerrijk te houden. U kunt altijd contact opnemen met Beta Nine via hun website: http://www.beta9.be




5

2 Java 2.1 De geschiedenis van Java In 1990 was software programmeur Patrick Naughton het zat om iedere keer maar nieuwe programma’s te moeten schrijven voor het bedrijf Sun Microsystems waar hij werkte omdat dit bedrijf met zoveel verschillende systemen werkte. Hij kreeg een nieuwe baan aangeboden en vertelde dit zijn baas en goede vriend, McNealy. McNeally wilde Naughton niet kwijt en vroeg deze om een lijst te maken met alle klachten die hij had. Aan de hand daarvan zouden ze de problemen veel beter kunnen aanpakken. Toen Naughton deze lijst had gemaakt en hem in had gediend, had hij niet over de gevolgen nagedacht. Hij was in de veronderstelling dat hij het bedrijf zou verlaten en was daarom zeer eerlijk geweest in zijn lijst met tekortkomingen. Maar het onwaarschijnlijke gebeurde. De lijst werd gemaild naar diverse programmeurs bij Sun en men kwam tot de conclusie dat er een universele programmeertaal moest worden gemaakt. Op de dag dat Naugthon zijn baan bij Sun zou opzeggen, deed de laatste hem een aanbod dat hij niet kon weigeren. Hij moest, samen met de beste programmeurs voorhanden, een programmeertaal ontwikkelen die met ieder besturingssyteem kon werken, Zijn enige opdracht was:’Make Something Cool’. Nadat Patrick Naughton deze opdracht gekregen had, ging hij samen met James Gosling aan het werk om een kleine programmeertaal te ontwikkelen die gebruikt kon worden om kleine elektronische toestellen te programmeren, zoals bijvoorbeeld microgolfovens en videorecorders. Deze eerste vorm van software kwam tot stand door de bestaande elektronische apparaten te ontleden en de software daarvan in kaart te brengen. Als gevolg hiervan ontwikkelde het team een reeks elektronische producten die het logo “Duke”-logo kregen. Aangezien elektronische toestellen intern niet veel rekenkracht en geheugen bezitten, moest de programmeertaal efficiënte en tevens compacte code generen. Omdat fabrikanten verschillende CPU’s kunnen kiezen voor hun apparaten, mocht het ontwerp van de programmeertaal niet te dicht aanleunen bij een bepaalde architectuur. Het project kreeg de codenaam “Green”.

Figuur 1: Duke




6

De ontwikkelaars baseerden zich op een al bestaand concept dat in het verleden al was toegepast in de programmeertaal UCSD Pascal. Niklaus Wirth was één van de grondleggers van dit model. De idee was een hypothetische machine te ontwerpen. Deze machine heeft net zoals elke andere computerarchitectuur een bepaalde instructieset. Je zou kunnen denken dat zo een hypothetische machine louter en alleen een conceptuele functie heeft die vervolgens gebruikt wordt door leerkrachten informatica en ingenieurs. Maar het is in feite de sleutel naar platformonafhankelijkheid. Stel dat een compiler code genereert voor deze virtuele machine, dan zou in principe een implementatie van deze virtuele machine het programma kunnen uitvoeren. Het is nogal voor de hand liggend dat een implementatie hiervan in hardware in eerste instantie moeilijk is, maar een softwarematige implementatie is ideaal en tevens zeer stabiel. De voorwaarde dat een programma geschreven in de hypothetische machinetaal op een bepaald platform uitvoerbaar is, is dat er op dit platform een ‘simulatie’ moet zijn van deze hypothetische machine. Een softwarematige implementatie van een hypothetische machine wordt een interpreter genoemd. Voor deze platformonafhankelijkheid moet je echter wel een hoge tol betalen, het is namelijk niet zo performant. Elke machineinstructie wordt in feite tweemaal uitgevoerd: één keer door de virtuele machine (software) en één keer door de onderliggende hardware. De keuze is aan de ontwikkelaar. Moet een programma performant zijn of moet het probleemloos op uiteenlopende platforms uitvoerbaar zijn? Het moet echter wel gezegd worden dat er technieken bestaan om dit grote nadeel tot een minimum te beperken. Voor de eigenlijke uitwendige vorm van de programmeertaal baseerden de ontwikkelaars van Sun zich op C++ (dit is waarschijnlijk te wijten aan hun Unix achtergrond). Ze maakten de taal objectgeoriënteerd. Gosling doopte de taal “Oak”. Ze realiseerden zich echter dat Oak een naam is van een bestaande programmeertaal en veranderden de naam in Java. In 1992 leverde het Green project een eerste stuk dat “*7” heette. Het was een zeer intelligent controlesysteem. Maar niemand bij Sun was geïnteresseerd om deze technologie uit te werken voor verkoop. Dus het Green team moest een nieuwe weg zoeken om de technologie te verkopen. Ook in de elektronica-industrie was er geen enkele belangstelling voor. Het team probeerde vervolgens een contract binnen te halen om een TV applicatie te ontwerpen dat nieuwe TV diensten kon verwerken zoals video op vraag. Maar tevergeefs … Het Green project heeft heel 1993 en de helft van 1994 gezocht naar mensen die de technologie wilden kopen, maar niemand was geïnteresseerd. Terwijl deze wanhoopspogingen gedaan werden bij Sun, werd een huidig belangrijk deel van het Internet, meer bepaald het World Wide Web steeds groter en groter. De toegang tot het Web wordt gerealiseerd door een browser die de HTML codes vertaalt naar een visuele voorstelling. In 1994 gebruikten de meeste mensen de niet commerciële web browser Mosaic, die ontwikkeld werd in 1993 door het informaticadepartement van de Universiteit van Illinois. Gosling en zijn medewerkers realiseerden zich dat ze een fantastische browser konden ontwikkelen. De technologie die het resultaat was van het Green project, konden ze gebruiken om belangrijke aspecten van een client/server applicatie af te handelen. Aspecten zoals betrouwbaarheid, platformonafhankelijkheid, veiligheid, real-time verwerking zijn misschien niet zo belangrijk in een werkstationomgeving maar des te meer in een client/server omgeving. Dus ze ontwikkelden de browser.




7

In werkelijkheid werd de browser geprogrammeerd door Patrick Naughton en Jonathon Payne en evolueerde naar de huidige HotJava browser. De HotJava browser was geschreven in Java om te pronken met de kracht van een technologie die nu bekend is als applets. Dus ze maakten de browser in staat om de Java bytecodes te interpreteren. Deze browser leverde het bewijs dat de door het Green project geleverde technologie wel degelijk de moeite is. Dit is één van de factoren waarom Java tegenwoordig populair is.

Figuur 2: HotJava browser

De grote doorbraak van Java kwam in de herfst van 1995, wanneer Netscape besliste om de Java technologie toe te voegen aan de volgende uitgave van Netscape Navigator (versie 2.0). Netscape 2.0 werd uitgegeven in januari van 1996. Bedrijven zoals IBM, Symantec, Inprise en vele anderen verwierven een licentie op Java. Zelfs Microsoft ging Java ondersteunen. Internet Explorer ondersteunt Java en standaard is bij Windows een JVM (Java Virtual Machine) meegeleverd. Microsoft heeft een ontwikkel-tool die Visual J++ heet. De syntax van de taal en de belangrijkste bibliotheken (zoals Strings, Utilities, netwerken, multithreading, …) komen vrijwel helemaal overeen met de Java specificatie. Maar de bibliotheken voor gebruikers interfaces en “remote acces” zijn compleet verschillend. Sun bracht de eerste versie uit in het begin van 1996. Versie 1.02 werd enkele maanden later uitgebracht. Maar Java 1.02 was eigenlijk niet volwassen genoeg om serieuze applicaties te bouwen (je kon zelfs niet printen in Javac1.02). De eerste maanden zagen troebel met het oog op de toekomst van Java. Maar de grote doorbraak kwam in mei 1996 toen de JavaOne conferentie gehouden werd. Op JavaOne maakte Sun Microsystems de toekomstplannen van Java bekend. Ze waren van plan om een hele reeks verbeteringen aan te brengen en nieuwe code bibliotheken toe te voegen. Velen vreesden dat deze verbeteringen jaren zouden duren, maar Sun heeft de beloftes vrijwel allemaal waargemaakt in Java 1.1 en in een verrassend korte periode. De grote aankondiging op de JavaOne conferentie van 1998 was de aankomende versie 1.2. In deze versie werd de toch wel ondermaatse AWT aan de kant gezet door Swing. De slogan van Sun “Write once, run everywhere” werd nu werkelijkheid. Drie dagen na de uitgave van Java 1.2 in december werd de naam veranderd in Java 2. Hogeschool Limburg 2002-2003-06-09



8

2.2 Voor- en nadelen van Java 2.2.1 Taalkenmerken Java is zoals al eerder gezegd gebaseerd op de syntaxis van C++. Deze syntaxis is zeer beknopt en biedt dus de mogelijkheid om met een beperkt aantal kleine elementen een grote functionaliteit te bekomen. Qua syntaxis hebben C++ programmeurs geen enkele moeite om de overstap te maken naar Java mits enkele subtiele verschillen. Ze moeten echter niet overmoedig worden, want Java is wel degelijk een compleet andere programmeertaal. Veel programmeurs die geen C/C++ achtergrond hebben, moeten meestal een tijdje wennen en vinden de syntaxis redelijk vervelend. Dit is natuurlijk louter een gewoonte. De ontwerpers van Java hebben zich eerst afgevraagd wat veel voorkomende fouten zijn in C++. Hier worden niet de fouten bedoeld te wijten aan het intellectuele vermogen van de programmeur, maar wel de impliciete foutjes die iedereen maakt en die vooral te wijten zijn aan de taal zelf. Deze foutjes kunnen het leven van een programmeur heel onaangenaam maken, omdat ze soms pas willekeurig aan het licht komen. Enkele schattingen zeggen dat gemiddeld elke 50 lijnen C++ code een bug bevat. Jammer genoeg hebben de ontwerpers van Java bepaalde C elementen zoals het switch statement niet verbeterd. Een overzicht van de meest voorkomende bugs die Java verhelpt. 2.2.1.1 Geheugenallocatie In Java is er in tegenstelling tot C++ geen manuele geheugenallocatie en –deallocatie. In C++ is de programmeur dus zelf verantwoordelijk om dynamisch gealloceerde geheugengebieden weer vrij te geven. Gebeurt dit niet, dan zal het geheugengebied gereserveerd blijven tot het programma eindigt. De gereserveerde geheugengebieden waarheen geen verwijzing meer naar bestaat, wordt de (welbekende) garbage collection genoemd. Java echter maakt gebruik van een Garbage Collector die de objecten waarheen geen verwijzing meer bestaat, automatisch verwijdert uit het geheugen. De programmeur moet zich dus nooit ontfermen over geheugenallocaties en –deallocaties van Java-objecten. 2.2.1.2 Pointers In C++ bestaan er pointers die gebruikt worden voor arrays en strings (hiermee bedoelen we niet de String class). Pointers zijn zeer gevaarlijk want ze kunnen naar een willekeurig geheugengebied verwijzen. Iedere C++ programmeur heeft wel eens kennis gemaakt met de volgende (gevaarlijke) pointer berekening: char c[10]; for(int i=0; i<=10; i++) c[i] = i;

Deze code zal probleemloos uitvoerbaar zijn (de compiler geeft helemaal geen error). De bug zou mogelijk, stilzwijgend kunnen voortbestaan. De fout kan nu en dan eens opduiken en ga dan maar eens zoeken. Een naald in een hooiberg. In Java kan je misschien niet expliciet gebruik maken van pointers, maar je hebt wel de kracht van pointers ter beschikking. Dit wordt mogelijk gemaakt door te werken met referentievariabelen. Intern maakt Java wel gebruik van pointers, maar als programmeur merk je er niets van. Je kan dus ook nooit (toevallig) een verkeerd geheugengebied verkeerd aanspreken. Als je bij de uitvoering van een programma een index buiten de grenzen van een array laat gaan, krijg je een ArrayIndexOutOfBoundsException en vervolgens wordt je programma netjes afgesloten. Hogeschool Limburg 2002-2003-06-09



9

2.2.1.3 Logische testen Java heeft een boolean data type dat altijd gebruikt wordt om bepaalde condities te testen. Statements zoals if en while accepteren alleen boolean datatypes. De volgende (gevaarlijke) C++ code if(i = 1) … zal niet eens compileren in Java. Je moet een test dus altijd voluit schrijven. 2.2.1.4 Overerving Een Java klasse kan telkens maar van één superklasse worden afgeleid. In C++ echter, kan een klasse meerdere directe superklassen hebben, wat soms tot dubbelzinnige situaties leidt. De programmeur moet een aantal regels beheersen om deze dubbelzinnige situaties te herkennen. Het probleem is dat de dubbelzinnigheden vaak leiden tot impliciete fouten in de code. In Java heeft men daarom multiple inheritance geëlimineerd en vervangen door interface. Een klasse kan dus wel meerdere interfaces tegelijk implementeren. Interfaces vormen een belangrijk onderdeel van objectoriëntatie in Java. Ze scheiden de implementatie van de functionaliteit. 2.2.1.5 Initialisaties Elke lokale variabele moet altijd geïnitialiseerd worden vooraleer deze kan gebruikt worden. Lokale variabelen in C++ krijgen altijd een willekeurige waarde, wat de compiler stilzwijgend accepteert. Klassevariabelen worden altijd van een standaardwaarde voorzien bij het opstarten van het programma. Je kan je natuurlijk afvragen of dit ook een potentieel gevaar betekent. De meningen hierover zijn waarschijnlijk verschillend.

2.2.2 Objectgeoriënteerd Java is een volledige objectgeoriënteerde taal (zelfs meer dan C++). Alles in Java, behalve de primitieve typen (int, long, float, …) is een object. Je kan geen enkele regel eigen code schrijven zonder deze in te kapselen in een klasse. Objectoriëntatie heeft de laatste 30 jaar zijn nut bewezen en daarom zou het onbegrijpelijk zijn als een moderne programmeertaal zoals Java dit niet zou bieden.

2.2.3 Distributed Java heeft een uitgebreide bibliotheek met routines om netwerk toepassingen te schrijven die gebaseerd zijn op het TCP/IP protocol. Java programma’s kunnen via URL’s objecten aanspreken over het hele Internet met hetzelfde gemak als een bestand laden vanaf de eigen harde schijf. De Java netwerkmogelijkheid om CGI scripts te vervangen door servlets wat “server side processing” vereenvoudigd. De servlets zullen de CGI scripts niet onmiddellijk vervangen, maar de meeste populaire web servers bieden ondersteuning voor servlets. Het voordeel van een servlet ten opzichte van een CGI script is dat servlets puur Java zijn en dus ook platformonafhankelijk, wat niet altijd gezegd kan worden van een CGI script dat bijvoorbeeld in Perl geschreven is. Java heeft ook een aantal mogelijkheden om gedistribueerde applicaties te schrijven. Dit kunnen pure Java oplossingen zijn door gebruik te maken van RMI en object serialisatie. Maar het is ook mogelijk dat Java objecten met objecten uit een andere programmeertaal communiceren via CORBA. Hogeschool Limburg 2002-2003-06-09



10

2.2.4 Robuust Java heeft als doel programma’s te schrijven die betrouwbaar zijn in vele opzichten. Daarom zal de compiler zo vroeg mogelijk errors proberen te detecteren. Zelfs tijdens de uitvoering van het programma worden er een aantal zaken zoals array indexen, null pointers, object casts,… gecontroleerd. Het grootste voordeel is waarschijnlijk dat Java een pointer model bezit dat het onmogelijk maakt om het geheugen op een verkeerde manier aan te spreken. Als er iets mis gaat gedurende de uitvoering van het programma, dan kan de JVM het programma netjes afsluiten. Het systeem zal bijna nooit crashen, wat toch wel een heel groot voordeel is. Dus zowel de compiler als de JVM maken van Java een robuuste programmeertaal.

2.2.5 Veilig Java is een taal met als grote doelstelling gedistribueerde en netwerk programma’s te schrijven. Daarom moest er een veiligheidsmechanisme ingebouwd worden. Dit mechanisme is ingebouwd in het Java platform zelf. Aan applets kunnen permissies toegewezen worden. Applets zijn programma’s in webpagina’s die zonder controlemechanisme wel eens je hele systeem (opzettelijk) om zeep zouden kunnen helpen. Betrouwbare applets kan men meer toegang tot bepaalde systeembronnen verlenen. Over het algemeen kan je zeggen dat Java de privacy van een netwerkgebruiker beschermt door lokale informatie zoals bestanden en systeemgegevens af te schermen van buitenaf. Programma’s die uitgevoerd worden door de JVM kunnen ook geen geheugen aanspreken buiten de JVM. Men noemt deze beveiligingen in het jargon het “sandbox” model. De JVM vormt een soort beschermende schil rond de programma’s zodat toepassingen met slechte bedoelingen geen kans maken.

2.2.6 Platformonafhankelijkheid Java heeft geen implementatie afhankelijke eigenschappen zoals C en C++ dat wel hebben. Het gedrag van elke Java code is tot in de puntjes gedefinieerd. In C is de implementatie van bijvoorbeeld een integer platformonafhankelijk. Elk Java programma zal zich op elk systeem hetzelfde gedragen. De slogan van Sun is “Write once, run everywhere”. Als je aan een C++ programmeur vraagt of zijn toepassing zonder problemen zal draaien op een ander systeem dan dat waarop het oorspronkelijk ontwikkeld is, dan zal deze toch wel een aantal bedenkingen hebben. Java programmeurs liggen daar zeker geen nachten van wakker omdat Java van nature uit platformonafhankelijk is. Java heeft een enorme run-time bibliotheek die je in staat stelt om dezelfde code ongewijzigd te gebruiken onder Windows 95/98/NT/Me/2000/XP, Solaris, Unix, Macintosh,… Dit is broodnodig om Internet applicaties te bouwen. Het moet wel gezegd worden dat Java implementaties op andere platforms dan Windows en Solaris achterop lopen. De Java compiler genereert een platformonafhankelijk bestandsformaat. Dus een .class bestand is uitvoerbaar op elke computer die Java ondersteunt.




11

2.2.7 Hoge prestaties De Java bytecodes worden uitgevoerd door een interpreter en de performantie hiervan is vrij behoorlijk. Maar een hoge uitvoeringssnelheid van de code is meestal wel vereist. Dit wordt gerealiseerd door gebruik te maken van JIT (Just In Time) systemen. Deze systemen gaan de bytecodes van sommige delen van het programma vertalen naar native machine code. De JVM gaat bepaalde programmadelen die veel worden uitgevoerd observeren en de nodige optimalisaties uitvoeren. Vooral de uitvoering van loops gaat enorm vooruit. Benchmarks tonen aan dat huidige Java programma’s soms sneller zijn dan C++! Als je echt “tot op het metaal” wil gaan qua performantie, kan je gebruik maken van native compilers. Dit type compiler vertaalt Java bron code of zelfs .class bestanden naar native machinetaal. Niet alleen de uitvoeringssnelheid is belangrijk, maar ook de compactheid van het hele Java systeem. Java moest oorspronkelijk in staat zijn om op kleine machines helemaal alleen te draaien. De grootte van de basis interpreter is ongeveer 40K. De standaard bibliotheken voegen hier nog een 175K aan toe. Dus een uitvoerbare Java omvat een ruime 200K. Merk wel op dat de GUI bibliotheken aanzienlijk groter zijn.

2.2.8 Multi threaded Threads zijn standaard ingebouwd in het Java platform in tegenstelling tot andere programmeertalen die thread ondersteuning moeten halen uit externe bibliotheken. Threads worden in Java behandeld (hoe kan het ook anders) als objecten. Java threads kunnen gebruik maken van multiprocessor systemen zoals het onderliggende besturingssysteem hier ook gebruik van maakt. Een nadeel hiervan is dat de implementatie en dus ook het gedrag verschillend is op verschillende platforms.

2.2.9 Publiek toegankelijk (open source) Informatie omtrent de Java specificatie is overal beschikbaar. De hele opbouw van het systeem is toegankelijk voor iedereen. Het voordeel hiervan is dat bugs in het Java platform veel vlugger gevonden worden. Sun heeft er goed aan gedaan om deze informatie vrij beschikbaar te stellen, aangezien zij nu veel vlugger feedback krijgen over hun product, wat natuurlijk voordelig is voor de hele Java gemeenschap. De meeste informatie over Java vind je natuurlijk op het Internet, dat eigenlijk te vergelijken is met “één grote discussiërende Java smeltkroes”.

2.2.10 Internet en intranet Op het gebied van netwerkapplicaties zijn applets een groot voordeel ten opzichte van HTML en de afkooksels hiervan. Een scripttaal kan nooit de functionaliteit van een echte programmeertaal bieden. Het concept van netwerkcomputers zal meer en meer gebruikt worden, omdat het vele onmiskenbare voordelen heeft t.o.v stand alone PC’s die eventueel met een netwerk verbonden zijn. Een netwerk PC laadt de software van een centrale server. De systeembeheerder hoeft alles maar op één plaats te installeren en te beheren. Applets zijn een ideale technologie voor dit soort toepassingen. Het schrijven van applets die uitvoerbaar zijn op het Internet is vrij moeilijk omdat browsers de Java technologie niet altijd Hogeschool Limburg 2002-2003-06-09



12

op de voet volgen. Applets zijn echter zeer geschikt om intranetten in bedrijven tot leven te wekken, aangezien deze systemen goed controleerbaar zijn.

2.3 Java netwerkprogrammering De player en de proxy-server van ons project maken gebruik van een betrouwbare TCP connectie. In Java wordt een TCP verbinding gerealiseerd door gebruik te maken van sockets. De netwerk classes bevinden zich in de package java.net.

2.3.1 Wat zijn sockets? Een socket is het eindpunt van een communicatie over een netwerk tussen twee programma’s. Dus sockets representeren de communicatie tussen een client en een server. Een server gaat op een bepaalde poort luisteren en wacht tot een client connecteert. Een client kent het adres van de server en de poort waarop de server luistert. Vervolgens kan de client proberen te connecteren met de server.

Figuur 3: Connectie aanvraag tussen sockets

Als alles goed gaat, accepteert de server de client en wordt er een socket gecreëerd. De server gaat de client-connectie echter omleiden naar een andere poort, zodat andere clients ook kunnen connecteren met de server op de oorspronkelijke poort.

Figuur 4: Opzetten van de client-connectie

Als de client succesvol geconnecteerd is met de server wordt er hier ook een socket gecreëerd. De client en server kunnen nu met elkaar gaan communiceren via sockets. De Socket klasse biedt een platformonafhankelijke manier om netwerkapplicaties te bouwen. Alle details van de netwerk hardware en software worden verborgen voor de programmeur. De ServerSocket klasse wordt door servers gebruikt om op een bepaalde poort te luisteren om clients te accepteren door sockets te creëren. In de volgende twee hoofdstukken worden voorbeelden gegeven van hoe je een minimale client en server applicatie maakt in Java.




13

2.3.2 Een minimale client Dit voorbeeld stuurt een boodschap naar een server en toont het antwoord op het scherm. De connectie wordt vervolgens verbroken. De werkwijze van de client is altijd: 1. een socket openen 2. input en output streams openen 3. communiceren met de server 4. streams sluiten 5. socket sluiten import java.io.*; import java.net.*; public class Client { public static void main (String [] args) { Socket socket = null; PrintWriter out = null; BufferedReader in = null; try { socket = new Socket(“test”, 80); out = new PrintWriter(socket.getOutputStream(),true); in = new BufferedReader(new InputStreamReader( socket.getInputStream())); out.println(“Client connection”); System.out.println(in.readLine());

}

}

in.close(); out.close(); socket.close(); } catch (UnknownHostException e) { System.err.println(“verkeerde host!”); } catch (IOException e) { System.err.println(“stream error”); }

Als je een input of output stream sluit, dan wordt de connectie automatisch verbroken.




14

2.3.3 Een minimale server De server in dit voorbeeld is multithreaded en kan dus probleemloos connecteren met meerdere clients tegelijk. import java.io.*; import java.net.*; public class Server implements Runnable { private Socket socket; public Server(Socket s) { Socket = s; } public void run() { Socket socket = null; PrintWriter out = null; BufferedReader in = null; try { out = new PrintWriter(socket.getOutputStream(), true); in = new BufferedReader(new InputStreamReader( socket.getInputStream())); System.out.println(in.readLine()); out.println(“server connection”);

}

in.close(); out.close(); socket.close(); } catch (IOException e) { System.err.println(“steam error”); }

public static void main(String [] args) { try { ServerSocket serverSocket = new ServerSocket(8080); while(true) { Socket s = serverSocket.accept();

}

}

new Thread(new Server(s)).start(); } } catch(Exception e) { e.printStackTrace(); }




15

3 Gebruikte tools 3.1 Linux 3.1.1 Geschiedenis van Linux In 1991 was de Finse student Linus Torvalds van mening dat er geen ernstig besturingssysteem bestond. Hij besloot zelf een nieuw besturingssysteem te schrijven met Minix in zijn achterhoofd, een heel eenvoudig besturingssysteem dat gebruikt werd om de werking van besturingssystemen uit te leggen. Linus zette zijn creatie op het netwerk van de universiteit waar hij studeerde en moedigde iedereen aan om het te downloaden, te gebruiken, verder te ontwikkelen en weer terug te uploaden zodat anderen van die ontwikkelingen konden genieten. Linus eiste wel van alle medeontwikkelaars dat ze zijn creatie ontwikkelden volgens de Posix besturingssysteem standaard en dat het gratis beschikbaar moest blijven. Zo is Linux ontstaan. De naam heeft Linus niet zelf verzonnen. Iedereen vond dat het Linux moest heten, omdat Linux zijn loginnaam was op de universiteit. Linux was in het begin duidelijk alleen iets voor de echte fanatiekelingen die goed konden programmeren en het niet erg vonden om met iets nieuws en onstabiels te experimenteren. Tegenwoordig is het voor iedereen die wel eens wat nieuws wil proberen en alle problemen rond Windows moe is of gewoon meer uit zijn/haar computer wil halen. Je kan Linux ook goed gebruiken voor een bedrijfsnetwerk als simpele file- en printserver, of als router/gateway/firewall om het intranet aan het Internet te hangen, als mail/web/ftp server of gewoon alles in 1. Linux lijkt op Unix en als je met het ene systeem weet om te gaan, dan is het andere ook geen probleem. Toch is het niet helemaal hetzelfde. Unix bestaat namelijk al een tijd langer dan Linux en draagt daardoor ook de last van de geschiedenis mee, doordat nieuwe versies iedere keer “downward compatible” moesten zijn, dit wil zeggen dat het de reeds bestaande functionaliteit moet blijven ondersteunen. Hetzelfde probleem maakt Windows traag en onstabiel omdat het compatibel moet blijven met DOS en 16 bit programma’s. Windows NT is wat dat betreft een verbetering. Linux is ook een stuk lichter dan Unix, en draait bovendien voornamelijk op Intel compatibele machines, terwijl Unix voornamelijk op Alpha en Sparc machines draait. Linux wordt mede daardoor veel gebruikt als web- en mailserver bij providers.

Figuur 5: Mandrake Linux 9.0




16

3.2 IntelliJ IDEA

3.2.1 Omschrijving IntelliJ is een ontwikkeltool (Integrated Development Environment) ontworpen door Idea dat is uitgerust met de laatste ontwikkelingen zoals bijvoorbeeld: ondersteuning voor refactoring, intelligente hulp bij het coderen, geïntegreerde CVS (zie volgend hoofdstuk), mogelijkheid om op een gemakkelijke manier API’s te implementeren en nog vele andere mogelijkheden om het programmeren plezierig te maken. Hun motto is dan ook: “Develop with Pleasure”.

Figuur 6: IntelliJ IDEA




17

3.2.2 Intelligente en gebruiksvriendelijke Java editor Er zijn een hele hoop redenen waarom we IntelliJ een intelligente en gebruiksvriendelijke Java editor kunnen noemen, in de volgende secties zullen we er een aantal aanhalen. 3.2.2.1 Code voltooiing Daar IntelliJ ontwikkeld is om het ontwikkelen sneller te laten verlopen verleent deze tool een soort virtuele derde hand om je te helpen bij het schrijven van veel gebruikte syntaxis, methodenamen, klassenamen en variabelennamen. Er bestaan drie verschillende manier om aan code voltooiing te doen, namelijk: 1. Standaard (Ctrl + Spatie) Aanvullen van één of meer karakters van onder andere klassenamen, methodes en variabelennamen.

Figuur 7: Code voltooiing 1

Indien nu Ctrl + spatie wordt gedaan wordt het volgende bekomen.






18

2. Smart Type (Ctrl + Shift + Spatie) Hiermee kan je een keuze maken uit een lijst met acties die op deze plaats in de code mogelijk zijn en wordt zo automatisch aangevuld.


Resultaat:


3. Klassenaam (Ctrl + Alt + Spatie) Aanvullen van klassenamen.


Resultaat:





19

3.2.2.2 Import assistentie Bij het gebruik van een nieuwe klasse zal automatisch de mogelijkheid worden gegeven om met Alt + Enter een import bovenaan het bestand toe te voegen. Dit zal tevens gebeuren wanneer er code van het ene bestand naar het andere wordt gekopieerd.

Figuur 14: Import assistentie 1

Resultaat:

Figuur 15: Import assistentie 2

3.2.2.3 Coderings assistentie Soms kan het gebeuren dat er je een methode kan worden gebruikt die je nog moet schrijven. Indien je hier dan de methodenaam voor schrijft, zal er automatisch een mogelijkheid worden gegeven om deze methode toe te voegen. Dit werkt als volgt:

Figuur 16: Coderings assistentie 1

Resultaat:

Figuur 17: Coderings assistentie 2




20

3.2.2.4 Implementatie van interfaces Bij het implementeren van interfaces moeten de methodes van deze interfaces ook geïmplementeerd worden. Dit kan simpel met de toetsencombinatie Ctrl + I of door een keuze te maken in het lijstje dat je bekomt door op het lampje te klikken.

Figuur 18: Implementatie van interfaces 1


Resultaat:





21

3.2.3 Besluit IntelliJ is een erg intelligente en gebruiksvriendelijke ontwikkeltool die het ontwikkelen echt wel sneller laat gaan. In het begin is het natuurlijk altijd even wennen, maar na een tijdje krijg je al de sneltoetsen onder de knie dankzij de “Tip of the day” venstertjes die je iedere keer bij het opstarten krijgt en gaat het allemaal erg vlot. Wij hebben er in ieder geval veel plezier aan beleeft.




22

3.3 Concurrent Versions System (CVS) CVS is een version control system. Door het te gebruiken kan je de historiek van de bronbestanden bijhouden. Bugs kunnen bijvoorbeeld in de software binnendringen wanneer ze gewijzigd wordt en pas na verdere wijzigen terug opduiken. Door middel van CVS kan je gemakkelijk oude versies ophalen om te zien welke veranderingen de bug tot stand heeft gebracht. Je kan natuurlijk ook elke versie van elk bestand dat je ooit hebt gemaakt opslaan met als gevolg dat veel ruimte op de harde schijf zal worden ingenomen. CVS daarentegen slaat alle versies van een file op in 1 enkel bestand. Enkel de verschillen tussen versies worden opgeslagen. Het is ook een handig hulpmiddel wanneer je met verschillende personen aan 1 project werkt. Elke persoon werkt in zijn eigen directory en CVS voegt het werk samen wanneer de programmeurs gedaan hebben. Hierdoor kunnen twee mensen hun veranderingen aan een project nooit overschrijven. In 1986 schreef Dick Grune een hoop shell scripts waaruit CVS ontstond. Hoewel vandaag geen enkele code van deze shell scripts nog aanwezig is in CVS, stammen de meeste conflictoplossingsalgoritmes er nog steeds van af. In april 1989 ontwierp en schreef Brian Berliner CVS. Brian werd wat later geholpen met het ontwerp en verkoop van zijn product door Jeff Polk.

Figuur 21: CVSWeb bij Beta9




23

3.4 The Jakarta Project Het doel van het Jakarta Project is om een commerciële kwaliteit server oplossing aan te bieden op basis van het Java platform en die ontwikkeld is in een open en coöperatieve manier. Jakarta is het grote project voor vele kleine zoals bijvoorbeeld, Ant, log4j, Junit, en andere.

3.4.1 Ant Ant is een build tool gebaseerd op Java. Waarom een andere build tool kiezen als er al make, gnumake, nmake, jam en andere zijn? De reden hiervoor is dat de andere build tools limieten hebben. Make-like tools zijn gebaseerd op shell, zij evalueren een set van onafhankelijkheden en voeren dan commando’s uit. Dit betekent dat je deze tools gemakkelijk kan uitbreiden door een programma te schrijven in het besturingssysteem waar je op werkt. Hoewel dit ook betekent dat je jezelf limiteert tot het besturingssysteem. Makefiles zijn dus geen goede keuze, omdat ze gebaseerd zijn op shell. Ant is anders. In plaats van een op shell commando’s gebaseerd model gebruikt Ant Java classes. Tevens wordt er in plaats van gebruik te maken van shell commando’s een buildfile geschreven in XML code: build.xml. Deze file bestaat onder andere uit targets die men kan aanroepen om de verschillende taken uit te voeren. Hoe ziet een buildfile er uit? Iedere buildfile begint met een project tag. <project name="LoadTestRecorder" default="run-client" basedir="."> ...

De project tag bevat de volgende attributen: 1. name : Dit is de naam van het project 2. default : Dit is het target dat standaard zal worden uitgevoerd 3. basedir : Dit is het pad vanaf waar de targets worden uitgevoerd Een target ziet er als volgt uit:

De attributen zijn de volgende: 1. name : Dit is de naam van het target 2. depends : Hiermee wordt bepaald welke target moet worden uitgevoerd voor de huidige target mag worden uitgevoerd.




24

Naast deze tags heb je ook nog: • <property file = “properties filenaam”> Deze tag duidt het bestand aan waarin je de eigenschappen voor het project kan specificeren. • <property name = “property naam” value = “waarde van de property”> Deze tag wordt gebruikt om variabelen te specificeren die zullen worden gebruikt in de buildfile. • <path id = “std.classpath”> Deze tag specificeert het classpath en bevat de <pathelement>-tag met als attribuut ofwel path, dat een directory aanduidt, ofwel location, dat een bestand, jar-file, … aanduidt. Binnen de targets kan men verschillende taken zetten zoals bijvoorbeeld: mkdir, javac, java, jar, … Elk van deze taken kan meerdere attributen hebben.

3.4.2 Log4j Bijna elke grote applicatie bevat zijn eigen logging en tracing API. In overeenstemming met deze regel, had het E.U. Semper project in 1996 beslist zijn eigen API tracking te schrijven. Na verschillende veranderingen en veel werk is de API geëvolueerd naar log4j, een heel populair pakket voor Java logging, dat wordt verdeeld door Apache. Log4j heeft drie componenten: categorieën, appenders en lay-outs. Deze drie soorten van componenten werken samen om het de ontwikkelaars mogelijk te maken log boodschappen naar gelang van de prioriteit en het type te bekijken. Het toevoegen van log statements in de code is een low-tech methode om te debuggen en meestal ook de enige manier, omdat de debuggers meestal niet beschikbaar zijn. Dit heeft echter ook zijn nadelen. Eén van deze nadelen is dat het de applicatie kan vertragen. Om dit nadeel te verlichten is log4j ontwikkeld om snel en flexibel te zijn. Het hoofddoel van log4j is om het gemakkelijk te begrijpen en het simpel te gebruiken. Het grote voordeel van loggen in de plaats van een gewone System.out.println(), is dat bij loggen de mogelijkheid is voorzien om sommige log statements even af te zetten. Dit kan allemaal zonder de broncode van de applicatie te wijzigen.

3.4.3 JUnit JUnit is een framework dat speciaal ontwikkeld werd om code tijdens de ontwikkelingsfase te testen. Volgens Gamma en Beck, de auteurs van JUnit, levert het simultaan uitwerken van testen en het ontwikkelen van code een groot voordeel op. Op het eerste zicht lijkt het uitwerken van testen eerder tijdverlies, maar uiteindelijk gaat het ontwikkelen zelf veel sneller omdat de code altijd getest kan worden en fouten onmiddellijk zichtbaar worden. Het debuggen wordt dus ook veel gemakkelijker en zal veel sneller gaan. JUnit testen worden gegroepeerd in test suites. De klassen die de test methodes bevatten moeten subklassen zijn van TestCase. De TestCase implementatie bevat een suite() methode die een Test object aflevert met daarin meestal een TestSuite die alle testen in de klasse groepeert.




25

Dit kan op verschillende manieren verwezenlijkt worden. Namelijk op een statische manier of door gebruik te maken van Reflection. Deze laatste manier is het makkelijkste: alle methodes in de opgegeven klasse die beginnen met ‘test’ worden dan automatisch aan een TestSuite object toegevoegd. Voor elke test wordt de setUp() methode uitgevoerd (deze bevindt zich ook in de TestCase implementatie). In deze methode kunnen een aantal objecten geïnstancieerd worden die in elke test van de suite gebruikt worden. Na elke test wordt de tearDown() methode uitgevoerd om eventueel objecten op te ruimen (bv. het sluiten van een stream). 3.4.3.1 Simpel voorbeeld van een JUnit test Stel dat we als voorbeeld het String object willen testen en meerbepaald de equals() methode. Er wordt dan een TestCase gemaakt waarin in de setUp() methode 3 strings worden aangemaakt, 2 dezelfde en 1 andere. in de methode testStringEquals wordt dan de equals methode aangeroepen. Indien de equals methode met de gelijke string niet ‘true’ teruggeeft, dan faalt de test. Net zoals indien de equals methode met de verschillende string niet ‘false’ teruggeeft. import junit.framework.*; public StringTest extends TestCase { private String s1, s2, s3; public StringTest() { } public static Testsuite() { return new TestSuite(StringTest.class); } public s1 s2 s3 }

}

void setUp() { = “test1”; = “test1”; = “test2”;

public void testStringEquals() { assertTrue(“equals methode faalt bij gelijke strings” ,s1.equals(s2)); assertTrue(“equals methode faalt bij ongelijke strings” ,!s1.equals(s3)); }

De assertTrue() statements verzekeren dat een bepaalde expressie waar is, anders faalt de test en wordt de boodschap (die meegegeven wordt als 1ste parameter) afgedrukt. Het uitvoeren van deze test kan op verschilllende manieren gebeuren. JUnit voorziet in een tekstgebaseerde omgeving en 2 grafische omgevingen (AWT en SWING). De tekstgebaseerde interface is handig om in batch programma’s te gebruiken, bv. om de testen elke dag op een bepaald tijdstip uit te voeren. De grafische interfaces zijn iets makkelijker in het gebruik en de SWING UI biedt ook de mogelijkheid om door de testsuites te bladeren en elke test afzonderlijk uit te voeren.




26

De grafische interface ziet er voor zowel AWT als SWING als volgt uit:

Figuur 22: JUnit - AWT

Figuur 23: JUnit - Swing

3.4.3.2 Toevoegen van een test Op de bovenstaande manier is het heel makkelijk om een test toe te voegen aan de suite. Het enige dat met gebeuren is een methode aan de StringTest klasse toevoegen die begint met ‘test’. Doordat het JUnit framework gebruik maakt van Reflection, is het niet nodig om de test apart toe te voegen in de suite() methode. Soms kan het echter nodig zijn om geen gebruik te maken van Reflection, bv. wanneer de performantie van de test belangrijk is. In zo’n geval moet er een TestSuite object gecreëerd worden waarin de testmethodes statisch worden toegevoegd.




27

4 Gebruikte technologieën 4.1 Hyper Text Transfer Protocol 4.1.1 Geschiedenis Het idee achter het HTTP-protocol waarmee clients en servers met elkaar praten, is ontwikkelt door mensen van het CERN (Europees Centrum voor Nucleair Onderzoek) in Geneve. Toen zei hun onderzoek over het delen van documenten tussen computers hadden afgerond, gaven ze het project over aan een Amerikaanse Universiteit (NSCA). De basis van het moderne World Wide Web is vervolgens ontworpen door andere Europeanen (en Fransozen in het bijzonder).

4.1.2 Wat is HTTP? HTTP, HyperText Transfer Protocol, is een protocol dat thuis hoort binnen de applicatielaag en wordt gebruikt voor gegevenstransport over het Web. HTTP is een geheel van regels die Web browsers en servers moeten naleven om informatie uit te wisselen. Hoewel de meeste mensen denken dat het HTTP-protocol enkel te maken heeft met het internet (World-Wide Web), kan en wordt het ook gebruikt voor andere doeleinden zoals gedistribueerde systemen om objecten te beheren.

4.1.3 Functionaliteit In grote lijnen kan de functionaltiteit van het HTTP-protocol als volgt worden beschreven: De client (dit is bijvoorbeeld een browser als Mozilla, Internet Explorer, Netscape, …) zal een vraag sturen over een TCP/IP verbinding die hij heeft aangemaakt. Vervolgens zal de betrokken web server die de vraag ontvangt een antwoord sturen, met daarin de gevraagde data.

Figuur 24: HTTP functionaliteit




28

4.1.4 Eigenschappen 4.1.4.1 De adresseer methode Het HTTP-protocol verwijst naar bestanden met behulp van ‘Universal Resource Identifiers’ (URI), dit zijn unieke verwijzingen naar een locatie (een URL), of een naam (URN). Bij het maken van een HTML hyperlink, bestaat de URL uit de algemene vorm: http://host:poort-nummer/path/file.html . Bij het ontwikkelen van http is er rekening gehouden met al bestaande protocollen, zodat het HTTP-protocol ook toegang heeft tot en kan communiceren met al bestaande protocollen als SMTP en FTP zonder dat daarbij data verloren gaat. 4.1.4.2 Client-Server Architectuur Het HTTP-protocol maakt gebruik van een client-server architectuur en is een vraag/antwoord protocol. Dat wil zeggen dat de server nooit uit zichzelf wat zal gaan doen, maar pas reageert op een aanvraag van een client. Standaard vindt de communicatie van HTTP plaats over TCP/IP. Het standaard poortnummer dat gebruikt wordt is 80, maar er kunnen ook andere poortnummers gebruikt worden. Het programma dat de aanvraag van een Internet-pagina doet (de client), maakt een verbinding met de server. De client stuurt een aanvraag naar de server waarin de gebruikte methode, de URL, het gebruikt protocol en informatie over de client staan. De server stuurt dan een berichtje terug met daarin een statusregel, hierin staat de protocol versie en een code die aangeeft of er een fout is opgetreden of dat het goed is gegaan. Daarna volgt informatie over de server en daarna het eventuele antwoord op de aanvraag (bijv. het aangevraagde HTML document). Bij HTTP versie 1.0 is de verbinding tussen de server en de client altijd een ‘connectionless’ verbinding. Dit wil zeggen dat de verbinding niet continu wordt aangehouden. Telkens als aan een aanvraag van een client is voldaan wordt de verbinding weer verbroken. Elke aanvraag wordt dus behandeld als een nieuwe aanvraag en wordt niet in verband gebracht met andere aanvragen. Dit heeft tot gevolg dat een server is verlopen. Daartegenover staat wel het nadeel dat elk onderdeel van een web document (bijv. figuren in de tekst) door een aparte aanvraag behandeld wordt en dit levert wel wat extra ‘overhead’ (extra systeembronnen of capaciteit benodigd om een gebruikersproces te realiseren) op.




29

Bij HTTP versie 1.1 kan de verbinding naast ‘connectionless’ een ook ‘persistent’ verbinding hebben. Een ‘persistent’ verbinding heeft de volgende voordelen: • Door minder TCP connecties te openen en te sluiten wordt er CPU-tijd gespaard bij de routers en hosts (clients, servers, proxies, gateways, tunnels, of caches). • HTTP vragen en antwoorden kunnen met behulp van pipelining over de verbinding gaan. Bij pipelining wordt een proces in meerde fases opgedeeld en wordt het proces stap voor stap uitgevoerd. Zo kan een client meerdere vragen versturen zonder dat hij moet wachten op het antwoord, op deze manier wordt de TCP verbinding ook efficiënter gebruikt. • Netwerk congestie wordt verminderd door het aantal pakketten die voortkomen uit het opzetten van een TCP verbinding te verminderen. • De tijd die nodig is voor het opzetten van de client-server voor latere vragen valt weg. Om er voor te zorgen dat de server bij kan houden hoe een gehele sessie verloopt, is het mogelijk om bijvoorbeeld een uniek Identificatie-nummer aan een verbinding te geven. Door het verloop van een sessie op te slaan in een bestand (cookie) hoeft alleen maar het bijbehorende ID verstuurd te worden. Door dit ID kan de sessie door de server gevolgd worden. Een nadeel hiervan is wel dat de administratie van deze ID’s goed moet verlopen en af en toe zullen de bestanden waarin de sessies worden bijgehouden opgeruimd moeten worden. 4.1.4.3 HTTP maakt gebruik van MIME-types Door het gebruik van MIME-types (Multipurpose Internet Mail Extensions) kan http vrij gemakkelijk aangeven welk type data verstuurd wordt. Elk MIME-type specificeert een apart data-type, HTML bijvoorbeeld is van het MIME-type “text/html”. Hierdoor weet de ontvanger op welke manier de data geïnterpreteerd moet worden, want een HTML-bestand zal uiteraard op een andere manier geïnterpreteerd moeten worden dan een GIF-bestand. Om gebruik te maken van deze MIME-types verstuurd HTTP een ‘header line’ waarin staat welk type data volgt (welk MIME-type). De ontvanger weet dan hoe met deze data om te gaan. Bijvoorbeeld: Content-Type: text/html Content-Length: 72 /* verplicht een lege regel */ Hier komt dan het HTML-document




30

4.1.5 HyperText Transfer Protocol methoden Om binnen HTTP aanvragen te versturen zijn er verschillende methoden om aan te geven wat het doel is van de bewuste aanvraag. Een aanvraag (of request) heeft de volgende algemene vorm: [METHODE] [REQUEST-URI] HTTP/[VER] [header line 1] [header line 2] * een verplichte lege regel * [de verstuurde gegevens (een formulier of een HTML-pagina) ] Een voorbeeld hiervan is: POST /cgi-bin/post-query HTTP/1.0 Accept: text/html Accept: image/gif From: [email protected] Content-type: application/x-www-form-urlencoded Content-length: 18 * een lege regel * naam=Piet%20Jansen

Het request-URI moet minimaal een '/' bevatten, wat betekent dat het default bestand in de root van de server gebruikt zal worden. Meestal heet dit bestand index.html. Er bestaan vele verschillende methoden, maar de drie meest gebruikte methoden zijn GET, HEAD, en POST. Deze worden hieronder kort beschreven. 4.1.5.1 De GET methode De GET methode wordt gebruikt voor het aanvragen of ophalen van documenten. Als je bijvoorbeeld op een hyperlink drukt wordt GET gebruikt. Als je bijvoorbeeld op een link naar het adres www.w3.org/hypertext/HetProject.html klikt dan zal door HTTP minimaal het volgende bericht verstuurd worden. GET /hypertext/HetProject.html HTTP/1.0

www.w3.org staat niet in de 'path' vermeld omdat door de browser eerst contact gelegd wordt met de server voordat de GET wordt verstuurd. Er wordt dus verwezen naar een file op de server van 'www.w3.org' in de directory 'hypertext'. Met GET kun je eventueel ook gebruik maken van condities d.m.v. de 'If-Modified-Since' header. De aangevraagde informatie wordt dan alleen maar verstuurd als de informatie veranderd is sinds de aangegeven datum. Deze conditionele methode is bedoeld om het dataverkeer te verminderen doordat de informatie vanaf de schijf gebruikt wordt en niet opnieuw 'gedownload' hoeft te worden. Een voorbeeld: GET / HTTP/1.0 Accept: */* Host: birk105.studby.uio.no:81




31

4.1.5.2 De HEAD methode De HEAD methode wordt gebruikt als alleen informatie over een document nodig is en niet het document zelf. Deze methode is veel sneller dan GET en POST doordat minder data verstuurd hoeft te worden. HEAD wordt bijvoorbeeld gebruikt om te controleren of een document sinds de laatste keer nog veranderd is. Als het niet veranderd is kan de versie op schijf gebruikt worden, anders moet met GET een nieuwe versie gehaald worden. De header lines zijn bij de HEAD methode gelijk aan die van de GET methode, alleen wordt de data nu niet mee verstuurd. Deze methode wordt o.a. gebruikt voor het testen van hyperlinks op geldigheid, toegankelijkheid en op recente wijzigingen. 4.1.5.3 De POST methode De POST methode wordt gebruikt om data te versturen van de client naar de server. Deze methode is ontwikkeld om een berichtje te plaatsen op een bulletin board, naar een nieuwsgroep te versturen, of data te versturen naar een database om deze uit te breiden. Tegenwoordig wordt deze methode o.a. ook gebruikt om (grote) formulieren naar de server te versturen. POST /cgi-bin/post-query HTTP/1.0 Accept: text/html Accept: video/mpeg Accept: image/gif Accept: application/postscript User-Agent: Lynx/2.2 libwww/2.14 From: [email protected] Content-type: application/x-www-form-urlencoded Content-length: 53 * een lege regel * org=CyberWeb%20SoftWare &users=10000 &browsers=lynx

Dit is een POST aanvraag aan het programma "/cgi-bin/post-query", het programma zal slechts de ontvangen invoer weergeven op het scherm. De client geeft aan welke MIME-types het kan ontvangen, en welke browser gebruikt wordt. Daarna geeft het aan welk MIME-type gebruikt is voor de verstuurde data, het aantal karakters dat meegestuurd is en de lijst met variabelen en hun waardes die door de gebruiker zijn opgegeven. Content-type 'application/x-www-form-urlencoded' betekent dat de variabelen op dezelfde manier gecodeerd worden als een URL; alle speciale karakters worden gecodeerd als %nn, waar nn te vervangen is voor de ASCII waarde van dat karakter in hexadecimaal.




32

4.1.5.4 Wat stuurt HTTP terug Bij een antwoord van de server op een aanvraag(request) verstuurd HTTP een status code waarin staat of de aanvraag succesvol was of niet. De status codes hebben allemaal een nummer, en die nummers zijn onderverdeeld in bepaalde categorieen: • •

•

•

1xx: Informatief - Niet gebruikt, maar gereserveerd voor toekomstig gebruik. Meldingen van de 1xx categorie zijn gereserveerd voor toekomstig gebruik, en zul je in de praktijk dus niet tegenkomen. 2xx: OK - Het verzoek was goed ontvangen, begrepen en uitgevoerd. Meldingen van de 2xx categorie zijn meldingen die aangeven dat alles goed is verlopen. 3xx: Geredirectioneerd - Er moet een actie worden ondernomen door de client om het verzoek te kunnen voltooien. Meldingen van de 3xx categorie betekenen meestal dat de pagina is verhuisd, en dat de client een nieuw verzoek moet doen. 4xx: Client Error - Het verzoek heeft geen goede syntax of kan niet worden voltooid. Meldingen van de 4xx categorie betekenen dat dat client een niet geldig verzoek heeft verstuurd. Deze kom je met normale browsers bijna niet tegen. 5xx: Server Error - De server kon een geldig verzoek niet voltooien. Meldingen van de 5xx categorie houden in dat er bij de server zelf iets niet in orde is. Veel voorkomende foutmeldingen zijn meldingen dat de file niet bestaat (404) of dat er een 'password' nodig is voor toegang tot de file (401). Hier volgt een voorbeeld van een HTTP antwoord op een aanvraag van een client: HTTP/1.0 200 OK Date: Wednesday, 02-Feb-95 23:04:12 GMT Server: NCSA/1.3 MIME-version: 1.0 Last-modified: Monday, 15-Nov-93 23:33:16 GMT Content-type: text/html Content-length: 2345 * een lege regel * ...data...

De server zegt eveneens gebruik te maken van HTTP versie 1.0, en stuurt de statuscode 200 om aan te geven de aanvraag goed is verwerkt. Daarna volgt de tijd van versturen, het servertype, MIME-versie, en het moment van de laatste wijziging. Vlak voor het versturen van de data verstuurt de server het MIME-type van de data, het aantal verstuurde karakters en een verplichte lege regel. Daarna wordt de data verstuurd.




33

4.1.6 HTTP header lines Een HTTP transactie bestaat o.a. uit 'header lines' eventueel gevolgd door een lege regel en daarna de eventuele data. Met 'header lines' kun je aangeven welk soort data verstuurd wordt, de hoeveelheid data, of bijvoorbeeld het tijdstip van versturen. Hieronder wordt uitgelegd welke 'header lines' daarvoor gebruikt kunnen worden. Zowel de client als de server versturen 'header lines'. Deze velden beschrijven de data, het is dus eigenlijk informatie over de informatie, en wordt ook wel meta-informatie genoemd. Als er 'header lines' ontvangen worden door de server van de client zullen de waarden van deze 'header lines' in de omgevingsvariabelen gezet worden voor verwerking door een CGI script. Deze lines worden opgenomen met de prefix HTTP_ gevolgd door de 'header line'. Eventuele '-' karakters worden omgezet tot een '_' karakter. Een voorbeeld 'header line' verstuurd door de client is de HTTP_ACCEPT variabele. Deze variabele geeft aan welke MIME-type door de client ontvangen kan worden. 4.1.6.1 Veel voorkomende 'header lines' Omdat HTTP zo vrij is in de keuze van het te versturen data-type is HTTP ook zo geschikt voor het versturen van multimedia. De volgende 'header lines' geven een inzicht in de (meta-)informatie die allemaal mee verstuurd kan worden met de data. Achter de naam van de header-line staat of deze door de client of door de server verstuurd wordt.

4.1.6.1.1 Accept (client) Deze header geeft aan welke MIME-types worden aanvaard door de client.

4.1.6.1.2 Accept-Charset (client) Deze header geeft aan welke types van encoding de client kan ontvangen.

4.1.6.1.3 Accept-Language (client) Deze header geeft aan welke talen door de client worden geaccepteerd.

4.1.6.1.4 Connection (client en server) Deze header geeft het soort connectie weer.

4.1.6.1.5 Content-Language (server) Deelt de taal van de data mee.

4.1.6.1.6 Content-Type (server) Deze header geeft aan welk type data verstuurd wordt. Hierdoor weet de browser hoe met de data om te gaan. Bijv. Content-Type: text/html of Content-Type: image/jpeg

4.1.6.1.7 Date (server) Geeft aan op welke datum en tijd het bericht is verstuurd. Bijv. Date: Tue, 15 Nov 1994 08:12:31 GMT




34

4.1.6.1.8 Expires (server) Dit geeft aan tot welke tijd de verstuurde informatie geldig is. Als de informatie wordt opgeslagen in de cache, mag dit niet gebeuren na deze tijd. Bijv. Expires: Thu, 01 Dec 1994 16:00:00 GMT

4.1.6.1.9 From (client) Dit veld geeft het Internet e-mail adres van degene die de aanvraag doet. Bijv. From: [email protected]

4.1.6.1.10

Host (client)

Deelt mee met welke server de connectie wordt opgezet.

4.1.6.1.11

If-headers (client)

Deze headers worden gebruikt om condities mee te geven aan je vraag. Een voorbeeld van zo’n header is ‘If-Modified-Since’. De aangevraagde informatie wordt in dit geval alleen maar verstuurd als de informatie veranderd is sinds de aangegeven datum. Deze conditionele headers worden gebruikt om het dataverkeer te verminderen doordat de informatie vanaf de schijf gebruikt wordt en niet opnieuw gedownload hoeft te worden.

4.1.6.1.12

Last-Modified (server)

Deze header deelt mee wanneer de data voor het laatst werd aangepast.

4.1.6.1.13

Location (server)

Deze header line geeft de exacte locatie van het aangevraagde document. Als er een volledig URL wordt gegeven dan stuurt de server een 'doorverwijzing' naar de client zodat deze het bestand met een nieuwe aanvraag direct kan ophalen. Location: http://WWW.Stars.com/Tutorial/HTTP/index.html Als de client doorgestuurd moet worden naar een bestand op dezelfde server dan kan ook een gedeeltelijk URL opgeven worden. Location: /Tutorial/HTTP/index.html De server zal de doorverwijzing nu zelf afhandelen en gedraagt zich alsof de client het bestand http://yourserver/Tutorial/HTTP/index.html had aangevraagd en niet het script dat deze header line terugstuurt. De server zorgt nu voor de verwijzing naar het nieuwe bestand, de client heeft hier nu dus geen omkijken naar.




35

Een voorbeeld van deze header line is te vinden op de site "Ask Dr. Web". Bij het invullen van het vragenformulier op deze site wordt gevraagd of je de FAQ (Frequently Asked Questions, een lijst met veelgestelde vragen en de antwoorden daarop) al doorgelezen hebt. Is dit niet het geval dan zal de client via de 'location' header line de locatie van de FAQ doorgestuurd krijgen, en de client zal dan de FAQ op het scherm tonen. Dit ziet er als volgt uit: if

($input{'YN'} eq "No") { print /* naar STDOUT */ "Location: http://WWW.Stars.com/Dr.Web/FAQ.html\n\n"; } else { print "Content-type: text/html\n\n"; &AntwoordOpVraag; }

4.1.6.1.14

User-Agent (client)

Deze header geeft informatie over de het gebruikte systeem zoals browser-informatie en informatie over het besturingssysteem.

4.1.7 Cookies en de privacy 4.1.7.1 Wat zijn cookies? Een cookie is een heel klein tekstbestandje dat op je pc wordt geplaatst bij het bezoeken van websites. Dit tekstbestandje bevat slechts een kleine hoeveelheid data, meestal niet veel meer dan een unieke identificatiecode. Als je op een later tijdstip dezelfde website bezoekt wordt er op je harde schijf in de lijst met cookies gekeken of je deze website al eerder hebt bezocht. In dat geval is er dus een cookie geplaatst en kan de je door de website als bezoeker worden geregistreerd door de opgeslagen cookie naar deze website te sturen. 4.1.7.2 Waarom maakt men gebruik van cookies? Cookies kunnen gebruikt worden voor het gemak van de bezoeker, door de bezoeker met een cookie te identificeren hoeft deze niet iedere keer dezelfde gegevens in te voeren zoals zijn inloggegevens of scherminstellingen. Dankzij de cookies kunnen er ook surfsessies worden opgezet, dit is vooral belangrijk bij shopping sites. 4.1.7.3 Voorbeeld van mogelijk cookie gebruik/misbruik 1. U surft naar een drietalige website; op het hoofdscherm moet u de taal kiezen (Nederlands, Frans of Engels). Via een cookie wordt uw taalkeuze bijgehouden. De volgende maal dat u naar dezelfde website gaat, wordt u direct doorverbonden met de startpagina in de door u gekozen taal. 2. U gebruikt regelmatig een zoek-engine voor opzoekingen; via een cookie gekoppeld aan een databank houdt de zoek-engine bij welke zoektermen u allemaal opgeeft, en bouwt zo een profiel op van uw interesses. Telkens u naar de zoek-engine gaat, krijgt u reclame banners in verband met onderwerpen die u interesseren.




36

3. Per toeval komt u op een porno site terecht; op de hoofdpagina's staan enkele aanlokkelijke beeldjes. Indien u meer wil zien, dan moet u bewijzen dat u ouder dan 18 jaar bent; hiervoor vraagt men uw kredietkaartgegevens. Weken later ziet u dat er via uw kredietkaart heel wat geld van uw rekening is, bestemd voor verschillende porno bedrijfjes. U heeft naar verschillende sites gesurfd, en alhoewel een cookie per webserver is, hadden al deze webservers een gemeenschappelijk (eventueel onzichtbaar) beeldje van steeds dezelfde site, waaraan een cookie gekoppeld was. (in de praktijk is het wel zo dat dit soort misbruiken nooit op grote schaal zal plaatsvinden; de kredietkaartbedrijven zullen zoveel reclamaties ontvangen dat ze de samenwerking met dit soort bedrijven zal stopzetten. Maar af en toe gebeurt het toch, bovenstaand voorbeeld heeft werkelijk plaatsgevonden). 4. Ook brengen websites via cookies graag het surfgedrag van hun bezoekers in kaart. Op deze manier kunnen ze zien hoe vaak een bezoeker terugkomt, hoeveel pagina's hij bekijkt, welke route hij volgt en hoe lang hij op de website blijft hangen. De resultaten van dit alles kunnen gebruikt worden om de website te verbeteren en in te spelen op de interesses van de bezoekers van de site. Voorbeeld 2 geeft de vage grens tussen gebruik of misbruik van cookies weer: bepaalde mensen zullen de handelswijze uit voorbeeld 2 onaanvaardbaar vinden, andere gebruikers vinden dit juist nuttig omdat ze onmiddellijk interessante links krijgen. 4.1.7.4 Werking van cookies binnen HTTP Om de werking van cookies uit te leggen gaan we ervan uit dat we voor de eerste keer naar een bepaalde website surfen. De browser zal een aanvraag sturen voor deze webpagina. Vervolgens zal de webserver antwoorden en de pagina opsturen. Indien deze website met cookies werkt zal er in de header van het antwoord een headerline Set-Cookie aanwezig zijn. Deze headerline ziet er als volgt uit:

Set-Cookie: NAAM=WAARDE [;attribuut1=value][;attribuut2=value]... NAAM: cookie naam WAARDE: cookie waarde Mogelijke attributen: Comment = waarde : Hierin kan commentaar worden opgenomen zodat de gebruiker kan zien waarvoor de cookie dient CommentURL = “http_URL” : Dit attribuut bevat een link naar een commentaarpagina Discard: De cookie wordt verwijdert bij het afsluiten van de browser Domain = waarde: Duidt aan tot welke site de cookie toebehoort Max-Age = waarde: Levensduur van de cookie Path = waarde: Directory-structuur van een website waartoe de cookie behoort Port[=”lijst van mogelijke poorten”]: communicatiepoort(en) Secure: Zorgt ervoor dat de cookie-communicatie over een beveiligde lijn gaat Verion = waarde: Versienummer van de gebruikte cookieafhandeling

De gegevens van de Set-Cookie headerline wordt door de browser opgeslagen in een bestand of directory met andere cookies en krijgen een identificatiesleutel toegewezen, meestal de bezochte site gecombineerd met de cookienaam. Vervolgens zal voor iedere volgende vraag een headerline Cookie worden toegevoegd met de eerder opgeslagen data. Deze headerline ziet er als volgt uit: Cookie: NAAM1=WAARDE;NAAM2=WAARDE... NAAM: cookie naam WAARDE: cookie waarde




37

4.1.8 Voorbeeld Hier volgt een voorbeeld van HTTP, dit voorbeeld toont hoe het HTTP protocol in zijn werk gaat. Hier gebeurt een uitwisseling tussen een Web browser en een Web server (www.beta9.be). Als antwoord op de aanvraag van de gebruiker om naar de URL (Uniform Resource Locator) http://www.beta9.be/index.html te surfen zendt de browser de volgende HTTP request naar www.beta9.be GET /index.html HTTP/1.1 Host: www.beta9.be User-Agent: Mozilla/5.0 (X11 ;U ;Linux i686 ;en-US ;rv.1.1) Gecko/20020826 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai n;q=0.8,video/xmng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 Accept-Language: en-us,en ;q=0.50 Accept-Encoding: gzip,deflate,compress;q=0.9 Accept-Charset: ISO-8859-1,utf-8;q=0.66,*;q=0.66 Cookie: css=sa Connection: close -- lege lijn bestaande uit een carriage return en een line feed --

Een korte uitleg: • De eerste lijn is de request lijn en bestaat uit drie velden: 1. een methode: De GET-methode. Dit wil zeggen de er van de server wordt verwacht dat hij een entity terugstuurt. 2. een request-URI (Universal Resource Identifier). De / duidt er op dat er vanaf de root het documentensysteem op de server wordt gezocht. 3. HTTP protocol versie: hier 1.1. • De tweede lijn is de Host header die aangeeft met welke server de verbinding wordt opgebouwd. • De derde lijn is de optionele User-Agent header die de browser identificeert waarmee de request werd verstuurd, maar ook zijn versie en het besturingssysteem waarop hij draait worden medegedeeld. • De Accept headers specificeren het type, de taal en de encoding waarin de browser de response graag in zou willen ontvangen van de server. • De voorlaatste lijn is de Cookie header, hierin wordt de data opgenomen uit het betrokken bestand dat opgeslagen werd tijdens het vorige bezoek aan deze bepaalde URL. • De laatste lijn is de optionele Connection header die de waarin de browser de server informeert om de connection open te houden na de response.




38

Antwoordend op de browser, zal de www.beta9.be server de volgende response versturen: HTTP/1.0 200 OK Date: Mon, 05 May 2003 07:46:05 GMT Content-Length: 6871 Content-Type: text/html Server: Apache/1.3.27 (Unix)(Red-Hat/Linux)mod_ssl/2.8.12 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.2.6 Last-Modified: Wed, 05 Mar 2003 15:04:16 GMT Etag: “598077-1ad7-3e6611f0” Via: 1.1 nchobo02 (NetCache NetApp/5.2.1R3) X-Cache: HIT from blackbox.intern.beta9.be Connection: close -- lege lijn bestaande uit een carriage return en een line feed --- body --

Een korte uitleg: • De eerste lijn is de status lijn bestaande uit drie velden: 1. HTTP protocol versie van de response: in dit geval 1.1, 2. een uit drie cijfers bestaande status code, en 3. een korte beschrijving van deze status code. • De Content-Length, Content-Type, Etag, en Last-Modified header lijnen beschrijven de verstuurde entity.




39

5 Extreme Programming 5.1 Inleiding eXtreme Programming (XP) is een jonge ontwikkelmethodologie die uit Amerika is komen overwaaien. Na Object Oriented Development (OOD) en Component Based Development (CBD) zou XP kunnen uitgroeien tot de volgende hype binnen software engineering. Het is zowel een logisch vervolg als een ontwikkelmethodologie die breekt met de principes van de traditionele ontwikkelmethodologieën. Zonder twijfel staat XP nog in de kinderschoenen en de methodologie zal wel een aantal jaren nodig hebben om te groeien. Eén ding kan echter wel worden gezegd, XP is revolutionair en controversieel. Alhoewel de term programming anders doet vermoeden, richt XP zich niet alleen op de programmeerfase maar op het hele ontwikkelproces. Het programmeren wordt daarbij wel als een belangrijke ontwikkelactiviteit gezien die waarde genereert. XP is extreem in de zin dat er maar een beperkt aantal programmeer- en projectmanagementtechnieken worden toegepast, maar dat die technieken wel ten volle gebruikt worden. XP stelt een aantal randvoorwaarden aan de technologie en de ontwerptechnieken die gebruikt worden. Voorbeelden hiervan zijn: Sterke betrokkenheid van klant en gebruiker, ontwikkelgereedschappen die iteratieve ontwikkeling gemakkelijk maken (zoals snelle compilers, goede editors en debuggers), de cultuur van de ontwikkelaars (mensen die bijvoorbeeld het liefst alleen werken passen niet in een XP-team).




40

5.2 Kostencurve

Figuur 25: Exponentiële curve

Figuur 26: Vlakke curve (eXtreme Programming)

De huidige software ontwikkelmethodologieën zijn gebaseerd op de veronderstelling dat de kosten om software aan te passen, exponentieel toenemen in de tijd. Met andere woorden, het kost veel meer een fout te herstellen wanneer een systeem eenmaal in gebruik is, dan toen het systeem in ontwerpfase was. In het geval van XP wordt beweerd dat met de huidige technologieën deze veronderstelling niet langer hoeft op te gaan. Alle methodologieën binnen XP hebben tot doel en zijn gebaseerd op het kunnen aanpassen van code zonder dat dit extra kosten tot gevolg heeft. Een consequentie is dat de noodzaak om eerst een doordacht ontwerp te maken; alvorens over te gaan tot de implementatie, verdwijnt. Maar op welke wijze drukt XP nu die kostencurve?




41

5.2.1 Feedback XP stelt dat uiteindelijk alles om code draait bij het maken van software. XP gaat er vanuit dat deze code dusdanig klantspecifiek is, dat de klant zo dicht mogelijk bij het ontwikkeltraject dient te staan. Bij XP wordt ontwikkeld op basis van testcases die de klant samenstelt. Geen functionele specificaties; er zal enkel worden gecodeerd wat de klant wil dat er uit de testcases moet komen. Niet meer en ook niet minder. Bij voorkeur dient een toekomstige gebruiker ten alle tijden aanwezig te zijn, zodat er voor gezorgd kan worden dat de applicatie exact dat wordt wat de klant wenst. Om dit proces zo goed mogelijk te laten verlopen, werkt XP met korte ontwikkelcycli, waarin steeds een aantal geselecteerde testcases wordt geïmplementeerd tot een werkend systeem. Aan het eind van iedere cyclus kan de klant het systeem beoordelen en desnoods de ontwikkeling bijsturen.

5.2.2 Refactoring Een belangrijke techniek waarmee XP zich verder onderscheidt van traditionele ontwikkelmethodologieën is refactoring: het herschrijven van code in kleine precies afgemeten stapjes zonder dat daarbij de zichtbare functionaliteit wordt aangetast. Refactoring voegt kortom niets aan de functionaliteit toe, maar het verbetert de eenvoud van het ontwerp. Door de herschrijfstapjes regelmatig uit te voeren is het overall effect vaak verbluffend. Er zijn inmiddels een zeventigtal herschrijfregels ontdekt en gedocumenteerd. De randvoorwaarde voor het succesvol toepassen van refactoring is dat er unit test voorhanden zijn, die automatisch uitgevoerd kunnen worden na iedere herschrijfstap om zeker te stellen dat de functionaliteit niet is veranderd. Refactoring wordt vaak gebruikt als voorbereiding op het doorvoeren van een uitbreiding of verandering van de functionaliteit.

5.2.3 Automatische unit tests Binnen XP neemt het schrijven van automatische unit tests een belangrijke plaats in. In eerste instantie maakt het refactoring mogelijk. Maar wat minstens zo belangrijk is, is de te implementeren functionaliteit die op deze manier wordt vastgelegd. Bij het doorvoeren van een uitbreiding worden eerst de noodzakelijke unit tests geschreven of aangepast. Een bepaalde functionaliteit is pas gerealiseerd wanneer alle unit tests, zowel de oude als de nieuwe, voor 100% slagen. Als er in een later stadium tijdens een functionele test een ‘bug’ wordt gevonden, is het schrijven van een unit test, die deze bug aan het licht brengt, het eerste wat wordt gedaan.

5.2.4 Eenvoud van ontwerp Wil een systeem makkelijk te veranderen zijn, dan dient het ontwerp zo eenvoudig mogelijk te zijn. Dit is makkelijker gezegd dan gedaan. De traditionele ontwikkelmethodologieën hebben ons geleerd vooruit te denken en bij het ontwerp steeds na te denken over functionaliteit die misschien in de toekomst moet worden gerealiseerd. Maar deze methodologieën gaan uit van de veronderstelling dat de kosten voor veranderingen exponentieel toenemen. Daarom hamert XP er op steeds het meest eenvoudige ontwerp te kiezen om de functionaliteit, die nu gerealiseerd moet worden, mogelijk te maken. Eventuele toekomstige uitbreidingen kunnen met XP namelijk zonder de gebruikelijke extra kosten worden doorgevoerd. Tevens blijkt dat bij de realisatie van een doordacht ontwerp maar al te vaak dat het eigenlijk niet (meer) voldoet. Dit kan enerzijds gebeuren doordat tijdens de analyse en het ontwerpen bepaalde details over het hoofd zijn gezien of anderzijds doordat de eisen zijn bijgesteld. Bij XP loopt ontwerp niet voorop, maar volgt het de code. Hogeschool Limburg 2002-2003-06-09



42

5.2.5 Pair Programming Eén van de meest extreme en controversiële aspecten van XP is het voorschrift dat alle ontwikkeling gedaan wordt in koppels – twee mensen achter één computer! Deze techniek maakt een essentieel onderdeel uit van XP zonder welke het niet zo kan werken. De koppels zijn niet vast, maar kunnen van dag tot dag verschillen. Voor elke nieuwe taak zoekt een ontwikkelaar opnieuw een projectlid om mee samen te werken. Pair programming heeft een aantal voordelen. Ontwikkelaars zullen minder snel het ontwerp van de code moeilijker maken dan strikt nodig is. Daarnaast zullen paren in het algemeen minder fouten maken. Er vindt continu een review van de code plaats evenals een uitwisseling van kennis over het systeem. Menig onderzoek heeft aangetoond dat peer-review(=feedback geven op de code) en code inspectie de krachtigste wapens zijn tegen bugs, veel krachtiger zelfs dan systematisch testen. Toch worden deze technieken maar met mondjesmaat toegepast en roepen ze vaak grote weerstand op bij de programmeurs zelf. Door af te dwingen dat alle software-ontwikkeling in koppels wordt uitgevoerd, die zoals al gezegd werd, regelmatig van samenstelling wisselen, ontstaat er een collectief ‘eigendomsgevoel’ en worden peer-review en code inspectie als van nature onderdeel van het normale software proces. Het gevolg is dat het uiteindelijk opgeleverde systeem niet langer bestaat uit een met ‘touwtjes’ aan elkaar gebonden verzameling van stukjes code, die totaal niet onderhoudbaar zijn. Iedereen kent ongeveer alles van het project. Zo zal het verlies van een bepaalde programmeur niet zo erg zijn en de opleiding van nieuwe werknemers verloopt ook vlot door de voortdurende training-on-the-job. Pair programming is daarmee het krachtigste middel teen de toenemende kostenspiraal. Het moge duidelijk zijn dat het ogenschijnlijke verlies aan productiviteit zich op deze manier dubbel en dik terugbetaalt.




43

5.3 De werkwijze van XP 5.3.1 De menselijke factor De menselijke factor speelt een centrale rol. Software ontwikkelen is mensenwerk. XP benadrukt dat ontwikkelaars in het algemeen normale werkweken dienen te maken. Overwerk en hoge werkdruk gaan ten koste van de ontwikkelaars en ook ten koste van de kwaliteit van de software. XP reduceert de noodzaak tot het uitvoeren van onvoorzien werk door het ontwikkelproces beter beheersbaar te maken en door te concentreren op die functionaliteit die echt nodig is.

5.3.2 Verantwoordelijkheid In een XP-project zijn de code en andere producten van het ontwikkelproces collectief eigendom van de ontwikkelaars. Hierbij draagt elk projectlid medeverantwoordelijkheid voor de gehele code en mag elk projectlid overal wijzigingen aanbrengen. Dit vereist wel een zekere discipline van de ontwikkelaars. Het is zeker niet gelijk aan ‘no ownership’, waar iedereen naar eigen goeddunken wijzigingen kan aanbrengen. Als niemand verantwoordelijk is, leidt dit al snel tot chaos. In de huidige praktijk wordt vaak individueel eigendom toegepast, waarbij ieder stuk code precies één verantwoordelijk projectlid heeft. Dit heeft ten opzichte van collectief eigendom een aantal belangrijke nadelen. Als er veranderingen nodig zijn in code van iemand anders, zullen deze minder snel worden aangebracht. Veranderingen die meerdere stukken code overspannen zijn ook problematisch, omdat niet één persoon daar de verantwoordelijkheid voor heeft. Dit leidt vaak tot onnodige duplicatie van code. Een ander probleem is het verdwijnen van kennis van een stuk code als de eigenaar ervan ziek wordt of vertrekt. Verder wordt nieuwe en gewijzigde code continu, dat wil zeggen steeds na enkele uren of na hooguit een dag, geïntegreerd en getest. Voorwaarde voor integratie is dat alle unit tests voor 100% slagen met de gewijzigde code. Eventuele conflicten en problemen worden op deze manier direct gedetecteerd en zullen een beperkte impact hebben op de rest van de code. Een voorwaarde voor continue-integratie is dat de gebruikte tools dit moeten ondersteunen.

5.3.3 Standaarden verplicht XP schrijft het gebruik van programmeerstandaarden voor om het collectieve eigendom van code te ondersteunen. Dit voorkomt ook zinloze discussies over bijvoorbeeld de layout van de code. Het projectteam is vrij om voor bepaalde standaarden te kiezen, zolang de projectleden maar in staat zijn elkaars code te begrijpen en aan te passen.




44

5.3.4 Levenscyclus van een project

Figuur 27: Planning game

Het projectmanagement van XP is erop gericht om op een voorspelbare en economisch verantwoorde manier voor de klant nuttige software te maken. Keuzes in projectmanagement worden over het algemeen bepaald door de vier variabelen: kosten, tijd, kwaliteit en omvang van het systeem. Deze vier variabelen zijn gerelateerd, maar wel op een complexe wijze, zodat ze niet allemaal tegelijk geoptimaliseerd kunnen worden. Een klant die eist dat de software “gisteren af moet zijn, moet doen wat ik wil, niet vast mag lopen, en vooral niks mag kosten” plaatst zich duidelijk buiten de werkelijkheid. Een XP-project begint met een planningsproces, genaamd planning game, gevolgd door een aantal korte iteraties. Elke iteratie duurt maximaal drie tot vier weken en resulteert in een werkend systeem. Dit betekent niet dat er na elke iteratie ook een release van een productieversie plaatsvindt. Door de korte iteraties krijgt de klant snelle feedback over hoe het systeem zich ontwikkelt en kan de klant regelmatig bepalen of de kwaliteit en omvang naar wens zijn, met andere woorden, of er nog steeds waarde wordt geleverd. Na elke iteratie kunnen de eisen worden aangepast. Eventueel kan de klant de ontwikkeling stopzetten als de verhouding tussen investeren in ontwikkelen van nieuwe features en de geleverde waarde niet meer klopt. De planning game is een dialoog tussen de klant en het ontwikkelteam. De klant bepaalt wat wenselijk is, en de ontwikkelaars bepalen wat mogelijk is. De klant wordt in dit planningsproces gedwongen prioriteiten te stellen. Beide partijen moeten risico’s identificeren en afwegen. En van beide wordt ook discipline vereist. Ontwikkelaars bouwen Hogeschool Limburg 2002-2003-06-09



45

alleen door de klant verlangde functionaliteit, en geen overbodige franje. Ze geven aan welke features moeilijk te maken zijn en hoe lang het bouwen van een feature duurt. De klant stelt geen onmogelijke deadlines en bepaalt welke eigenschappen van het systeem het eerst moeten worden gebouwd. De wensen van de klant worden vastgelegd in zogeheten user stories. Elke user story beschrijft een voor de klant zichtbare eigenschap van het systeem, compleet met eventuele randvoorwaarden aan deze eigenschap, zoals prestatie-eisen. Aan het begin van een iteratie wordt een iteration planning game gespeeld. De klant bepaalt daarin welke stories in die iteratie worden gerealiseerd en mag daarbij nieuwe stories toevoegen en bestaande verwijderen. De ontwikkelaars bepalen voor elke story welke ontwikkeltaken nodig zijn om deze story te implementeren. Ze bepalen tevens de tijd die een taak gaat kosten. De tijd die een story gaat kosten is dan de som van de taken. De klant hoeft niet te weten wat die taken precies zijn. Wat het ontwikkelteam wel duidelijk moet maken zijn de risico’s die verbonden zijn aan bepaalde stories, zoals bijvoorbeeld het gebruik van een nieuw en onbekend databasesysteem. Soms is het nodig om eerst een technologieverkenning te doen. Dit wordt dan gewoon als een story ingepland, met toestemming van de klant uiteraard. Hoe de taken worden verdeeld in het team, en hoe ze gepland worden is een zaak van het ontwikkelteam. De klant kan prioriteiten in zijn stories aangeven door te bepalen welke nu en welke later worden uitgevoerd. De volgorde is uiteraard wel afhankelijk van de technische randvoorwaarden die door de ontwikkelaars worden vastgesteld.




46

5.4 Nadelen Ondanks de grote belofte die XP lijkt te zijn, worden er vanuit de praktijk ook nadelen onderkend: De belangrijkste is misschien wel dat het niet eenvoudig is XP in te voeren. Omdat de verschillende elementen van XP zo op elkaar ingrijpen, wordt er alleen een goed resultaat bereikt als ze allemaal worden toegepast. Er is nog relatief weinig ervaring met XP. Code ontwikkelen met enkel oog voor de wensen van de gebruikers kan problemen geven wanneer een einddoel in het oog moet worden gehouden. Het einddoel kan ondersneeuwen met de tijdelijke doelen van de te realiseren iteraties. Dit leidt gemakkelijk tot uitloop van de oplevering van het uiteindelijke systeem. Veel aandacht van de projectleider is vereist om dit nadeel van XP te managen. Bovenstaande heeft ook zijn weerslag op de verwachtingen van de opdrachtgever. Deze dienen eveneens aandacht te krijgen zolang XP nog geen bekende ontwikkelmethodologie is. Niet elke ontwikkelaar is een teamspeler. Om volgens de principes van XP te werken zal zorgvuldig een team moeten worden samengesteld. Twee junior ontwikkelaars bij elkaar of twee eigenwijze ontwikkelaars zullen niet de beoogde programmatuur opleveren. Er dienen strakke afspraken gemaakt te worden omtrent de gebruikersparticipatie om enige vorm van vrijblijvendheid in de kiem te smoren. Het schrijven van unit tests moet de uitgangssituatie zijn en blijven voor het ontwikkelen van programmatuur. Wanneer gebruikers niet in staat zijn geweest unit tests te schrijven en ontwikkelaars toch doorgaan met ontwikkelen, ontstaat een systeem waar niet door de gebruikers over is nagedacht. Er zijn een aantal zeer succesvolle projecten bekend, maar de vraag die zich opdringt is of deze projecten succesvol waren vanwege de kwaliteiten van de mensen die er aan mee deden of vanwege de kwaliteit van XP.




47

5.5 Besluit Resumerend, XP belooft dat het projectrisico’s reduceert, dat bedrijfsmatige veranderingen soepel worden opgevangen, en dat het de productiviteit verbetert gedurende de gehele levenscyclus van een systeem. Bovendien wordt gesteld dat door in teams te werken het echt leuk wordt om software te ontwikkelen. Hoewel net het paar programmeren bij veel mensen in eerste instantie weerstand opwekt. De activiteiten tonen hun sterke kanten vooral als ze in combinatie gebruikt worden, zodat sterke en zwakke punten elkaar compenseren. Elk project zal zijn eigen variaties op onderdelen van het proces hebben, afhankelijk van de behoeften. Hoewel XP nog volop in ontwikkeling is, kan het nu al gezien worden als een stap op weg naar professionalisering van software engineering.




48

6 Stageproject 6.1 Probleemstelling Het is niet altijd even gemakkelijk om een beeld te vormen van wat een webapplicatie zoal aankan. Om een test uit te voeren op een webapplicatie werd van ons verwacht een tool te bouwen die het connecteren van een veelvoud aan gebruikers zou kunnen simuleren. Deze connecties zouden zo sterk mogelijk op real-life connecties moeten lijken om de test betrouwbare resultaten te laten genereren. Dit was het beste te verwezenlijken door het gebruik van twee onderdelen, namelijk een recorder en een player. Het doel van de recorder was een manier zoeken om een surfsessie op te nemen. Dit moest zodanig gebeuren dat de sessie op een bijna identieke manier opnieuw zou kunnen worden afgespeeld. Vrij snel werd duidelijk dat dit het beste mogelijk was door een browser via een zelfgemaakte proxy-tunnel te laten connecteren met het internet. Op die manier is het mogelijk de sessie op te nemen zodat noch de client noch de webserver dit merken. Speciale aandacht was vereist voor de opname en verwerking van HTTP headers en de bodies bij een postrequests. Het doel van de player was het opnieuw loslaten van de opgenomen sessie(s) op een te testen webapplicatie. Hiervoor was een HTTP client applicatie nodig die op dezelfde manier zou werken als iemand die een browser gebruikt. Men moet hierbij rekening houden met sessies, het invullen van forms in webapplicaties en een representatief tijdverloop van iedere gesimuleerde surfsessie. Het moest mogelijk zijn op een gemakkelijke manier resultaten te verkrijgen van deze test, daarvoor was een flexibel plugin systeem nodig dat de gebruiker toeliet om zelf interpretaties te programmeren van de testresultaten.

Figuur 28: Use case




49

6.2 Proxy-tunnel

Figuur 29: proxy-tunnel

6.2.1 Gebruik Voor het opnemen van een surfsessie zijn slechts enkele kleine handelingen nodig als voorbereiding. Men moet de caching van de browser die men wil gebruiken om de surfsessie op te nemen volledig uitschakelen zodat elke request wel degelijk plaatsvindt. De proxy instellingen van de browser moeten ingesteld worden op de proxy-tunnel, op die manier kan de netwerktrafiek opgenomen worden. Om een opname te maken start men eerst de recorder, surft wat rond op een site (webapplicatie) en sluit vervolgens de recorder af. De opname bestaat uit één xml-bestand voor de requests, één voor de responses en eventueel files waar geposte informatie in werd opgeslagen (bijvoorbeeld afkomstig van forms).

6.2.2 Trafiek Om te trafiek van en naar een proxy-server goed te begijpen hebben we geëxperimenteerd met verschillende (Linux) commandline tools zoals Curl, netcat en telnet. Dit hielp ons zeer goed om duidelijkheid te scheppen in de aanwijzingen die we in verschillende documenten en rfc’s hadden gelezen. Een HTTP request die naar een proxy-server wordt gestuurd ziet er anders uit dan een HTTP request die men rechtstreeks naar de web-server stuurt. Een request die langs een proxyserver wil heeft buiten het pad ook de vermelding van het protocol en de host in de methodelijn staan. Sommige browsers sturen eveneens een Proxy-Connection header naar een proxy-server om de connectie op client-proxy niveau te kunnen regelen. In volgende voorbeelden zijn de verschillen tussen de headers rood gemarkeerd. Voolbeeld van een request voor http://www.gps-buddy.com/ via een proxy-server: GET http://www.gps-buddy.com/ HTTP/1.1 Host: www.gps-buddy.com User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; q=0.8,video/x-mng,image/png,image/jpeg,ie/gif;q=0.2,text/css,*/*;q=0.1 Accept-Language: en-us, en;q=0.50 Accept-Encoding: gzip, deflate, compress;q=0.9 Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Connection: close Proxy-Connection: close Cookie: language=en; GPS-BuddyLanguage=en




50

Voorbeeld van dezelfde request maar dan via een directe connectie met het internet: GET / HTTP/1.1 Cookie: language=en; GPS-BuddyLanguage=en Host: www.gps-buddy.com Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809 Accept-Language: en-us, en;q=0.50 Accept-Encoding: gzip, deflate, compress;q=0.9 Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Connection: close

In verband met de headers is de job van de proxy van het bovenste voorbeeld het onderste te maken. De recorder zal zijn job als proxy vervullen en de nodige aanpassingen in de headers maken. Er is een mogelijkheid om de proxy zelf te laten connecteren op een proxy, als van deze optie gebruik gemaakt wordt vinden de veranderingen natuurlijk niet plaats. De webserver stuurt een response terug die via de proxy-tunnel de client zal bereiken. In de proxy-tunnel worden de header en de body van de response gesplitst om de header apart te kunnen bekijken. Tegelijkertijd wordt het geheel onveranderd doorgestuurd naar de client.

6.2.3 Opname De opname van zowel de requests als de responses gebeurt voor ze de proxy-tunnel ingaan. Bij het binnenkomen van de request in de proxy-tunnel zal er een request object aangemaakt worden en dit zal vervolgens weggeschreven worden naar een XML-boom. Onmiddellijk daarna zal in het geval van een POST request een bestand worden weggeschreven dat de data in de body bevat. Dit bestand krijgt een unieke naam waarnaar wordt verwezen in het overeenkomstig XML-element. Bij het ontvangen van de response in de proxy-tunnel zal er een response object aangemaakt worden van de afgesplitste header. Deze header zal in een aparte XML-boom worden opgeslagen. De data in de body zal niet worden opgeslagen, maar enkel worden verder gestuurd naar de client. Beide XML-bomen worden weggeschreven naar XML-bestanden. Samen met het opslaan van de header zal er ook meta-data worden gegenereerd, deze zal bestaan uit: • een reference-element: dit bestaat uit een unieke sleutel dat requests aan de overeenkomstige responses linkt • een timemark-element: dit is de huidige opname van milliseconden op het moment dat de header in de proxy-tunnel binnenkomt voor de requests, de timemark voor de responses wordt gezet op het moment dat de laatste byte van de response de tunnel heeft verlaten • voor zowel requests als responses worden er uit de eerste regel van de header verschillende XML-elementen aangemaakt.




51

De header van de request zal in het XML-bestand op de volgende manier worden opgeslagen: POST http://www.gps-buddy.com/gpsBuddySelection.m HTTP/1.1 Host: www.gps-buddy.com Accept: text/xml,application/xml,application/xhtml+xml, */*;q=0.1 User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809 Content-Length: 20 Accept-Language: en-us, en;q=0.50 Accept-Encoding: gzip, deflate, compress;q=0.9 Content-Type: application/x-www-form-urlencoded Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Referer: http://www.gps-buddy.com/jsp/Dispatch.jsp Connection: close Cookie: language=en; GPS-BuddyLanguage=en < data in de body >

Een wellettend oog zal opgemerkt hebben dat in de XML-versie geen Cookie-header meer te bespeuren valt. Cookies zijn sessie-gebonden en moeten dus niet opgeslagen worden, deze cookies zullen opnieuw gegenereerd worden door de client-simulator. Het body-file element onder de header in de xml verwijst naar het bestand waarin de data van de body is opgeslagen. Dit element komt enkel voor bij POST requests.




52

De header van de response zal in het XML-bestand op de volgende manier worden opgeslagen: HTTP/1.0 200 OK Date: Thu, 12 Jun 2003 06:56:30 GMT X-Cache: MISS from blackbox.intern.beta9.be Server: Resin/2.1.8 Cache-Control: private Connection: close Content-Type: text/html Via: 1.1 nchobo05 (NetCache NetApp/5.3.1R3)

In zowel de request- als de response headers speelt de volgorde van de headerlines geen rol, enkel de methodelijn (request) en statuslijn (response) moeten voor de headerlines. Toch wordt door de recorder deze volgorde opgeslagen. Om een beeld te geven hoe de request en response objecten in de code voorgesteld worden kan het klasse diagram op de volgende pagina wat duiding brengen.




53

Figuur 30: Header Object UML




54

6.3 Client-simulator

Figuur 31: Werking van de loadtester

6.3.1 Gebruik Men heeft de mogelijkheid om verschillende opgenomen sessies aan te duiden voor simulatie. Voor iedere sessie moet ingesteld worden hoeveel keer zij zich simultaan zal afspelen. Vervolgens kan een plugin-file worden aangeduidt met verwijzingen naar een aantal plugins om de verkregen resultaten na de test te interpreteren. De GUI voorziet in een mogelijkheid om deze plugins een visualisatie te geven. Tijdens het afspelen van de test worden de nodige sessie-regelingen getroffen (cookies) en wordt post-data op dezelfde manier meegegeven als bij de opname.




55

6.3.2 Eén player sessie van dichtbij bekeken Hoe gaat het afspelen van een player sessie in zijn werk? Eerst en vooral zal een opgenomen sessie in een XML-bestand worden geparsed met SAX (Xerces). Daar gewerkt wordt met SAX zal het bestand sequentieel worden uitgelezen. Dit proces is niet zwaar systeembelastend omdat er slechts weinig gebruik gemaakt wordt van het geheugen. Omdat er verschillende player sessies zich op hetzelfde zullen afspelen is dit zeker en vast geen luxe.

Figuur 32: PlayerSession




56

Tijdens het parsen van het XML-bestand zal er opnieuw een request worden samengesteld aan de hand van het header-element. Deze request zal dan uiteindelijk naar de webapplicatie worden gestuurd. Dit lijkt echter makkelijker dan het is, daar men met verschillende dingen rekening dient te houden. Bij het lezen van een post-request zal er een body-file element geparsed worden. De player zal er op dit moment voor zorgen dat de inhoud van de body-file waarnaar wordt verwezen meegestuurd zal worden met de request-header. Zo zullen bijvoorbeeld de formulieren zoals deze voor het inloggen die zich op de webapplicatie bevinden automatisch worden ingevuld. Buiten formulieren worden post-requests ook nog gebruikt voor het uploaden van bestanden, ook dit zal gesimuleerd worden, want daar is in principe geen verschil tussen. Vervolgens wordt er rekening met het juist afhandelen van sessies. Dit zal gebeuren aan de hand van de Cookie header-lines. Dit gaat als volgt te werk: De request die werd gegenereerd aan de hand van het XML-bestand zal naar de web applicatie worden gestuurd. Vervolgens zal de webserver antwoorden en de pagina opsturen. Indien deze website met cookies werkt zullen er in de header van het antwoord één of meer Set-Cookie headerlines aanwezig zijn. De waardes van de Set-Cookie headerline zullen worden bijgehouden in een Vector en vervolgens worden opgeslagen in een algemene tabel die door de player wordt beheerd, per sessie zal de player een nieuwe tabel verzorgen met enkel die cookies die voor deze bepaalde sessie gelden. In deze tabel worden Cookie objecten opgeslagen met behulp van een uniek sleutelveld bestaande uit de naam van de website en de cookienaam en indien er op een bepaalde website een nieuwe Set-Cookie wordt gedaan die hetzelfde is als de eerder opgeslagen waarde zal deze worden vervangen. Bij iedere volgende request zal de player altijd heel de tabel doorlopen om te kijken of er al cookies voor die website beschikbaar zijn, dit kunnen er meerdere zijn. Indien de tabel Cookie objecten bevat voor deze website zal er een cookie-headerline worden gegenereerd en worden toegevoegd aan de request header. Deze lijn zal er als volgt uitzien: Cookie: NAAM1=WAARDE;NAAM2=WAARDE... NAAM = cookie naam WAARDE = cookie waarde

Dit mechanisme zorgt voor een naadloos en proper gescheiden sessieverloop van iedere afzonderlijke sessie. De response die volgt op een request in de player zal niet door een browser worden gelezen zoals dat gebeurde bij het opnemen. De player stuurt de response naar een dummy outputstream die zoals de naam doet vermoeden helemaal niets doet. Het doel van deze op het eerste zicht nodeloze handeling ligt in het genereren van time-marks. Op deze manier heeft men representatieve informatie om te vergelijken met de originele sessie.




57

6.3.3 Het geheel van sessies in een simulatie

Figuur 33: Het spawnen van sessies

Er kunnen verschillende opgenomen sessies tegelijkertijd worden afgespeeld. Men kan instellen hoeveel keer iedere sessie zich op hetzelfde moment moet afspelen. Om dit te realiseren is een soort van hiërarchische structuur van threads nodig. Zoals op het bovenstaande schema te zien is start de LoadTester klasse een veelvoud van Player threads. Een Player klasse neemt als één van zijn argumenten de bestandsnaam van een opgenomen sessie en hoeveel keer deze moet worden afgespeeld. Dit afspelen gespeeld in een veelvoud van PlayerSession threads.




58

6.4 Testing framework Er is een framework aanwezig dat toelaat zelf kleine of grote java programmaatjes (plugins) te schrijven aan de Client-simulator. De hoofdbedoeling hiervan is de gebruiker toe te laten zelf eigen interpretaties te schrijven aan de resultaten die de Client-simulator simuleert. Er zijn voorbeeld plugins voorhanding en er is een default plugin die de resultaten op een algemene manier weergeeft. De resultaten worden verzamelt door de plugin die door het framework resultaten toegestopt krijgt in SnapShot objecten. Deze SnapShot objecten zijn momentopnames van één request-response afhandeling met alle mogelijke meta-informatie en informatie over de xml-file. Een SnapShot bestaat uit 2 RequestHeader objecten, 2 ResponseHeader objecten en een LogInfo object. Dat is steeds een request-response paar uit de opname van de sessie en een request-response paar uit de sessie die wordt afgespeeld door de player. Het LogInfo object bevat op voorhand ingelezen informatie over het XML-bestand. Een View interface schrijft voor welke methodes een plugin moet bevatten, deze ziet er als volgt uit:




59

Om aan te geven welke plugins men wil gebruiken stelt men een file samen met de vermeldingen van de classes. Deze file ziet er bijvoorbeeld als volgt uit:

Lijnen die beginnen met het hekje worden niet bekeken door de framework, dat is handig om wat commentaar toe te voegen. De andere lijnen worden gelezen en de framework zal door middel van reflection de aangeduide klassen proberen te laden. Er is een mogelijkheid om een custom GUI zelf te schrijven en toe te voegen aan een plugin. Door de getGuiClass()–methode een String te laten teruggeven met daarin de naam van de custom GUI klasse. Ook deze klasse hoort zich aan een interface te houden, de ViewGui interface die dient om de custom GUI aan de GUI van de Client-simulator te koppelen:



60

Figuur 34: Framework UML





61

6.5 De GUI in beeld In de volgende hoofdstukken wordt de gebruikersinterface van de LoadTester uit de doeken gedaan. Dit zal gebeuren aan de hand van een surfsessie op www.gps-buddy.com.

6.5.1 Recorder en browser

Figuur 35: RecorderGUI

Dit is het gebruikersvenstertje dat kan worden gebruikt om een bestand te kiezen waarin de daarna volgende surfsessie zal worden opgenomen. Indien men na het kiezen van het bestand op de startknop drukt zal de proxy-server worden gestart. Deze zal op een bepaalde poort gaan luisteren naar requests van de browser. Nadat de browser proxy-instellingen op de proxy-server zijn afgestemd kan de surfsessie beginnen. De surfsessie op www.gps-buddy.com ziet er als volgt uit:

Figuur 36: Surfsessie op www.gps-buddy.com




62

6.5.2 LoadTester

Figuur 37: LoadTesterGUI

De LoadTester applicatie wordt gebruikt om opgenomen surfsessies opnieuw te simuleren. Hiervoor kan men bovenaan in het venster met de knoppen “Add recording” en “Remove selected recordings” de gewenste opnames van surfsessies toevoegen of verwijderen. Aan iedere surfsessie kan ook nog een getal worden meegegeven dat aanduidt hoeveel keer de simulatie van die bepaalde sessie zal worden gesimuleerd. Onder de lijst met surfsessies kan men een gewenst plugin bestand kiezen, hierin zitten de gewenste bestanden die resultaten zullen genereren. Vervolgens zal bij het drukken op de startknop de simulatie worden gestart. De vooruitgang kan gevolgd worden op de statusbalk.




63

Nadat de simulatie is beëindigd zal de resultatenknop beschikbaar worden. Bij een druk op deze knop zal het volgende venstertje worden geopend.

Figuur 38: Plugins venstertje

De inhoud in dit venstertje zal automatisch gegenereerd worden aan de hand van het plugins bestand. Iedere plugin die is terug te vinden in het bestand zal in dit venster worden opgenomen met daaraan een resultatenknop gekoppeld. Bij een druk op de resultatenknop zal er opnieuw een venstertje verschijnen met daarin de resultaten. Hoe deze resultaten worden weergegeven wordt bepaald door het verwijzing naar een bepaald venster in de plugin. De resultaten kunnen worden weergegeven in een standaard resultatenvenster, waarin de gewenste resultaten enkel tekstueel worden weergegeven.

Figuur 39: DefaultViewGUI




64

Men kan ook zelf een ventertje maken dat de resultaten weergeeft op de manier dat men het zelf wil. Als voorbeeld zit er een venstertje in LoadTester dat een grafische weergave geeft van de intervaltijd tussen de originele surfsessie en de gesimuleerde surfsessie. Bij het schrijven van zo’n venstertje dien je enkel aan de plugin de juiste view (= het geschreven venstertje) mee te geven en vervolgens zorgt het framework voor de juiste implementatie zodat je enkel op de “Results” knop moet drukken om het volgende te krijgen.

Figuur 40: CustomViewGUI

Deze grafiek kan aan de hand van de volgende code en de JFreeChart libraries worden gecreëerd. De data voor de grafiek bestaat uit een array van doubles waarvan een CategoryDataset moet worden gemaakt.




65

7 Lijst met figuren Figuur 1: Duke............................................................................................................................ 5 Figuur 2: HotJava browser ......................................................................................................... 7 Figuur 3: Connectie aanvraag tussen sockets........................................................................... 12 Figuur 4: Opzetten van de client-connectie.............................................................................. 12 Figuur 5: Mandrake Linux 9.0 ................................................................................................. 15 Figuur 6: IntelliJ IDEA............................................................................................................. 16 Figuur 7: Code voltooiing 1 ..................................................................................................... 17 Figuur 8: Code voltooiing 2 ..................................................................................................... 17 Figuur 9: Code voltooiing 3 ..................................................................................................... 17 Figuur 10: Code voltooiing 4 ................................................................................................... 18 Figuur 11: Code voltooiing 5 ................................................................................................... 18 Figuur 12: Code voltooiing 6 ................................................................................................... 18 Figuur 13: Code voltooiing 7 ................................................................................................... 18 Figuur 14: Import assistentie 1................................................................................................. 19 Figuur 15: Import assistentie 2................................................................................................. 19 Figuur 16: Coderings assistentie 1 ........................................................................................... 19 Figuur 17: Coderings assistentie 2 ........................................................................................... 19 Figuur 18: Implementatie van interfaces 1............................................................................... 20 Figuur 19: Implementatie van interfaces 2............................................................................... 20 Figuur 20: Implementatie van interfaces 3............................................................................... 20 Figuur 21: CVSWeb bij Beta9 ................................................................................................. 22 Figuur 22: JUnit – AWT .......................................................................................................... 26 Figuur 23: JUnit – Swing ......................................................................................................... 26 Figuur 24: HTTP functionaliteit............................................................................................... 27 Figuur 25: Exponentiele curve ................................................................................................. 40 Figuur 26: Vlakke curve (eXtreme Programming)................................................................... 40 Figuur 27: Planning game ........................................................................................................ 44 Figuur 28: Use case .................................................................................................................. 48 Figuur 29: Proxy-tunnel ........................................................................................................... 49 Figuur 30: Header Object UML ............................................................................................... 53 Figuur 31: Werking van de loadtester ...................................................................................... 54 Figuur 32: PlayerSession.......................................................................................................... 55 Figuur 33: Het spawnen van sessies......................................................................................... 57 Figuur 34: Framework UML.................................................................................................... 60 Figuur 35: RecorderGUI........................................................................................................... 61 Figuur 36: Surfsessie op www.gps-buddy.com........................................................................ 61 Figuur 37: LoadTesterGUI ....................................................................................................... 62 Figuur 38: Plugins venstertje.................................................................................................... 63 Figuur 39: DefaultViewGUI..................................................................................................... 63 Figuur 40: CustomViewGUI .................................................................................................... 64




66

8 Bronvermelding 8.1 Boeken • •

Richard Hightower/Nicholas Lesiecki, Java Tools for Extreme Programming: Mastering open source tools including Ant, Junit an Cactus, First Edition, John Wiley & Sons, Inc., USA, 2002, blz 516 David Flanagan, Java Examples in a Nutshell, Second Edition, O’Reilly & Associates, Inc., USA 2000, blz 566

8.2 Websites •

Java: http://java.sun.com http://java.sun.com/docs/books/tutorial/networking/sockets/index.html http://members.lycos.nl/java/page4.htm

•

JUnit: http://www.junit.org

•

IntelliJ: http://www.intellij.com http://www.intellij.com/docs/IDEA_30_Overview.pdf

•

HTTP: http://www.silicon-press.com/briefs/brief.http/brief.pdf http://www.informatica-educatie.nl/1985_3_frameset.html http://www.linuxfocus.org/Nederlands/May2000/article122.shtml http://www.w3.org/Protocols/rfc2616/rfc2616.html

•

Cookies: http://pisa.belnet.be/pisa/nl/cookies.htm http://www.dedigitalerevolutie.nl/redirect.asp?pagina=e-business/cookies.htm



Automated web applications testing

Recommend Documents