Samenvatting Internettechnologie 3e bachelor informatica UGent 31 mei 2014
1 Inleiding 1.1 Basisprincipes van netwerkgebaseerde computersystemen Een systeem is opgebouwd uit verschillende interagerende deelsystemen die zelf opgebouwd zijn uit deelsystemen of atomaire componenten. De architectuur van een systeem is de structuur en organisatie van het systeem en deze bestaat uit 3 componenten: Decompositie: het opsplitsen in deelsystemen zoals LAN, WAN, routers, hosts,... Functionaliteit: de functionaliteit van een bepaalde server is bv. email Interactie: hoe de communicatie tussen deelsystemen in elkaar zit. 1.2 Infrastructuur van netwerkgebaseerde systemen De infrastructuur is een platform voor specifieke applicatiesoftware en verzorgt communicatie, opslag, dataverwerking en interactie met de gebruiker. De hardware en softwareinfrastructuur kan men zien als een gelaagd systeem: applicatie middleware (ipc library, databank abstractie software) besturingssysteem (netwerkstack, bestandssysteem) hardware (netwerk, opslag) Iedere host heeft een OS voor netwerk, GUI, opslag,... de middleware is echter optioneel. De communicatiediensten zijn vandaag zeer belangrijk en moeten rekening houden met verschillende soorten communicatie. Zo kan men communicatie hebben in LAN s waarbij de servers op dezelfde fysieke locatie staan of WAN s waarbij dit niet zo is. Ook zijn de communicatienetwerken niet homogeen zoals mobiele netwerken. Een netwerk interpreteert geen data maar er wordt onderzoek gedaan op cognitive networking. Men wil vandaag vooral dat er geen congestion optreed op punten zoals de internetlijn, serverbelasting, peering punten,... Het bestandssysteem verzorgt veel taken: Organisatie van bestanden in directories Centralisatie van gegevens in server hosts (fysisch of logisch) wat backuppen makkelijker maakt. Het toekennen van permissies aan gebruikers File sharing Vaak zijn bestandssystemen over meerdere fysieke hosts gespreid en men spreekt dan van Distributed File System of DFS. De gebruiker ziet dit niet en men kan replicatiesoftware gebruike nvoor backups en beveiligde netwerkcommunicatie toepassen. Het gebruik van een DFS zorgt voor een lagere Total Cost of Ownership of TCO omdat het beheer eenvoudig en dynamisch is waardoor alles efficiënter kan. De meeste applicaties maken gebruik van databanken die met een DBMS worden beheerd zoals MySQL, MSSQL, PostgreSQL, SQLite,... en er bestaan standaardbewerkingen die alle DMBS systemen kunnen zoals opslag van nieuwe data, verwijderen van data, zoeken naar data (filters),... Het is niet wenselijk deze standaardbewerkingen voor elk DBMS opnieuw te implementeren en daarom kan men van een middleware softwarelaag gebruik maken. Dit is een API die DBMS, OS en programmeertaal onafhankelijk is, voorbeelden: 1
ODBC of Open DataBase Connectivity: initieel enkel voor Windows maar nu voor de meeste besturingssystemen en het wordt door veel DBMS leveranciers ondersteund. JDBC of Java DataBase Connectivity: een software API voor Java en als de DBMS software geen JDBC gebruikt is er een ODBC naar JDBC bridge. De veelgehoorde term the cloud is nogal vaag en kan software, gegevensopslag of infrastructuur betreffen. 1.3 Client/Server architecturen Deze architectuur is per definitie asymmetrisch wat wil zeggen dat vele clients één server aanspreken. De server is hierbij reactief omdat hij reageert op aanvragen van de clients die actief zijn. In dit soort architectuur wordt de business application gecentraliseerd en kan men zo goede beveiliging, onderhoud, bescherming,... aanbieden. De gebruiker heeft echter minder controle over de gebruikte versie van de software. Een server moet dus altijd beschikbaar zijn en weet niet wanneer een client een request zal sturen. Afhankelijk van wat de vereisten zijn voor de applicatie moet er dus aan redundantie gedacht worden en van aangepaste hardwareplatformen gebruik worden gemaakt. Clients mogen aan- en afgezet worden volgens behoefte van de gebruikers en we maken onderscheid tussen 3 soorten clients: 1. Fat client: zeer veel functionaliteit. 2. Thin client: uitsluitend presentatie en gebruikersinterface zoals een webbrowser. 3. Ultra-thin client: een apparaat enkel voor de grafische weergave van applicatieresultaten en verwerking van input van de gebruiker. Zoals remote desktop en Citrix. De presentatie wordt ook door de server gedaan. In een C/S architectuur hebben we typische verschillende lagen: Presentation layer: de volledige gebruikerservaring met bv. een GUI zit hierin. Ook de formattering van data als die van de server wordt verkregen. De browser vervult meestal alle taken in de presentatielaag bij webtoepassingen. Application layer: ook wel application logic of business logic. Deze laag omvat de applicatieservers die de applicatiefunctionaliteit implementeren, input ontvangen, beslissen welke acties er moeten worden ondernomen, data verwerken,... Veiligheid is zeer belangrijk in deze laag, zeker als men op het gevaarlijke internet moet. Data layer: ook wel database layer of Enterprise Information System (EIS). Deze laag ontvangt en stockeert data uit de applicatielaag en verzorgt ook het opvragen en doorgeven van data terug aan de applicatielaag. Onder data verstaan we records, bestanden,... en voorbeelden zijn ERP systemen en andere MIS of Management Information System systemen. Men kan diverse lagen redundant uitvoeren. Zo kan men op de datalaag data repliceren en partitioneren met fileservers, DBMS systemen,... Op de applicatielaag kan men gaan voor modulaire of redundante applicatielogica. Men kan zo een indeling van architecturen maken: One tier: de 3 lagen zijn in 1 entiteit geïntegreerd en de clients zijn terminals die zowel presentatie, applicatie en data vanop de server benaderen. Typisch is dit een mainframe architectuur die zeer gecentraliseerd is wat onderhoud gemakkelijk en goedkoop maakt. 2
Two tier: De clients worden steeds krachtiger en de presentatielaag bevindt zich nu op de client. Op deze manier kunnen meer veeleisende presentatiemanieren worden gebruikt en het netwerk moet enkel nog data doorsturen. Een API (zoals REST) wordt mogelijk. Dit is voldoende voor veel netwerkgebaseerde systemen maar als informatie kritisch is, is dit systeem ontoerijkend. Three tier: de drie lagen draaien nu elk op hun eigen machine. De presentatielaag bevindt zich bij de clients en zowel de applicatielaag als de datalaagdraaien op verschillende servers. Dit zorgt voor een hoge schaalbaarheid en beveiliging, de clients hebben namelijk geen rechtstreekse connectie met de datalaag. Ook kunnen verschillende applicaties dezelfde data gemakkelijk aanspreken. Men kan zowel logisch (firewall) als fysisch (verschillende datacenters) de data beveiligen. Men kan met contentnetwerken voor de data de performantie ook verbeteren. Four tier: dit wordt gebruikt in webapplicaties. De applicatielaag wordt nu verder opgesplitst in: Web layer of Integratielaag gericht op presentatie Business logic zoals regels, sessiebeheer,... Grote webapplicaties hebben vaak deze architectuur en.net en J2EE platformen hebben dit type architectuur. De Business logic gaat dan vaak via API invokatie terwijl de web layer in de browser draait. Interactie tussen de weblaag en business logic gebeurt met RMI of Remote Method Invokation. Dit laat toe dat gedistribueerde objecten met elkaar communiceren en er zijn heel wat techologieën zoals Java/RMI met Java Remote Method Protocol (JRMI), Distributed Component Object Model (DCOM) met Object Remote Procedure Call (ORPC), Common Object Request Broker Architecture (CORBA) met Internet InterORB Protocol (IIOP),.NET Remoting,... Onder business logic verstaan we: Business objecten: bv. een cataloog, een winkelkarretje, een account,... Business logic voor een object: bv. elke klant heeft een uniek account, een account bestaat uit naam, email en adres,... Soms spreken we van multi-tier als we de applicatielaag of middle tier verder opdelen. Een extra component is dan vaak de Data Access Layer (DAL). Het meerdere aantal lagen laat gemakkelijker onderhoud toe met een lagere TCO. Dit wordt typisch voor complexe software gebruikt waar meerdere personen onderhoud en beveiliging doen. De applicatieserver is dan vaak gedistribueerd en databankservers wordt door veel applicatieservers bevraagd. Een E-comerce platform zal typisch N-tier zijn opgebouwd. 1.4 Het opzetten en beheren van netwerkgebaseerde systemen Bij het opzetten van een dergelijk systeem moet men met enkele parameters rekening houden: Is het wenselijk een systeem netwerkgebaseerd te maken, vaak wel. Schaalbaarheid: het systeem moet goed kunne nomgaan met veranderlijke capaciteit en activiteit. Meestal zijn hiervoor verschillende hosts nodig wat de applicatie dus netwerkgebaseerd maakt. Administratie: er is nood aan automatisatie om alles op orde te houden. Netwerkgebaseerd kan men dit gespecialiseerd doen door een goede scheiding van de componenten. 3
Men moet dan een architectuur ontwerpen. Informatie is het basisproduct welke door data wordt voorgesteld. Men moet bij het ontwerp van de architectuur gemengt decompositie en assemblage toepassen. Decompositie is het opsplitsen in deelsystemen waarbij elk systeem onafhankelijk kan worden ontwikkelt en assemblage is de aanschaf en integratie van bestaande deelsystemen. Hoe meer deelsystemen hoe modulairder het systeem is. Bij het beslissen over de locatie van de data en de dataverwerking moet men rekening houden met 4 fundamentele taken qua data: 1. Verwerven 2. Opslaan 3. Verwerken 4. Presenteren Het toekennen van welke taken door welke host worden gedaan zal de performantie en communicatie bepalen. Steeds moet men zich afvragen hoe dicht de data zich bevindt, hoeveel gebruikers er zullen zijn, hoe veranderlijk de data is,... 1.5 Hoe Google werkt Het doel van Google is om het internet doorzoekbaar te maken en reclame te verkopen met AdWords en AdSense. Het werd opgericht door Larry Page en Sergey Brin na hun onderzoek aan Stanford University. Het google zoekmodel is gebaseerd op meer dan 100 verschillende parameters maar de belangrijkste is PageRank: Gebaseerd op citations wat wil zeggen dat men kijkt hoe populair een url is door het aantal verwijzingen te tellen. Het is een maat voor de waarschijnlijkheid dat een willekeurige surfer op die pagina terecht komt. De PageRank P R(A) van een webpagina A wordt als volgt berekent: [ P R(T1 ) P R(A) = (1 d) + d C(T 1 ) + + P R(T ] n) C(T n ) (1) waarin: T 1,..., T n : deze pagina s bevaten een hyperlink naar A, de citations. d: de damping factor : dit is de waarschijnlijkheid dat een gebruiker een bepaalde pagina verlaat voor een andere, meestal d = 0.85. C(x): het aantal linken dat vanuit pagina x vertrekt naar een andere pagina Er is steeds behoud van PageRank vanuit een bepaalde pagina. De berekening van PageRank is een iteratief proces en er zijn tools op het web die de PageRank kunnen berekenen. Soms gebeurt deze berekening via theoretische modellen of simulaties of soms is het gewoon een look-up service bij Google. Om te vermijden dat er SEO wanpraktijken gebeuren is niet bekend hoe de echte PageRank wordt berekend. Vanuit SEO standpunt wil men zoveel mogelijk inkomende links, citations. Hoe minder uitgaande links in de pagina die verwijzen naar je webpagina hoe beter, want de citations moeten uniek zijn. 4
PageRank is uiteraard niet het enige criterium en moet gezien worden als een vermenigvuldigingsfactor in het hele zoekproces. De meeste zoekmachienes associeerden de tekst van een hyperlink, de anchor text, enkel met de pagina waarop hij voorkomt. Google associeert de anchor text ook met de webpagina waarnaar hij verwijst. Dit omdat anchors vaak goede beschrijvingen bevatten. Ook kunnen links naar afbeeldingen, video of audio wijzen die anders niet tekstgebaseerd kunnen worden geanaliseerd. Het is de enige manier om te crawlen op sommige dingen. Het gebruik van anchor text houdt ook risico s in zoals een Google Bom. De gebruikers registreren veel domeinen die allemaal naar een site verwijzen met dezelfde anchortekst xyz. Als men dan de term xyzïntikt in Google is de kans groot dat men op die pagina terecht komt. Als veel gebruikers samenspannen kan dit effect ook optreden. Een voorbeeld zijn de woorden miserable failure. Naast de anchor text wordt ook de volledige raw HTML van een pagina bijgehouden en de visuele presentatie van de woorden. Algemeen gebeuren volgende 4 stappen bij een zoekopdracht: 1. Zoek alle webpagina s die de trefwoorden van de zoekactie bevatten. 2. Rangschik volgens de features per pagina zoals trefwoorden en opmaak ervan. 3. Breng het principe van anchor text in rekening. 4. Pas PageRank toe als vermenigvuldigingsfactor. Google gebruikt dus een zeer sterk gelaagde architectuur omdat men een goede kwaliteit wil aanbieden met een zeer goede performantie. Er is een instantaan resultaat voor zoekacties in een systeem met honderden miljoenen webpagina s. Het Google-datacenter in België zorgt voor enkele milliseconden betere performantie in Europa. We bekijken nu de verschillende lagen: 1. Crawling: de GoogleBot download automatisch webpagina s en kan dit snel en efficiënt doen. Een URL server stuurt een lijst van de te downloaden URL s naar de crawlers. De gedownloade pagina s krijgen een unieke ID en worden gecomprimeert opgeslagen. 2. Indexing en Sorting: elk document wordt omgezet in een set van hits die in barrels of databases worden opgeslagen. Een hit is een woord met metadata zoals opmaak. Alle hyperlinks worden geparsed en in een Anchors database opgeslagen met de oorsprong, het doel en de anchor text. De sorter sorteert de inhoud van de barrels zodat de docid s en wordid s gemakkelijk gevonden kunnen worden. 3. Interne operaties: de URL resolver haalt URL s uit de anchor databae en converteert ze naar absolute URL s waarna ze aan de docid s in de barrels worden gelinkt. Er wordt dan een database met alle docid s opgebouwd en er wordt een checksum berekend van de URL s gelinkt aan de docid s en daarop wordt gesorteerd. Zoeken kan nu met binary search worden gedaan. Een database met alle links wordt gebouwd wat dus een verzameling van paren docid s is, daaruit wordt dan de PageRank berekend. 4. Searching: het Google Query Evaluation Process verloopt in 5 stappen: (a) Interpreteer de query. (b) Zet zoekwoorden om in wordid s. (c) zoek in de documentenlijst naar docid s die alle zoektermen bevatten. (d) Bepaal pagina rank op basis van hit-types (title, anchor,...) met hun gewicht. (e) Combineer het resultaat met PageRank. 5
1.6 Hoe Amazon werkt Amazon wil een plaats zijn waar mensen alles kunnen vinden. Ze werken daarvoor samen met e-commerce partners en bieden vele diensten aan. Amazon heeft ook andere diensten zoals IMDB. De Amazon Web Services of AWS zijn cloud diensten: EC2 of Elastic Compute Cloud: dit is aanpasbare rekencapaciteit aangerekend in CPUuur en dataverkeer. Er kunnen binnen minuuten servers aangemaakt worden met AMI s of Amazon Machine Images. Je kan publieke gebruiken met linux of windows, private met eigen app s of betalende door third party. S3 of Simple Storage Service: men kan objecten tot 5Gb opslaan in de cloud. Dit kan zowel publiek en privaat door URL met ACL (Acces Control List). Er is een hoge beschikbaarheid van 99,99% en ondersteuning voor BitTorrent en verschillende API s. De objecten zitten in buckets. SimpleDB SQS of Simple Queue Service: een schaalbare berichtenservice die zeer betrouwbaar is en tot miljoenen berichten per dag kan gaan. Inter Process Communicatie, buffering,... zijn mogelijkheden en er is een simpele 10 methoden platformonafhankelijke API. Mechanical Turk: sommige taken zijn moeilijk voor een computer maar makkelijk voor een mens zoals beeldherkenning, spraakverwerking,.... De Mechanical Turk API stelt ontwikkelaars in staat gemakkelijk menselijke intelligentie toe te passen. De developer geeft een Human Intelligence Task op die aan echte mensen worden overgelaten. Voorbeelden zijn vertalingen, the sheep market,... Deze diensten worden aangeboden om de rompslomp en kosten van web development weg te namen. Het beheer van servers, voorzien van koeling, bandbreedte, stroom en het voorbereiden op schaalvergroting is vaak moeilijk en duur. Men moet grote investeringen doen op voorhand indien men wil voorbereid zijn. Obstakels zijn schaalvergroting zoals een continue stijging in gebruik (youtube, facebook). Andere opstakels zijn pieken zoals Slashdot of de jaarlijkse belastingsaangifte. De oplossing is Web-scale computing waarbij vaste kosten voor een hoge capaciteit variabel worden omdat er schaalbaarheid op aanvraag is. Er is een hoge beschikbaarheid en betrouwbaarheid. En de envoudige API s en lage TTM (Time To Market) maken het kost-effectief. Amazon bekijkt welke delen van zijn techologie het aan ontwikkelaars kan aanbieden, dan worden obstakels om ermee aan de slag te gaan verwijderd of verkleind en zo bekomt men een verzameling API s en businessmodellen voor Amazon services. Ze bieden zowel data aan, infrastructuur (SQS, S3, EC2), zoeken tot zelfs mensen. 1.7 Energieverbruik Webapplicaties vereisen veel rekenkracht en dus moeten meer machines worden ingezet. Datacenters zetten daarom massaal in op groene energie en datacenters worden strategisch geplaatst in koude gebieden dicht bij water. 2 Clustering Bij de karakterisering van de werklast bij een goede capaciteitsplanning is clustering zeer belangrijk. Deze algoritmen kunnen het optimaal aantal basiscomponenten bepalen en ze geven waarden voor de parameters die deze basiscomponenten karakteriseren. We vermelden hier twee basisprincipes MST of Minimum Spanning Tree en het k-gemiddelden algoritme. 6
2.1 MST-algoritme Dit is een hiërarchisch algoritme dat start met het beschouwen v an alle individuele gebeurtenissen als zijnde clusters. Twee clusters die het dichtst bij elkaar liggen worden dan samengevoegd tot een nieuwe cluster totdat het gewenst aantal bereikt is. Meer formeel: 1. Als de performantiedata van P gebeurtenissen gekend is waarbij elk meetpunt uit K metingen bestaat. We hebben danp meetpunten van de vorm (D p1, D p2,..., D pk ) met p = 1,..., P. 2. Kies J als het gewenste aantal clusters. 3. Stel het actuele aantal clusters j gelijk aan het aantal meetpunten, dus j = P. 4. Herhaal volgende stappen totdat j = J: (a) Bepaal de parameterwaarden van de centroïden C 1,..., C j voor elk van de j actuele clusters. Deze zijn gemiddelden van de parameterwaarden van alle meetpunten van de cluster. (b) Bereken de (bv. euclidische afstand) tussen elk paar centroïden en bouw de j j- interclusterafstandsmatrix op. Element (m, ) stelt dan de afstand voor tussen clusters m en n. (c) Bepaal het minimale van nul verschillende element (q, r) in de interclusterafstandsmatrix. (d) Voeg de clusters q en r samen en verminder het actuele aantal clusters j met 1. 2.2 k-means Het k-gemiddeldenalgoritme is een niet-hiërarchisch clusteringsalgoritme dat start met het kiezen van J meetpunten/gebeurtenissen. Deze worden als beginschatting gebruikt voor de centroïden van de J clusters die moeten worden gevonden. De andere meetpunten worden toegevoegd aan de dichtstbijzijnde clusters. Deze allocatieprocedure wordt iteratief uitgevoerd totdat geen enkel meetpunt meer van cluster verandert, of tot een vooraf vastgelegd maximum aantal iteraties is bereikt. Meer formeel: 1. Als de performantiedata van P gebeurtenissen gekend is waarbij elk meetpunt uit K metingen bestaat. We hebben danp meetpunten van de vorm (D p1, D p2,..., D pk ) met p = 1,..., P. 2. Kies J als het gewenste aantal clusters. 3. Kies I het maximum aantal iteraties. 4. Kies J startpunten die zullen gebruikt worden als initiële schattingen voor de clustercentroïden. Men kan bv. de eerste J meetpunten kiezen of de J meetpunten die zich mutueel het verst van elkaar bevinden. 5. Beschouw elk meetpunt en vloeg het toe aan de cluster met de dichtstbijzeijnde centroïde. Herbereken de parameterwaarden van deze centroïde met het nieuwe meetpunt erbij. 6. Herhaal iteratiestap 4 tot geen enkele meetpunt meer van cluster verandert of tot I iteraties werden gedaan. Voor een voorbeeld van het clusteringalgoritme zie het bijbehorende clusterdocument. 7
3 Operationele aspecten 3.1 Performantie van webgebaseerde toepassingen Bij het meten van de tijd die verstrijkt om een webrequest te beantwoorde zijn 3 componenten belangrijk: 1. Client (browser): de eidgebruiker klikt op de link waarna de browser in lokale cache kijkt. Indien de pagina gevonden werd is de antwoordtijd R c. Anders moet er een IP-adres aan de DNS server worden gevraagd, een TCP connectei gemaakt worden en een HTTP request verzonden en ontvanen worden. 2. Newerk: transport van de data 3. Server (webserver): de server ontvangt de HTTP-vraag en voert deze uit waarna het antwoord wordt verstuurd en afhankelijk van persistent of niet de connectie wordt gesloten. Er zijn dus heel wat verschillende tijden om te meten: R r : de totale antwoordtijd R N1 : de transfer van de HTTP-vraag (client naar server) R N2 : de transfer van het HTTP-antwoord (server naar client) R S : de server residentietijd (tijd voor serveractiviteit) R C : de client residentietijd (tijd voor clientactiviteit) Als we stellen dat R N = R N1 + R N2 dan geldt: R r = R C + R N + R S (2) Hierbij is R C << R N + R S. Indien we met caching te maken waarbij hebben we: p C = N C N P (3) met p C de succesrate wat het aantal cache hits gedeeld door het totaal aantal aanvragen is. De totale antwoordtijd R r wordt nu dus: De cachegrootte heeft dus een grote impact op de browsesnelheid. R r = p C R C + (1 p)r r (4) Een succesvolle webtoepassing heeft een sterke verhoging van het aantal clients en servers. Schaalbaarheid is dus zeer belangrijk zeker als men weet dat de globale performantie wordt beperkt door de traagste component in het systeem. Een bottleneck is een deelsysteem dat de globale performantie beperkt en identificatie daarvan is zeer belangrijk en deze moeten het eerst worden aangepast bij upscaling. Het is belangrijk om een inschatting te kunnen maken van de benodigde resources. Zo kan men schatten heoveel objecten en welk type er zullen worden opgeslagen, hoeveel requests met welke omvang er zullen zijn,... Voor een publieke applicatie is dit veel moeilijker dan voor een interne applicatie. Voor een systeemadministrator is performantie gelijk aan de verreiste bandbreedte, de gegarandeerde uptime,... voor gebruikers is dat de beschikbaarheid, de snelheid van antwoorden,... Hoe performant een applicatie is, is ook grotendeels perceptie en er moeten dus kwantitatieve performantiematen zijn. Bij webtoepassingen heb je niet steeds alles onder controle (flash crowds, 8
slechte verbindingen,... ) Enkele belangrijke performantiematen zijn de volgende: Throughput: de verwerkingscapaciteit vande connectie tussen client en server. Dit wordt in aantal HTTP-requests/sec of bps uitgedrukt. Latency: de tijd die de server nodig heeft om antwoord te formuleren. De totale antwoordtijd hnagt af van de latency en de throughput en de verwerkingstijd van de clients. Afgeleide maten zijn packet loss in procent wat het aantal fouten per seconde betekent. De populariteit van de toepassing komt overeen met het aantal gevraagde connecties met de server. Service Levels zijn niveau s die aangeven welke mate van dienstverleningskwaliteit wordt geleverd. Periodiek wordt gemeten wat de performantiematen zijn om adequate capaciteitsplanning te kunnen uitvoeren op piekmomenten. Een SLA of Service Level Agreement is een overeenkomst tussen provider en afnemer over de geleverde kwaliteit. Gebruikers ervaren 0.1 seconde als instantaan, 1 seconde als traag maar doenbaar en vanaf 10 seconden is het zeer slecht. Proxy servers die dichter bij de user staan kunen latency korter maken en bandbreedtevereisten verlagen door ze te spreiden. De Content Delivery Netwerken of CDN s doen dit. De proxy server is nu een client en server tegelijk met een lokale cache. Voor een proxyserver kan men volgende performantiematen gebruiken: De succesverhouding p C = N C N P : dit zecht niets over de bandbreedte. De byte-succesverhouding: dit zegt wel iets over de bandbreedte. Hoeveelheid getransfereerde data: het totaal aantal verstuurde bytes uit de cache. Scripting voegt veel functionaliteit toe en maakt websites dynamisch. De keuze over welke scripts op de server lopen en welke op de client kan een grote impact hebben op de globale performantie. De distributie van de te verwerken objecten (bv. bestandsgrootte) en de populariteit ervan zijn twee belangrijke aspecten van de performantie. De invloed van de bestandsgrootte-distributie (of bijhorende verwerkingstijd) heeft volgende aandachtspunten: Een niet te verwaarlozen staart wat wil zeggen dat de kans op zeer grote bestanden niet te verwaarlozen is. Afgeleide grootheden zoals gemiddelde vertonen grote variabiliteit. De betekenis van individuele performantiemetingen op basis van bestandsgrootte moeten geminimaliseerd worden. De verwerkingstijd van bestandsgrootte-distributie of bijhorende verwerkingstijd volgt veelal een pareto-distributie: 9
We kunnen de CPU-belasting indelen in klassen en dan daarover het gewogen gemiddelde nemen. Stel volgende verdeling van de CPU-tijd van 10 HTTP-requests reeds gesorteerd: 0.3 0.4 0.6 0.7 0.9 1.4 1.5 1.5 1.7 18.1 t < 1s t 6s t 6s De gemiddelde CPU tijd over alle klassen is dan 6,7s. De algemeen gewogen CPU tijd wordt echter: 5 0.58 + 4 1.53 + 18.1 = 2.71 10 De 2,71 seconden is nu wel de meest relevante waarde. Niet enkel de bestandsgrootte is belangrijk maar ook de populariteit van de objecten. Dit is ook een goed gedocumenteerd fenomeen en er bestaat de wet van Zipf die stelt dat hoe groter de populariteitsrang p hoe minder populair (f = frequentie van optreden) het object is: f 1 p (5) De populariteitsrang is gewoon het volgnummer van de pagina indien deze op dalende populariteit worden gesorteert. Stel dat je paginas A en B hebt waarbij pagina B 100 bezoekers per dag heeft en pagina A 10 bezoekers, dan krijgt pagina B populariteitsrang 1 en pagina A populariteitsrang 2. Ter volledigheid geven we nog eens de netwerkkarakteristieken weer: Latentie of vertraging: dit is de tijd nodig om één pakket van client naar server of omgekeerd te transfereren. De Round Trip Time of RTT is een maat om latentie uit te drukken in seconde en telt de totale tijd voor een pakket om aangevraagd en teruggezonden te worden. Bandbreedte: een paat voor de snelheid waarmee data kan worden verzonden, in bps uitgedrukt. Bandbreedte-latentieproduct een capaciteit voor datatransfer van de client naar de server of omgekeerd in aantal bit of byte. Er is altijd een groot verschil tussen gemiddelde activiteit en piekactiviteit, daarom is het aan te raden om met percentielen te werken. 3.2 Capaciteitsplanning Een belangrijk begrip bij capaciteitsplanning is adequate capaciteit en er is een methodologie nodig voor capaciteitsplanning met: Efficiënte (deel)systeemconfiguratie Geschikte netwerk- of systeemconfiguratie Kostefficiëntie met personeel- en investeringskosten Een SLA is het contractueel vastleggen van performantievereisten zoals een server die minimum zoveel tijd beschikbaar moet zijn of zoveel requests per seconde moet aankunnen. Als er geen SLA is geldt een best-effort approuch waarbij men een zo goed mogelijke dienstverlening nastreeft. Bij het kiezen van de goede technologie speelt niet alleen de performantie een rol maar ook de kennis, de kost,... Hoe strenger de SLA is hoe hoger de kosten typisch zijn en er zijn 2 types kosten: CAPEX: dit zijn de opstartkosten en omvatten hard- en software, installatie, personeel,... OPEX: operationele kosten met administratie, onderhoud, telecomkosten 10
Schaalbaarheid is belangrijk maar niet altijd eenvoudig te realiseren. De definitie van adequate capaciteit is nu dus: Het continu realiseren van de SLA s. Dit gebruik makende van vooraf gedefinieerde technologieën/standaarden De realisatie gebeurt binnen de beperkingen van de kosten. De heterogeniteit aan diverse deelsystemen maakt het soms moeilijk, zo zijn er veel OSen, hardwaresooften,... Er zijn 3 modellen om de adequate capaciteit bij C/S-gebaseerde systemen te bepalen: 1. Werklastmodel: dit model beschrijft de vraag naar middelen binnen een representatieve tijdsspanne. 2. Performantiemodel: dit voorspelt de systeemperformantie als functie van de systeembeschrijving en de werklastparameters. De antwoordtijden en verwerkingssnelheid komen dan uit het model en deze kunnen met de SLA vergeleken worden. 3. Kostenmodel: de kosten voor soft- en hardware, telecom en administratie van het systeem worden bekeken. 3.2.1 Werklastmodellen De werklast wordt beschreven door een systeem in deelsystemen op te splitsen en deze dan met kwantitatieve parameters te beschrijven. Twee basisparameters zijn: Workload Intensity (WI): een maat voor de globale load op het systeem. Service Demand (SD): een maat voor tijd nodig voor elke resource component (bv. CPU, RAM). Veel parameters worden afgeleid of geschat omdat ze niet rechtstreeks kunnen worden gemeten. Bij een hoge werklast zijn er veel gebeurtenissen en alle individuele werklastparameters van de gebeurtenissen bekijken is dan niet altijd relevant. Daarom gebruiken we een compacte representatie, namelijk het werklastmodel. We splitsen door middel van clustering de werklast op en berekenen de gemiddelden van de clusters omdat het globaal gemiddelde niet veel zegt. Het aantal clusters beïnvloed de nauwkeurigheid van het werklastmodel en clusteringsalgoritmen berekenen 11
het optimaal aantal clusters. Idealiter geven performantiemonitors een waarde aan voor elke werklastparameter. In de realiteit zijn er vaak geen goede performantiemonitors beschikbaar en noodgedwongen wordt er te weinig tijd aan performantiemonitoring besteed. Sommige monitors geven globale parameter waarden zoals het totaal aantal getransfereerde pakketten in LAN, totale CPU benutting,... opsplitsing is dan beter en vuistregels om dat te doen werken vaak al goed. Vaak is het afdoende enkel de performantieparameters van de bottlenecks te meten en deze dan te vertalen naar andere omstandigheden en types van hardware. Best kiest men een vastgelegde benchmark als maatstaf. Op die manier kan men een syntetisch model gebruiken om het model te calibreren indien het verschil tussen de syntetische en werkelijke werklast te groot wordt. Op basis van de huidige toestand en de historiek kan men de toekomstige werklast en pieken voorspellen. Op deze manier kan men een strategie uitstippelen en eventueel hardware aanpassen. Een correcte trendanalyse is dus zeer belangrijk. 3.2.2 Performantiemodellen In dit model is het systeem een black box. Interne details worden niet gemodelleerd en enkel verwerkingscapaciteit wordt gemodelleerd met de verwerkingsfunctie of throughput function: X 0 (k) met k het aantal aanwezige aanvragen (6) Het toestandstransitiediagram (TDD) of State Transition Diagram (STD) bevat de mogelijke toestanden van (deel)systemen en de transities tussen toestanden waarin het systeem zich kan bevinden. Een alternatief is het modelleren van individuele componenten/deelsystemen. Het eerste servermodel gaat uit van een oneindige populatie en oneindige wachtlijn. We nemen nu een aantal parameters op in het model: λ (aanvragen/s): de aankomstsnelheid van de aanvragen X 0 (k) = µ: we modelleren een homogene werklast waarbij alle aanvragen statistisch gelijk zijn en enkel het aantal een invloed heeft. We hebben dus een constate verwerkingsfunctie. De oneindige wachtlijn in het model zorgt ervoor dat alle aanvragen worden behandeld en er dus geen verloren gaan. We gaan dan ook uit van een operationeel overzicht waarbij het aantal aanvragen bij het begin van de observatie gelijk is aan dat van het einde van de observatie. Tijdens de observatie kan het wel schommelen. We hebben dus: λ (aanvr/s) µ (aanvr/s) aankomst request server aanvraag in wachtlijn aanvraag wordt behandeld Het model berekent: Het model moet nu p k berekenen, dat is de fractie van de tijd dat er k aanvragen in de server aanwezig zijn. Het gemiddeld aantal aanwezig aanvragen. De gemiddelde response tijd. De benuttiging van de server. De verwerkingssnelheid van de server. 12
De toestand van de server wordt door 1 parameter gekarakteriseerd, namelijk het aantal aanvragen aanwezig in de server. Dit heeft als gevolg dat het gedrag onafhankelijk is van de manier waarop de toestand werd bereikt en dat het gedrag onafhankelijk is van de huidige toestand. We hebben een geheugenloos of Markov-systeem met een aftelbaar oneindig aantal toestanden k en kunnen dit in een TTD voorstellen: Het operationeel evenwicht stelt nu dat de flow in en uit elke toestand (de pijlen) gelijk is, dit noemen we het global balance principle. Dit geeft ons een evenwichtsvoorwaarde aan de grenzen: Dit heeft als gevolg: λp 0 = µp 1 µp 1 = λp 0 (λ + µ)p 1 = λp 0 + µp 2 µp 2 = λp 1 (λ + µ)p 2 = λp 1 + µp 3 µp 3 = λp 2 µp k = λp k 1 p k = p 0 ( λ µ) k met k = 0, 1, 2,... (7) en dus is p 0 de fractie van de tijd dat het systeem idle is. Het systeem bevindt zich steeds in een toestand en dus: ( [ k λ ( ) ] k 1 λ p k = p 0 = 1 p 0 = = 1 µ) λ µ µ k=0 k=0 k=0 (8) De voorwaarde voor convergentie is nu dat de snelheid van de aankomst van de vragen λ kleinder is dan de verwerkingssnelheid µ en dus: λ < µ De benuttiging U van de server wordt gegeven door: U = 1 p 0 = λ µ p k = (1 U)U k (9) De toestandsdistributie is dus enkel afhankelijk van de benuttiging en niet van de individuele waarden. Het gemiddeld aantal aanvragen in de server is nu dus gelijk aan: N = kp k = (1 U) ku k U = (1 U) (1 U) 2 = U 1 U k=0 k=0 (10) en de gemiddelde verwerkingssnelheid van de server is dus gelijk aan: X = Uµ + (1 U) 0 = λ (11) 13
De gemiddelde verwerkingssnelheid is dus de gemiddlede aankomstsnelheid. Dit is logisch aangezien er geen aanvragen verloren gaan. We kunnen nu ook de gemiddelde antwoordtijd gaan berekenen: ( ) ( ) U 1 N = RX R = = U /λ 1 U λ 1 U = 1 /µ 1 U = S 1 U (12) waarbij S de gemiddelde verwerkingstijd per aanvraag is. Als U laag is (naar 0 gaat) dan is de gemiddelde antwoordtijd de gemiddelde verwerkingstijd per aanvraag en is er geen verlies ten gevolg van wachten. Als U hoog is (naar 1 gaat) dan is de antwoordtijd oneindig lang en is er dus veel tijdsverlies ten gevolg van wachten in de wachtlijn. Het tweede servermodel heeft een oneindige populatie maar een eindige wachtlijn. Net zoals in het eerste model is er dus een zeer groot aantal gebruikers maar de server heeft een beperking op het aantal aanvragen dat kan worden behandeld en qua geheugen en opslag. Niet alle inkomende aanvragen kunnen in de wachtlijn worden gezet: k W (k = 0, 1, 2,..., W ) We passen het model nu aan om hiermee rekening te houden. De toestand van de server wordt nog atlijd door n parameter beschreven met de bijkomende voorwaarde dat er een eindig aantal toestanden zijn: De evenwichtsvoorwaarde aan de grenzen is dus: p k = p 0 ( λ µ) k k = 0, 1, 2,..., W (13) Om p 0 te berekenen weten we dat het systeem zich in een toestand bevindt: W W ( ) ] k λ [1 ( p k = p 0 = p λ /µ) W +1 1 1 0 = 1 p µ 1 λ 0 = λ /µ /µ 1 ( λ /µ) W +1 (14) k=0 k=0 De benuttiging van de server wordt gegeven door: ( λ /µ) [1 ] ( λ /µ) W U = 1 p 0 = 1 ( λ /µ) W +1 (15) en de fractie verloren aanvragen is dan p verlies = p W. Op een gegeven punt heeft het verlengen van de wachtrij geen invloed meer op het aantal verloren aanvragen. Het is een dalend exponentieel verband. We berekenen nu het gemiddeld aantal aanvragen in de server: N = W W kp k = p 0 k ( λ /µ) k (16) k=0 14 k=0
Met behulp van de hulpformule: bekomen we N = W k=0 ka k = W aw +2 (W + 1)a W +1 + a (1 a) 2 (17) [ ] ( λ /µ) W ( λ /µ) W +1 (W + 1) ( λ /µ) W + 1 [ 1 ( λ /µ) W +1] (1 λ /µ) (18) Op een gegeven moment zal het gemiddeld aantal aanvragen in de server een constante worden en niet langer stijgen indien de wachtrij langer wordt. Links zien we dus de fractie verloren aanvragen in functie van de lengte van de wachtlijn en rechts het gemiddeld aantal aanvragen in de server in functie van de lengte van de wachtlijn. De gemiddelde verwerkingssnelheid van de server wordt nu gegeven door: X = U µ + (1 U) 0 = λ 1 (λ /µ) W 1 ( λ /µ) W +1 (19) De gemiddelde verwerkingssnelheid is dus kleiner dan de gemiddelde aankomstsnelheid omdat er aanvragen verloren gaan. De gemiddelde antwoordtijd wordt nu gegeven door: R = N X = S W (λ /µ) W +1 (W + 1) ( λ /µ) W + 1 [ ] 1 ( λ /µ) W (1 λ /µ) (20) Net zoals het gemiddelde aantal aanvragen zich stabiliseerd met een stijgende wachtlijn doet ook de gemiddelde verwerkingssnelheid zich en dit met hetzelfde soort verband tussen de twee, exact hetzelfde met de gemiddelde antwoordttijd, dit is zeer logisch natuurlijk. We hebben dan ook een veralgemeend servermodel met als karakteristieken: Een oneindige populatie De aankomstsnelheid van de aanvragen hangt af van de toestand De behandelingssnelheid van de aanvragen hangt af van de toestand Er is een eindige wachtlijn 15
We berekenen nu weer deze formules en bekomen: W k=0 k 1 λ i p k = p 0 (21) µ i+1 i=0 k 1 λ i p 0 = 1 p 0 = µ i+1 i=0 [ W k 1 λ i µ k=0 i=0 i+1 ] 1 (22) U = 1 p 0 (23) 4 Hypermedia X = N = W µ k p k (24) k=0 R = N X = W kp k (25) k=0 W kp k k=0 (26) W µ k p k De termen het internet en het web worden vaak verkeerdelijk als synoniemen gebruikt: k=0 Het internet: een internationaal computernetwerk Het web: het WWW of World Wide Web is een informatiesysteem bovenop het internet bestaande uit geconnecteerde documenten en diensten. Vroeger werden meestal adressen van ftp servers gegeven of emails met commando s. Het internet was toen al goed uitgerold. Op het huidige web heb je echter geen technologische kennis meer nodig en verkrijg je een webpagina met links naar alle nodige documenten. We hebben dus: Hypertext: een document waarin kan worden gelinkt naar andere documenten. Vanop een startpagina kan men dus naar alle beschikbare data gaan. Hypermedia: het zelfde zoals hypertext maar dan voor gelijk welke media. De visie en implementatie van hypertext is veel veranderd van de originele visie van Ted Nelson. Hij had een fexibele manier van documenten linken voor ogen die multidirectioneel is en waarbij alle documenten aan elkaar hangen. Met een onderverdeling in: Chunk-style-hypertext: keuzemogelijkheden via bv. voetnoten. Collateral hypertext: annotaties over de eigenlijke tekst. Strechtext: evoluerende teksten met externe fragmenten en LOD. grand hypertext: alles wat bestaat over een onderwerp. 16
Het Xanadu platform van Ted Nelson alsook enkele andere platformen braken niet door omdat ze gesloten waren. De gepresenteerde informatie bevatte keuzes beperkt tot een lokale verzameling documenten. Er was n lokale databank en links naar andere systemen of software was niet mogelijk. Het idee van Tim Berners Lee werd niet enthousiast onthaald omdat het enkel tekst bevatte terwijl de andere systemen afbeeldingen, kaarten,... hadden. Het World Wide Web was echter heel simpel en had globale schaalbaarheid waardoor dit een van de snelst groeiende toepassingen was op het Internet. Het systeem bestaat uit 3 basiscomponenten: 1. Uniform Resource Locator (URL): dit is een unieke identificatie van resources bestaande uit een protocol, domein en pad. 2. HyperText Transfer Protocol (HTTP): dit werkt met een request/response paradigma en bevat standaardmethoden voor data. De server antwoordt dan met de gevraagde representatie. 3. HyperText Markup Language (HTML): deze taal wordt gebruikt om hypertextdocumenten op te stellen. De browser geeft deze weer en kan de URL s gebruiken. Bovenstaande 3 zaken die samen het Web vormen zijn toevallig zo groot geworden omdat er in het begin nog geen formele definitie en analyse van de architecturale principes was. Vandaag wordt HTTP voor veel meer dan alleen maar HTML gebruikt volgens de REpresentational State Transfer of REST manier. Dit werd in 2000 voorgesteld door Roy Thomas Fielding en het is een conceptueel framework voor het analyseren van gedistribueerde hypermediasystemen zoals het Web. Het is een manier om data te bekijken en te bewerken en is toekomstbestendig: De start is een systeem zonder grenzen Er worden constraints toegevoegd om gewenste eigenschappen te bekomen. De client en server zijn volledig ontkoppelt zodat er een onafhankelijke evolutie kan zijn. Twee bekende constraints zijn: Client-server constraint: dit leidt tot de gewenste schaalbaarheid. Cacheability constraint: antwoorden kunnen en mogen gecached worden, ook dit leidt tot schaalbaarheid. HTTP is niet de enige implementatie van REST en niet elke HTTP toepassing houdt zich aan de REST constraints. Het is echter wel belangrijk om zich aan de REST constraints te houden om alle gewenste eigenschappen ervan te bekomen. Twee unieke constraints voor REST (en dus het Web) zijn statelessness en uniforme interface. Het toestandsloos zijn wil zeggen dat de interpretatie van een request niet mag afhangen van de vorige request. Dit leidt tot volgende eigenschappen: Visibility: elke request bevat alle nodige context om het te begrijpen. De request is op zichzelf dus al voldoende om de interactie te visualiseren. Reliability: het falen van een request heeft geen impact op het al dan niet falen van een andere request Scalability: de server hoeft geen toestand bij te houden waardoor meer requests kunnen worden afgehandeld. Deze architectuur wil niet zeggen dat de server helemaal geen toestand bijhoud, we maken onderscheid tussen: Resource state: deze wordt op de server bijghouden en betreft resources. Deze toestand is de gecombineerde toestand van alle resources binnen een applicatie en wordt wel op de server opgeslagen. Dit maakt dus geen deel uit van de statelessness constraint. 17
Application state: deze zit vervat in de body van berichten en deels op de client. Deze toestand beschrijft waar de client zich bevind in de interactie met de resource state en bevat info zoals de user agent, welke links de client naartoe kan, of de client ingelogd is... Een resource is elk stukje informatie dat benoemd kan worden, in de web-toepassignen wereld zijn het conceptuele stukken informatie die door de server kunnen worden aangeboden. Een resource identificeert constante concepten en dus geen concrete waarden die een concept aanduiden op een bepaald ogenblik. Een resource is dus nooit gelijk aan zijn waarde. Clients kunnen de resource state bekijken en/of manipuleren en dat is net waarom een client met een server interageert. De resources zijn namelijk niet beschikbaar op de client en daarom wordt het client/server-paradigma gebruikt. Het is niet de taak van de server om de application state bij te houden. Als een antwoord verstuurd is mag de server vergeten dat dit gebeurde en dit komt de schaalbaarheid ten goede. Het maakt niet uit hoeveel clients er verbinden aangezien ze zelf hun application state bijhouden. De REST architecturale stijl benadrukt sterk de uniforme interface: 4 constraints: identificatie van resources, manipulatie van resources via representaties, zelfbeschrijvende objecten, hypermedia als moter van application state (hypermedia constraint) Dit leidt tot simplification, visibility en independent evolution Een resource moet uniek identificeerbaar zijn en elk stukje info dat uniek identificeerbaar is, is een resource. Een resource kan meerdere identifiers hebben maar elke identifier mag slechts naar één resource wijzen. Op het web zijn de URL s de identifiers. In REST hebben de clients nooit rechtstreekse toegang tot resources en alle interacties gebeuren via representaties. Een representatie representeert een resource in een formaat gekozen door de client of server (in het web bv. HTML, txt, JSON, RDF,... ). Dit formaat wordt ook wel het media type genoemd en eenzelfde resource kan soms in meerdere media types worden voorgesteld. Een representatie omvat de data en de metadate (bv. de HTML headers). Berichten moeten zelfbeschrijvend zijn en dus zonder voorgaande informatie kunnen worden geïnterpreteerd, of dus zonder out-of-band informatie. HTPP heeft hiervoor de bekende GET, POST, PUT, DE- LETE,... methoden. Out-of-band info zou bijvoorbeeld documenten leesbaar voor mensen kunnen zijn, clients kunnen daardoor moeilijker met de toepassing interageren. Hypermedia is de motor van application state. Er wordt vereist dat de interactie gegeven wordt door informatie in hypermedia representaties die door de server uitgestuurd worden. Dit is dus fundamenteel verschillend van: Out-of-band informatie zoals documentatie Een lijst met stappen zoals bij RPC interacties Een REST systeem moet de representaties van hypermedia aanbieden die elementen bevatten die een client toelaten naar een volgende stap te gaan. In HTML zijn dit links, knoppen en formulieren. Andere representaties hebben andere elementen. Men verwacht dus dat een webpagina links bevat naar alle mogelijke volgende stappen, dit is echter niet altijd zo. Zo kan een webshop niet altijd een rechstreekse productlink aanbieden en men noemt dit unidirectionele links. Hypermedia is belangrijk omdat machines niet zo gemakkelijk als mensen manieren vinden om wel tot dat product te komen. Voor een machine moet men een Web API maken zodat deze gemakkelijk met de data overweg kan. In de praktijk bevatten representaties voor machines vaak geen hypermedia controls, hierdoor moetzen ze strikt geprogrammeerd worden met vaste adressen. 18
REST bestaat dus uit 3 componenten: Resources: zonder constraints en dit zijn adressen. Acties: met constraints en dit is bv. GET, POST,... Representaties: met constraints en dit si bv. JSON, HTML,... Met hypermedia op het web bedoelt men de simultane presentatie van informatie en controls. De representatie moet dit dus ondersteunen, maar het is niet persé nodig dat info en controls met elkaar verweven zijn, er moet enkel simultane toegang zijn. De affordance tussen dingen stelt hoe duidelijk het is dat je een actie kan ondernemen met iets. Sommige voorstellingen hebben een slechte affordance waarbij het niet duidelijk is welke acties je kan ondernemen met de data. Er zijn 3 types van machine clients: 1. Web browsers: bestuurd door mensen en toont hypermedia en verbetert de browsing ervaring afhankelijk van de content en representatie. 2. API client: een softwaretoepassing. 3. Autonome agent: kan met meerdere API s interageren en complexe taken uitvoeren zonder daarvoor expliciet te zijn geprogrammeerd. 5 Metadata en semantiek 5.1 Metadata Er is een overload aan informatie en om informatie te filteren is er nood aan metadata, de vele multimediabestanden vereisen ook metadata. Vroeger was metadata data over data waardoor men makkelijk con categoriseren, zoeken, browsen,... en het was een onderdeel van de eigenlijke informatie. Vandaag is metadata gestandaardiseerde en gestructureerde informatie die automatische processen kunnen sturen en er zijn verschillende types metadata: identificatie beschrijvend annotaties technisch... allemaal met als doel de gevonden data te begrijpen meer dan enkel en alleen te lokaliseren. In de toekomst wil men intertwingularity of het kristalliseren van informatie. Men wil kennis over de content uitdrukken en het zoeken naar informatie wordt het bevragen van kennis. Dit heeft semantische interoperabiliteit als doel wat wil zeggen dat er een medium is waarin zowel mensen als software bij het verwerken van data en content tot dezelfde conclusies kunnen komen, men genereert dus kennis. Metadata wordt gebruikt voor het begrijpen, delen, management, zoeken, verwerken, presenteren,... van content. Een taxonomie is een classificatie waarvan de structuur op voorhand is bepaald. Het is een hiërarchie met gecontroleerde woordenlijsten, thesauri, opgesteld door experts. In het begin was er enkel een classificatie voor diersoorten, maar nu zijn er voor heel veel dingen classificaties. Dit 19
is een top-down aanpak. Een tag is een annotatie is een vrije tekst en het zijn sleutelwoorde die persoonlijk en informeel zijn. Waar vroeger taxonomieën of woordenlijsten werden geruikt om content te beschrijven worden nu tags of folksonomieën gebruikt die door de gebruikers worden gevormd. In een folksonomie zit geen voorafgedefinieerde structuur en/of hiërarchie en de gebruikers voegen samen metadata toe. Alle termen zijn dus evenwaardig en er wordt bottom-up gewerkt. Je hebt zowel brede en smalle folksonomieën. Het probleem met folksonomieën is dat er culturele verschillen zijn waarbij mensen data anders interpreteren, er zijn taalproblemen, er is ambiguiteit, spellingsfouten. Er kunnen subjectieve tags zijn, persoonlijke tags,... Er is een overvloed aan metadatastandaarden naar analogie met de vele multimediastandaarden. Er zijn ook standaarden die de structuur van metadata vastleggen: MODS of Medadata Object Description Schema. Dit is een XML bestand die volgens een vaste manier gestructureerd is. XML of extensible Markup Language is door de W3C gestandaardieseerd en het is een taal die de structuur van een document vastlegt. Een XML schema wordt gebruikt om de structuur van een document te beschrijven en zegt: Welke elementen er mogen voorkomen. In welke volgorde de elementen mogen voorkomen. Welke types/waarden er mogen in staan. MODS is een XML schema waarbij een textuele specificatie de semantiek van de elementen bepaalt. Het voordeel van XML is dat zowel mensen als machines de documenten kunnen lezen ben begrijpen. Men bekomt dus gedeelde informatie voorgesteld in een algemene structuur. De huidige metadatastandaarden bepalen de structuur van de data en er zijn verschillende standaarden in één systeem waardoor er mappingen nodig zijn. Een standaard lost nog niet alles op omdat er soms nog dezelfde problemen zijn als bij tags. Zo kan men een creator property op meerdere manieren invullen. Het is moeilijk om de semantiek van metadata te beschrijven aangezien dit uit pure tekst bestaat en niet verstaanbaar is voor machines. Ook is de huidige metadata voor multimedia nog niet goed te begrijpen, twee verschillende standaarden kunnen hetzelfde beschrijven maar op een totaal verschillende manier. We moeten dus onderscheid maken tussen: Het huidige web is bijna uitsluitend syntactisch opgebouwd. 5.2 Semantiek toevoegen aan data Syntax - bepaalt de representatie van metadata - XML+XML schema zorgt voor interoperabiliteit m.b.t. correctheid - XML is de facto standaard Semantiek - bepaalt de betekenis van metadata elementen - gesloten beschrijving zorgt voor interoperabiliteit m.b.t. disambiguïteit XML bevat dus geen semantiek en enkel syntax, de oplossing zijn semantische web technieken: Gebruik van RDF, RDF Schema, OWL,... Er zijn ontologieën in plaats van XML schema s 20
Een ontologie is een formele representatie van een verzameling concepten binnen een domein en de relatie tussen deze concepten. Het wordt gebruikt om te redeneren over eigenschappen in dat domein en het kan gebruikt worden om dat domein te definiëren. Het bevat de volgende concepten: Individuals (Instances) Classes (Concepts) Attributes Relations Functions Constraints Het bestaat uit triples zoals <note, hasauthor, Tim> die we in een graaf kunnen voorstellen. Het is essentieel dat er van URI s gebruik wordt gemaakt. Deze URI s wijzen naar een object en geven een unieke identificatie. De bedoeling is nu om meerdere bestaande data te linken en zo een enorme kennis te vergaren. Het Open Linked Data princiepe is een standaard procedure om domain ontologieën op het web te publiceren via HTTP, URI en RDF. Het is een robuuste en elegante manier om kennis te koppelen. 5.3 Het semantisch web Om een semantisch web te maken moet de beschikbare informatie begrijpbaar zijn voor machines op een ondubbelzinnige manier. Het moet gemakkelijk zijn om de informatie te combineren en uit te wisselen. We willen dus een web van data (semantisch web) in plaats van een web van documenten (syntactisch web). Dit moet in het huidige web kunnen worden geïntegreerd. Informatie moet conceptueel worden voorgesteld door middel van gerichte grafen, dit wordt in de praktijk door RDF gerealiseerd. De structuur van het semantisch web bestaat dus uit 3 lagen: De abstracte graafrepresentatie is onafhankelijk van de bestaande dataformaten en een verandering aan het schema van een lokale database breekt niets. Nieuwe informatie en connecties kunnen op een triviale manier aangebracht worden. Het semantisch web zorgt er dus voor dat niet alleen mensen het web begrijpen maar ook machines, de bezieler is weer Tim Berners-Lee. Deze metadata kan in de XHTML code worden verweven. Alles gaat dus om betekenisvolle representatie van data en traditionele technieken gaa nuit van een gecentraliseerd database systeem waarin alles staat. Dit is echter niet schaalbaar en staat haaks op het gedecentraliseerde web. 21